MLEARNING AND GAME CREATION
In earlier articles, I emphasize the subject of gamification and the importance of making learning fun. Today, it’s time to take a look at the process of developing an actual mLearning game, from the idea to execution.
The Game Plan To realize your idea of making a game, you must have a plan – a clear vision of how to get from start to finish. For my game plan, I decided to break the process down into four stages:
Proposal/Game Design
Alpha/Game Functionality
Beta/Game Polish
Delivery/Distribution
The Proposal If you are working for a client, your project must first be approved before you can count on funding it. The proposal is a game idea pitch, an opportunity for you to share your concept of the game with the clients and discuss any modifications to the look or function. Often, we present three ideas for games to a client, and let them select one.
Game Design Document and Storyboards Once the game is selected, it must be documented in a Game Design Document. This is the game Bible, the script detailing every aspect of the game. It is the vehicle of communication for all team members working on the game.
There are free templates for game design documents on the internet. Some of the contents are specific to a particular game type, while others are more general. Some items that should be found in a game design document include:
A game overview, answering questions like what is the game about, what do you control, what is the style of the game, and what is the objective/winning condition.
A list of all screens, detailing all functions that can be performed on each screen.
Description of features and game play.
If appropriate, world layout, game characters, storyline.
Guideline to UI (User Interface), art direction, sound/music direction.
Appendices to character sketches, scenery/set design, monsters/villains, vehicles, architecture and objects found in the game.
Based on the Game Design Document, the next step is to create Storyboards for every screen in the game, providing a concrete visual guide to the 2D and 3D artists working on the game.
The Alpha Stage During the Alpha stage, the focus is on game functionality. The appropriate IDE / programming language / development kit must be selected to code the game, depending on game type and target platform. If the game uses a 3D engine, the appropriate engine must be chosen.
The goal of the Alpha stage is to create a functional game, albeit some of the graphics and sound are not polished yet, and some of the functionality may need to be refined. However, all-in-all, by the end of the Alpha stage, the game should be playable. The deliverable at the end of the Alpha stage is a straw-man version of the game, which means the skeleton/back bone is there but still needs to be fleshed out.
At the end of the Alpha stage follows a period of Alpha testing and debugging. The Alpha testing can be done internally (by the people working on the game), and reporting should be coordinated by someone who will sort the bug reports by priority and eliminate duplicate reports.
On to Beta During the Beta phase, the focus is on polishing the game. This is the time to focus on graphics, animation, sound and music, and really dazzle and jazz it up. The programming team must also work out all the problems encountered during Alpha testing.
It is not enough for the game to be playable. The game should be beautiful! For example, when the player gets points for some action, the points should not just appear. They should pop up with some visual and sound effect. The controls should be refined – when the character comes to a stop, there should be a slow-down or deceleration. The character should not go from a full run to a full stop with no transition.
There are more things to polish in a game than I can describe. If you are a careful observer, try to pay attention to all the little special effects and animations that occur when you’re playing a well-designed game. Often, you won’t even notice the little fading effects, or the movement of animated backgrounds, the mouse-over effects of buttons, and all the little intricacies that go into making a game polished.
The famous Beta Test Beta testing is famous because this is usually the first chance the community has the opportunity to try out the game. By this point, the game should be polished. The reason to open the test up to people other than those working on the game is to get input from the experience of a user who has never played the game before. Is the game too hard? Too easy? Is it boring? Is it well balanced?
Beta testers should be encouraged to find every possible way to “break the game”, or any game mechanics. Again, reporting should be coordinated by someone who will prioritize the bugs and eliminate duplicate reports. After Beta testing and fixing of the problems found, the game is essentially ready for the market.
Delivery and Distribution Often, the delivery requires multiple platforms (PC, Android, iOS, etc.) and porting the code must be taken care of. Other requirements may be translating the game into multiple languages. These considerations should be known from the onset, and appropriate planning put in place so that the porting and translations will occur smoothly.
Bringing eLearning into Gaming The process I described above applies to creating any sort of game. At my company, we focus on creating games with an eLearning element. Sometimes it can be as simple as asking a multiple choice question at certain points during the game. Other times, the eLearning is much more integrated into the storyline and character advancement.
If you would like to explore more about gamification and eLearning, take a peek at our company website: Pathways Training and eLearning, at http://www.pathwaystrainingandelearning.ca/ . We always look for fresh ways to engage the learner and to make the experience as fun as possible!
