Designing my first video game

Finally, after years of playing around with game development and making prototypes and unfinished games, I started making a real game that I will release in a couple of weeks. I wanted to explain what’s the design process I followed.

Prior to this one, I started another game a few months ago. It requires a lot of hand-crafted content to make it a viable game, and I felt that it would take me too long for a first game, so I decided to park it and start again, much smaller.

The idea

Originally, this wasn’t even to be a complete game, just some gameplay I would release for free as if I was participating on a game jam. Later on, I decided to spend more time on making something that qualifies as a game, even if it’s a small one. The skills to create a prototype are different to the ones to create and finish a game, so the later was a more interesting thing for me.

Taking the advice of other people here and here, I decided that the first game should be very small; something that you can make in a short period of time (this varies a lot depending on how much time you can spend, but I’d say not more than a month or two working full-time on the game). As I love retro games, I looked at old classics to find a starting point. But I didn’t want to create yet another clone; reinventing old games games is cool, but cloning doesn’t really feel good to me. I chose to make a space shooter inspired on Space Invaders, but I had to find something to make it different. I went for using colours to add a puzzle component to the game, which looked to me like an interesting combination to explore.

After some brainstorming, I came up with these rules:

• There are a few different enemy types, each one with a different colour.
• The player is given 3 colours and has to kill enemies of those types.
• When the player has killed 3 enemies of the types requested, another 3 are generated.
• If the player kills the wrong kind of enemy 3 times, it is penalised by re-spawning some of the enemies already killed.
• Of course, if the enemies reach the player at the bottom of the screen, it dies.

These are simple mechanics that can play well together and converts our beloved classic game into something different. No more indiscriminate shooting; you have to think before pushing the fire button. Also, this helps me do an exercise of game design without having too many things to balance at once.

Sounds like a plan! So I got started.

The prototype

I started going straight for a version of the gameplay that would prove whether my idea worked or not. Just one level with the fundamental elements of the core mechanics and a simple UI. I took the -very simple- ECS engine I started writing on top of MonoGame for my previous/parked game, and it was surprisingly solid and useful. I managed to start coding the game logic almost straight-away, and got the prototype up and running in 2 days.

When I handed the prototype over to my first testers (who aren’t used to play action games anymore, so I thought they would be a good fit for an initial test), I got disappointed by the fact that they didn’t seem to understand what the game was about. They started shooting like if there were no tomorrow, and got surprised when the enemies would reappear. My initial attempt to hint this penalty was to change the colour of the limits of the screen, from white, to orange, then red. But my testers just didn’t notice. They also missed the fact that the 3 colours on the left-hand side were the ones they should follow to kill the enemies. I failed at communicating the rules in a self-explanatory way to users who played the original classic long time ago. My bad.

There was something important missing though: sound. My plan is to use sounds, in combination of graphics effects, to notify the player when they do an action that is wrong. My goal here is to teach the players as they play, without using words. I didn’t include any sounds in the prototype (which was deliberate, to see how good or bad the existing graphics effects were), but they will be in the final game.

I decided to improve the UI to make it more obvious that the user had to pay attention to the 3 colours on the left-hand side. My next tester, a bit more used to play video games these days, got the idea straight-away. That was an improvement. The mechanics seemed to work, so it was time to start making the game.

The levels design

Following the advice of other solo developers, I looked for a way to avoid the content trap. This trap consists in the solo dev taking ages to create the content of the game, regardless of how simple it is. This is what happened to me on the first game I attempted.

I tried procedural generation for the enemies formations, but felt like it didn’t really suit this kind of game. I wanted the levels to be hand-crafted to make them more interesting and surprising, with space-related shapes rather than just enemies being placed randomly. Luckily, this didn’t take more than one day, so I didn’t repeat the same mistake again. I did use procedural generation for the enemies colours though, so every run would be different. This both shortens the content creation time, and makes the game more interesting to re-play. Win-Win.

As there weren’t many different levels, the next thing idea to add some variation was to change the enemy movement patterns. The game starts with the classic horizontal movement (although I decided not to let the enemies reach the limits of the screen, to make the game faster), but it changes after a few levels. I tried a few different movement patterns that I was happy with. They make shooting the enemies more difficult, as the player needs to keep track of what’s going to be the next movement in order to kill the right enemies. Again, simple, but effective, and can be combined with the existing content to create more levels.

Conclusion

Even a simple game requires the game designer to think carefully about many variables. How many enemies should be re-spawned when the user kills the wrong ones? How many failed attempts should be allowed? How many different kind of enemies should we include to make the game balanced? What about the difficulty curve to make sure the players feel challenged at some times but without overwhelming them?

All of these variables, and a few other things, require careful thought. Making a small game allowed me to focus on a small amount of parameters I could play with to make a game that is fun, without having too many things at once.

Originally published at srodrigo.me on January 28, 2019.