Development Update #23

Hello everyone!

Welcome to the twenty-third development update for Haunted: Attack of the Dead Men.  As I said in the release announcement, this update will be the last of the monthly updates and will serve as a postmortem of the project.

Before I get into that though, I do feel like I need to set expectations for the future of the game.  I will go into a bit more detail later, but unfortunately the game didn't do as well as I'd hoped based on the pre-release feedback.  It's actually quite difficult - as I found out the hard way - to stay motivated to work on something that's had a number of negative comments (excluding constructive criticism), so I've decided to reduce my focus on Haunted: Attack of the Dead Men in favour of other pursuits.  This does not mean that the game has been abandoned, as I still plan to release updates for it, however I have decided to reduce the scope of these updates for now.  Of course, if something changes and the game gets popular again (for example, in a Steam sale or other promotional event) I may reconsider this decision, but for now I am much more motivated to work on a new project which I will briefly cover at the end of this update.

With that out of the way, let's start with what went wrong so we can finish on a high note.

The Bad

It Always Takes Longer Than You Think

Trying to determine an accurate release date is a very difficult thing to do.  When I initially set the release date for this game, I wasn't sure how long I'd be able to sustain my own interest in it so I went with a very overly-optimistic estimate to try and finish it in just over a year.  However, it ended up taking almost two years, which meant I had to delay the game twice and I was very reluctant to delay it a third time.  As I would later discover, managing a release is quite a stressful experience, and the pressure did start getting to me in the final month as I still had a few last things to implement and a rapidly approaching deadline.

Map 13 was finished just two months before release

On a related note, I have since learned that it is a good idea to make sure the game is (mostly) finished well in-advance of the actual release.  Making sure that the last couple of months or so are focused only on small things like bugfixes and polish can really help to ease the stress of actually releasing a game.  Additionally, it gives time for reviewers to play the complete game and have their reviews ready for the release date, while also giving beta testers a bit longer to hunt for bugs.

Lesson learned - don't commit to a concrete release date until you are really sure you can make it, and when you do give yourself a few extra months.

Mechanics Before Mapping

This was a mistake I made early on, long before the consequences became apparent which made it very difficult to rectify.  Level design is very difficult to get right, especially when you have no feedback to iterate on.  The first four levels of the game were made without getting any real feedback outside of a few friends, and when the demo was released there were still eleven more levels to make.  I decided to focus on getting the rest of the levels done first and implement any mechanics they needed as I went.

A very early screenshot of Map 5 from the first development update!

However, when the demo started gaining steam and more players gave their feedback on those early levels, I felt that trying to redo them from scratch would take too long.  So, I did what I could to address more specific concerns but stopped short of throwing them out entirely.  That was a bit of a problem though, as those early levels are very important for getting players hooked.

One reason for this odd approach to level design was simply because I never expected to actually release the game when I started working on it more consistently about three years ago.  At that point it was still only a hobby project and I had a lot to learn about good level design - knowledge that would help a lot when making the later levels.

Lesson learned - figure out all of the gameplay mechanics first in simpler levels, then commit to proper level design when players are happy with the mechanics.

Develop Efficient Processes

Another reason why it was difficult for me to redesign the early levels was that I didn't have a very good workflow for making them.  I used a mish-mash of engine features to produce them - for example, many levels used Godot's Gridmap nodes (essentially like a 3D tilemap where models can be "painted" in the world), while others used terrain generated in Blender with various assets added on top.  The workflow for creating levels often involved flipping between several different tools and applications, and working around various engine issues with some of those features.  This slowed down the level design process a lot, and while I was able to improve my efficiency over time it still wasn't a great workflow.

Map 7 was crafted with a mish-mash of some very oddly shaped Gridmaps...

Ideally getting this right is something you do at the start of a project, because when you've been building a game using one way of doing things for a while it gets harder and harder to switch to different ways of doing things.  It would be very inconvenient if, for example, the first half of the game was made one way and the second half another way - it could introduce bugs and other problems that are specific to only one half of the game.

Lesson learned - I need to start my next project with a better way of doing things.

Don't Upgrade the Engine Half-way Through

