Week 2's task for TDEMO was to make a game that played using only one button press, similar to Flappy Bird or Cookie Clicker, but we weren't allowed to use the mouse. Having no experience with either Unity or Unreal, I would have to learn one engine from scratch, and decided to go with Unity. To learn the basics, I watched this video (https://www.youtube.com/watch?v=pwZpJzpE2lQ&ab_channel=Imphenzia) to try and understand how Unity worked.
Unfortunately, I didn't realize Unity used C# as opposed to C++ so I would have to quickly learn to code in C# as well. After following the tutorial for the best part of 2 hours I had managed to make a very basic platformer with the player being able to control the character's forward and backwards movement, as well as being able to jump. I was also able to make the camera move with the character.
However, this did not really help me figure out how to create a game that would be controlled by one button, though I now understood the absolute basics of creating a model and prefabs and writing C# code to make the model move. In the end, I decided to make something simple and go with a 3D autoscroller - the idea being you would press space to make your character jump - not unlike Flappy Bird. While not original in the slightest, at my current skill level it is the best I can do for now.
I was able to create the scenes and the character by simply creating 3D boxes and then scaling them to my preferred size. By enabling Rigidbody on the character (a standard square box) and freezing the rotation, I ensured that it wouldn't start rolling when it jumped.
With the stage set, I needed to work out how to make the game autoscroll as the only planned user input was to control the jumps. I solved this by giving the character a set amount of force on the Z-axis when the game first starts and periodically adding force via FixedUpdate. I use FixedUpdate rather than simply Update as I am using Time.deltaTime to time my periodic boosts.
private void Start()
{
rb.AddForce(0, 0, 500);
}
void FixedUpdate()
{
rb.AddForce(0, 0, 500 * Time.deltaTime);
}After playtesting and finding the game more difficult than it should have been, I realized that the cube I was using as the player-controlled model was actually too large and therefore obstructing the view of some of the obstacles on the course, artificially inflating the difficulty. I solved this by scaling the player cube down so the player could see more of the course.
However, this made me look for other ways to ensure a clear line of slight of the course at all times. I therefore researched how other autoscrolling games managed to maintain this aspect. For 2D games like specific Mario levels, this was easily done as the player could see all obstacles on the screen at any given time, whereas for 3D games like Octagon, the obstacles were kept short enough that the player's camera angle was capable of keeping them all in sight. Neither of these examples would work for my game, however, since the idea was to jump to avoid obstacles rather than go around them like Octagon handles their game. I therefore decided to make the prefabs of my obstacles semi-transparent in order to implement visibility of the level. With this change, the game became easier to manage.
Level 1 of my game goes as follows:
I decided to turn the mesh of the goal off because it could potentially obstruct the player's view of the obstacles. Level 1 was intentionally made so that the player could clear it without having to jump more than once mid-air, while Level 2 was designed so the player had to jump mid-air to clear the level (show not tell). As a way to prevent players from just mashing Space and sticking to the skybox (also made transparent - even with shadows removed I felt it detracted from the appearance of the game), Level 3 had one obstacle the length of the skybox on the ceiling.
An issue I found while alpha testing the game was that the velocity of the player would be kept upon collision/respawning as opposed to being reset to 0, leading to some respawns having much faster scroll speed than expected. I theorized that this issue was due to the respawn aspect of the code not altering the force upon the player object, meaning that if the player did not fully collide with an object (collision turning the force on the object to 0) and instead just brushed against it, it would not halt the player object. Currently, I do not know how to fix this issue.
After ensuring the functionality of the game, I wanted to work on other aspects of the game - namely a simple menu so the player isn't thrown into the game immediately. To do this, I made a new scene and created a UI Canvas, a Background and two Buttons. By simply linking the buttons to code that told the scene to change upon being clicked, I made a transition to the first level from the main menu. However, I ran into issues with the background image not rendering in-game, instead only showing the buttons and a black background.
This was somehow caused by having the background and the prefab material being both loaded at the same time; removing the prefab material fixed this issue (credits to Ricky for helping solve this).
Next, I wanted to make a simple GUI that indicated what level the player was currently on. By setting a new UI text box and putting the following code in a new script:
public Text txt;
void Update()
{
txt.text = SceneManager.GetActiveScene().name;
}I was able to create and code the textbox that tells the player what level they are on. When the scene changes to the next level, so does the text in the UI.
Another thing I wanted to implement as QoL was a transition between levels - namely a quick, 1-2 second fadeout before loading the next level. To do this, I needed to create a new Panel under the Canvas hierarchy, add textboxes, then animate the fading in of the panel itself by adjusting the transparency of the panel + textboxes. Finally, I had to disable it on the Inspector, then write code that re-enabled it upon the player's collision with the goal hitbox.
void OnTriggerEnter(Collider other)
{
completeGameUI.SetActive(true);
}I gave the game to a two of my friends to act as beta testers, with the context that it was a 1-button game. The first commented that the level design forcing them to multijump was a success, and requested a pause button. The second mentioned that the variable speeds of the player object was frustrating, and also asked that a death counter be added to record the failures of the player. He also said that while the instant respawn was useful in preventing frustration, a quick respawn animation would make the game look more polished. This concept is also seen in Celeste, where the game punishes you less harshly by not making large rooms and ensuring the player can retry levels very quickly with a short death animation.
I attempted to code in a death counter which would track the player's deaths across all 5 levels and show the total number on the end screen, but was unsuccessful in enabling the total number to be stored. However, I managed to make the counter track deaths for each level individually.
Overall this project taught me how to use Unity and C# on a basic level (as evidenced by the unpolished style and the semi-functioning code). For a complete beginner on both, I feel that I have managed to create a respectable project, and that I have managed my time adequately, though not perfectly. If given another opportunity to continue work, my goals would be to fix the current issues of movement speed and continuous death counter, as well as add a pause button and create more levels, including moving obstacles.