Bell Master postmortem (Patreon)
Content
A game postmortem is all about figuring out what worked and what didn't during the development of the game. The goal of this document isn't to list things that could be improved in terms of design or specific features in Bell Master, but rather to focus on processes and decisions that can be adopted or improved going forward into the next game.
This document is going to be painfully honest, which means a lot of negativity. Since the goal is to learn and improve, it's acceptable. Also, I apologize in advance for any corporate speak, it's an occupational hazard. So, let's start at the beginning:
Initial release
Put simply, it was a mistake. I put up a rough and ugly prototype, looking for artists, in the wrong forum, destroying the games initial exposure. My programmer art was not passable and even using real porn would have been a better call. I didn't spend enough time learning the community before throwing my hat in the ring, and it showed.
I also dove head first into making the engine and prototype before fully completing the pre production phase. This led me to create a game scope that was unrealistic for my available time, which meant I had to take 4 months to rework a lot of the design to reduce the games scope drastically. This also rendered a lot of the engine work done prior useless as the features that required it were cut.
My decision to support mods on day one was extremely optimistic. It took a lot of time and effort and did not pay off in any meaningful way.
On the good side, my decision to add a cheating menu on day one was a massive win, both in helping make development quicker, and in providing quick solutions to players before bugfixes were rolled out.
Writing and story
Generally speaking my writing style was validated. The story was well received (even if the ending was somewhat divisive). And the Old Man character was both fun to write and fun to read.
Finding the wife's "voice" was difficult, and writing dialogues in general is still a struggle, with snarky monologues and scene descriptions coming much more naturally.
The "marketing" material for the game created a false assumption for some players, expecting the game to be a more generic mind control power fantasy. I need to pay more attention to the tags and game descriptions in the future as they are often a players first interaction with the game.
Pacing issues came up a lot in player feedback, more build up before narrative payoffs would have helped.
Project management and working with artists
The Excel based task management system I developed during working on this game works really well. All tasks were created, tracked and executed in a consistent manner. The two month release cycle also worked well, with no version feeling rushed or low on content.
Working with artists on commission is hard. Setting up scenes, finding visual references and communicating what I want drawn is a time consuming process. I still prefer it to using 3D art software so it'll have to do until I get a permanent artist on anything resembling a viable wage.
Two artists flamed out during the project leaving me to find new ones mid version, the lesson being never to rely on just one artist for a project. On the good side I did get finding new artists down to a science. With the commission audition system proving itself in terms of cost, time and benefit.
My current art budget still only allows for a small amount of art each month. This is a limitation I must take account of while designing the next game.
My refusal to open a Patreon earlier was misguided. The increased art budget really helped towards the end of Bell Master and could have been bigger if started earlier.
Tech
Rolling my own dialogue engine was a double edged sword. While I learned a lot and had fun tinkering with it, and it did allow me more freedom to tailor features to my exact needs, it probably would have been more efficient to use a 3rd party asset for this. Lack of proper tooling made adding new scenes a manual, error prone chore.
Using Unity's animation system allowed me to relatively easily add animations to the game. This was a massive win. However my handling of animation transition was very poor, leading to the need for some very ugly hacks when saving and loading animation states. This must be improved going forward.
Emulating a lot of known and liked features from renpy was a really good decision. Specifically save anytime and the mouse control scheme got good feedback. Adding a text skip option would have been even better.
While Unity has its quirks and some of its bugs are beyond me, it has made development easy and quick, allowing for more design freedom, easy animations and cross platform support, in a language I actually like working in.
QA and bugfixes
I gladly accepted AWolfes offer to QA the game. He's been invaluable and a joy to work with. I consider him a part of the team going forward. The QA process evolved as we worked together to a point where we both agree that it works well. There were very few bugs in each release and none embarrassingly game breaking.
I initially had a bad habit of rushing to release versions after one QA cycle. This has been addressed and corrected during development.
There was enough time left before and after release for QA and bugfixes. Iterations were rapid, collection of bug reports was well organized and hotfixes were delivered quickly.
Gameplay and design
I took 4 iterations to refine how stats worked in the game. Taking in player feedback and adjusting the design to make it more fun without compromising the games core. This was a first practical implementation of my approach to game design and it proved itself very effective.
Having a minimum of grinding was a design goal from day one, and was both achieved and praised by players. The game is short and sweet instead of longer but tedious.
The dates feature allowed me to add side content while slowly building up the main game. This worked well with an episodic release structure. A similar feature should be considered for future games in the same release structure.
The dynamic nature of the game made it hard to add music to it. I need to consider how music integrates into my design much earlier in the process.
The lack of music and minimal sounds were the right choice in terms of time and money, but still hurt the final product.
Taking the time to polish the UI and overall presentation really paid off. Having appealing screenshots helps with marketing and frankly a pretty game is more fun to play and to work on. To improve for next game, UI polish step should happen as soon as the game design is finalized.
Community
I was generally responsive to community feedback. The weekly updates helped keep the project on track and the community engaged. I made it a priority to be as available to the community as I could and it's been a mostly positive experience.
I could do better in making the discord a more active server. I still don't really "get" discord.
I did not pursue any cross promotion or other meaningful collaboration with other developers. This was a missed opportunity.
I've made a connection both with players and other developers through the development process, cultivating ongoing conversations that have been both enlightening and fun.
Release
The final release went smoothly with only minor bugs reported and quickly fixed.
Weekly updates going towards the final version helped build up some hype and manage expectations.
After the release, I was a little exhausted and am still playing catch up with responding to feedback and questions. As well as ramping up to the next game.
Conclusion
Bell master was all I could ask for and more in terms of a first game. Despite making several mistakes, I've established a good working system for developing games with the limited time and money I have available. The game turned out strong and I've learned more than enough to make me confident going into the next one.
Did I miss anything crucial in this postmortem? Did you learn anything interesting from reading it? Will adding random questions at the end lead to more comments? Let me know!