In the Spring, I team-taught a colloquium on history education game design with my respected colleague Ronald Morris, a professor in the History Department at Ball State. Regular readers may have noticed that I have not written much about this experience. I’ll get to it. Or not.
This colloquium explored the design of a game for Indiana 4th grade students. The production of a high-quality educational game remains Ron’s main focus in the project, while I am also specifically interested in exploring how students can learn directly from the mechanics of the game as opposed to the layer of story atop the mechanics. My interest in this question goes back several years to when I first read Raph Koster‘s Theory of Fun for Game Design, which is the first book I recommend to anyone who expresses interest in Fun. (That’s “Fun” with a big “F”, by which I mean the serious study of fun.)
The students in the colloquium created some compelling physical prototypes in the first half of the semester, and the goal was to create a high-quality design document from these experiences. Unfortunately, the final document does not meet production standards. We are still planning to build a game, and specifically, my Game Programming students will be building it in the Fall. The task of finalizing the design document therefore falls in my lap, and it’s not unwelcome.
In the colloquium, we used Wave to start the document, but performance was not adequate for our purposes, and so the document moved to Google Docs. I do like docs for quick and dirty documents, but years of wysiwym editing in LaTeX have left me with very little patience for wysiayg editors. A lot of the advice I encountered online recommended the adoption of wikis for design documents, and so my first step was to import the existing Docs file into Google Sites, a general-purpose Web site creation utility that has convenient wiki-like features. The two main advantages of Sites are that (1) I already know it well and (2) I don’t have to configure a wiki server.
I quickly found, however, that the format of the original document was not empowering my creativity. I felt like I was mechanically creating pages but with no real end in sight. I decided to invest an afternoon to find the best practices for design document creation and management, beyond the technology and into the realm of content.
Suffice it to say that you can find a lot of advice about game design on the Internet. I bounced from site to site and eventually ended up on GameDev.net’s General Game Design page. There, I downloaded some templates and started tinkering. The one that stood out happened to be based on Tim Ryan’s series of articles at GamaSutra, the first on proposal and concept documents and the second on functional and technical specifications. If you’ve read this far in hopes of finding my links to the best advice I’ve found, and the title of this post didn’t give it away, there you go.
The funny thing about these articles is that these are the same ones I read four years ago in my first foray into serious game development (serious development, that is, not serious games at that point). The articles themselves are from 1999, and a lot has changed since then in both the games industry and the academic treatment of games. I’ve read many books on game design and design theory since then, and Ryan’s articles still stand out as having just the right balance of practical advice and theoretical soundness. They have also helped me identify my Summer path more clearly:
- Write a concept document and share it with my stakeholders, who are Ron and a few key undergraduates whom I will be trusting with high-responsibility tasks in Fall. The concept document is essentially complete and I am awaiting feedback.
- Write a functional specification.
- Write a technical specification, while concurrently developing the milestone schedule.
- If necessary, develop any core software architecture that will be required before the Fall semester begins. After all, I will be managing a team comprised entirely of novice developers.
That leads me to my next great quandary: how do I manage a team of 30 novices on a critical project? But that’s a topic for another day.