Game design and evolution

One of the topics that fascinates me the most (outside game design) is evolution, probably for the same reasons I love game design. When I find intelligent and creative solutions to a problem I'm often in awe and the evolution of a species is characterized by a lot of interesting solutions to challenges that species had to face. The interesting part is that these solutions aren't perfect, and are usually an adaptation of some already existing structure. For example, research suggests the human larynx is lower in the throat to allow a greater control over sound production and speech, but this also means that we have a greater risk of choking than other animals, as we have to raise to swallow food. So it's not like human's throat was made from scratch to allow us to speak well. We adapted something already existing and gained some disadvantages along the way.

And what is another area where solutions are found by adapting existing structures? You guessed it, it’s game development (which is luckily the main topic of this blog).

I started to wonder if I could find any interesting similarities between the two when something clicked while I was thinking about my latest project: vestigial structures. Vestigial structures are elements of an organism that persist even though they have lost the original function they had in an ancestor or in the embryon. For example humans still have the coccyx, a bone once connected to our tail. Usually these structures don’t present any advantage, but they are rarely harmful, hence they were not removed during the course of evolution. This is where the similarities with game development really strike: the most insidious things are the ones that don’t have many advantages or functions, but do not pose any actual harm and simply stay in the project, keeping you away from the elegance we all strive for in our games. 

Today I thought I’d share some things in my latest project that I noticed do not have their original function anymore or they were designed for a reason that is no longer true and hence could be better designed if starting again.  Before jumping in, I wanna briefly resume this game: it is a rhythmic-action roguelike game, where players deal more damage by attacking on the beat and enemies attack in time with the music. Our aim was to blend the fast-paced gameplay of Hades with the rhythmic combat of Hi-Fi Rush. You can find more information about my game here, now let’s discover the many features of this game where the answer to the question “why?” is more historical than an actual design reason. 

Three-attacks combo

One thing that really strikes me today is the fact that our combo is composed of 3 attacks, even if 4 would be more natural with a 4/4 rhythm. So why is that? The answer goes back a long time and is pretty amusing. At the beginning we discovered that by having a 3 attack combo, by mixing melee and ranged attack, we would get 8 combinations. We decided to associate each combination with a different note (with the first one repeated at the higher octave). Each note would then destroy a magical shield that could randomly appear on some enemies with that same note written on it. After fully implementing this mechanic we realized it wasn’t so much fun as players had to remember an arbitrary combination of attacks for each note and it didn’t fit our fast-paced gameplay. Obviously though, by that point, the combat and combo system was already implemented so we made a quick switch: the shield on the enemies could be destroyed by every note. This removed the need to memorize the combos or to even print the number on the enemies head. The “shield” feature had the same sort of adaptation human larynx has gone through (which is an example of exaptation). On the other hand, our combo system remained based on three attacks even if our primary reason wasn’t anymore relevant, so it is a great example of vestigiality.

Low obstacles

For our levels we decided early on to have low obstacles to stop players movement and block enemies' projectiles. Going forward we decided to have the player dash through enemies and obstacles, while at the same time our AI was better refined to avoid obstacles before deciding to shoot. In the end our obstacles still have gameplay relevance, but it's interesting to notice how much it was reduced by other choices during the course of the development.

Lunge attack

Our third attack is a forward lunge that many of our playtesters have found uncomfortable as it pushes players where they don’t wanna be and takes control of the character’s movement away from them. So why do we have a forward lunge? At the beginning of this project we didn’t know if our 3D artists would have learned how to animate the character in time for the end of the project. I made this simple proposal: the character has a flying sword that is magically controlled by a conductor’s baton. This would have greatly simplified the animations while in the meantime, separating the animation from the actual range of the sword, giving more freedom to tune the movement without requiring any rework of the animations. This worked out fine, but obviously as soon as our 3D artists learned (really quickly I must say) how to animate melee attacks, we were excited and very eager to leave our old system. And the lunge? Well, when we had a flying sword, we could maneuver it as we liked. If the sword lunged forward the character could stay still. We finalized our attacks early on and when we had to turn them into animations we opted to simply move the character where the sword once flew. It was after everything was set that we realized we had something that played fine in place of another attack that could have been much more appropriate. I must add that we also wanted to encourage players to mix melee and ranged attacks, so moving the character forward was our way to allow the third melee attack to follow naturally 2 ranged attacks.

A final word

There are many examples like that, but I think these are enough to understand some important things I learned in this analysis:

• Always think critically about your game and every single element in it. Does it serve its original function? Does it serve another function? What would happen if you removed it?

• Design your game from your core gameplay. This is common practice in game design but I discovered another important reason. Vestigial structures are very common and can’t always be removed. Therefore, you want them in your secondary features. The magical shield note-thingy should have been designed after the right number of attacks in a combo was already set. 

• When adapting or changing some already existing structure, think about all the consequences of that decision and what the previous structure allowed or didn’t allow in your game. Maybe now you have more freedom in other elements or maybe you need to be aware that other problems will arise.

That’s all for today, hope you found this article interesting. See you next week when we’ll all suck a little less.