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

December 30, 2008 Leave a comment

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

February 14, 2008 1 comment

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

Categories: Solutions Design

Common to uncommon… unlearn, learn…

February 12, 2008 Leave a comment

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

Categories: About