As a swarm you invade unexplored crystalline worlds. What counts is the mass - the more the better. Command your units with sharp wits in order to overcome obstacles and defeat the enemies in your way. There will be cunning riddles blocking your path: Use your sheer number and sacrfice a few units to get through, or split your swarm to solve them and become even biger than you were before. If you see yourself against one of the enemies, be smart as well: You might be able to simply outnumber your foes a few times, but only good tactics will last for long. Distract them with one group, and stab their back with the other! The further you get, the harder challenges will test you. Evolve units and use their new abilities to claim your path to victory.
Date: 3rd semester (2014/2015)
Duration: 5 months
Team Size: 6 people
Technology: Unreal Engine 4, Blueprints Visual Scripting
Constraints: Make a full playable game prototype using the Unreal Engine 4 and its Blueprint System. Use no more than 10 different objects (but each of these as often as you want).
My Part: I worked mostly on the game concept and system, including most of the scripting. I also did all the organizational and project managing work.
What I've learned: Originally this semester our team worked on another idea. After a few weeks of development, we then decided to drop it completely and start again. To recognize that something is just not working, and then dropping it, was a hard but good lesson. Also after that I've learned a lot on how to design, iterate and choose game mechanics. How to work close together with our Level Designer, and obviously how the Unreal Engine and its Blueprint-System works.
While working on I/O, I've made good experiences with analog prototypes, so we decided to make one, based on my rough swarm idea, as well and played it through. This helped us to understand the possible interactions and dynamics a swarm game could implicate.
To define the main gameplay, our Level Designer and I prototyped various game-situations and visualized the interaction of the player. The core of Critical Mass should be to treat your units as ressources, split the swarm and make the sub-swarms work together.
Treating your units as ressources means also sacrificing (spending) them. We came up with the idea of filling up a pit with units, so the others can cross over. During the development this idea turned into building a bridge from level to level out of your own units. This way we could also gain more control over the total amount of units necessary at the end, - and left at the beginning of each level.
We decided to use the split-mechanic not just for fights, but also for puzzles. The player should, as usual, have the possibility to simply rush through and sacrifice a few units, if his swarm is big enough - but also to solve the puzzles and gain additional units as reward.
As usual, not all of our ideas made it into the final game. Originally we wanted to implement four different unit-types and combinations between these. Regarding time and scope we decided to merge two of these into one, and leave out the combinations. Another example was the waypoint system, that we thought was a good idea, but turned out to be completely confusing in testing.