The beginning of a game (Unity)

Something I've struggled with in my quest to become a game designer is how hard it is to actually get practice designing games. In my courses at school, I was usually the lead programmer on the project, which meant most of my time was dedicated to coding. Don't get me wrong - I love coding video games. But in school projects and small games on the side, having to spend so much time on development meant there was very little time left to work on design.

I wanted to change that. That's why this week I spent my free time developing the start of a small game that will let me practice my design skills. For this to be successful, the game had to have a few key qualities:

1. The game must have little to no art. I didn't want to create sprites in photoshop or tour the web for animations. I hoped that by keeping art entirely out of the development process, I could focus on design aspects instead.

2. The game had to be 2D. 3D games tend to look very unpolished without proper 3D animations and models, and since I didn't want to spend any time on art - this was a must.

3. Game design had to be easily incorporated into the development of the game. Some games choose to create enjoyment for the player through loveable characters or great music - which I totally respect. But for this game, I wanted to choose a genre that required constant decisions about the flow and structure of the game.

4. It had to be co-op. This wasn't so much about game design, but rather what I am interested in. I knew I wouldn't be able to commit myself to a game I didn't enjoy, and adding multiplayer is an easy way to increase my interest in a game. However, I didn't want to deal with the back-end of making a networked game (and the hours of coding that comes with it), so I settled on local cooperative multiplayer.

With these ideas in mind, I came up with the basic idea for the game.

1. A co-op multiplayer game played with the controller

2. Players play as little shapes buzzing around the screen

3. Fight enemies (bullet-hell genre) and solve puzzles in a level-based format

I didn't really have an idea for how I wanted the game to flow, but I knew I needed some basic elements implemented to start prototyping. I started by coding the basic player movement. This included a small triangle to represent the player, with the controls mapped to a traditional gamepad.

Notice how the game being two dimensional allows for very simple art to still look good. The player is just a triangle with a tail, but it still looks polished.

The next thing to add was some basic moves or abilities to the player. This is where actual game design starts coming into play. I could start asking questions like:

1. What sort of abilities should the player have?

2. Should they be static or upgradable through the game?

3. Should friendly fire (the ability to damage your teammates) be enabled?

However, I wasn't quite ready to start considering those questions. I wanted some basic functionality implemented to compare to before I started "designing". I added in a dash, a ranged attack, and a melee attack.

I'm not happy with how the melee attack looks or feels, so I'll be tweaking that next week

The final thing I wanted for my first prototype was some basic enemies to attack. Since I wanted this game to be a sort of "bullet hell", there would need to be a source for lots of bullets firing at the player at once.

In my mind, there are two distinct approaches to this. The first is by having a single enemy that shoots lots of projectiles very frequently. This is usually the approach taken for "boss" levels.

The second is to have many smaller enemies firing just a few bullets at a time. I think this can sometimes be overwhelming for the player, especially if there are too many enemies to keep track of at once, but it seemed like a good place to start for my game.

This is where I went off the rails. I had told myself before the project to focus on design, and try to leave intense programming and art for later. And yet, I quickly found myself reading through this paper on a technique called "boids" and coding a huge script to add it into my game.

I didn't stop and think whether basing my enemies on "boids" would lead to fun gameplay. I didn't consider whether the idea was scalable performance-wise for a game like this. I didn't consider if the random nature of boids' movement would make the enemies feel "dumb". These were all questions I should have asked myself before writing a single line of code.

I'll take a moment to explain what I mean by "boids". It's a way of simulating the movement of flocks by giving each "boid" (in my case, an enemy is a "boid") a few simple rules to follow. They are:

1. Avoid crashing into nearby boids

2. Steer towards the center of nearby boids

3. Align yourself with nearby boids

To have this work in my game, I added two more rules:

1. Steer away from walls

2. Steer toward the player

It's amazing how these simple rules lead to very complex behavior, and if you're interested in learning more about how it is implemented, I recommend Sebastian Lague's video on the topic.

Anyway, like has happened way too many times in the past, I spent a long time coding up a new feature that works well and looks great, but isn't necessarily a good game mechanic. Here is what I came up with:

From a development standpoint, I'm extremely happy with how this turned out. The performance is great, it looks like little fish or birds swimming around the screen, and I made it very customizable to create different flocks for enemies.

The problem I immediately faced after implementing this was very clear: the enemies weren't very fun to play against! They looked interesting and behaved like I had wanted them to - but they weren't very challenging to fight. The player could easily dodge all of their projectiles unless there were tons of enemies, which meant fights would take far too long to be interesting.

However, that doesn't mean that I wasted my time. In the future, I can iterate on the idea, tweak their numbers, and preform playtests to create enemies that feel great to battle. Those are the sorts of questions I'll be tackling next week.

Super Mario 64, a game widely considered one of the best in its genre, famously spent several months solely developing the movement of Mario (read more here). Mario jumping and rolling around the world is the backbone of the game, so they made sure it felt smooth, responsive, and fun.

In my game, the character's movement and basic abilities are the core of the game (often called the core gameplay loop), and thus I have to make sure they feel right before even thinking about developing more features. The hope is that by making the core gameplay loop extremely fun, the rest of the game follows suit and you don't need to rely on genius level design to keep the player interested.

But those are questions for next week. For now, I'll leave you with a little demo of the game so far.