The Antigen Shift!

Use your microscopic space craft to stop viruses in this vampire survivors - esq arcade game. 

Match antibody-bomb shapes to their target viruses to survive as long as you can!

If things get tough out there, use your EMP and dash abilities to tip the infectious odds in your favour. 

Earn bonuses by defeating enough viruses without taking damage. But if damage should come your way, defeat viruses to fill up your cure meter to heal yourself. But beware! Every time you need to heal yourself, the next potential bonus will get slightly further out of reach, requiring more viruses defeated to be granted.  

Controls:

The Development Journey

Summary

For my third project, I wanted to do less of a deconstruction of a specific game I've played, and instead choose some mechanics as development goals, and then produce a small gameplay experience from there.

I started with the desire to allow the player to rotate a level with one hand, whilst platforming with the other. Each level was essentially a marble maze, except the marble was a playable character. Upon prototyping though, this idea quickly fell out of the scope of a smaller project from which I could learn many programming skills.

The idea was shelved in my notes, but I recycled the code used for rotating the level, for cycling though shapes. These shapes were originally platforms that a player could place as ways to access new areas in a 2D platforming game. Not wanting to spend time working on another platformer though, this shape cycling was finalized as being able to select different shaped bombs which would have to be matched to the different shaped enemies in the final game. 

Development of the bomb mechanic allowed the game to naturally grow into a survival based arcade game, with the goal being overall longest survival time. 

Skills Learnt and Developed

Unity Input System

My first main goal for this project was to acquaint myself with the newer unity input system. Through learning the basics of this system, I managed to develop a more abstract set of code that is applicable to both keyboard and controller inputs. Though my next project will delve deeper into this system, this prototype allowed me to become comfortable with the basics of elements such as input maps/actions, different input interactions and processors, and taking input from multiple sources. 

Events and abstraction

My last project introduced me to event based programming and the wealth of power that comes with it. This project allowed me to expend on this skillset, and develop an event driven game using both tightly coupled and highly abstract events where applicable. Events being triggered by elements such as players cycling though their available weapon shapes informed many moving parts within the game, such as UI updates and setting up the player's weapon with its own set of attributes based on the player's current selection. These goals would have been very difficult to achieve without heavy reliance on the update loop and constant coroutine usage, without the use of events, delegates and actions. 

Audio Management

The Antigen Shift is the first project in which I wanted to focus a bit more on audio implementation. Past projects had simple clips playing, however none of this audio was managed in a clean, extensible way.

For this prototype's audio, I looked into creating an audio manager that persists from scene to scene, and allows other scripts to access it through static methods to play audio in a variety of ways. The audio manager allows me to handle all audio in one place, with the only elements external to the manager being static method calls where needed throughout other scripts. This path of static method calls would likely be hard to manage in a larger scope project, however fit the needs of this project. 

Particle Systems

I had lots of fun playing around with the wealth of modules in the Unity particle system. These particles allowed me to branch out from aesthetics that rely purely on pixel art. The goal was to have a unique particle for each of the main interactions in the game. These included enemies being defeated, the player being hit, enemies bouncing off of the screen boundaries, health spawning and health pickup. Each of these actions were made more interactive and noticeable through simple particle effects. 

UI Navigation

In my past projects, UI was only navigable through mouse clicks. This was mainly due to the UI being a means to an end for the prototype, but also due to a glaring gap in my knowledge. 

For this prototype, I dedicated some time to learn how to control the UI with button inputs for both a keyboard and controller through the Unity event system. I learnt how to give each button priority for control depending on in game circumstance, as well as learning about explicit navigation between buttons.

Game Design Considerations

I tried to think about every element of the experience within this prototype and give each of them a defined reason for existing. The main goal was to keep the player from becoming too comfortable with their current circumstances. Due to being based on survival time for high scores, the game needed to be constantly threatening the player with the prospect of death, and constantly reminding the player that they couldn't just stay still and achieve ludicrously high scores. 

Friendly Fire!

One of the earliest considerations I made towards this goal was making the player's bombs cause damage to the player. Reason one for this choice, was so that as soon as the player places a bomb, they must move to avoid self inflicted damage. This prevents the player from staying in one spot for too long. 

It also forces the player to be more tactical in where they place their bombs, as frivolous use of the bombs could lock the player into a corner of danger, or make their play space too difficult to navigate at the speed required to avoid an enemy.

Speed It Up! 

To prevent the player getting too good with their current play session, I wanted difficulty to scale depending on how long the game has been going. To achieve this, I split enemy spawning up into separate object pools that activate and deactivate in sequence. 

These spawners are scaled in difficulty through their spawn rates and the speed of the enemies released by the spawners. Once all spawners had been cycled through, the game would register one "round" being completed. Spawners would then reset, with the difference that all of the enemies within them have had their movement speed multiplied by a predefined difficulty multiplier. 

Personal Space

Halfway through the project I realized that due to the nature of enemies spawning in random locations with random trajectories, there were many opportunities for players to become trapped through no fault of their own. This removal of autonomy led to frustration, as there were situations in which the player was helpless to avoid danger, regardless of their perceived skill level.

To remedy this, I added the ability for a player to use an area of effect ability that would push enemies in the immediate vicinity away. Due to enemies being velocity based in their movement, this also had the added benefit of enemies bumping into others whilst thrust away, making all threats currently moving towards the player slow down. Enemies would then resume their original velocity upon hitting a wall of the play space to prevent being stuck in this new, easier difficulty level. 

This ability also allowed me to play around with new UI elements that I hadn't previously used, such as sliders. This slider would show the player the recharge level of their shock wave attack. 

Charge!

In a similar vein of consideration for player autonomy to the EMP attack, I also added the ability for the player to boost their movement speed at will. The aim of this was to tackle the phenomenon of a player essentially seeing the writing on the wall of their own demise and being helpless to stop it, thus leading to frustration. 

What I mean by this, is that if players saw enemies moving in a certain trajectory towards them, they could judge that based off of their own speed, the enemies direction, enemy speed, and potential space to move to, that they were defeated, long before this defeat has actually happened. This only leads to frustration due to inevitabilities that the player can't control.  It's not fun too see that you're done for 5 seconds before you actually face the defeat, and have no way to remedy this. 

Boosting allowed the player to tackle tight dodging and get themselves out of what they would judge as precarious situations if they are skilled enough to navigate danger at higher speeds. 

Originally, I wanted to limit boosting to short bursts to prevent misuse, however I found it more interesting to leave the use in the player's hands, as continuous boosting could actually lead to more danger if the player doesn't consider their movement carefully. This means that defeat caused by moving too fast is on the player, instead of having unplanned speed changes happen at the least opportune times leading to potential entrapment. The boosting implementation resulted in a careful balancing act for the player. What might originally be considered as a permanent buff making dodging much easier, could quickly become their downfall if abused.