OK, this one can be very awkward to deal with when a major new version comes out half-way through development.  I started the project in Godot 3.4, and later switched to Godot 3.5.  However, a lot of very important (and useful) features were coming in Godot 4.0, which initially released a few months after the demo.  This created a huge dilemma for me, as I knew I needed some of those features but the game was already half-finished by the time I decided to upgrade.  This upgrade set me back by a whole month and created a number of bugs, some of which I was never quite able to resolve.

Upgrading the engine was difficult but did provide some nicer visual effects

Lesson learned - next time I won't get quite so jumpy if Godot 5 comes out half-way through my next project.  Although, that seems very unlikely right now.

The Good

Release a Demo

Demos are really good in many ways.  They are good for players as it allows them to try the game before buying, and they are good for getting feedback and building a community before release.  Doing so also helped me to commit to finishing the game, which was quite daunting given that I'd never done so before.

Development Update #1, published a month after the demo was released, showed off some new weapons

Get Feedback Early

This is something I think I got right with how I managed the demo.  I decided to participate in Steam Next Fest early on (only a few months after the initial demo release), and despite the game being very rough around the edges it still got way more attention than I was expecting which led to a good amount of feedback.  I will definitely do the same for my future projects, but I will likely focus more on getting the store page and branding right first to make them stand out better.

Development Update #5, published a few weeks after Steam Next Fest, revealed the train in Map 7 and garnered quite a bit of interest

Keep Players Updated

Writing these development updates was very useful for two reasons - it kept players informed on what was going on, and it also helped me to break the game down into month-sized chunks.  By breaking the game down like that, it became a lot easier to manage and decide what to work on, as I only had to figure out what I wanted to show off in the next update rather than wondering how I was going to actually finish the game.

Development Update #22 was the final update before release.  The game took approximately 22 months (and a few weeks) to finish!

Get Good at Planning

If you want to see a project through to the end, you have to have a good way to organise and plan the next things to work on.  After trying and failing to work on things ad-hoc, with a bunch of notes containing jumbled up ideas I wrote down as they came to mind, I decided to use an issue tracker to organise things properly.  I think this single decision is why the game got finished in the first place - it was really important for helping me to understand what needed doing and allowed me to plan what to work on next.  Later on I started using milestone tracking which became very useful for planning updates to the demo (and later the beta).  If you want to make a game of your own, but it feels too daunting, it's a very good idea to start by using an issue tracker!

What's Next

As I said at the beginning, unfortunately Haunted: Attack of the Dead Men did not do as well as I'd hoped.  This isn't anything I could have predicted, and I am very grateful to everyone who did decide to buy the game, however before release the game was getting a decently large number of wishlists which unfortunately didn't translate very well into sales in the first month.  Of course, I can't know exactly what the reason for this is - it could be that wishlists are simply not a great indicator of how successful a game will be, and my expectations were just too high.  Or, it could be that most players are waiting to pick it up in a sale.  Nevertheless, I have decided to focus a bit less on Haunted: Attack of the Dead Men for now.

I have spent the past two years working pretty solidly on it, and it is about time I took a break from it so I can return with a fresh perspective.  I am more than happy with what I've been able to achieve, and at the end of the day this game is just the game I always wanted to make.  It was the game I often daydreamed of making as a teenager when I should have been paying attention in school.  But if I want to make use of what I've learned, I need to be able to move on from it and try something new.

Which means that this isn't the end of my game-development projects, far from it.  I found it very difficult to actually take a break from my hobby, so after about two weeks I was already starting work on a new project - something where I can test new ideas and apply the things I've learned (especially the things I've mentioned in this update).  That something will remain a bit of a secret for now, but I will say this - it will be a first-person horror game, and with any luck there will be something to show off by the end of this year.  But why not, I'll throw in a screenshot as a reward for reading this far.

What lies at the end of this dark corridor...?

But that's quite enough for now.  If you made it to the end of this update then congratulations, that was a lot to take in!  If there's any aspiring game developers among my audience, I hope this update proved somewhat useful to you as that was one of the reasons why I published this kind of update.  For everyone else, I hope it's provided some insight into how a game is developed and why things tend to happen in the way they do.

As always, thanks for reading!