So, this week for ETEC 697 (Ed Tech in Informal Learning Environments), we were talking about two topics in particular:
Where the idea for a game comes from (chapter 3 from Rouse)
and
Getting the gameplay working (chapter 15 from Rouse)

Rouse, R., & Ogden, S. (2004). Game design theory & practice, second edition (2nd ed.). Plano, Tex.: Wordware Pub.

To start, some quotes from his text that I found particularly interesting:

Regarding the initial ideas for games:
“… computer game ideas can come from three distinct, unrelated areas of the form of gameplay, technology, and story.” (Page 41)

“often a game developer will have enjoyed a game in one of these genre and will want to apply her own spin to it.” (page 42)

“sometimes the designer will have both the stories she wants to tell you the type of gameplay she wants to explore, and will attempt to do both in the same game, even if the two do not go well together.” (page 43)

Regarding starting with a specific technology:
“Going into a project with a large portion of the game’s technology already developed is also fairly common occurrence” (page 43)
Of course, this makes me think of the iPhone as a platform that is already very robust, and well developed. It is no wonder, therefore, that so many developers have moved this platform — sometimes exclusively — to create content.

“When technology is handed to a game designer who is told to make a game out of it, it makes the most sense for the designer to embrace the limitations of the technology and turn them into strengths in her game.” (Page 44)

“For the greater good of the game, the story and the technology must be compatible with each other.” (Page 45)

Regarding starting with the story:
It is surprising to me that it seems that this is the least common of the three paths to get to a game. Perhaps it is the altruistic side of me, but as humans, we have lived primarily through the stories we tell, and it is the stories that are most compelling. This is not to say that games developed with technology or gameplay do not have compelling narratives, it just seems counterintuitive that the story comes after these other two areas frequently.

{{I find it interesting as a sidebar, that Rouse is clearly a fan of the rock band Rush, since phrases like “if you choose not to decide, you still have made a choice”, and “those who wish to be must put aside the alienation, get on with the fascination, the real relation, the underlying theme.”
Just an intriguing way to view some of the ideas and gameplay…}}

In chapter 15, which is “Getting the gameplay working”, some quotes here:

“by concentrating on getting a small piece of the game fully functional and enjoyable, the developer can get a much better sense of whether the final game is going to be any fun or not. If the gameplay does not turn out to be as anticipated, the prototype provides an early enough warning that the game needs to be either redirected in a more promising direction or, in the worst cases, aborted entirely.” (Page 283)

“looking back, if we had focused on making the gameplay fun before making a large number of levels, we could have avoided a lot of extra work and wasted effort.” (Page 285)

Regarding starting small, and prototyping early on:
“Besides, a playable demo will make the game easier to sell to a publisher or a green light committee.” (Page 286)

“It is very easy to lose sight of your gameplay goals when your game languishes in an unplayable state for much of the time. Certainly the game can be broken in many ways, with various components that do not yet work as they are supposed to…” (page 288)

“It is often a good idea to start developing your content from the beginning of the game. Early parts of the game need to be at the highest level of quality possible, so you want them to represent your more seasoned efforts, while levels at the end of the game will often tend to be more atypical and hence will not represent the “regular” gameplay that you want to have working first.” (Page 289)
It is interesting here, to think about the comparisons and differences between game design and lesson development, therefore. With good lesson design, we typically are not changing our knowledge fundamentally as we are developing our content, activities, and instructional plan after setting our end goal. If we know our goal is to have the students understand simple machines through an activity that involves building racecars out of popsicle sticks and rubber bands, we know as we design the lesson that we will not understand Popsicle sticks much differently at the end of our process than when we started. This is very different in game design, where the platform that we develop our content in will become easier to use, better understood to apply, and potentially evolve as we work on our design. There is also the time frame involved. In lessons, we typically design over a few days, although there is iterative design that occurs year by year as we go back and revise and improve lessons we’ve used in the past. For game design, the period of development which may be months or over a year, almost guarantees that changes in our understanding of the platform, or the platform itself will happen. Yet, there is a common idea here — the start (think Gagne’s first event: Gain Attention) and the end (culminating activity) both need to be powerful to best ensure their success.

Regarding prototyping: “observe how easily they manage to pick up the controls and mechanics. It is much simpler to make a game harder than to make it easier.” (Page 290)

“As you work on a project, you’re likely to become overly familiar with some of the content you have created, and familiarity can breed contempt.” (Page 291)

“Always try to remember how you first felt when you play a level or tried to pull off a particular move” (page 291)

Regarding the role of programmer versus designer — assuming that you have a team working on the project: “nevertheless, a designer who cannot program will be beholden to the talents and inclinations of her programmers, which can be eternally frustrating.” (Page 292)

Although not all of these ideas apply directly to instructional design outside of gaming, or certainly a few ideas in here that are significant whether we are looking at games, educational games, or just classroom instructional practice. A few thoughts that came into my mind through the reading:

One of the emerging technologies that still are in their early stages are virtual worlds. Specifically, second life is a platform that has no content at a starting point, but gives developers ample opportunity to construct openly in their environment. Is Second life is a technology looking for a story? There are certainly examples of projects that are creating virtual worlds with a story embedded — World of Warcraft, Runescape (quote of the day from my seven-year-old this morning “dad — someone ‘jacked’ my identity — can I make a new one?” I had to ask him what that meant, and then realized identity hijacking was a fairly common phenomena in that virtual world). These MMORPG (Massive Multi-player Online Role Playing Games) have story built into them, and a social community as a significant element. The numbers involved in these worlds attest to their viability, and as informal learning environments, we can use that as a learning laboratory to best design from.

Regarding multi-touch interfaces, I’m usually most intrigued with iPhone, but I saw this video recently that provided another window in game design: Microsoft surface D&D project

So here is a example of a powerful multi-touch technology, where the game play, the story, and the technology all Weave together. Perhaps that is the best view of where the future lies in game design — a happy mix of all three.