Simulations Vs. Games – How to Choose Among, When it Comes to Learning

Simulations and games are a great set of tools to teach. Usually when it comes to making a decision about what is more suitable for a particular learning requirement, whether a simulation or a game, the decision is usually driven by personal preferences or past experiences.

Before we analyze what might be best for given situation lets consider the following facts:

Development Objectives

Games are played to be won

where as

Simulations are to be completed

Experience Objectives

Without imagination there is no game

where as

Without experience there is no simulation

 

Now lets take an example of the “Game of Football”. Hey, I am talking about the “Game” played on the field! Want to do something with football, virtually? Yes.. Ok, create a software utility that helps you learn how to dribble a football on your PC screen using mouse or keystrokes. It’s a simulation. Dribble it against a human or computer opponent, it’s a game. Both have their level of fun element. Add goal scoring to the game you made, its more fun. Add dribbling through obstacles in your simulation, again, its more fun.

Definitely fun is a spice for building games and simulations, but not a differentiating factor. Some simulations are more fun and some games are really boring. This is against the common belief that games have more amount of fun element involved. As a game designer, it’s your talent as a cook, how delicately you play around with spices.

Below I have listed some variables that can help decide whether a game or a simulations is more suited for a given learning situation. I am still working on them and will keep on fine tuning.. suggestions are welcome!

Learning Requirements	Simulations	Game Based Learning
Mission criticalness	High	Medium to Low
Required Learning Explicitness	Controlled, guided	By discovery or by chance
Learning modes	Show, Guide and Test	Test
Persistence of learning required	Medium to High	Medium to low
Skill building	Medium to low	High
Relative scale of Target System	Large to Medium	Small
Performance Support requirements	High to Moderate	Moderate to Low
Complexity of Target System	Medium to low	Highly complex to moderately complex
Targeted brain hemisphere	Left Brain Learning	Right Brain Learning
Number of variables in environment	Medium to High	Low
Design Effort	Medium to Low	High
Media Development Effort	Medium to Low	High
Technical Development Effort	Medium to High	Low to Medium

 

Agile Design Engagement for Solution Design

Solution Architect (SA) is the first person to get famous (infamous J),  when anything among cost, quality or schedule of a project goes haywire. So we SAs normally are very hard-pressed to get the best solution design possible. And in this pursuit we tend to take extra time and extra effort to come up with a recommended solution.Then I thought why not apply the principles of Agile Software Development (Agile Manifesto) to solution design and see what happens.

The principles of Agile Software Development are:

1. Early and continuous delivery
2. Late requirement changes welcome
3. Short delivery iterations
4. Business persons and developers work together
5. Motivated individuals
6. Face to face conversation
7. Working software is primary measure of progress
8. Maintain constant pace indefinitely
9. Technical & design excellence
10. Simplicity is essential
11. Self organizing teams
12. Team raises its bar & performance in intervals

Now read them again from solution design perspective only:

1. Early and continuous delivery
2. Keep continuously probing for requirements. Plan the probe
3. Short design iterations
4. Work closely with customers. Communicate early and often
5. Motivated individuals
6. Design in progress (DIP) is the only measure of progress
7. Maintain constant pace indefinitely
8. Communication, planning & design excellence
9. Simplicity is essential
10. Learn, adapt and perform continuously

Having fast design iterations can have following advantages:

1. Always in face of customers (internal & external). Let them also own the solution. You will always land closest to the required solution
2. Better personal relationships with customers because of continuous communication
3. Judgement about the worthiness of a project can be made early. Early evaluation of a good or a bad opportunity. You can save costs for your customer and problems for yourself and your development team
4. Design iterations will make design evolve and the evolvement will be in the right direction, towards correct solution.
5. Best for a partnership approach towards customers with clear benefits

Common to uncommon… unlearn, learn…

Big things happen only when we are able to spot small things happening. Whether an apple falls to ground, or water out of a bathtub, finding the uncommon out of common is the key, and is the challenge. Welcome!

– Jatinder