Posted On: 2019-03-25
Working as a solo developer on a project brings some interesting challenges, compared to working in a group. One of those challenges is managing priorities: when working with a team, usually there is one (or more) people responsible for understanding customer needs and making the tough calls about which features/bug fixes are worth delaying the release, versus which should be cut. As a solo developer, however, I find myself having to make those kinds of calls alone, which can be difficult, as making impartial judgment about whether working on something is worthwhile is particularly tricky when you are knee-deep in that problem.
Ordinarily, I try to prioritize things that define the core experience (core mechanics, main narrative, etc) as well as resolving bugs that detract from that core experience. Unfortunately, for the particular project I am working on, the aesthetics are considered a part of the core experience, so I have something of an ever-increasing scope problem (I like to think this is because my art is improving, but it's probably more that I am not yet skilled enough to produce quality work in a reasonable time frame.) Fortunately, I recently realized that I can expect multiple "releases" for this prototype: I am already planning for multiple rounds of gathering feedback, so it seems reasonable that I wouldn't have everything working perfectly for the first one. Of course, the risk associated with that approach is that I don't want gathering feedback to be distracted by bug reports: fresh eyes for a project are (currently) hard to come by, so I want to make sure that I can make the most of each opportunity.
Having realized that I don't need to finish everything right away, I've taken the time to work through prioritizing which aspects are worth resolving immediately (things that I am confident harm the core experience) versus things which I will delay resolving until after some feedback has been gathered (things that I think harm the core experience, but that wouldn't hurt having a second opinion on.) As such, I will be trying to set expectations for initial playtests appropriately, and identify which specific things I should ask in order to get that second opinion.
After working through the list of all the things that I think need to be done, I was pleased to discover that most of them could be safely delayed. I still have one rather large task (something I had planned to completely rewrite, so it's still full of bugs,) but, for the first time, I feel like I can see a future in which I will (finally) get some feedback on whether or not the game will be fun to play. With that being said, it won't be listed on the site until I've gathered and applied enough feedback to be confident that the core experience should be unimpeded for most players. If you are interested in testing an earlier version please reach out to me and I will talk with you about what to expect and how to provide feedback.