I’m making decent progress on the new prototype. It’s exciting to be working on a whole different genre. This time, I’ve approached prototyping a bit differently.
The Point of Prototyping
I don’t think it’s controversial to say that the goal of making a prototype is to find out if an idea has potential while expending the minimum amount of effort necessary to expose that potential. The smaller that effort is, the faster you can prototype, which in turn means you can create more prototypes (or iterate on them faster). This translates straightforwardly into better products.
Potential: Disguised By Inaccessibility
For prior game prototypes, I made the odd assumption that explanations/tutorials weren’t worth investing in for a quick-and-dirty prototype. After all, we just want to know if the core mechanic is interesting or enjoyable. It’s not unreasonable to expect the tester to try the idea for a few minutes.
In truth, I’ve never had this work reasonably. Partially that might be explained by not having a ‘proper’ testing setup, where someone has agreed to test for a duration. Even if true, since that won’t change in the near future, I still need to solve the problem.
Another partial explanation could be that game devs, in order to minimize time to hook a player, have become skilled at using clear graphics and visual/aural prompts to guide player behavior. Thus, players expect there to be hidden meaning in the graphics and animation that simply isn’t there (or hasn’t been reworked repeatedly for clarity).
Yet another explanation could just be that I design confusing mechanics!
Whatever the reason, my desired outcome is the same: I want to know if the idea is any good, and I am not reliably getting that information.
Tutorial-Driven Development: A Better Way?
For this prototype, I’ve decided to try an experiment: I’ve sacrificed a significant portion of the initial 25 hour budget to implementing reasonably clean placeholder graphics and effects, along with a tutorial that guides testers through what they need to know to explore the specific feature I want to test.
One unexpected (though intuitive) benefit has been that I don’t need to worry about building out any more of the game than is necessary to drive that guided tour, and a little bit of a test-drive afterwards.
Another benefit is that having to find ways to clearly explain the mechanics has helped shake out some unnecessary complexities of the system.
The obvious downside is that this approach leaves fairly little time to actually implement interesting mechanics, so we’ll see how it pans out. Hopefully the time spent working on tutorials can be shortened significantly by familiarity and creation of a reusable package.
Altogether, this is one of those decisions that makes me feel my lack of experience. It’s unlikely I had it right the first time, and it’s unlikely I’ve found the Truth now. It’s frustrating to labor under incomplete understanding, but I guess that’s life.
—
And that’s that, for now.