New Project: Education in Game Design

My colleague Jack and I are conducting a study of education in game prototyping. Over the past three weeks, we have been reviewing literature, syllabi, blogs, and other material on games prototyping and the education around it. Our goal is to review the way prototyping courses are taught and develop our own syllabus for such a course.

Course review

Game design as a taught subject is relatively new. Most veteran game designers studied computer science, art, or did not have formal training. The validity game design education has not yet been tested, at least not extensively, in the industry.

We collected syllabi from game design programs across the US, and a few international schools. When searching for these, we specifically asked for classes that taught prototyping. One immediate result was that the definition of prototyping varied among these schools. Some taught it as rapid iterative testing, where a single project was sent through multiple prototyping stages over a number of weeks; this was the most common approach.

A number of the classes taught the rapid iteration method as part of an introductory game design course. These classes often started with tabletop and other physical games, and later led to digital games. This method seems appropriate for to teach to brand new designers, as it cuts down on time spent programming. One criticism I have of teaching physical prototypes first is that it can seem restrictive- the students must check off this box before they are allowed to work on digital projects. I’m concerned this approach will turn students away from wanting to design board games. This is an area that would require more research to know for sure.

Several schools taught game design in an art studio format. This method seemed to be the best structure in terms of providing significant feedback. Students could view and critique each other’s work openly, so that they became accustomed to giving and receiving legitimate feedback.

Literature review

A noteworthy result of the literature review of education in game design was the marked lack of it. There are blog posts from students entering the game design field, but little formal studies or surveys, and little from industry employers. Game design programs are new and perhaps we have yet to see their full mark on the industry, but there is certainly a lack of feedback on the success of games education.

I attempted to explore the avenue of game patterns, both in education and in industry use. While there general consent that these are useful, there is also a lack of significant feedback or documented success.

Design philosophy

An interesting spin on this investigation is artistic movements. We looked into Dogma 95, a movement in film to bring the craft back to purity. The founders of this movement created a list of constraints that involved filmmakers had to follow. While some of these constraints seem odd (such as no sound added in later) and were somewhat a joke, the result was a subculture of filmmakers and the creation of entirely new ideas and films. In games, UFO 50 and Meditations.game are results of similar movements. Of the syllabi we gathered, only one used constraints like these.

These movement used constraints, whether technical, creative, or content, to both push and purify design. This is in contrast to AAA design methodologies, which use constraints for consistency. These sort of constraints also have more of an artistic feel than those in classrooms, which are generally limits to manage workload.

All of these groups- Dogma 95, large AAA studios, and classrooms, use constraints for different reasons and have very different results. The question here becomes one of design philosophy. Are we creating a class that prepares students for industry work, to teach them standard design processes, or to push them creatively? Based on our own educational experience, we decided to form our own restraints based on the latter.

Class structure

Following the game a week structure used by some classes, Jack and I created a schedule that includes time for building games, review of the process and structure, and a second round of review. We will both keep active blogs during this time to document the experience.

Following some of the ideas of Dogma 95 and one class syllabus, we created a list of our own design constraints:

There can only be one game camera and it cannot move

This will prevent the making of more First Person Shooters, or will it?

There can be no score

Games scores can be an easy way out. Get a certain number of points and you win. This rule will force more creative win conditions or perhaps question winning entirely.

No words can exist in the game

We debated this for awhile. This rules out written dialogue and is a serious issue for narrative games. However we decided this was an interesting challenge and decided to keep it for the first round. We did rule that including subtitles for accessibility purposes was permitted.

The game must contain meaningful sound.

Personally this both my favorite and the easiest constraint for me. Sound is one of my favorite parts of game making, so I look forward to building on that.

It must be made by you and you alone.

This will be my biggest challenge because I have always leaned on others for technical skills and I grew accustomed to group brainstorming. However I’m excited to grow (struggle) through this. On a broader note, we believed this step was important for students to learn about their own design methodology. Working alone will force them to develop a system, an approach. It will also force them to consider multiple angles from perspectives that they may not be used to, such as the artist role.

All visual & audio assets must be taken from something else

We want this to be about rapid design and design philosophy, not the creation of assets. This also forces creativity because you cannot simply make what you need. You either find it or adapt to what you have.

Assets taken from others must be credited (this does not have be done legally though)

Steal all you want but give credit for it!

Separate from constraints, we also created a list of prompts and themes, which will be assigned randomly. In the syllabus review and our own class experience, technical and time constraints were common, but rarely was there a theme.

Thus ends the review stage. Next is the creation stage, where I will undoubtedly spend a significant time yelling at my computer and making terrible games.