Nicola Palomba

Flea Swarms

Fleas move in swarms, following a leader, wandering around the battlefield and avoiding obstacles. When the leader is destroyed, a new one is chosen and the rest of the swarm starts following it. When a flea is hit or when the player is too near, it starts emitting projectiles in a circular pattern. Fleas aren't very dangerous, but they sometimes drop health and ammo.

Turrets

Turrets are attached to a certain type of asteroid. They simply shoot at the player whenever they get too near. They use an auto aim algorithm similar to the one used by the player (described below).

Hidenseeker

The Hidenseeker uses a state machine to determine its behaviour. They start by wandering around the battlefield, then a coordinator scripts notifies a certain amount of them (random between 1 and 3), which seek the player, anchor around them and shoot them. After a certain amount of projectiles, they flee until they're far enough from the player, then start wandering again.

Big Ships

Taking down big ships is the main objective of the prototype. They're guarded by a shield, which is disabled when all the turrets at its poles are destroyed. When that happens, Big Ships start shooting aiming missiles, that deal a pretty big amount of damage. Successively, the player has to destroy the three generators located on them to finally take them down, while avoiding the other enemies.

Enemy movement

All enemies are powered by steering behaviours to implement fluid movement. Collision avoidance, shown in the gif, is achieved with the same set of algorithms and it's very useful in an environment full of asteroids. Most enemy AIs are a state machine that select the right behaviour to use depending on the context. For example, the purple enemies seek the player, shoot at them and then evade after a certain amount of time

Auto aim

When the player is hovering an enemy with the cursor, it's possible to activate the auto aim system. Designing a perfect auto aim is not very difficult, designing one that doesn't make the gameplay eccessively easy means finding a compromise. This is the prediction algorithm:

• Compute the time needed by the bullet to reach the enemy (depending on the enemy distance and bullet speed
• Compute the position of the enemy after that amount of time, using its current velocity
• Iterate these two steps to refine the precision of the prediction
• This would be enough in case of a straight trajectory, but since the enemy could change velocity during the amount of time needed by the bullet to reach it, the above process is used to adjust the trajectory even after the bullet has been fired
• The adjustment process only lasts a few milliseconds to avoid making the game too easy

Radar

The radar is implemented in a quite simple, but effective and robust way.

• Each enemy has a child red sphere located in the "Radar" layer
• The player has a child camera that only renders the "Radar" layer
• Said camera renders its output to a texture, which is then rendered in the UI
• Since a texture is 2D, the y position relative to the player is displayed through the color of the spheres. A purple sphere represents an enemy below the player, a red sphere is located at their same level, a yellow sphere is above. These colours are configurable in the settings to better fit the player's needs.
• The camera can only render visible objects: the ones that are not visible, but distant less than a certain amount, are rendered at the edges of the radar by moving the spheres along the border

Settings menu

I find it very important to let users customize parts of their experience to improve it. The Settings menu lets players modify the volume of music and sound effects, invert movement axes, toggle post processing effects and set the difficulty. I also included a few options for colorblind people, allowing to customize the channel mixing and change the colors of the radar. A screenshot of the game is used as a preview for the selected results.