Week 1: Stealth Game Genre Mechanics

Looking at other stealth games and deciding on what problem I should address

Many of my favourite games belong to the stealth genre. I will be taking a few of these games and analysing what makes these games unique in the stealth genre.

What makes Metal Gear Solid game a Metal Gear Solid game

The Metal Gear Solid series has evolved over time so I will be talking about the games as "generations" and what I mean by that is how the series approached stealth in terms of their mechanics.

The first generation would consist of the first 2 metal gear solid games. They both approach stealth with cover mechanics. The player would have to advance to the next areas avoiding guards using the actual environment as cover. The player could press themselves against walls and peek past corners, or crawl through tight spaces. The player also had access to tools that would help them through the level, such as the iconic cardboard box, or the chaff grenade that could disable electronics, although many of these tools were used to advance in the level, and not necessarily help with stealth, such as the mine detector for the minefield, or the night vision goggles for the cave. MGS2 changed it up a bit. More actions were added in such as hanging from ledges and swimming. More items were also added in to help with stealth, such as empty magazines, which the player could throw to distract an enemy, or the book which compelled enemies to read them.

The second generation would be MGS3 and MGS4. MGS3 introduced the camo index mechanic. Players would use camouflage to blend in with the environment in order to hide in plain sight. This system was revamped in MGS4 with the Octocamo suit, enabling players to change camouflage on the fly without having to go through menus. MGS3 also introduced the stamina bar for the player, that would need to be replenished with food. Players could also get injured or sick and would need to use items in order to treat the injuries or suffer their negative effects, so while infiltration is still a focus of the game, there is also a survival aspect added in.

The last generation would be MGS5. One of the big things they had to adapt for was the open world aspect of the game, so they designed the outposts so that they could be infiltrated in different ways. This also played into the customisation aspect that gave players a decision on how they would approach an outpost with the equipment they brought on missions. At the same time though, this took away from the "procure on site" aspect of the previous games. Instead of finding new and exciting items, you would be tasked with finding the blueprints for those items and then spending in game currency and time to research them in mother base. They also added a system where enemies would adapt to your most used tactics. If you infiltrated at night a lot, enemies would be equipped with night vision goggles or flashlights. If you commonly used gas attacks, you would find more enemies equipped with gas masks.

What about Hitman?

Hitman takes a different approach to stealth than Metal Gear Solid. Instead of using cover to avoid enemies (which is still an approach), the player instead uses disguises in order to hide in plain sight, waiting for an opportunity to advance in the level in order to eventually eliminate the designated target. The challenge comes from not doing suspicious actions that might compromise your disguise such as being discovered in a place the player should not be in, or getting too close to somebody who might recognise that you are not the person you pretend to be.

The levels in hitman games are designed for replay value. There is no one answer to taking out your target during a mission. The paths that the player can take in the newer hitman games are essentially determined by what equipment they have taken with them. Perhaps the player would like to go through some kind of locked door, and want to be more discreet so they take the lockpick with them. The customisation of what items the player will take with them on a mission essentially gives the player planning capabilities.

Stealthy approaches have also been encouraged and even rewarded since Hitman 2: Silent Assassin (2002). The less alerts and non-targets killed, the better the rating the player achieved and, if they achieved the silent assassin rating, they would receive new or better guns. In the newer hitman games, stealthy approaches are still rewarded. The stealthier the approach, the higher the score the player receives. Challenges were also added as optional objectives to reward players with certain level privileges and new weapons and items.

How Dishonoured differs from Metal Gear Solid

Dishonoured approaches stealth in a very similar way to MGS where the player would avoid enemies using cover, except it differs from MGS because there is a level of verticality that is involved. Like Metal Gear Solid, the player has access to many tools that can help them with stealth. These tools are a little different from the MGS series however. The player has magical abilities which they can upgrade. They use a different mana as a type of consumable which is universally used for all those abilities. the other consumable tools are equipment. They have their own unique consumables for each piece of equipment.

The game also had a system where the playstyle of the player impacted the game. If you played lethally, it might be easier to quickly dispatch guards, however the levels to come became more diseased. You would see more rats and weepers, and it would also affect the ending of the game.

What are the similarities between these games?

One of the biggest similarities of these games are the enemy states of awareness. Each of these games has at least 3 states of awareness. The first state is being undetected. It means the player has not made an error, therefore enemies are unaware of the player's presence. The second presence is the alert state. This is the state where enemies are hostile to the player. The last state is a suspicion state. Some of these games have more than one suspicion state, which means that the enemy is somewhat aware of you, but how much depends on the level of the state. In MGS2, if you are in view of the enemy, but outside of their cone of vision, they can see you in the distance, and will investigate to see who is there. Enemies can also find bodies if the player doesn't hide them, in which case they will go into a caution state.

