Gamemaker, "Monkey" Books, and "Game Design I" Class

The SGD 112 "Game Design One" classes I taught this fall were set up by the school to concentrate on use of Gamemaker to produce electronic games. Gamemaker is a very clever and useful miniature "game engine" (less than 8 MB) written for educational purposes. We used a book co-authored by the creator of Gamemaker, Mark Overmars, called Gamemaker's Apprentice. The school had paid for the Pro version of Gamemaker, but it was not available to install on the computers. We downloaded and installed the free "lite" version of the program. The book includes GM6 lite; we installed lite version 7, and had no compatibility problems with what was in the book, nor did we need the Pro version, though there were some examples on the accompanying CD that used the Pro version.

Although the book is apparently error-free, and has the reader make some interesting games within the distinct limitations of the engine, it suffers from the major problem of all such books. I call them "monkey books", because typically the reader rushes through the instructions, finishes the project (not without various detours in some cases from failure to follow instructions), and has little to no idea of what he or she actually did. I think of it as like monkeys somehow following directions but being no wiser when they're done. A person can certainly go much more slowly and try to understand what is happening, and the book usually makes an effort to explain why it is necessary to do such-and-such, but typically this is ignored by the students. I tried to go the slow route, and was frequently amazed that the students finished the projects so much faster than I did at home.

Even though it is possibly the best "monkey book" I've seen, it is still a monkey book. Worse, the students get sick of "monkey business" in the long run. They want to "do their own thing".

What can be done about this? The students MUST learn the basic techniques of Gamemaker if they're going to make simple electronic games of their own. Yet some students point out, quite correctly, that they won't be listing Gamemaker on their resumes. (It should be said here that last year this class began using the Alice programmer training environment, but that didn't prove to be very good for games. Gamemaker became the substitute.)

A big problem with the syllabus I inherited, is that the lab (Gamemaker) is a significant part of the grade and the majority of the class meeting time, but no testing of Gamemaker knowledge was provided for, while the CD in the book contained all the finished projects and their milestone versions. So having students hand in a completed project was pointless and proved nothing. In the end I told the students the lab grade would depend heavily on their attendance, and that I could not give them credit for projects they might do outside of class because they might not be doing anything at all! With no testing, students did not care a great deal whether they actually understood Gamemaker or not, once again encouraging "monkey" methods.

However, I am not a proponent of testing as a way to encourage students. I'd rather have them do something productive and instructive--testing is neither. What I would do in a future version of this class is, unfortunately, a bit more work for the instructor, but better for the students. We would still use the textbook as a means of introducing/reinforcing various programming techniques associated with Gamemaker, but we would spend more time creating very simple games, in part collectively, in part individually. We would discuss the designs of these games, discuss how they can be structured for Gamemaker, discuss whatever is needed to make the actual creation easier, and then have the students do it.

We would make "clones" of well-known old-time video games, provided Gamemaker was up to it (and usually it will be). These games, though simple, clearly had good gameplay, good design, and are still played by many people now and again. The games in the textbook are clever, but the students don't connect with them/identify with them the way they might with the famous old-timers. Examples in rough order of increasing complexity:

• Pong
• Space Invaders
• PacMan
• Asteroids
• Donkey Kong
• Galaga/Galaxian
• Warlords
• Missile Command

Even though these would be clones, I think there would be more sense of accomplishment in figuring them out, and in having a variation of a famous game, than there is in reproducing monkey-style the games from the Gamemaker book.

Second, we would "mod" existing Gamemaker games, whether the ones included with the textbook, or others we'd obtain online. (There is one chapter of the book that mods a game from earlier in the book, though in this case the reader observes the effects of the modding, rather than doing the modding themselves.) I would probably mix these two activities together with material out of the book.

In the end, the class is supposed to be about game design. But if students are going to get jobs as designers--level designers, almost certainly, not game designers--then they'll need to produce games for their portfolios, and so we're trying to "kill two birds with one stone". The class MUST do non-digital games as well so that the students can concentrate on game design rather than game production, but doing the game production helps the artists and programmers learn things they need to know, as well.