Posted On: 2018-11-29
Before I dive into today's blog post, I wanted to mention again that I made a prototype last week and if you haven't looked at it yet, you can still download it from my page on itch.io. I'm planning that my next blog post will be a short retrospective for the game, so if you want to get the most out of that post, I recommend playing it. For today's post, I will be writing a bit about a problem I ran into while developing my next prototype (a short puzzle game called "Bypass".)
For a bit of background, the game is about connecting several objects together, including an energy source, so that it forms one large connected chain of objects. I also added the ability to "detonate" the connected objects, which would remove them (and the player would be scored on how many of the objects they were able to remove.) I made a few levels and gathered some feedback, to see if this was a good foundation for a game, and it seemed to be turning out alright. In the process, however, I discoved that detonating objects was not particularly satisfying for players and limiting for the kinds of puzzles I could make.
After brainstorming different kinds of interactions that could be supported with this system (connecting things to a power source), I decided to work on trying to implement the most ambitious one: making a system that allowed you to go inside a "broken" object so that you can connect the power source to an "output", which then would then "fix" the object. This would allow me to create puzzles within puzzles: for example, one puzzle could have a broken power source, so the player would go inside it and solve another puzzle to fix it.
I've spent the past few weeks working through the details of implementing this system, and I've gotten it to the point where it is technically functional, but requires quite a bit of work before it can be called a game (right now it's more of a technical sandbox.) Unfortunately, from what I have right now it doesn't appear to be making the game any more fun, just more complex (to code and organize.) After making a list of all the things it would take just to get it from technically complete to actually fun, I realized I was in for at least a month more work, and I wasn't confident that it would even be all that fun once I was done.
After talking about it extensively with my (very patient) wife, I realized that what I am facing is the Sunk Cost Fallacy: the ambitious mechanic is not worth the cost of seeing it to completion, but I keep trying to justify doing so anyway. One of the contributing factors to this is that I wrote a detailed blog (originally intended to be today's post) that explained how I implemented persisting changes between inter-connected puzzles, through the lens of these changes improving the game. For all my experience cutting losses and cancelling prototypes early, it seems that telling people about something (either directly or via a blog post) still has a lot of power over my decision-making.
There are several pieces of good news about all of this. Firstly, I had the foresight to branch the code (and assets) for Bypass before starting working on the new system, so I should be able to switch everything back to the version before I implemented any of those changes. Secondly, even though I won't be keeping any of the work I did, the skills and knowledge gained should be helpful if I need to persist data in future projects. Finally, the hard lesson of all this: that writing/speaking about a topic means I may try to defend it even when I know it's not right, is something that I must keep in mind in the future. After all, the only way to be right is to find out you are wrong and then change your mind.