GMTK Game Jam 2022 - Semi-AutoCHROMAtic

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 Ruby, Skyao, and 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 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 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:

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.