Difficulty and the prototypes

When we let off last time, we had a few different iterations on a rail-shifting platformer mechanic. We had a version where the player could physically shift to parallel rails, and a version where the player could shift between two colored layers in the same physical space.

The point of a prototype at this early stage in development is to demonstrate a specific mechanic and explore its viability. You don't want to include extraneous systems or elements, for two reasons: they can distract from the core experience you made the prototype to test in the first place, and they can also be a resource hog. Part of a prototype's appeal is that it's quick and dirty, and if done right you can get a sense for what's worth investing significant time and resources into before you have already done so. Therefore, in the interest of simplicity I did not give any thought to the actual level layout presented in the prototype. I threw some blocks on the rails and figured that was good enough. After all, we're testing the mechanic, not the level design. Why spend time fussing with developing a polished play-space if you don't even know if it's for something worthwhile?

The results from the prototype's first round of outside testing were therefore surprising. Players consistently remarked that the prototype felt too easy, and that they felt like maybe it would be more fun in later levels. More than one player noticed that both versions of the prototype were completable using only one mechanic, i.e. only jumping or only shifting. Because the prototype did not require players to actually use all the key mechanics, initial testers were unable to discern how the mechanic actually felt to play.

So it was back to the drawing board. The testers needed challenges which required interesting uses of the key mechanics, so the next iteration delivered just that. There were challenges which required jumping, challenges which required shifting, challenges which quickly varied between the two, challenges which required both at the same time, heck, there was even a later version which combined both shifting ideas into one prototype, featuring challenges which required all introduced mechanics in quick succession. These prototypes were ultimately more successful. Players were able to fully experience the shifting mechanic, and provide valuable feedback because of it.

Of course, this level of challenge density still wasn't ideal. These later prototypes had the problem of being incredibly difficult; players could easily die dozens of times in a couple minutes. Overall skewing too difficult is better than skewing too easy; players may get frustrated, and you may not get the average tester through the entire prototype, but at least they get to experience the key mechanics in a game context, as opposed to a prototype where the key mechanic might as well not even exist. Ultimately, as a team we decided to pursue another game idea entirely (more on this next time!) meaning that this was the last iteration of the rail platformer. However, if it were to get more attention, the difficulty would probably be lowered somewhat, just to create an ideal environment for players to experience the key mechanics. When creating an effective prototype, it isn't enough to simply throw in the key mechanic; there are often key sub-systems or supporting elements that are necessary to show your intent. In this case, it was difficulty.