Destructor
Programmer
2nd Place in the Unity Developer Community Game Jam 2020
The UDC game jam 2020 had the theme of “You are the Weapon”. For this we decided to create a 2D platformer with a central dash mechanic, where the player character could dash forward angrily bashing walls and enemies aside. For this project we used Unity with C# scripting to build the game. I worked alongside Niamh Loughran (Artist/Production) [LinkedIn Link] and Ross Stewart (Designer/Coder) [LinkedIn Link]
Play the game on Itch.io or download the unity project!
Features worked on:
Grid Snapping Tools
We decided early on that the art for the game would be pixel art, based in 12x12 pixel cells, taking inspiration from Super Metroid and other games like it. I recognised the need for a “"Mario Maker” grid snapping system so that art assets could be brought in, and artists and producers could build, place and rearrange assets as needed without manually lining assets up for the tile based look.
C# code to visualise the snapping grid
The grid in engine (Very faintly)
Code and maths to calculate where a position should be snapped to. This was run for each child, grandchild etc under a master_grid game object. This also meant objects that needed to be outside the snapping environment (Eg the player) could be easily sorted and filed elsewhere.
Dash Mechanic
The main mechanic of the game was a dash the player could perform to break through doors, or enemies. When breaking through an enemy the player would get an extra boost of height, allowing them to perform another dash, either into another enemy or onto safe higher ground.
The basic movement of the player was adapted from an existing code piece (Brackeys, 2018, github.com/Brackeys/2D-Character-Controller), several additional features were added. Firstly and most simply, cleaning up of the code and inspector elements for the use of other team members. Variables were split into specific setting groups making it very clear what changed and edited what.
Next other function were added to implement the dash mechanic itself, and other desired behaviours. The dash move was done through the use of rigidbody constraints, forces, and coroutines.
Firstly, if the dash button was pressed and the player wasn’t already dashing, and could dash based on the dash limit, an is_dashing bool was set to true. This called a looped coroutine which A) Checked if an inspector set distance had been reached from the original dash position, ending the dash. If this wasnt true, B) Applied an inspector set x-axis force to the rigidbody2D, every fixedUpdate cycle using Yield Return New WaitForFixedUpdate(). Fixed Update was important here since using Yield Return Null, essentially waiting for the next frame, would be extremely inconsistent due to the differences in frame times, meaning the coroutine looped a different amount each dash, meaning different amounts of force would be applied each time the player dashed.
Rigidbody constaints were also used to lock the player objects Y position during a dash. Unity rigidbodies need to be set all at once. For example, setting the constraints to freezeY, will unfreeze any other active constraints (eg freezeX or freezeRotation). This led to many odd behaviours, such as the character spinning slowly and being locked to a Y value even after the dash had concluded. After learning a bitwise OR operator was needed to be used in order to set multiple at once, this issue was solved.
Unity Animators
Once art and various poses were produced for the player and other objects, unity animator trees were used to implement transitions between these, based on certain boolean values set within scripts. An example of the player tree can be seen here, and the code used to set it.
