Gum Drop
Role: Gameplay Programmer
Team size: Solo
Time Frame: 2 weeks
Engine: Unity (C#)
Github: https://github.com/DylanMather2004/My-Mobile-Game
Role: Gameplay Programmer
Team size: Solo
Time Frame: 2 weeks
Engine: Unity (C#)
Github: https://github.com/DylanMather2004/My-Mobile-Game
Gum Drop is a simple arcade-style dropper game created for android using Unity with the Android SDK. The game was developed over 2 weeks during a term break from University.
Whilst currently kept as a private project, I am now debating releasing the project on the Google Play Store.
Gum Drop was my first game built for mobile platforms. The project introduced me to mobile gaming fundamentals such as touch input and saving data to android devices. It was also my first project that made use of the New Unity Input System, which introduced me to events, callbacks and more efficient input reading methods as opposed to checking input each frame. The result was a much more performant game, which was crucial for a game that was developed for less performance intensive devices such as mobile phones.
My game called for a simplistic control scheme, requiring only tap inputs by the player. As such, creating the Input Actions necessary was relatively simple. The action type was set to button and the path was set to touchscreen press. In order to test this in Unity, I would need to use the device simulator, which allowed me to use my mouse to virtually test the input without having to build the game and run it on my device or an emulator, thus allowing me for faster testing of mechanics.
in the scene I created an input manager object that stored the InputManger Component. This component allowed me to assign delegate functions to inputs. In this case, I bound the Touch Action to the OnJump function from the player script.
Gum Drop's character, Gummy, will automatically move left and right whilst on the ground. The player can tap to make him jump, and once in-air, tap again to send him crashing down to break the pink platforms. Breaking these platforms will net the player points, and breaking multiple platforms in a row, would apply a multiplier to the player's score. Be careful however, as breaking too many platforms will send you straight into the spike pit, so you must weigh up the risk to go for extra points.
The Player Movement Script features a method for jumping that takes a callback context, which can be used by the Input Manager to bind inputs to the method. This method then applies a jump force if the player is on the ground, or enables the drilling boolean, which speeds up the player in update and allows pink platforms to be broken in the OnCollisionEnter method.
I also used a physics raycast as a ground checker. This allowed me to implement some leeway when receiving jump input. This would improve the player experience as slightly early inputs would still trigger a jump, which felt more responsive to the players that tested my game.
My Game Manager script was responsible for handling game states and saving scores using JSON serialization. When the player dies, their score is taken by the game manager and checked against their current high score. If the new score is higher, it is saved as the new high score.
The Save Score function checks if there is an existing filepath, and if there is, it will add the new score to that filepath, and if not, it will create a new file and save the score to it.
The Load Score function checks if the file is present, and if so, it will load the value stored there onto a local variable, to be checked when the next score is received.
These methods use the C# System.IO Extension, which allows for reading/writing to external files on a device using the StreamReader and StreamWriter classes.
The game manager also features an End-Condition Checker, which checks if the player is still present in the active hierarchy. This method is quite inefficient however, and I would instead opt for a method call on the player, which occurs when it collides with the spikes, as opposed to checking it's status in the hierarchy every frame.
I used the Unity Animator Controller Module, which allowed me to handle animations in script by setting the current player animation for the action performed.
In the original script, this was a check that was performed every frame, however, I could use an Enum to create a simple switch case state machine to handle animations instead of using if statements every frame.
This project was a good introduction into the fundamentals of mobile game development, whilst also working to teach me about the principles of mobile game design, prioritizing simplistic mechanics that are easy to grasp for the casual gamer. I learned how to develop mobile applications in Unity using the device simulator to process virtual touch input, that was implemented using the New Unity Input System, as opposed to hard-coded input reading.