GMTK Game Jam 2022 - Semi-AutoCHROMAtic

A screenshot from a 3D first-person shooter game. The player is looking down at some green terrain with threes on it. On the terrain are some enemies, each with a different colour and health bar of a matching colour. At the bottom of the screen, a die with 5 hearts on it can be seen. In the bottom left of the image is a hand with a die embedded in it. Next to this hand are a net of a cube with even numbers of cyan, yellow, and magenta faces, and below this are four slots for ammo. One slot has a magenta circle, two have cyan circles, and one has a yellow circle. In the bottom right of the image is a second hand holding a floating octahedron with faces showing all three colours together. Next to this hand are a net of an octahedron with two cyan faces and two yellow faces, and below this are four more slots, two of which show yellow circles and two of which show cyan circles. In the centre of the image is a triangular reticule.

Semi-AutoCHROMAtic is the first submission that I’ve ever made for a game jam. It was made for the GMTK Game Jam 2022, a 48 hour game jam hosted in July 2022 with the theme Roll of the Dice. This project was the first time that I’ve ever used the Unity game engine or the C# programming language before, and so some of the time was spent getting used to those technologies.

For this project, I teamed up with Profile photo for Ruby Ruby, Profile photo for Skyao Skyao, and Profile photo for Takanu Takanu to create a first-person shooter where the ammo that you have access to is randomly chosen from the sides of a six-sided die with cyan, yellow, and magenta faces. Each of the enemies has a health bar of a specific colour. Ammo of a matching colour will instantly kill an enemy, whereas mismatched ammo will deal a small amount of damage instead. There are also dice that can be picked up and which act as secondary weapons, with a D4 being a shotgun, a D6 being a standard gun but with different distributions of colours, a D8 being a multi-coloured gun, and a D20 being a cluster bomb. Secondary weapons have limited ammo based on the number of sides of the die that was picked up (i.e. 4 shots for a D4) with the exception of the D20 which fires once and then splits into 20 fragments.

Concept art showing ideas for the cyan enemy, yellow enemy, magenta enemy, and a combined cyan/yellow enemy with a two heads and a green body. Ideas for the faces of the dice can be seen, with the cyan die having two horizontal lines, the yellow die having a single vertical line, and the magenta die having a circle. The game logo can be seen in the top right.

Concept art by Skyao for the enemies, including two-headed enemies which would have had multiple health bars

The roles in the project were split such that Skyao and Ruby worked on art-focused tasks (concept art, texturing, modelling, rigging, and animating), Takanu worked on environmental art and level design, and I worked on mechanics and various programming tasks. Since the player movement was handled by Unity’s First Person Character Controller starter asset, the main parts of the project that I contributed to were:

  • Weapons
    I started the project by working on the weapon systems, and I spent the majority of the time with them.
    There are two types of weapons. The first is guns, which cast rays from the player’s camera (straight forwards in all cases except for the D4 shotgun, which for each shot randomly chooses a direction between +10° and -10° horizontally and vertically). The second is the D20 cluster bomb, which summons a projectile that falls towards the ground, and then summons 20 fragment projectiles to deal damage to enemies in a small radius.
    The visual aspect of the shots uses Unity’s Line Renderer components, with the colour determined by the ammo type that was fired. The visual aspect of the D20 projectiles uses a Trail Renderer in order to show the trajectories.
    Upcoming ammo types for both primary and secondary weapons are queued (with primary weapons using a Queue<AmmoType>, and secondary weapons using a List<AmmoType> with an index that passes through the list as shots are used). Though the primary weapon continuously replenishes itself with random ammo types, the secondary weapons choose one of a fixed set of ammo types (e.g. a D6 might have 2 of each colour, or might have 4 of one colour and 1 of each of the remaining colours). This was going to be linked to the texture of the die that the player picked up, but our time ran out before we could implement this.
  • Enemy AI
    The enemy AI is relatively basic, with enemies trying to perform the first action that applies:

    • If not in range of the player, do nothing.
    • If in range of the player but not looking at the player, turn towards the player.
    • If in range of the player and looking at the player, move towards the player.

    Though basic, this works quite well for our game. Each enemy’s ability to attack the player runs separately to their movement, only constrained by their distance to the player and the time since their last attack.
    Originally, the enemy movement routines didn’t quite work as expected, with bugs including but not limited to:

    • Enemies ignoring obstacle collisions
    • Enemies clipping into the ground because they were trying to target the player’s feet
    • Enemies strafing in circles around the player
    • And enemies running away from the player at great speed

    Eventually, the movement system was implemented using a Character Controller component and the SimpleMove method, which automatically accounts for collisions with terrain and obstactles, as well as automatically applying gravity. If I had the ability to improve something about the enemy AI, I would add an acceleration curve to the enemy movement so that they don’t immediately start sprinting towards the player at full speed.

  • UI
    The UI was designed by Skyao and was implemented using Unity’s UI system.
    In the editor, we positioned images where we wanted them ahead of time. Then, during gameplay, the images are swapped with different textures/shown/hidden based on the state of the game, such as whether the player has a secondary weapon. One exception is the 3D model of the health die, which Ruby set up to automatically rotate based on a health parameter. We were going to add a similar animation to the die in the player’s left hand, but ran out of time.
    If I had the ability to improve something about the UI system, I would look into better ways of showing the secondary weapon nets. The current method requires a lot of duplicated boilerplate code, and so I would have liked to refactor it to reduce repeated functionality.
Concept art showing ideas for the cyan enemy, magenta enemy, and a combined cyan/yellow enemy with a two heads and a green body. The final project's UI layout can be seen, with two hands in the bottom corners, upcoming ammo types, 3D shape nets, and a health die shown. The game logo can be seen in the top right.

Concept art by Skyao for the UI, closely matching the final implementation

In the week after submission, our game was played by about 44 people, and ranked by 24 people. Our rankings were:

Criteria Rank (of 6,149 games) Score (of 5)
Creativity #2,610 2.917
Enjoyment #4,425 1.958
Presentation #3,676 2.417
Overall #3,621 2.431

Overall, I want to give a massive thank you to Ruby, Skyao, and Takanu. I had an absolutely brilliant weekend working on this project, and although there are a couple of bugs and things I’d have wanted to touch up slightly given more time, I think that we can be really proud of the game we made.

videogame_asset Play publicWebsite

Written by Profile photo for James Cordon James Cordon | First published: | Last updated:
Link to this page: