I have seriously misjudged M. David Merrill.

His Component Display Theory was very computer sciencey, and unwieldy, and really turned me off; but First Principles is *really* good. Thank you Gail for pointing me at it!

I’ve had this notion for a while: that the process of becoming an expert is a very long one (with the exception of the occasional aberrational protégé). Eventually, along the path to becoming a ‘master of your craft’, most people seem to discover the big picture (perspective), which seems invisible to beginners. Beginners concern themselves with lots of details (and with exhaustive inventories, catalogues, prescriptions for how-to, etc.); masters concern themselves with first principles (the essence).

After reading this, I want to ask, “What more do I need?” This seems to say it all. (and how come nobody put this under my nose before?) http://id2.usu.edu/Papers/5FirstPrinciples.PDF

I agree with almost every claim he makes (although I think that fantasy problems can be just as compelling and facilitating as real-world problems), and, even better,… good games are already designed to meet all of these First Principles:

Activation:

the back story gives clues as to the kind of knowledge that will be needed to accomplish the mission. This gets re-inforced throughout the game (gameplay is typically monitored and certain actions on the part of the player trigger intervention by the game with more information, offers of help, etc.). In a sequel game it is even easier: it is a given that the sequel will expand upon what players learned in the previous version. In fact, sequels that don’t do that are typically panned (=? no sales =? game fails =? developer doesn’t do *that* again)

Demonstration:

games are often quite clear about what the player will need to be able to do/ achieve in order to accomplish the mission. Media plays a starring role here (animation clips, audio, flashbacks, etc.)

Application:

skills are learned and knowledge is gained and as the player becomes more competent, the difficulty level gets ramped up – eventually culminating in a “level up”, where new challenges are presented, twists on ones already learned, etc. Players have constant feedback ingame – stats on their progress, vitals on their avatars, remaining resources, etc.

I really LOVE “Appropriate practice is the single most neglected aspect of effective instruction” Hear, Hear! and, Hear, Hear! again!

You can’t rush mother nature. (wasn’t it the Green Giant who said that?)

Here is where good games absolutely shine – just imagine what we can do if we can entice people to willingly spend 5-10-30 or more hours practicing?

Integration:

-publicly demonstrate their new skills – this is part of the need that game communities fulfill – around every popular game (whether it be a multi-player game or not) people create websites, chatrooms, wikkis, offer screenshots, hints, tips, cheats, discoveries,….. this has other side-effects too: some people have learned html just so they can contribute to the games community of their choice. There’s reflection a’plenty. Also invention, exploration, ….

Unfortunately, the process for creating a good game is about as easy to quantify as creating a good movie, writing a great novel, musical, or symphony, making a great painting, … you get the picture. What we can do is examine the ‘greats’ to see what they have in common; follow some “making of” processes and see what nuggets we can pull out. There are people doing that (media studies folks, mostly). What I want to answer, is: Given that I want to make a game that teaches ‘X’, how can I do that in such a way as to increase the likelihood that it will be both a good game and successful learning experience?

I don’t remember now if I sent you the link when it first got posted, but there’s an article on games design that is relevant to this: http://www.gamedev.net/reference/design/features/wageslave/

Here’s what I thought was relevant.

For those with even less time than I, here’s a summary of the main points of this article. Note that these transcend target audience and genre; they could probably be applied to any game.

• Make every moment the player spends in your game time well spent.
• Spend that time entertaining and rewarding the player for choosing your product.
• Challenge without frustrating, and guide while still keeping the player in control.
• Your world, your choice. If something isn’t fun, don’t put it in the game.
• Keep the player in the game as often as possible.
• But let him leave whenever he wants.
• And remove any barriers that stop him from picking up where he left off..
• Keep it simple, keep it accessible, and keep it fun.
• Don’t demand a huge time commitment from the player or dictate the length of his sessions; let him take it at his own pace.
• Don’t fix things that aren’t broken.
• Test with a wide spectrum of players and non-players to find out what’s intuitive and well-received.

Here’s a quick and dirty re-write for a learning application:

• Make every moment the learner spends with your application time well spent. [goal in this ‘game’ is meeting the learning objectives]
• Spend that time entertaining and rewarding the learner for choosing your product. [reward is tied to assessment and meeting objectives]
• Challenge without frustrating, and guide while still keeping the learner in control.
• Your world, your choice. If something isn’t fun, don’t put it in the application – ultimately the design has to mesh with the values and tastes of the designer: it’s nearly impossible to design something good that you don’t like – kind of an oxymoron.
• Keep the learner active as often as possible.
• But let him leave whenever he wants.
• And remove any barriers that stop him from picking up where he left off.
• Keep it simple, keep it accessible, and keep it fun.
• Don’t demand a huge time commitment from the learner or dictate the length of his sessions; let him take it at his own pace.
• Don’t fix things that aren’t broken.
• Test with a wide spectrum of learners and others to find out what’s intuitive and well-received.

Be the first to like.

Like

Unlike