We’ve had our fair share of digital learning game development projects; and a recent one threw a spoke in our design wheels like never before. Thought I should share the top five things we learned from our experience.
1. Be absolutely certain about the game objective; what must the player do to win? – We had varied ideas and that resulted in a multitude of win-states, not nice for a learning game. Make sure to tie down to a singular objective, and one that is achievable given the game mechanics. Eliminate game mechanics that do not explicitly tie to the outcome.
2. The game environment needs to be dynamic – nothing in the real world is static. If a player chooses not to do anything, the game environment must still change, and adapt to the ‘non-play’. Ideally, there must some penalization of the player for not making moves, after all that’s what the game-play is about.
3. Be sure of how you score players – decide on what variables the score will depend, what clearly defines a winning score and how the system will compute it. If a player can’t understand how actions in the game relate to an increase/decrease in score, there is very little motivation to pay attention to the score, consequently to the win-state. Also, make sure you work out the formulae to calculate the score right at the beginning, the more variables in your game, the more complicated and difficult to develop it gets.
4. Include a ‘How-to-Play’; right from prototyping stage – as designers and developers of course you know how to play the game. The other stakeholders do not; don’t take their game play experience for granted. Secondly, chances are not all stakeholders are familiar with exploratory game-play; rather than explore, they’ll just click around a little and quit; and based on that loose and limited experience will want to make changes to the game, which the designers and developers will find hard to stomach.
5. Design is one thing, development is another – It’s very easy to get carried away by the vision of the game-designer. They imagine all sorts of things, but not all are practical during development; sometimes (mostly) as a direct result of the cost and time available for game development. Know the budget and timelines and tailor your game design around it. Otherwise, as time goes by, you keep reducing the feature set to match the timeline/budget and end up with a game that looks nothing like what you pitched to the stakeholders as a designer. Which almost invariably leads to disappointed stakeholders.
Goes without saying, we won’t be repeating these mistakes in a hurry ever. More careful consideration will be accorded to game design and development on a budget.
