Releasing My First Game - Drunk Chicken

I just completed designing and coding my first ever game, Drunk Chicken. It was an exciting process! So I decided to document it here to share with you all.

Can you beat Drunk Chicken? I will say, it looks easy but it gets pretty chaotic after the snakes start appearing. But what are your thoughts? I would love to hear them. Hope you enjoy! :)

Description: Drunk Chicken is a single-user Unity3D game published for WebGL. The inspiration for the game came from my own family’s chicken farm, which also happens to be right across the street from a bar. After deciding that I was going to build a game from start to finish by myself, I combined these two brainstormed ideas. Thus, Drunk Chicken was born.

Year: 2020

Role: During this project I was the sole designer, developer, and creator. It was a fantastic learning experience, taking about 8 weeks to complete.

Getting Started: Before beginning development, it was necessary to break the game into manageable steps. This meant first creating a Project Design Document containing the project timeline, project draft sketch, and overall project concept (this was broken down into player controls, basic gameplay, sound & effects, gameplay mechanics, user interface, and other bonus features). Link to Project Design Document here.

Project Concept: The player controls a chicken in an isometric game where the arrow keys control movement. During the game, the player must collect wine bottles from the platform. These bottles increase with each level. The goal of the game is to grab all the wine bottles while avoiding the foxes. There are sound effects when wine bottles are collected, when the player gains or loses a life, when a power-up is collected, and when the player destroys an enemy fox. There are particle effects when a player collides with a fox, picks up a life, loses a life, or powers-up. As the game progresses, an increasing number of enemies are added for each level, making it challenging to collect all the wine bottles. The User Interface includes a count of lives, bottles, and current level. Additionally, the User Interface includes a title screen, and game over/restart screen. The game is over when the player’s lives reach zero or they fall off the edge of the platform.

Project Timeline: Drunk Chicken took 8 weeks to complete. Due to health complications and surgery, the project was delayed. Each week I set a milestone focusing on a single sub-category of the overall project concept. 

Project Draft Sketch:  

Challenges

Throughout Drunk Chicken I encountered various challenges which I’ll describe here. These include:

• Level transition optimization. After my first test run with users, I realized that it was hard to distinguish an advancement to the next level. Characters would increasingly spawn, but the UI indicators were small and there were no pauses in player movement between each level. To fix this, I needed to add a flash of text indicating each level that would appear on the player screen for a couple seconds. During this flash, the player should not be able to move, nor should the enemies be able to attack the player. The challenge here was that the function to advance to the next level was inside of the SpawnManager script Update() method. This presented a problem with my first attempt at the problem because when I tried to create a coroutine to delay player movement and enemy spawning, the coroutine would run every frame. Thus, spawning hundreds of enemies. The reason I was using Update() to increment each level was so that I could find the moment when all the collectibles were grabbed by the player using FindGameObjectsWithTag().Length. I realized after my first failed attempt that I would have to try a different approach. I would have to reorganize my code so that I wasn’t using Update(). So my second attempt involved moving the level incrementation method to the GameManager script and calling the coroutine from there. Instead of polling every frame with FindGameObjectsWithTag().Length (which is much more costly since a depth-first search amongst all GameObjects in the scene is done every time), I changed my code to poll and decrement from the total amount of collectibles of each level only when a collectible was destroyed.
• Enemy spawning on top of the player. While testing in “Play Mode” I would find that enemies would spawn on top of the player or on top of each other, which ruined the player experience. To fix this, I first added a bouncy PhysicsMaterial to each GameObject so that way if they collided it would have a slight bounce instead of flying off the screen. Second, I calculated the difference between each enemy position and the player position and origin and had the enemy position be recalculated if it fell within the starting safe zone.
• Fixing character movement. To clearly communicate the movement of the chicken and fox GameObjects to the player, it was necessary to get the characters to turn and face the direction they were walking in. To fix this, I created a new 3D Vector consisting of the horizontal and vertical GameObject movement input, created a Quaternion rotation using this 3D Vector and applied it to the GameObject rotation and translated movements. Additionally, when GameObjects collide they would create rotations on the X and Z axes so the GameObjects would have bizarre character movements or would fall over and get stuck. To fix this, I turned off the rotation on the X and Z axes within Unity.
• Silent collectibles. To provide user feedback, I set up a sound to play whenever a collectible GameObject was destroyed. However, while testing the code in “Play Mode” the sound wouldn’t play. The key to this fix was to have the audio clip play at player position and not at the collectible position because after it would get destroyed the sound wouldn’t have a position to attach too, and therefore, wouldn’t play. 
• Enemies falling through the floor. After replacing the primitive GameObjects throughout the scene, I would enter “Play Mode” in Unity and find that my enemy GameObjects would fall through the platform. I was also trying to program the Player script so that when the player and enemy would touch the enemy would be destroyed. My enemies had been set up with only Rigidbodies and “Is Trigger” enabled. I realized I needed to change my collision behavior between player and enemy within the script to OnCollisionEnter instead of OnTriggerEnter, add Colliders to the enemy GameObjects, turn off “Is Trigger”, and check to see that gravity is turned on for the Rigidbody component. 
• Broken Restart button. After the player receives the Game Over screen, the Restart button would appear to give players the quick option to play again. Despite looking throughout my code over and over, I couldn’t find any errors. I later figured out that I needed to go into the Unity Inspector of the Restart Button UI element and add the GameManager GameObject from the hierarchy, into the On Click () window of the Button (Script) component. This way, the button would know what method to run when clicked.

