Our input system isn’t hard to learn – neither are the bite-sized Spanish concepts we introduce in our exercises. But if you were to present players with our icon interface and ask them to play, they wouldn’t have a clue what to do – this is inherent in the design of Minspeak, where we favor the expressiveness of the icon set over the initial guessability. In much the same way, if we asked players to read text or view a clip about how to use the icons, their eyes would glaze over. The way Minspeak is taught in a disability context is through coaching the player and having them work through small examples – in the digital world, the analog to this is an interactive tutorial.
Our tutorial is one of the most sensitive areas of our prototype – any failings in the tutorial lead to the player either being unnecessarily frustrated or completely stymied in the game. Careful tutorial design and iteration was essential for achieving the success rates we’ve seen – to support this, we created a data-driven state machine-based tutorial system that lets our actual transition logic mirror the flow presented in our tutorial design.
The pseudo-code in the diagram above demonstrates the Tutorial States are specified declaratively entirely in terms of the actions they take and their transition logic. One key we found to maintaining a sane architecture is ensuring that no state is shared between entrances to a Tutorial State, as they are inherently re-entrant. Java doesn’t support anonymous functions or closures (“lambdas” in some languages), but its facility for anonymous subclasses allows us a slightly more verbose alternative – we use these to provide a method to generate a new State every time we need that state.
Another point of note about the architecture of our Tutorial system (in particular the state machine architecture we built to base it on) is the gradual shift we went through from deep inheritance hierarchies to aggregation. Specifically we found that the types of actions and effects that Tutorial States have (like posting messages, showing arrows, changing animations, adjusting UI elements) tend to be very common ones that can be shared across many states – instead of specializing it makes much more sense to simply attach the ones we need. At the same time, inheritance served us well even after our architectural shift, in that we could bundle common effects and transition logic in a way that supported easy future modification.