Documentation - Post-Mortem

Comparison of Final Result to Concept Document

            The general concept statement of my game has not changed in the slightest since its conception. The player still collects supplies and kills zombies in the day to protect their house from any zombies that are left at night. Genre-wise, it is still a survival game, but the core concept has drifted away from other games from the genre, bearing very little resemblance to Plants vs Zombies, Minecraft, or Terraria. Out of the survival games I am familiar with, it is still most similar to Don’t Starve with the heavy emphasis on day and night and the more of a foraging and collecting style than Minecraft's farming, for example.

            The audience of Zombie Forager has changed very slightly. I thought originally it might be a game aimed at children, like Plants vs Zombies but I now believe it would be not only too difficult, but maybe also not up-beat enough to be considered as such. The moody artwork and music has morphed the game into something a little more serious, although there is still a very ‘cute’ undertone to it all. I previously said in my Game Concept Document that,

• “[Zombie Forager is] aimed at serious apocalypse and survival game lovers who want something light-hearted to play on a lazy afternoon. I can see this game also attracting casual gamers who want a dip into an apocalypse world but do not want the time investment.”

This is still quite true of my game as the core mechanics are still very much an easy-to-learn, hard-to-master, casual, apocalypse-survival game at heart.

            The backstory of my game is basically the same, but I also like the idea of adding that the other parent of the family was a hunter with a bow and arrow, but they died in the apocalypse already, and now this parent is tasked with using their equipment to save the kids. However, in the actual game, there is not yet a way to find this information out. I did plan to possibly include a skippable opening cutscene but found it would not be the best use of my time, considering also that results in the feedback forms on whether this should be included are mixed and inconclusive, which I will discuss more later.

            In my concept document I outlined which features would be important base features that would make up the minimum playable product and completed them relatively early on in development. I also managed to complete features such as basic procedural generation and some zombie AI using ray-casting, as well as an auto-aiming feature for the bow and arrow that also used ray-casting.  However, I have not included additional environment animations, a happiness system for the player’s family, or any story-based content.

           The procedural generation turned out very differently that what I originally imagined, but it works far better than my other ideas. The whole concept is a grid of circular spawning areas in which a tree spawns, as well as:

• Probably a random zombie of the three types (becomes definite in later levels)
• Probably one random food of the three types
• (Unlikely) Either a glow-shroom or a bone
• Probably a bundle of short sticks or a long stick

Apart from zombies (and trees), all spawns become scarcer at higher levels.

           I also made zombie AI even more simple than was planned. They now move toward the player if it is daytime as long as the player is in range and not obscured by a tree trunk. At night, they move toward the house from any distance unless they are in range of a shroom-torch which they will move toward instead.

           Additionally, I simplified the automatic aiming to not consider the direction the player is facing and to just shoot the closest zombie in range not obstructed by a tree. It works but is not quite as skill-based as the original would have been, so I may change this in future. It could work quite well if I could do an ‘overlap cone’ instead of an overlap circle in unity.

            The concept art is where I made the biggest changes, which was something I expected all along, but not quite to this extent. After receiving the first designs from the artist I was working with, Harry Sussams, I went about changing all my art designs, from making all the colours darker and less saturated, to making the item pickups smaller and removing their black outlines. I also had to change my ideas for zombies I would use. The only zombie sprites I managed to find online were either too big (size is very important with pixel art) or had black outlines. I could not afford for Harry to make more sprites, so I tried to make them myself. They somewhat stand out as not being as detailed or realistic as the rest of the art, but most testers (discussed later) did not find them to be overly distracting. The layout of the forest and the UI are very similar to the original. I found I did not require a ‘time of day scale’ in the end, as the uncertainty of the length of day added to the player's fear and the fading light communicated that there were only a few seconds left before night adequately. I had finished most of the game before the testing session and felt I had adequate time to make better UI art, so that is something included in the final product as well.

            Finally, something that was not explicitly stated, but was implied, in the concept document was that the gameplay scene would be continuous through each level. However, I found this difficult to achieve, so the scene is reloaded when the player levels up and, for now, the player also loses all collected items.

Feedback Summary

Note: The formatting here is the best I could do with Itch, the extra 5 and 7 are frustrating to me too, and although I used letters for the indented points, saving the post changes it to numbers. 

