Post-Mortem - "Boat Game" (Prototype)

After what, nearly a month, give or take half of that. You'd expect an update on this prototype. But before I even get to bug-fixes, and other possible tweaks. I had to first look inward, and assess myself, the process this prototype was developed, and other canaries. This took awhile, but in reflection, I feel it's always worth it to ensure I can try and work on improving my own development, that will go to help improve my future projects.

End result of this reflection, is a personal evaluation that I'm allowing public downloading of, in the namesake of transparency and what-have-you, and it's also linked within this Post-Mortem. Provided below, is the summarized excerpts of that evaluation that ultimately went into this post-mortem.

The Context

After a belated delay from my last project, which took two months to develop in total. I intended for my second 'actual' project to take less time to develop to a bare minimum standard, under the lens of "Game Jam" length, which is one-to-two weeks at most. So I got cracking on the basic plan and attempted rapid development of this prototype from the envisioned blueprint.

However, technical difficulties alongside excessive iterations on my end, led to delays that ultimately, made this second published prototype of mine, take roughly two months at most to develop. Essentially the same length of pace as my past project. Which in total, has become a reliable enough standard for how "long" it'd take for me to develop a prototype for a possible game idea, to build on at a minimum.

Now, I can probably cite in more detail, my process log. But I feel that for this post; better of saying only my key findings in key sections here, abridged and all. Instead of risk repetition. For those curious on my process of development, I've added an attachment to the main project documentation involving my own personal evaluation.

What Went Well (The Good)

Strong Vision
For context, given my previous iterations on a similar concept, on a boat game (not released here!) during my Summer projects in my college/university days. I had a strong vision of what the game itself should be, in a simplified, "arcade" lens for the sample gameplay. Given some polish, it would help guide me not just in a polished demo, but lay the framework for theoretically, a fully playable, "indie game".

Simplified Scope
But that strong vision. Came the requirement to break it down into easy to achieve features, that can be done in as short amount of time as possible. It took some iteration, but I believed that I did it to a reasonable, "vertical slice" lens. Along with having a casket of lessons to learn when it comes to deciding on "bare minimum" features, instead of "nice to haves" for a playable proof of concept I have in hand

Low-Poly Art-Style
I did not regret the intentional use of aiming for as low a poly-count as possible, when it comes to ship models. Not just in order to dodge the trap of "taking too long" in rapidly developing the base, along with ensuring modularity when it comes to ship hulls and sails. But to where possible, also avoid being intense on the user's specs/end, in mindfulness. This not only led to the ability to rapidly scale my ships as and when required. But ensure a uniform style that if further developed, could at least end up with possibly a "good enough" art style for a "3D Indie game".

That said, personal experience with this wasn't pitch perfect. With some technical issues experienced with importing from Blender to Unity, that led to a bit of excessive twiddling in 'bug fixing' and other tweaks. Along with some tiny hindsight details from design to publishing, that I could be a bit more tactical under, while keeping to the lens of "low-poly count", and "low time waste/sink" in the amount of level of detail to put into each ship hull part.

Public Domain Outsourcing
Can't help but bear emphasis. But for last minute audio, I outsourced it to save time spent on creating folly or worse; background music. Of which, all the sounds I used, came from Freesounds.org. And all under the "Creative Commons 0" license, so I wouldn't have to worry about crediting in the short-to-medium term. When possible, I'll recalibrate everything to give due credits to all sounds used, regardless of licensing agreements being in public domain (or not).

What Went Wrong (The Bad)

Exhaustion
From physical tiredness, to mental blank-outs during development, ended up slowing the pace of my project by having lost energy and focus, that drained what motivation and passion I had for developing each part required for a functional prototype. I'm betting in some lens, it's probably a mix of persistent mental health and stress issues on my end, along with lack of "joy" that led to this being a possible factor.

