Analyzing and Reconstructing a First Person Shooter

Last semester, I worked on a solo mission to create a first person shooter game titled 'Blitzfire'. In this blog, rather than focusing on the product, I wanted to instead take a step back and analyze the process and the thought behind it, to see if it could yield any general insights on game systems and the design process.

THE STARTING POINT - Blitzfire was built based on the concept of orthogonal unit differentiation. For more details regarding this design concept, I highly reccomend the following GDC talk. The game features two NPC classes orthogonally differentiated on a few axes.

WEAPONS - The player has at his disposal two different weapons that map to specific use cases in the possibility space.

 

The weapons were constructed in the possibility space to author the following mindset:

• Pistols potentially take longer to kill enemies.
• Shotguns place the player at danger of receiving damage.

The gameplay pattern a combination of these two weapons produces should in theory be as follows :

• Players use pistols so long as the health of the enemies is low, or when risk of receiving damage when getting close to enemies is high.
• ​Players use shotguns in positions where there is lowered risk of of receiving damage, or enemy health is high.

ENEMIES - The NPC classes are constructed in a manner that mirrors the weapon design in the possibility space. 

The soldier is an extension of what makes the pistol effective, i.e. an enemy that has low health and low damage potential but can deal damage instantly. The commando is an extension of what makes the shotgun effective, i.e. an enemy with high health and high potential but fires projectiles that can be dodged. In doing so we create a space to effectively author a level where players are actively prioritizing waves of enemies instead of randomly firing.

INSIGHT #1 - If you look at levels and the overall design of first person shooters available in the market today, you would be hard pressed to identify this sort of a design thought process in their construction. They mostly rely on a high bar of production quality to elicit engagement rather than nuanced mechanics. So here is possible a rather bold statement :

"There is an inverse relationship between engagement through gameplay and the requirement for high production value". 

This does not mean that high production value is not valuable to games. Simply that the more the depth in the game's mechanics, the more the production effort can be oriented towards creating theme through narrative, characters and environment design rather than bearing the weight of engaging the player in level design. Think about the difference between Doom and COD.

So I'm going to steal Jesse Schell's idea of creating different lens' that designers can peer through. If I'm stealing Jesse's ideas I may as well steal his phrase as well - "So here's a lens for you"!

LENS OF ENGAGEMENT QUOTIENT : In a level you're designing, are you trying to engage your player through fancy effects and linear events occurring in the level? Or is the engagement coming from an interplay between the game's mechanics.

DATA BALANCE AND GAME MECHANICS - Now back to Blitzfire. Without getting into specifics, and ignoring other variables, we have two properties that must be inversely proportional to one another to create a balanced system: Enemy spawn rate and Enemy Health.

Similarly we could construct a graph of hitscan to projectile damage on the x axis, damage dealt by attack on the y axis and introduce different enemy types in the balanced zone created there. However, that doesn't make for a particularly interesting system. Where it becomes interesting is where and how additional game mechanics can be added.

INSIGHT #2 - "Game mechanics add value when they exist outside of a balanced game system, thereby offseting balance zone."

For example, if we were to tune spawn rate and enemy health in a manner such that they lie in the enemy advantage zone, we would necessitate an additional mechanic that restores this advantage to the player. Consider a feature that staggers enemies.

This type of a feature would shift the data balance zone offsetting the enemy advantage.

LENS OF MECHANICS PURPOSE: Consider the mechanics set of your game. If you were to remove a given mechanic, how would the game play differently? Is the mechanic altering the nature of your game flow? If the answer is not at all, then what purpose is the mechanic serving? Do you need it?

A BASIC TEST - With this system a very basic level was constructed in order to test whether the system in and off itself was potentially engaging. The enemy patrol routes were as described below.

 

In general, commando's needed to advance on the player faster than soldiers to force the player to make quick decisions and maneuver him/her around the space. The result was absolute chaos :

• The pistol was rendered useless as every point in space had an equal probability of receiving damage.
• Strategy was impossible to conceive as there was no breathing space to pause and consider enemies.
• The stagger feature was a complete failure as it was impossible to ascertain the duration of neutralized fire.

Why did this system fail. Was it because of the level? Not really, the level design element here was so minimal that it can be safely ignored. Was it data balance? Not really, it wasn't that the game was too hard or easy. It was just that it didn't elicit the type of player behavior we were seeking, i.e., to be making prioritization choices on enemies and weapons.

INSIGHT #3 - "There exists a minimum threshold of complexity, both in level design and game mechanic set to elicit particular player strategies."

In this case, the missing game mechanic was a system to defend. Defense was important to elicit the player behavior described because it allows the player to press pause and assess the situation.

LENS OF GAME COMPLEXITY : Kind of converse to the lens of mechanics purpose. When you're trying to make a level work by eliciting a particular player behavior, consider if the game has all the necessary components to be creating the effect before trying to balance data or shuffle your level.

THE MATRIX TEST - But how do we assess what type of cover mechanism we need? Is there potentially a test we could conduct to add this new mechanic intelligibly rather than based on instinct. What if we wanted more than one defense mechanism? How do we identify what type of mechanism would suit a given situation? Two different defense mechanisms were considered :

Crouch Based Cover

Time Based Forcefield

The idea behind the test was that in observing the elicited player behavior when these elements were used in isolation, we would be able to use them more appropriately when combined in levels. 4 playtests were conducted with permutations of the two weapons with the two defense mechanisms. The results were fascinating:

Using the results from this test I was able to draw concrete observations and takeways that were later used in level design.

LENS OF MATRIX TEST : Before combining different game mechanics, try testing them in isolation to see the player behavior it elicits standalone. This will give you insights on the mechanics which will allow you to combine these mechanics more intelligently.