A Postmortemaking-of Quazar's Claim

This was originally a post written on my blog at ptgrant.com

So Quazar’s Claim has been out for over a week and even though this is a miniscule game project, it being my first released solo development, I did learn a lot and think it’s beneficial to write out a bit of a postmortem while it’s fresh in my mind. There are lessons from this that I’ll be taking with me for future game projects and perhaps other devs (especially those making their first game) will find it useful or interesting. If you haven’t seen the game, you can play it here.

Some history about the project: I went into it knowing that this would be my first release and that I should keep it small and simple for it to actually be feasible to stay motivated and work it into a polished state. Way back in January I had this idea for a minigame: something bite-sized and arcadey to do with digging. The biggest inspiration behind the concept was probably Mr Driller, a game where I think the fun is in having to quickly scan your surroundings as you dig down and avoid putting yourself in a situation where you’ll be crushed by a falling block. I wanted that — but with more chaos.

I should mention my availability was all over the place and I would work on the game pretty sporadically, which is an awful way to make anything. I honestly thought development would take me a month or two, but due mostly to how infrequently I worked on it that didn’t happen. My first piece of advice is to keep notes on everything you worked on that day. Even if you are consistently working on it daily, having a living log of what pieces of code you touched yesterday or feature you only half finished is incredibly helpful to be able to pick up where you left it. At the start of the day I also like to write down a small list of what things I want to get done today to help keep me focused.

I knew I wanted a game about digging around a world of different shaped blocks that will react and fall and collide. How hard could that be? Turns out it’s quite hard. I genuinely think the majority of development was spent on figuring out how complete freedom of digging tiles from randomly generated shaped terrain blocks and have blocks fall and react with each other would work. It was really an iterative process of adding a small piece of functionality, it breaks other things, find a solution and repeat until I had something that behaved. I had to make some compromises in a few places, but I think the end result was very close to what I envisioned.

What debugging the terrain system looked like

There still wasn’t much of a game at this point. Collecting treasure made sense, but it’s really not that exciting just having a room to dig around and collect all the gems. This game needed action and a reason to keep you moving.

Here’s the remnants of the only piece of concept art on the game, a scribble on my whiteboard:

I think that writing was meant to say "Bring ore to bucket"

My idea was a big drill combined with a bucket being lowered through the earth and you would score points by digging out ore and carrying it to the drill. The moving drill turned it into a sort of auto-scroller, forcing the player to keep moving which adds to the excitement. I was insistent about not allowing the player to jump, this was a game about descending damnit! So I added the directional dash mechanic instead, which lets you zip across the central pit, and quickly get out of dangerous spots (possibly encouraging taking bigger risks).

The one area that went exceptionally smoothly was the art. It’s sorta my thang so maybe not a big surprise. All art assets started off as placeholder while I settled on dimensions, sprites were anything quickly slapped in that I thought was thematic and for the proxy terrain tileset I just used one of Kenney’s. If you want to know how I made the final tileset I have a write-up here. I honestly didn’t put too much thought into the finished art, which sounds bad, but most of it was based on the proxy assets because I thought they worked fine. Once animations and particle fx were in that’s when it suddenly felt a lot more polished.

Early version with placeholder art

Only in the last week before I planned on releasing it did I send it to others for playtesting. If I was doing something more serious of course would be playtesting as often as it made sense, but with this I wasn’t too fussed. It was still a mistake to leave it that late as others quickly made it clear that they didn’t like having to manually pick up gems, I trusted that feedback and changed it ASAP. Playtesting also brought lots of suggestions of things that could be added to the game, all great ideas if I wanted to expand it out but I’ll shelve those for Quazar’s Claim DX.

I put it out as a browser game on Itch for free. The process of making a page and uploading the game was super straightforward and it simply worked, so props to Itch for having an easy platform to distribute on. Release has been… underwhelming, if the stats are accurate. I posted on Twitter, Reddit and some Discord communities and likely only a couple hundred people have played it so far. That said, feedback has been great! Everyone has said nice things and that they enjoyed it, yet I can’t help but feel disappointed that it’s not getting much reach. The big lesson here is even if you have something of decent quality and it’s free and convenient to play, you still actually have to try hard to give it away. The same problems of an over-saturated market and difficult discoverability apply in this space, and if I wanted more people to find the game I would have had to actually put in marketing effort for the weeks/months leading up to release.

***

Here are some other various lessons gathered from my journey…

Draft up new features on paper before touching code

I’ve got a bad habit of thinking about the next feature and then jumping straight into the code without fully knowing what I’m trying to achieve. This inevitably results in hitting some roadblock and realising what I’ve just done isn’t going to work, but if I’d just jotted down some ideas/diagrams beforehand to fully plot out how it works, I wouldn’t have wasted time and effort.

Makes scenes/objects work independently

This may seem obvious but when you’re cobbling together systems it’s easy for different parts to rely on each other just to function. This ended up happening with my terrain system and meant that I couldn’t easily make small test levels with fixed terrain layouts.

Replace prototype code before getting too deep

When it came to the player I had very basic movement code from one of the earliest prototypes. When I needed to add more functionality I would just tack on another bit code that did the job for now but wasn’t ideal, which inevitably turned into one big mess. I knew I’d need a tidy state machine eventually so why didn’t I just spend the time adapting to that before things got out of hand?

Stress test systems that will be scaled up

This specifically happened to me with the terrain/tile system I had devised. It worked fine for one screen’s worth of tiles but once I added the endless scrolling and needed three times the amount of tiles active, it (understandably) created a performance hit and I had to rethink and optimise.

Create custom debug tools that make sense

I realised just printing messages in the log wasn’t going to cut it when it came to bug hunting. A lot of game state info was not visible to the naked eye so I had to write custom visualisers with important info that could be toggled for me to identify the trickiest bugs. It’s important to keep any debug stuff separate so that they can easily be turned off for release builds.

Record testing sessions when debugging

Many times I ran into timing-based bugs and the only way I singled them out was by capturing gameplay alongside the console log, then reviewing the video to pinpoint the exact frame something bad happened.

Do test builds regularly

I didn’t. It should basically be common sense, but I left it until the game was almost complete to do my first build and guess what? It was very broken and something was very wrong with it. I also discovered that the version of Godot I had built the game in had messed up web builds (which is what I was targeting), so I had to change engine version in the week before release which is regarded a pretty bad idea.

Find a musician and find them early

This probably applies to other roles too, but in my case I thought it would suck to have the same free generic music that’s already been used in every other zero budget game, so I thought I’d try my luck asking around if any musicians would want to make a piece for the game. I encourage others to do the same. You may be surprised to find that there are professionals out there who are happy to do something for free just because they like the project, plus it’s always good to make those connections. It’s very likely not going to be their biggest priority, so make sure to get that process started early on. THIS ADVICE IS ONLY FOR A GAME WITH NO FUNDING THAT WON’T GENERATE REVENUE. If it’s a commercial project please please pay people for god’s sake.

***

Plenty of mistakes and mishaps, plenty to reflect on and learn from, but that’s the case with anything you make right? I’m very glad I found this stuff out when working on a very small, low stakes project rather than something important and costly. I’ve come out of it with a smarter way to work which I’ll be using on whatever I make next. The important thing was making something fully complete and experiencing (even just a little taste) of every stage of the game dev process. It’s already been said a thousand times but it’s true: putting out a finished game of any size is bloody hard work. If you don’t believe me, I’d like to see you try fucko. Sorry, sorry, it’s easy to get defensive against the imaginary haters. What I’m getting at is you should be proud of the achievement of developing and releasing any game. I am.