Designing a game

When I was a young academic in Australia, a colleague asked me if I would talk to some folks about a game. He knew that I had designed games before returning to grad school, and had subsequently done one on my thesis research. This group, the Australian Children’s Welfare Agency, had an ‘After Care’ project to assist kids  who needed to live independently. They’d spent their budget on a video, comic book, and a poster, but now realized that the kids would play games at the Care centers. I had a talented student who wanted to do a meaningful honours project, and so I agreed.

Following best principles, we talked not only to the project leaders, and the counselors, but more. We weren’t allowed to talk to youth ‘in care’ (for obvious reasons), but they did get us access to some recent graduates. They gave us great insights, and later they playtested the prototype for fine-tuning.

One of the lessons from this was important. The counselors told us that what these kids needed were to learn to shop and cook. While I  could have made a game for that, when we talked to the kids we learned that there was more.  (My claim: you can’t give me a learning objective I can’t make a game for, though I reserve the right to raise the objective in a taxonomic sense.)   They said what was important were the chains. That is, you could get money while you looked for a job, but… They wouldn’t give you money, however, they’d deposit in a bank account. BUT, to get that, you needed ID.  To get that, however, you needed references. And so on. So that was the critical focus.

I taught my interface design students HyperCard, to have a simple language to prototype in. This meant that we had an environment that we knew games could be built in.  My student did most of the programming, under my direction.  When that wasn’t quite sufficient to finish the development, I used some grant money to hire her for the summer to finish it.

The resulting play was good, but the design was lacking (neither my student nor I were graphic designers). I ended up going with the project team leaders to get philanthropic funding to add graphics. (Which introduced bugs I had to fix.)  They also had it ported to the PC, which ended up being a mistake.Their hired gun used a platform with an entirely different underlying model and wasn’t able to translate it appropriately. Ouch.

The resulting game, had some specific design features:

• It was exploratory, in that the player had to wander around and try to survive.
• It was built upon a simple simulation engine, which supported replay.
• There were variables, like health and hunger and sleep that would get worse over time, driving action.
• The audience was low literacy, so we used graphics to convey variable states, interface elements, and location.
• Success was difficult. Jobs were difficult to obtain, and better jobs were even harder. And, of course, you had to discover the chains.
• There was coaching: if you were struggling, the game would offer you the opportunity for a hint. If you continued to struggle, eventually you’d get the hint anyway.
• There was also a help system, where the basics were laid out.
• There were random events, like getting (or losing) money, or having drugs or sex. (We were trying to save lives, and didn’t worry about upsetting the wowsers.)

There was more, but this characterized some of the important elements.  In reflecting upon the experience, I realized the alignment between effective education and engaging experiences that means you can, and should, make learning  hard fun.  I wrote a journal article (with my student) that captured what I will  suggest are critical realizations (still!).

They held an event to launch the entire project, including the game (and they gave me a really nice sweater, and Dana something too ;).  Tomorrow, I’ll pass on some of the subsequent outcomes.