Lessons Learned

There were many lessons to be learned throughout the process of this project. These include:

• Organizing the code. Creating a project with different characters, functionality, etc. starts off as very overwhelming at first. It gets confusing knowing where to start. So I learned to break down the project into smaller steps and create weekly milestones, as described in my Project Design Document. This breakdown was also helpful in organizing the architecture of the code classes and functions. I kept in mind that methods should be simple and focus on one task. Doing this also helped prevent code from getting messy or confusing to read. I was thankful for this structure after I had to come back to chunks of code weeks after writing them. Define, refine, and organize!
• Game design. After my first draft of the project was complete, I had some friends test out the game. As I watched them play, I realized that the game had a few flaws. First, it didn’t clearly indicate to the users its purpose. The fix for this was to introduce game elements (such as the powerup and the life icons) incrementally to the users, so they could have time to decipher their meaning without being overwhelmed by the amount of elements they saw on screen. Second, the distinction between levels wasn’t obvious. Players would pass on to the next level, and not realize it. To fix this, I slowed down the pace of the game. I created text that flashes with each new level achieved and momentarily suspended enemy spawning and user activity. This allowed the new levels to register with the users more clearly.
• Increased my Unity and C# knowledge. 
• Timeline. While deconstructing the project concept, I learned to schedule my milestones into manageable, achievable goals while still including some reach goals. This pushed my project to completion.
• Function, then art. When constructing my project, I learned it was best to start with primitive objects when creating a playable prototype, rather than adding in all your assets in the beginning. This was helpful because I found the development process easier when I first focused on functionality and making the game playable. Additionally, assets could easily need changing later on in the development process, so this saves time.
• Performance. Drunk Chicken requires hundreds of prefabs to be instantiated during a single run of the game. Overtime, these GameObjects drastically impact the performance and user experience of the game. To fix this, I programmed the prefabs to be destroyed once they fell off the platform, thus, preventing them from accumulating. 

Future Improvements

After completing the design, development, testing of Drunk Chicken, I’ve taken the time to reflect on where the game has opportunity for improvements. These include:

• The snake enemy GameObject does not properly move across the game platform. It partly sinks below it so I would perfect this.
• The grass plane does not sit perfectly on top of the game platform. 
• Add additional bonus items to make the game more versatile.
• This was an improvement implemented after a user test. I realized the game UI was too small to read during my first iteration, so I increased the font size and fixed the alignment to provide a better user experience.

Most Interesting

I had a ton of fun making Drunk Chicken. I enjoyed multiple portions of the learning, designing, and developing process. These include:

• I most enjoyed learning about the different particle system settings and creating distinct particle systems for each of my prefabs. For the powerup particle in particular, I had to place an invisible sphere with a straight shooting particle effect attached and then create an animation that would rotate the sphere so that when the animation played fast enough the particle appeared to be swirling. (I wanted to see if I could replicate this effect without creating an additional Gameobject, after drastically increasing the emission of the particles, adding a trail, and changing the shape to a code with an arc that loops I was able to achieve this effect).
• Learning the ins and outs of creating a game from start to finish. I found it to be a good challenge, thinking about all aspects of the game. I also had a blast playing around with sound effects and visuals such as the prefab meshes. All the assets look cohesive, and as a bonus they save on computing power since they’re all low poly.