JAIR Post-mortem

26 Mar 2017

Around 3 months ago I started a project to build an infinite runner in my spare time, which I titled “JAIR” (or “Just Another Infinite Runner”), purely for lack of a better idea. Yesterday I finished working on it and so I’ve put up a project page for it here and I thought I’d just write up some notes about how those 3 months went.

Just Another Infinite Runner

Things that went well:

I ended up with something complete.

…in that it has a menu with instructions, you can play the game and lose, there are some purely-visual polish-ey bits etc. Even if it isn’t much fun.

My original goal was to actually finish something (for some definition of “finish”) and I feel like I’ve mostly achieved that. The game has no sound and no textures/sprites/graphical assets, but I managed to end up with something that isn’t too painful to look at and can actually be played like a game. I will concede that there are a few bugs that I am aware of and haven’t fixed (mostly to do with collision detection/response) and this is part of the “putting of trying to solve harder problems” point (which we’ll come back to), but overall it can be played and I’m content enough to let people play it.

I stuck to my original deadline.

I managed to finish within the timeframe that I initially specified: 3 months. I wasn’t working as consistently as I’d like for those 3 months and certainly could have gotten more done if I was, but for the first side-project that I’ve taken on since getting a full-time job, I’m ok with the amount of work I did (though I’d definitely like to improve on it).

I stuck to my intermediate progress goals/deadlines.

At least mostly. While working on the game I’d set out a list of tasks I wanted to get done in each week (better terrain generation, clean up the movement, fix this collision detection bug etc). For the most part I succeeded in sticking to those (with some shuffling when I realised that one thing was more important/related to recent work than another) although in the last two weeks or so I tended to just ignore those lists and do the immediately obvious next-thing-to-do.

I learned to appreciate game engines a bit more.

I didn’t use a (proper) game engine to make JAIR. I had SDL to make windows and OpenGL contexts and that’s it. I wrote my own rendering with OpenGL, I wrote my own collision detection, I wrote my own entity management, all of it. Most of this already existed in dge, which I started sometime in 2015 for another project (that never happened), but that is very minimal and I had to add a bunch of things to it as I went along.

This is great for learning how these things work and its great for satisfying the urge to do everything myself, but as I only truly started understanding while working on JAIR, it does make doing anything non-trivial a fair amount more tedious and slow. This also ties in with the problem of putting of trying to solve harder problems (see below) such that more than once, I ended up not doing any (significant) work, just because I needed to add functionality to the collision detection or something.

Now notice that I list this as a thing-that-went-well. That’s because while I do think I might enjoy doing engine work if I got into it, the point of this project was to have something to finish so that I have something to show, and writing everything myself hinders that. So for my next project I will be using an engine of some sort.

Things that didn’t go so well:

Putting off trying to solve the harder problems

If there were just one thing that I’d like to improve on in future projects, it would be to never put down a task right after picking it up. If you have something to do, just do it. Now. You’re not going to want to do it later, or tomorrow, or after you’ve finished this trivial-feature-that-takes-you-5-minutes-but-actually-adds-very-little. More than once I’d be working and realise “ok, so we need to do thing X, but meh thing X is a lot of effort so I’ll do something else”. Not only does this mean that I don’t get the experience of (at least trying to) do the thing, but I also waste a bunch of time and effort because that thing needs to be done for a reason, and not doing it has consequences elsewhere in the project.

Not sticking to the original mandate of simplicity

I started the project in an attempt to have something that I’ve “finished”. Since finishing things is hard and a skill to be learned, I figured I’d start with something simple and small. What sort of game is generally quite simple and small? Infinite runners (Ironically…the development process is small, not the game world). So I started thinking about what sort of things I’d like my infinite runner be:

As you can imagine my game-that-was-chosen-for-its-simplicity pretty quickly became not-so-simple. This resulted in a bunch of work being done, only to be scrapped a week later when I realised it would take far too long and have far too many consequences for other parts of the game. I did cut it down to something manageable, but the whole process would have been a lot easier if I had just Kept It Simple…Stupid.

Staying focussed on this project until it was finished.

Quite a while ago I decided that the next project I do will involve some networking. It might be a simple arena shooter or a tower defense or some other uncategorized…thing….but it will be multiplayer. This meant that in the last 2 or 3 weeks of working on JAIR, I started getting very distracted by the idea of the next project (I won’t lie, I’m pretty excited to do some networking). I gather that this is a problem that faces loads of developers (games or not) and I’m not sure what there is to be done about it (if anything), but it did keep me from being focussed on just finishing JAIR.

On the next episode…

I haven’t quite settled on what I’m going to do next, but the plan is to pick some multiplayer game to clone (almost certainly some or other Warcraft 3 map) and do that for the next 3 months. I only know that it’ll be 2D, multiplayer, built using some or other engine, and posted here when it’s done. See you then!