The state machine governs all of the behavior and decision making that an NPC is capable of. Each different enemy has a unique implementation of the states themselves, but all NPCs (friendly and enemy) use the same organization of states, which is detailed below:
The Sleep State
This is the state that all enemies default to when created (spawned by the PCG algorithm, outlined above). This state does nothing on each update, not even play an idle animation. As a sleeping enemy is either out of sight of the player or too far away to have any meaningful gameplay impact, it should be occupying as few system resources as possible. This state will transition into the Awake state when the player gets close enough to the NPC that he would be able to see it. Note that this “wake up” distance is large enough that it would be impossible for a player to actually sneak by an encounter. The primary goal of this state is to minimize the system resources an NPC that is, say halfway across the map uses. Since this NPC is far enough away to both be imperceptible (as he is being blocked by buildings and the like) and no action it can take will ever impact the game world for the player, we do not even animate them, as even that takes up unnecessary CPU time.
The Awake State
The Awake state is represents an NPC which is near enough to the player that he can be seen. By default the Awake state tells the NPC to play its idle animation. If the NPC gets close
shift into the Attack State. If the NPC gets sufficiently far enough away from the player, it will transition back into the Sleep State. Where enemy NPCs just stand around waiting while in this state, allied zombies will move towards the Hospital at the end of the level, until they either shift into the attack or sleep states.
The Attack State
The Attack State is where most of the interesting things happen. The majority of the time, an NPC will exist in the Chase sub-state, as they try to get close enough to the player (or zombie) to attack them. Civilians are the exception to this as they, being helpless and unable to defend themselves, instead flee from the player (or zombie).
The Chase Sub-State
This sub-state is the default sub-state of the Attack State (in other words, it is the state that is automatically entered when the NPC enters the Attack State). It moves the NPC closer to its target (player or zombie for enemies, or enemies for allied zombies) until it is within the attack range for that specific NPC (different for melee and ranged NPCs), at which time it will shift into the Shoot or Melee sub-state (depending on if it is a ranged or melee NPC
respectively).
The Shoot or Melee Sub-State
This sub-state is actually a blip-state, meaning an NPC is only in this state for exactly one update at a time, before shifting back into whatever state it was in previously. This simple state is responsible for the actual attacking that an NPC does. For example, an enemy will play its attack animation, roll to see if it hits its target, send a message to its target letting it know if it has been hit (if it scored a hit on its to-hit roll) and play any sounds associated with the attack. Lastly, this state tells the state machine to transition back into whatever state it was in before entering this state (typically the chase state).
The Flee Sub-State
This state replaces the chase state for the Civilian enemies, and does basically the opposite of what the chase state does. Instead of trying to close the gap between the NPC and its target, the Flee Sub-State instead tries to run away from the closest target (player or
zombie). This sub-state does not take pathing into account, and as such an enemy can run straight into a building, trapping themselves in their blind panic.
The Dead State
The dead state is transitioned into from any other state when an NPC’s health is reduced to 0 or below. It plays the NPCs death animation and logs the time of death of the NPC. After a certain amount of time has passed, the Dead State destroys the NPC’s game object, freeing up the memory for use. This delay between death and freeing the allocated resources is
intentional as it allows the corpse of the NPC to exist within the world for a short duration before being removed, which not only is aesthetically pleasing (things do not just disappear when they die) but also allows the corpse to continue to impede movement for a short while, making battles more dynamic.
The Zombify State
The Zombify State is the last state an NPC can be put into. It is the state which an NPC enters if it receives a message from the player saying it has been bitten. This state is
responsible for immediately destroying the NPC’s game object (unlike the Dead State, which lets the corpse exist for a little while before destroying it) and creating an allied zombie in place of the now-dead NPC.
Playtesting
During the final term of our project, we began playtesting. Our playtesting meetings were conducted once a week in the lab. Each week, 1 to 4 volunteers were brought into the lab
to test our game. These testers were allowed to test only once, so as to not bias our future test results. Before the testers began playing, we informed them that we were not allowed to talk to them during play, but they were allowed to play aloud. Each player’s visible reactions and speech were recorded for review. Whichever one of us was overseeing the playtester was responsible for noting their observations, what comments the player made while playing, if they got stuck and where (and how they got “unstuck”), were there points where they looked visually frustrated, did they pay special attention to particular aspects of the game, as well as anything else we might have noticed during the playtest (for example, a bug the player missed or if a particular enemy wasn’t behaving as intended). At the end of their playthrough, each player was given a review form and a bug report form. The review form consisted of various questions concerning gameplay, such as time to play and enemy difficulty. The bug report form allowed the user to report any freezes or crashes that occurred in the game. If any crash or freeze was reported, we asked the player if they could consistently reproduce the error for future diagnosis.