1. Difficulty: the first three questions were about the difficulty of the game
   1. How confusing were the controls? The responses were an almost even split between ‘took a while to get used to it’ and ‘instantly understood what to do.’
   2. How confusing was the gameplay loop? The responses were very evenly spread throughout the confusion level options, though I am confident many people did not read the gameplay loop section of the description before starting the game.
   3. How difficult did you find the game? More than half of the testers found they could easily beat the first level without being bored from it being too easy.
   4. Overall, the difficulty seemed to be relatively balanced and the controls straightforward, but I did add a tutorial level to remove some confusion about the gameplay loop.
   5.  
2. Fun: Many of the questions were about how much the players enjoyed the game, each coming at it from a different angle.
   1. Did you play more than one level? Only one tester played three levels while all other testers played one or less.
   2. Why did you stop playing? This is where the problems with the UI that I was not aware of before the testing session start effecting the results. Many players died before the end of the first level due to not being able to eat food as the inventory was off the screen. After this, players would understandably give up. Players who did have the ability to finish the first level mostly felt they did not have time to play another level, but one did become bored.
   3. Would you play the game again when the player art is finished, and I’ve incorporated all the feedback? 100% 'Yes' responses.
   4. Would you recommend this game to any of your friends? Why or why not? Not everyone responded to this question, but for those who did, the consensus is that they would not share it in its current state, which makes sense given the UI challenges and some missing art and visual effects.
   5. Is there anything you think needs to be added or removed to make the game more fun? Three responses had interesting suggestions while one mentioned the UI again.
   6. As is easy to see, the takeaway here was mostly just to fix the UI. However, most people could imagine themselves having fun with the game when it is finished, which I think is a good, though not definite, sign that I am on the right track. I was able to get some input about the need for more communication about enemy health which was quite helpful, allowing me to incorporate health bars.
   7.  
3. Art, music, story: at this stage I had not completed the sound effects, nor added the character animations, but I used three questions to gauge testers’ responses to the art and music. I also had an additional question asking whether the game needs more story elements.
   1. What did you think of the zombie art? Most testers thought it was cute and funny, and no one thought it was awful, at least not to the point of redoing it all.
   2. What did you think of the environment art? There was a 50/50 split between ‘immersive and professional’ and ‘cute and funny’ with one tester-added positive response – overall every response was a very positive reaction.
   3. What did you think of the music? Most thought the music was really good, but more than one tester felt it did not really fit the game. However, it is hard to say whether this was due to the problem with the music being far too loud on itch.io as this was a major response mentioned verbally in the session.
   4. Do you think the game would benefit from a skippable heartfelt backstory to set up the world and characters at the start of the game? The response for this question was exactly 50/50, with the majority of the responses on ‘maybe’ and an even split between ‘yes’ and ‘no.’ I do not think I will have time to add more story elements, but maybe in future updates of the game.
   5. After reading these responses I did not feel the need to change anything, fundamentally, but I did reduce the volume of all the music by 50% as many recommended. I also added sound effects and player animations. I balanced the sound effects with the music at 50% volume.  
4. General Impressions: I used three more questions to ask about players’ general impressions of the game.

1. What did you like most about the game? Out of the six responses I received, most people liked the art and the gameplay loop the most, which told me my game was headed in the right direction and would be even better with the main character animated and the lighting completed.
2. What did you like least about the game? Three of five responses were about the UI not working, and the others were confused about the arrow mechanics and auto-crafting.
3. On a scale of 1 to 10, how do you think the average person would rate my game? This was a bit of a throw-away question. I was surprised that all responses were above 5.
4. This section was very helpful in telling me that I was on the right track with original art and the game play loop and telling me I needed more communication about arrow shooting mechanics and auto-crafting which I incorporated through on-screen text.

Asset List

Animations: This folder contains all the animations and animation controllers for the player and three types of zombies. The zombies each have four directions of running animations and an idle animation which is a single frame. The player has four directions of running, four directions of idle, eight directions of drawing the bow, eight directions of running while the bow is drawn, eight directions of shooting the bow, and eight directions of standing still while the bow is drawn.

Audio: This folder contains all the audio assets I used, all of which I made specifically for this project. They include:

• One loopable footsteps sound
• Approximately 2 and a half minutes of ‘daytime music’
• An audio clip played when the game over screen appears
• 40 seconds of loopable main menu music
• About two minutes of ‘night time music’
• Two ‘zombie attack’ sounds – one of the two is chosen randomly for each attack
• Four ‘arrow shooting’ sounds – one of the four is chosen randomly for each shot

