Posted On: 2022-11-14
As of October, it's been four years since I first began work on this project. This is an important milestone: when I first imagined working on this, I knew it would take a while, but I'd thought that, by four years in, even if I wasn't done, I'd at least have the end in sight.
That is not where I am today.
This project has been full of unexpected issues and delays. Within the first three months, the core idea for the game was prototyped, and then abandoned (see the linked post for a refresher on why.) Since then, the project's struggled to find its core mechanic.
Where the notebook provided clear (if faulty) guidance to focus all my efforts on a single purpose, the ensuing lack of focus has been quite hard on the project's overall health. Features that ordinarily would be fairly contained in scope (saving, art style, character dialogue, pathfinding, etc.) have each, at one point or another, ballooned in scope as I tried to give them some twist or quirk that no other project has. Ultimately, none of them became a "killer feature" and, what's worse, this complexity has come at the cost of maintainability, as prototypes and abandoned implementations are intermixed with the pieces that did turn out good enough to keep - leaving the whole project bloated and hard to understand.
Along the way, I've also implemented, and later replaced, essential parts of the project. The game's dialogue system was mostly built around Yarn (including a custom writing tool to automate parts that were proving difficult to maintain), but I ultimately scrapped that in favor of Ink and its superior editor, features, and workflow.
Likewise, the game's core physics system (2d movement, platforming, etc.) has gone through massive changes as well: the very first implementation was entirely coded by hand (on weekends/holidays 5+ years ago), and the ensuing rigidity and unexpected obstacles convinced me a third-party tool would be best for future work. As a result I built the Magic Training Prototype around the (now-defunct) Rex Engine, which worked great for that smaller project, but has since brought a lot of headaches as I try to connect it to other systems (ie. saving, scene transitions, flight, etc.) By this point, I'm only using the bare minimum of Rex Engine parts (it refused to play nice with flying) - but even that will change soon.
Lastly, I spent the better part of this year implementing pathfinding and, unfortunately, it's not been going well. While it is technically working, the current implementation promises to be a significant long-term maintenance burden. The vestiges of Rex Engine demand a completely different approach to pathfinding, and trying to get the (third-party) pathfinding system to handle the available forms of movement has brought bugs, slowdown, and complexity that, while individually manageable, increase significantly whenever the different systems overlap.
As I look back on all the challenges, half-implemented ideas, and third-party code that disappointed, it seems clear (if a bit frustrating) why it's taken four years to get where I am. Realistically, though, I can't move forward getting the same results: four more years of those same struggles won't result in a finished game - and I want to be done in less than that. I've been thinking a lot about this, and settled on several important things I need to change:
What I do with my writing has to be the reason people seek my project out.
At this point, I have more dead/broken code than actually working code in my project. If it doesn't work, it needs to get out.
I've been too lax about using automated tests - not least because Unity makes it so difficult (no mocking, tests run inside editor context, etc.) Unfortunately, this means the difference between "working code" and "broken code" is defined by (undocumented) manual tests, so there's no way to accurately confirm that "yes, this feature was implemented fully" (or that it even works today.)
A decreased tolerance for scope creep alone is not enough, I need to arm myself with the tools to enforce that. Both up-front planning and scheduled check-ins/deadlines are useful for this: the former can weed out bad ideas early, and the latter can help catch scope that increased mid-task.
While I am confident these changes will improve my overall productivity; I have some more concrete changes in mind - including some that impact the blog schedule and content. I hope you will join me next post (the 28th), where I will detail turning this scope-cutting ambition into a proper plan.