Assignment 3A

Assignment 3A - Devlogs

Beginning to work through the week 2 content, various design and development processes were considered for my game. Elements thought to be found useful were game loops, which included call back methods to update frames, implementing game objects and utilising scripts for the game. In the first instance, the functioning of the race car was to ensure basic functions. These included accelerate, turn left, turn right and brake. With the help of the Unity tutorials (Lewis, 2024b), the #PlayerMovement script that was gathered for Invaderoids because it aligned with the concept of the racing game. During modifications to the script, to achieve a more ‘car-like’ feel, changes to the magnitude and friction were implemented. This was demonstrated in a tutorial with Lewis (2024a).  

To implement week 3’s content to my game, involvement of 2D graphics and input were considered. 2D graphics as seen in the concept devlog, were imported to improve visual expectations. A paint .png of the Monaco grand prix circuit was imported. Unfortunately, the blue race car that was submitted in the concept devlog was not able to save as an individual .png file originally from the Canva server. To overcome this hurdle, another picture was found from a Google search (Zhitnaya, n.d.).

Once it was imported to Unity, I spent a lengthy amount of time using the Sprite Editor to outline the object, removing as much of the whitespace possible. Doing this has made the object look more practical for game play.

In addition, the importance of components are vital in the smooth running of the game. Rigidbody2D, Sprite Renderer and a collider (I used polygon collider) enables stable control of the Driver. Collision detection with walls and other Comp (competitors) would be enabled to reduce player health and warn the player of potential restart functionality. From previous feedback, checkpoints would be beneficial to implement rather than restarting the entire game.

Minimal animations were considered. These included particle animations for any collision as well as, exhaust smoke if accelerating/GetKey ‘w’ and tyre markings for sudden braking. A spritesheet of exhaust smoke was custom made using Paint. The Sprite Editor was utilised to create a sprite animation. Additional animations like spectator movement were considered to illuminate an event-like atmosphere.

Input keys are the typical ‘w’ ‘a’ ‘s’ ‘d’ as well as, the arrowed keys – this is seen in #PlayerMovement.

Game behaviour as it was seen in week 4 AI behaviours to mimic a competitor would be implemented. The goal is to copy the movability of the Driver then apply steering and A* path finding code to mimic other drivers. It would be interesting to enable a DRS function if the coding capabilities allow for it. The rule is, if a driver is behind the next car within 1 second, DRS can be enabled to gain speed and safely overtake. Once the overtake was successful, DRS for that driver will be disabled. Likewise for the Driver who has been overtaken, if they are now within 1 second of the driver in front, they are allowed to use the DRS function after 3 seconds of being overtaken. This function would be available to all drivers. Unfortunately, the game is not yet ready for testing as I do require more time practicing basic scripting. I am currently in progress, and I do plan to produce the points I have discussed. It would be optional to include DRS in this game if it is not too out of my capabilities. As per previous feedback, invisible checkpoints would need to be researched to implement to enhance user experience. This would be like Mario Kart in the sense that Driver health is now at ‘0’, therefore the Driver would have to restart at the previous checkpoint to allow for the disadvantage.