Prefabs: This folder contains all the prefabs I made for this game. Some were necessary for the game to function while others just made my life easier when I wanted to reuse a similar object in another scene. The prefabs include:

• Nine items that can be used by the player, with varying functions
• Three different types of zombies with varying health, speed, and attack damage
• A player prefab so I could put a controllable and animated player on the title screen
•  A tree, spawned throughout the forest, that turns transparent when you walk behind it and blocks line of sight of zombies
• Three zombie health point prefabs to make it easier to add them to each zombie instead of remaking them five times
• A load scene button, customisable by just typing in the scene name on the script and changing the button text, very useful for quickly creating UI
• A spawner prefab, which I placed in a grid formation throughout the level, the prefab allowed me to edit all the spawners at the same time without worrying about missing any
• A ‘spawner spawner’ which I planned to use to randomly place the spawners throughout the level, but it was far too random, and I liked the evenly spaced spawners instead

Scenes: This folder contains the five scenes I created for this project:

• Main Menu
• Game Over
• Next Level
• Sample Scene - the default empty scene name in which I put most of the game
• Tutorial Scene 1 - numbered because I thought I would split the tutorial into several scenes but did not

Scripts: This folder contains every single script I used for the game. It was previously unorganised because I rarely use the folder to access scripts, preferring to go through the game objects they are on, so some of the folders may not make perfect sense. There are forty-six scripts in total, as I like to separate every function into very small pieces.

•  Environment Scripts
  • Lighting and day/night behaviour: DayNightCycle, TurnOffAtDay, TurnOnAtDay
  • Trees, House, Shroom-Torch: HouseHealth, sortScript, TransparentHouse, TransparentTree, PullZombie
  • Spawn: Spawning, SpawnSpawners, DestroyIfTooClose
  • Manage Music
• Inventory Scripts
  • EatItem
  • PlaceItem
  • DestroyAndDamageOnCollision
• Player Scripts
  • EightWayMovement
  • RayThrSixty – a strange script that is accessed by the shooting script and does not do a three-sixty-degree ray-cast array anymore
  • Shooting
  • HealthAndHungerManager
  •  Inventory – basically a dictionary that also detects item pickups
• Score Scripts – just three scripts that keep and display scores
• Tutorial Scripts – four scripts that display tutorial messages at specific times, some of which replace original scripts
• UI Scripts
  • CameraFollow, SyncPosition – keeps camera and green pullback bar in place
  • Nine scripts that allow the UI text and numbers to synchronise with other scripts
  • TargetIndicator – controls the white arrow that points toward the player’s house
  • LoadScene, WaitBeforeLoadScene
• Zombie Scripts
  •  Attack
  • Three health point scripts for each of the health point prefabs (ie. Health point two destroys itself if zombie health is below two)
  • ZombieHealth
  • ZombieMovement – this script changes the direction of movement depending on day or night and whether it can see the player or a shroom torch and uses ray-casting to do so.

Sprites: There are a lot of sprites in this folder, mostly because I noticed a lot of mistakes in my artwork and had to redo it.

•  Zombies: Each zombie has two sprite sheets because I thought I could flip one of the directions in Unity, but it proved a bit too difficult.
• Player: The player has one big sprite sheet. I hired a pixel artist, Harry Sussams to make all the animations for the player character for the game. (Harry Sussams, 2022)
• Environment and Items: There is one sprite sheet for this, but due to some sizing issues I split two of the sprites into different files
• House: The house sprite and separate lit windows for night
• UI: The inventory buttons (multiple versions), Health and energy bars (recoloured and resized throughout the HUD), White Rectangles for bar fills and backgrounds, Indicator Arrow (home direction and low energy), Zombie Health Icons

TextMesh Pro: I used ‘TextMesh Pro’ for all the UI in this project, this is a folder of all the assets that come with that.

Font: I downloaded the font used for this project some time ago. It is called Electronic Highway Sign and can be found for free online. I used a bold version. (Ash Pikachu Font, 2011)

References:

Ash Pikachu Font, Electronic Highway Sign, 2011, Digital Font, N/A, https://www.dafont.com/electronic-highway-sign.font

Harry Sussams, Character Design, 2022, Digital Pixel Art Animations, United Kingdom, https://www.harrysussams.com/pixel-art