… Iterative Learning
Though typically a virtue, on how development is a constant learning experience. I felt that for the scope of "get it working" order, I ended up re-iterating a key feature far too often to the point of procrastination. Instead of subscribe to the mentality of ensuring I "get it right, first time". Which ultimately, leads to the last point that badly affected my project's 'pace'...

Rushed Programming
What later led to the requirement of iterative learning, was this. Or either I spend enough time planning on what features I wanted on a "micro/small scale" lens, before recalibrating is needed. Or worse, in struggles to get things done in time, I end up later rushing my active development instead of taking due time to plan on other things like tasks, etc. This was probably caused partially by social pressure on my end, along with guilt over being a "slowpoke" with development pace that later on led to taking shortcuts that at times, led to the detriment of this project's full potential, as a prototype. That said, it wasn't without full faults, as I at least managed to do some "shortcut" debugs with some last minute bugs, primary sea/ocean related along with late-term simplifications of scope that should have been done at the start.

So in short, I fell under the same trap of placing too much emphasis of "doing", instead of "thinking" as my last project, which in turn led to more technical difficulties that led to delays and re-iterations, that ultimately made the project take two months to build.

The Worst Thing? (…And the Ugly)

Procrastination
By a lack of motivation, alongside a lack of visual reminders of what tasks I should do, along with what's *left* to do. Ultimately led to the feeling of "twiddling my thumbs" during development, in waiting and delaying features to do until 'later', led to active months of development, instead of the intended scope of "no more than 2/3" weeks in scale.

To a point, this root cause of vice was tackled by the late-minute (re-)implementation of a Kanban Board, to aid in project management. Which served to not only keep track of what's left to be done under a projected milestone deadline. But also gave me motivation in achieving tasks to ensure that a functional (and playable!) Prototype was built with a fast pace. Like knowing how far up I am, in having climbed a mountain. In that lens...

Lessons Learnt

Bar the key notes already mentioned in things that went well, and... not well. There's a few hindsight lessons I discovered during the course of development in hindsight. That had served to help me deal with things that did not went well, for my prototype project.

Project Management
Bars emphasis. But it helps to not just remind me of what's left to do, or scrapped in the "later/never" pile. But also to keep note on what I have achieved, to help with the mountain that is game development. As an aside, it also helps to keep track on the features needed to develop, simplify where need be. And to keep myself accountable, so I can ideally develop with purpose and pace, instead of waste half an hour trying to guess what I'm supposed to do blindly. More so, when given milestones to achieve key roadmap checkpoints by/at and all.

As an aside. It also helps to keep note on any features scrapped, and their reason. In case I end up with time to revise on development of other spare features, past the "core" of the project as it stands.

Paper Prototyping
Given the hindsight sunk cost I have under the length of prototype development taking months to realize instead of "Game Jam" Weeks. If I can skip the coding/development, and have the idea in 'flow' playtesting on paper doodles and cutout sheets. Then if done right, with dice and such. It can lead to not just more rapid iteration on a potential "third" prototype to develop alongside brainstorming. But can even be used in tangent with business analysis without being too stingy, on rejecting a developed prototype after months have been sunk in development.

Moving forward

Bar having to cutout repetition as/where needed for this post-mortem...

In reflection to my "slowpoke" pace in development, I'm at the stage where without assured employment or such to generate a more reliable income, I have to knuckle down and choose a prototype to develop further, into a playable demo to later on sell to the general public as a playable game, under this platform; itch.io or Steam.

And honestly? The prototype I have ultimately chosen for further development, is this prototype boat game. As bar some rough edges, I still have a stronger passion for, and faith in this project being able to maybe generate "some" revenue to me. So long as I stick to my guns, and polish the gameplay and content until it is done.

Regardless of choice. I'll likely have to take a bit more of a breather on games development. If only to look into any sort of social club to gather more energy/joy in my life, before I make further decisions under job hunting, and/or further development of this prototype at the expense of possible further game jams, or other possible prototype idea, on paper...