What I Learned from a Year of Making Games

Back in January, I wrote on bit-tech about creating my first game, a text adventure called 20something that I created in Twine. The response was positive, and I was also encouraged by several readers here to create something more involved.

So, I gave it a go.

Here's what I learned from making game number three, my first with graphics: Super Ultimate Cyberpunk Assassin. Super Ultimate Cyberpunk Assassin, which we'll shorten to SUCA, is a top-down shooter where you charge around with a chunk burst-firing pistol and tear through areas full of enemies. It's not super polished, as I sought to learn how to use GameMaker Studio 2, which I used to create SUCA. The core loop of the game feels fairly solid, though, despite some shaky presentation, so I feel happy to talk about it. 

But this is also what I've learned about making games in general. 

You have to code everything

I felt like an idiot for not knowing this, but in fairness I think we all 'know' it but forget it from time to time: Everything in a game has to be coded, and if there's a shortcut anywhere then that is a shortcut that's been written in code in the first place to save someone the effort later.

Take reloading. I programmed in reloading for SUCA, and that doesn't just require you to put in the function of reloading, which would be time-consuming enough, but it also requires you to tell guns that ammo exists and how much of it they hold. On top of this I had to put in an animation on your cursor to let you know how far through it's going, and layer on a sound, for the feel of it. Each of those bits can (and would) break and have their own bugs that would then need fixing.

My menu is a high quality PNG image, with invisible chunks of wall that take you places when they register a left click. This is, I'm informed, quite a standard practice. The instruction screen, credits? All PNG images with clickable bits of wall.

The pathfinding in my game is an invisible object, full of code that makes enemies able to read the map and make their way around it. No invisible object hidden on the map? No pathfinding. 

Making games is wild.

Finding the fun takes a while

After a few days, I had a prototype that worked. You could reload, you could kill people, and the maps were rough but ready.

While it was far from complete, the game was a passable facsimile of a top-down shooter.

The game wasn't fun, though.

Finding the angle that makes your game enjoyable for people to play takes a while, but it's essential if you want anyone to actually play it. With my narrative games before this, the story was the fun: You can read my words and enjoy the order they're put together in and feel compelled by the story, or you can decide it's not your thing. That's the best you can do with a piece of interactive fiction.

This game isn't interactive fiction, though, with what little information you can infer being solely available through environmental storytelling. This meant that I had to experiment with a couple of different options. The choice to make the game about speedrunning was a meta way to keep the pressure on players, to force them to move aggressively. The external mechanics push on players to make them move a little faster, as does a tweak to make the AI a little better at reacting to your presence.

Remember last time when I said that everything needed creating? Other ideas I tested - attempts at a score system and even story beats, for example - all required development to try and implement at a basic level only to find out that they weren't really helping. Hell, the speedrun mechanic only really came into the game in the last few days as I looked for a hook to get people to experiment with the game.  

Nail what makes your project fun, and you might just have a working game, which is important if you're going to be experimenting, because this next part is really important for making games.  

Release your games

On my machine there are 15 different unfinished games, a mash-up of Twine projects that died along the way, odd prototypes, and tiny experiments in Bitsy that were more interesting or funnier in my head then in the game.

In my mind, the golden rule of being a games hobbyist is to release your games. You can do this for free on Itch.io, and the process is as simple as uploading an album of photos to Facebook. Releasing is good for you, because some healthy criticism and the warm endorphin rush of someone digging something you've made will only spur you on to the next thing.

It's a golden rule that I've broken many times, with 20+ prototypes ending up as three released games on Itch.io with one re-releasing on Steam with a little polish. I'm letting myself down somewhat, but that's okay because at the risk of sounding trite…

Making games is a journey 

It might sound like inspirational nonsense, but over the last few years that I've been making games - tabletop, narrative, and weird shooters ideas - I've slowly improved, and it's noticeable in the ideas I have and the way I'm executing them. I still think there are some areas that I'm bad at, but there are also lots of areas that I'm showing a marked improvement in.

Like any creative project, making games isn't for everyone, but my argument is that anyone can make games, if they want to, and get something out of it. 

Learning to make games has taught me a bunch, too. First, it taught me to code, when nothing else seemed to be working. Secondly, it taught me how difficult games can be to do well. Making a game is easy, but the AAA projects that come from big studios feel like real achievements now, and the next time I see someone say 'but adding this feature I want in the game would be a quick job', I'm going to scream internally and roll my eyes.

You can play my games here, and they're all free. I'll no doubt make a few more in 2018, and I'll be back with more of what I learn in the process if I think it'll be of interest to you guys.