Another similarity between the games are the methods in which enemies will detect the player. This can range from sight mechanics to footsteps mechanics. Static "guards" like security cameras are commonplace in these games. You also tend to see a lot of traps and obstacles that the player has to overcome.

Another similarity between these games are the tools they offer the player to help with stealth. They also tend to give the player combat items to give them the option to fight back, though this is less than ideal most of the time.

Ideas for stealth mechanics

The problem I will be trying to address is the repetitive patterns that the player can recognise that removes some of the replay value of these games. You can play a level in any of these games in a different way, but the problem is all the environmental factors that make up the challenge of the level are the same, so after the player has played the level a couple of times, they know what to expect.

What if whilst you were playing the environment changed leaving the player to have to adapt to the change in the environment. You could have walls that moved to make rooms look different, or maybe you could have procedurally generated environments created from prefabs that join together like pieces of a puzzle, that way you never know what to expect. I program variances in the prefabs to give even more replay value, almost like a sort of layering of procedural generation.

Mechanic technical hypothesis

Many people on my course struggle to get their head around how to code a mechanic they have in their head, so this section breaks down my process of how I think when I want to code a mechanic. When I play games I like to guess how a mechanic works from a technical standpoint and this generally helps me with how to decide what to do first. It also allows me to use the technology and mathematics I am aware of in an adaptable way. I do this in a very similar way to how pseudocode works but in a more mental fashion. I usually use this alone for mechanics I can easily think about, but for complex mechanics I use this alongside pseudocode. This has also helped me plan out UML class diagrams because I can determine what variables and functions might be involved.

Lets take the enemy vision mechanic from Metal Gear Solid for example. First I have to break down how the mechanic works from a gameplay perspective i.e. you somehow happen to enter in an enemy's cone of vision and the enemy sees you. That's great! but we're not done yet. You have to also consider when this isn't necessarily true. If you are behind cover and enter the cone of vision, the enemy will not see you. If you are using a cardboard box, the enemy will also not see you. The more of the cases you are able to identify now, the less likely you are to run into problems when you identify them later (or sometimes not at all) when you start coding. Once you have considered this, you need to decide which of these cases are important to get the basic mechanic working. The cardboard box is something I would consider doing later, as it's an item, so I consider it related to the mechanic, but separate.

Now it's time to consider the technical aspects of the mechanic. To do this, I draw upon my knowledge of what technology is at my disposal. First I break down the components involved lets take a case from the last paragraph. "you somehow happen to enter in an enemy's cone of vision and the enemy sees you". I have identified 3 components. Its fairly obvious you are going to need a player character and an enemy AI character, and you've probably already considered these components from other prerequisite mechanics such as movement, so you might not need to put in too much thought with these two. The third component (the cone of vision) can be viewed as a subcomponent of the enemy since an enemy has a cone of vision, or you can view it as a separate component, I personally choose the former. Now you need to figure out how to create these components (you've probably already done this with the first two). For the cone of vision, I would personally create a trigger collider in the shape of a cone. Finally, I create conditions which can be created in code to determine if the player is seen or not. I keep these conditions the same throughout all mental test cases, and if they do not meet the desired outcome of one of them, then I have to alter my hypothesis. In this case, the condition will be if the player is in the trigger collider of the cone of vision.

Now I try and visualise in my head the cases, and run tests mentally to try to figure out if the technical hypothesis satisfies them.

I first think about the first case "you somehow happen to enter in an enemy's cone of vision and the enemy sees you." I will split this case into 2 parts, which are before entering and after entering the trigger collider. I visualise what is happening in game and then I visualise what would happen from a coding standpoint if these conditions were in an if statement.

From my current understanding, I don't see any problems

I then think about the second case "If you are behind cover and enter the cone of vision, the enemy will not see you" Again I split it into 2 parts, before and after entering the cone of vision.

Uh oh, looks like we've run into a problem. The condition only considers if you are in the area of the trigger collider, therefore it wont matter if you are behind cover or not.

Now you need to need to either amend your hypothesis or start again. If you cant figure out how to fix this issue, it may very well be that you have a gap in your technical or mathematical knowledge, in which case you will probably need to research this for yourself. Luckily, I know of a technology known as ray casting which can be used for several different applications. The idea is that you cast a virtual "ray" between one thing and another, and if that ray is intercepted by another object e.g. a wall, then it stops there. I simply need to add a conditional statement to say if that ray reaches the player from the enemy uninterrupted by other objects, then that conditional is met. Since I am adding in a second condition into the cases, I also need to consider what kind of logic gate I will be using. In this case I decide to use the logical AND operator, because I want both conditions to be true for the enemy to see the player.

Now that you have amended the technical hypothesis, you should re-run the cases again and see if the technical hypothesis satisfies them.

Congratulations! the hypothesis is sound. You will of course need to actually test that it actually does work once you have coded it, but the point is you've identified issues you could run into so that it won't bother you later.

I will of course be using this example for my own prototype, which I will eventually get round to coding.