Week 6 - 2D games - Movement, Projectiles and UI elements
With this week came the conclusion of our 2D games project, where the team focused on player movements and logic to make the game playable, including things such as keeping score, pausing the game, adding a number of lives to the UI and firing projectiles in order to be able to kill enemies, each of which will be covered in this post.
Keeping score and number of lives:
This was accomplished using a simple UI overlay to the game and setting it on a layer that was drawn after the rest of the game objects, with basic collision logic for the projectile so that if it kills an enemy then a score is increased by x, and collision logic for is a player runs into an enemy. The projectile is spawned at an offset to the player's current location, which is also rotated with the player is running in the opposite direction, to ensure that a projectile always follows the forward direction of the game object it is attached to.
An example of this is as follows:
Pausing the Game:
Pausing the game is a simple matter of making a script that sets the timescale of the scene to 0 and adding it to a game object. In addition to this a layer of text that is default hidden that says "paused" was added to the canvas that is shown when the timescale is set to 0 and hidden again when timescale is put back to 1.
Player Movement and Inputs:
Player movements and input caused the biggest issues for the group because of a large bug involving the misuse of a Singleton as a sound manager. The bug meant that one of the player sprites was destroyed immediately on loading the scene because a Sound Manager singleton was added to both game sprites, so when the second sprite was loaded, the first sound manager was destroyed along with the playable character it was attached to, but once this was fixed (after a very long time taken to identify the issue) it was fairly simple to map keys to player movements. The singleton issue is shown in the following image, along with how keys were mapped using the Unity inputs.
Ending and Resetting the Game:
Ending the game was simple. Using the same logic as pausing the game, with a bool to declare that the game has ended, we were able to set up an input to reset the game. This was done manually, as reloading the scene caused a lot of issues with the sprites of the player and enemies. This was done as follows:
Keeping score and number of lives:
This was accomplished using a simple UI overlay to the game and setting it on a layer that was drawn after the rest of the game objects, with basic collision logic for the projectile so that if it kills an enemy then a score is increased by x, and collision logic for is a player runs into an enemy. The projectile is spawned at an offset to the player's current location, which is also rotated with the player is running in the opposite direction, to ensure that a projectile always follows the forward direction of the game object it is attached to.
An example of this is as follows:
Pausing the Game:
Pausing the game is a simple matter of making a script that sets the timescale of the scene to 0 and adding it to a game object. In addition to this a layer of text that is default hidden that says "paused" was added to the canvas that is shown when the timescale is set to 0 and hidden again when timescale is put back to 1.
Player Movement and Inputs:
Player movements and input caused the biggest issues for the group because of a large bug involving the misuse of a Singleton as a sound manager. The bug meant that one of the player sprites was destroyed immediately on loading the scene because a Sound Manager singleton was added to both game sprites, so when the second sprite was loaded, the first sound manager was destroyed along with the playable character it was attached to, but once this was fixed (after a very long time taken to identify the issue) it was fairly simple to map keys to player movements. The singleton issue is shown in the following image, along with how keys were mapped using the Unity inputs.
Ending and Resetting the Game:
Ending the game was simple. Using the same logic as pausing the game, with a bool to declare that the game has ended, we were able to set up an input to reset the game. This was done manually, as reloading the scene caused a lot of issues with the sprites of the player and enemies. This was done as follows:
One thing that the group worked on during this week that turned out to be very successful (once bugs were identified and fixed) was a singleton class that manages all sounds within the scene, which can be accessed by any game object that wishes to trigger a sound, instead of adding audio sources and audio clips to many different game objects. This seemed like a far more efficient way of adding sound to a 2D game where the screen is always centered and the source location of the sound is not relevant. All of the scripts for the work this week can be found on GitHub through the following link: https://github.com/KAdams01/2DUnityJazzRabbit
Additional notes: Another issue with inputs this week was that the logic for having one player was vastly different from having two, so the first attempt at copying and pasting player one but changing the sprite failed horrible. Logic such as what the projectiles can hit and the previously mentioned sound manager issue took a while to solve.
Comments
Post a Comment