Lyon, France


Swarm – The Game

GenreRhythm / Action / Bossfight
ControlsMouse & keyboard / Controller
Target audienceMidcore / Hardcore players
Released onSteam

The Network has been infested. Fight a giant creature ruled by music to cleanse it. Face it while switching between 2 complementary Game Modes!

Swarm is a Bossfight game in which all the boss actions fit the music.

To defeat the creature you will have to switch between a Melee and Shooter mode !

Swarm – The Project

Duration5 months
Team6 game design students
Context3rd year diploma project
My main rolesCreative Director / Game Designer / Lead Programmer

My first project as Creative Director

Swarm is a game about feeling, the main objective was to create a impressive and powerful experience with a strong musical link.

The main purpose of the musical aspect wasn’t to make rhythm mechanics, but to “Feel the music”, this was the main intention and guideline of the project.

My role was to make sure that every aspect of the game follow this intention, and that everyone have the most accurate vision of the targeted experience possible.

It wasn’t an easy task, due that we were working on the first DLC of Neon Beats at the same time, and most of the team had to find internships and spend time on personal branding. Some people couldn’t work full time on the project and i had to make sure they know what to do, have the required information and that their work fit the global vision of the project.

My work as Game Designer

A powerful rhythm experience

We wanted this powerful bossfight rhythm experience, but how to do it ?

Making rhythm related games isn’t easy, there are a lot of constraints related to the music.

The boss is divided in several phases linked to specific music parts, each phases consist in an boss hp bar and patterns. However, players will not finish a phase exactly in time with the music. In order to fix that, the transition to the next phase will wait until the end of the music loop to process.

Moreover, the music isn’t only composed of loops, but also contains two major drops, so we can’t make all phases loop and wait until the boss hp reach 0. That’s why we created another type of phase based on dodging boss attacks for a determined period of time.

Progression in a short game

In order to have a good and polish vertical slice with the best game feel possible, the game contains only one boss.

Having one boss don’t let much time to teach progressively the different mechanics and boss patterns.

In that idea, some work were done on 3Cs to provide few accessible mechanics with a low amount of inputs and a simple static camera changing depending on the current game mode which doesn’t need to be controlled directly by the player.

It was important to also have clear signs & feedbacks to understand the different interactions, and to predict the boss behaviour.

For the boss patterns, we did our best by following the kishotenketsu japanese narrative structure (introduction-development-twist-conclusion) in the fight in order to have a good interest curve. Moreover, the targeted audience being midcore / hardcore, a die and retry aspect isn’t necessarily a bad thing and quickly offer a proper challenge to the player.

If one day we decide to push the concept further, adding severals bosses can be great in order to have a better macro progression and teach the mechanics in a more fluent way.

About the game feel

Game feel was central in this game, we wanted the player to feel powerful, and so, every player and boss actions had to be as juicy as possible.

A lot of work was done on the character and boss animations, which use some of the basic principles of animation like squash & stretch, timing, secondary motion, anticipation and exaggeration. But also on all the player movement and dash following specifics curves, and details like a little dash when the player attack.

The camera will shake on player and boss hit and punch in the opposite direction on player dashes.

Post-processing was also really important to achieve a good game feel. Screen goes black and white with a glitch effect during few frames when the player get hit and chromatic aberration strength increases when the player attack.

Finally, the Sound Design and the fact that the boss make actions with a lot of feedbacks in rhythm added a lot of flavour to the game.

Two complementary game modes

Originally, game modes weren’t supposed to be controlled by the player, but by the boss itself in order to have an even stronger musical link. However having it controlled by the player allowed more interesting interactions and decision making.

The two game modes needed to be complementary in some ways, and encourage the player to switch between those as much as possible.

We added little bees only killable in the shooter mode, and their eggs only killable in melee. It was enough in theory, but not in playtests. We thought that it was a nice feature to have because it add sub-objectives to the bossfight, however, it didn’t make the player switch that much.

Later, we tried a build with limited amount of dash charges, and the only way to get this charges back was to switch. It felt really nice and it encourage players to switch and have the best experience possible.

My work as Lead Programmer

Being at the same time Creative Director and Lead Programmer allowed me to shape the game in a more significant way at either macro and micro level.

Peer programming

I wasn’t alone on programming but with our lead game designer. I had to ensure that the global architecture and code was as clear as possible, and also giving him all the information and help i could.

We worked both on the character controller and game mode switch, in order to do that, the logic and data of the different character controllers were stored in ScriptableObjects so that we could easily alternate between a shoot-em-up like and a platformer like controller.

A ScriptableObject events / data pattern was used in order to ease the prototyping and follow the SOLID principles.

Afterwise, we split on different tasks, my mate was responsible of the menus, when i was responsible of the core.


I started by doing some r&d on differents ways to link audio and gameplay, which made me create several systems.

The first one was a bpm timeline track in unity which will raise events in rhythm according to the bpm.

However, timeline aren’t using Unity digital sound processing time which make it really hard to have smooth loops within the music.

Which led me to using fmod, and create an audio event system in which i can put markers directly in the audio engine in order to throw specific events on the game loop.

I also created an audio spectrum analyzer so we can have elements like health bars reacting to the audio.

The boss

After that i developed boss actions (movement, aim, laser and dash), and patterns that are controlled directly by the audio event system. I made a tool to prototype patterns more easily, so i can design and test a pattern quickly.

Last details

It was time to polish a bit, and so, i spent a lot of time on working on the game feel, modeling the boss, making the boss and character animations, writing shaders, UI and tweaking values.

Later, i created a leaderboard by using Firebase and the Rest API, an achievement system and linked the game to Steam.


It was a really hard and intense experience, i had a lot of responsibilites and work to do which led to some crunch and nights at school. However i learned a lot in terms of game design, programming and most importantly social skills. A huge thanks to all of my teammates for this experience.

Other team members’ portfolio :