Nathaniel Baird

4/20/2016

Untitled Zombie Game Write-Up

While working on TRIAD my inexperience with Unity, Blender and C# caused me to

spend more time troubleshooting problems than I would have liked. Additionally my approach to

the construction of the game was inefficient. For example, I spent too much time modeling and

animating the player’s weapon. Ideally such endeavors occur only after a working prototype of

the game is finished. After working on TRIAD, then, I wanted to practice efficiency. The goal

was to create a working prototype over the course of a single weekend. I would use only one

level and spawn increasingly threatening zombies in waves. As the player’s kill count increases

he would be rewarded with more devastating weaponry. The spawn locations of the zombies and

weapons (as well as the specific types of weapons) would be randomly determined. Finally, if

the player were unlucky enough the lights in the game would go out for a single zombie wave,

causing considerable tension. My hope was that both efficient use of time and effective use of

random number generators would result in an unpredictable and replayable experience.

The project’s main success was that I managed to hold myself to my goal concerning

efficiency. I completed all of the necessary tasks (modeling, rigging, animating, designing,

coding and sound editing) in a couple of days. Because of how efficiently I spent my time I was

able to attend more closely to the game elements which I deemed problematic during testing

periods. For example, I was provided with more opportunities to tweak the weapon balance and

the map layout. Early on I recognized that the pistol which the player begins with was far too

powerful due to its rate of fire and accuracy. I chose to solve this problem by giving the weapon

(and various other weapons) a degree of inaccuracy. This change, which I had not considered

previously, helped give many of the weapons a unique personality. I also found that it was too

easy for the player to backpedal around the arena, eventually causing the zombies to clump up in

one big pile, resulting in the tedious experience of shooting ineffectual bullets into the endless,

slow-moving pile of zombie flesh. To alleviate this problem I constructed level geometry aimed

at trapping a player too focused on backpedaling. A narrow alleyway cuts the map in two and

forces the player to either avoid it and occupy a fraction of the game space or pass through it,

risking the possibility of becoming trapped by zombies entering from the other side. I found that

a conservative use of time (utilizing the most basic weapon models and avoiding weapon

animations all together) allowed me to attend to core gameplay related problems and their

solutions.

The unpredictable nature of the game provides it a considerable degree of replayability,

especially considering that the level geometry never changes throughout the experience. There is

a tension in hoping that certain weapons spawn. The experience of climbing up a tower’s

walkways to see which weapon has spawned in is engaging, particularly when the player has

been relying on a rather ineffective weapon up till that moment. The game does not encourage

players to remain stationed on one single building for their entire playthrough. Not only do the

semi-randomized spawn locations force the player to maneuver about the map, but some of most

entertaining moments occur when a player must abandon their temporary fortress as the zombie

hoard streams up its pathways.

I believe that the zombie sound effects turned out well enough given the low amount of

time I spent on them. Most of their groans are merely ordinary yells and screams pitched down in

Audacity. An exception I am particularly proud of, however, is the zombie’s head explosion

sound effect. I used a recording of a man biting into a cabbage and adjusted its pitch and speed to

render its sound heavier and shorten its duration. I then combined the result with the noise of a

popping plastic clamp to provide the clip with a crisp initiation. The result is a convincing head

shot sound clip!

Despite accomplishing the goals listed above the final product suffers from numerous

issues. Those relate to the ways in which certain weapons function, the weapon spawning

system, the player’s movement and how failure is presented to the player.

One significant problem with the game is that some of its weapons are underpowered or

boring. Although adding varying degrees of inaccuracy to the weapons had an overall positive

influence on the game the addition introduces problems of its own. One problem is the weapons

begin and remain at their peak inaccuracy, meaning that the first shot fired from the pistol is as

inaccurate as the fifth. While others tested the game I noticed that after firing a few shots at

distant targets they determined (falsely) that their weapon had a limited range. An easy fix to this

problem would be to gradually increase the inaccuracy of weapons as they are fired in quick

succession. Such a feature would also increase the skill required to play the game, as players

would need to learn to fire the weapons in different patterns rather than clicking the left mouse

button as fast as possible.

Another issue with two of the weapons in particular is their firing rate. The slingshot and

the flintlock pistol are the two slowest firing weapons in the game. The slingshot at least is

interesting to use; it is the only weapon in the game which fires projectiles visible to the player.

Although the slingshot is perfectly accurate (shots land in the same place every time) its

projectiles gradually lose altitude. The player is rewarded for achieving headshots with the

slingshot as it does tremendous damage. Body shots, on the other hand, are ineffectual, thus the

slingshot is a weapon that is difficult to master but capable of dealing extreme damage.

Unfortunately it fires so slowly that even a well practiced sling shot user cannot hope to pick off

enough zombies before they pose a serious threat. The slingshot is a weapon that is begging for a

slightly more complicated set of mechanics governing the gunplay. Enforcing a limited amount

of ammo for the other weapons or implementing a system which provides the player more points

for using more difficult weaponry could increase its viability. The flintlock pistol is nearly as

ineffective though not nearly as much fun. Its gimmick is that it packs an enormous punch while

sporting terrible accuracy. The weapon will at best cause the player to crack a brief smile once he

recognizes how terrible the weapon is. Here is where the game’s randomness detracts from the

overall experience. It can be frustrating for the player (particularly on repeat playthroughs) to be

provided these less than optimal tools by the game solely because he is not lucky enough to

obtain more effective ones. I established the weapon spawn system such that at later waves

higher tier weapons have a chance of spawning in the game. What I did not do (but should have

done) was add a cut-off point at which lower tier weapons had no chance whatever of spawning

in place of the more desirable high tier alternatives. Had I done this some excitement regarding

which tools are provided to the player would be preserved while ensuring that the player loses

the game due to his own failures rather than due to sheer chance.

A further problem which persists both here and in TRIAD concerns the player’s

movement. The player movement script I wrote ensures that the player’s forward direction is the

direction which the camera is facing in. This means that when the player stares at the floor while

trying to move forward he will be completely stuck! This issue was less noticeable in TRIAD but

is far more apparent here. That is because there are many occasions in which a player must

abandon a piece of level geometry by walking off of it and falling to the floor. But if the player

tries to look toward where they might land it is likely that they will find their character

completely paralyzed, as though he is afraid of heights! I immediately realized the problem when

a zombie killed me because this. The solution is simple; one must ensure that the camera and the

body of the player are sufficiently distinct from one another. When a player rotates his camera

the player’s body must match the rotation solely on the y-axis. The body then remains facing

parallel to the ground at all times.

Finally, the game lacks resolution. When a zombie is close enough to the player the game

is jarringly restarted immediately. In tests some players were not even sure whether or not they

had failed. Sometimes players were not convinced a zombie had touched them at all since they

were not provided any evidence that that had occurred. I see two obvious ways of polishing up

this issue. One would be to add a sound effect (perhaps the sound of a zombie eagerly opening

its saliva-filled mouth) that signals that a zombie is closing in on the player. This would alert the

player to a zombie sneaking up from behind (and would increase the tension of the circumstance

significantly). It would also be worth while adding a death cinematic so that the player is

punished for failure in a recognizable way. Such a cinematic might involve a zombie grabbing

the player’s character and engulfing the entire camera, for example.