Delusions of typical students starting game development curriculum

Here are some of the delusions common amongst beginning game development students. The teacher's job is to counter these delusions. It's better to be honest, to work from reality rather than encourage fantastic "dreams".

• They'll design a game and someone else will do all the work!
• It's all creativity instead of work.
• Ideas will just come to them, floating in out of the ether--and that one idea is all they need
• AAA list games can be produced easily--they have no idea of the magnitude involved.
• They'll play games all day in the job. (Even game magazine editors cannot do that.)
• It matters that they're expert game players (it only slightly matters, and only for designers)
• They're going to have a big effect on a AAA game soon after getting a job (they'll probably never have a big effect)
• Getting a degree is going to get them a job. (They have to show what they can do, degrees don't count for a lot yet.)
• If they just make a game that includes all the currently-popular elements (a market-driven game), theirs will be instantly popular.
• They're going to be able to assemble a development team without salaries and get things done on schedule with the promise of royalties once the game goes commercial. (Though at least this happens every once in a while.)
• They'll start their career working in the position they want to achieve in the long run.
• Think the college curriculum is an extension of high school and act as such.
• If they can do just what's in the curriculum, and without any additional effort, they will have 100% of what it takes to succeed.
• They will only work on hard core games, underestimating the amount of casual game players.
• Work will always be fun and they will always enjoy playing the game they create at the end.
• They can never make a "bad" game that gets canceled.
• Testing is only playing the game, not writing long reports on bugs and flaws.
• They can sneer at and ignore non-AAA titles as though there was something wrong with them and they'd never need to work on such a thing
• It will be Easy.

All delusions . . .

Brief review, Understanding Comics

Understanding Comics by Scott McCloud.
Originally published 1992, this version 1993 (many printings since), purchased recently from Amazon $15.61.

This 216 page softcover "comic book" in largish trade paperback form is an exploration of comics as a distinct art form with its own conventions and possibilities, not merely as a combination of pictures and words. Some of our video game industry guest speakers for our Simulation and Game Development curriculum recommended it. Wanting to be an "educated person", I bought a copy and read it in bits over the course of a couple weeks.

I don't read comics nowadays, but I did when I was a kid and somewhat beyond (the first one I purchased, for 12 cents, was Spider Man #6--yeah, I sold it long ago). My brother collected comics quite seriously for many years. Comics are clearly still a big deal to young people, though often in the form of Japanese manga, which involve different conventions than American comics or European comics.

Anyone who is interested in drawing professionally should think about reading this book. It explains comics on their own terms, and using a well-drawn (mostly black and white) comic to do so helps make many things clear. It is fundamentally a work of...well, I'm not sure I can pin it down. I don't want to say philosophy, or art history, nor is it a "how to do it" book, but the treatment is absolutely serious (with occasional bits of humor thrown in). Though I cannot draw, it was an eye-opener for me, and should be for most people who do draw, whether they're interested in video games, or comics, or films, or something else. There's a lot more to drawing, and to comics, than the "kids stuff" that many people think, and this book illuminates all of that, also throwing light on some of those other media that involve drawing.

I can see why it is so widely recommended. Well worth reading if you have an interest in visually-related storytelling.

Consoles

I am not a console game player--why, when I have a fine PC?--but I have been impressed with the ideas behind the Wii. The other day I had my first chance to actually play the Wii, which strongly confirmed my point of view.

I need to tell a story about my "worst prediction ever". After the crash of video gaming in the early 80s, I supposed that there would never be another video game console comparable in popularity to the Atari 2600. Because cheap computers, particularly the Commodore 64, could do everything a console could do and lots more, at a similar price. Obviously I was wrong, as the first Nintendo machine revived the genre.

What happened? I underestimated the buying public's fear of computers. In particular, I think parents buying game machines for their kids feared having to cope with a keyboard machine. And we have since seen a long succession of consoles dominate home gaming.

Nowadays, we have expensive consoles that are computer wannabes, the PS3 and the XBox360. Both are "frozen" technology, when compared with PCs. I still don't know why anyone would want to bother with an expensive computer wannabe that cannot be upgraded practically, when you can play on a much more versatile PC. Yes, the game software often isn't available for a PC; but in my particular case, the games I like to play (strategy wargames) are made for the PC to begin with.

What we have in the Wii is a throwback to the days when consoles were simple family fun, when people played consoles yet were afraid to deal with "complicated" computers. The new controllers allow gameplay that you just cannot have on a PC (or competing console) at present. The entire "ambience" of the Wii is that it's a fun thing to do with other people, not alone. That it's a game machine, not a technology machine. That it's for the casual player, not the hardcore type. My recent exposure at a party for a game club, with four playing at once, confirmed every one of those impressions.

So if I were going to buy a console, it would be a Wii, not a computer wannabe. (Though I can see buying a PS3 for the Blu-Ray, I'm not sufficiently into high definition movies to bother--upconversion from a progressive scan DVD is fine with me.)

My experience with game development students is that most of them are very hard core. A major task for the instructor is to convince them that they are not typical, and that they cannot plan to make games only for the hard core. The growth in games, in my estimation, will be in casual games, the downloadable games for PCs and games on such services as Xbox Live. And in simulations. NOT in AAA list games that are prominent in Best Buy or Circuit City. The Wii is selling as fast as Nintendo can make them, much faster than the competing consoles. There's a big market there, and game students need to be aware of it.

An "unbalanced" though symmetric game

I've observed here that symmetric games are usually perfectly balanced, except that there may be an advantage in order of movement. This is why, in many of my symmetric games, I've tried to eliminate order of movement or at least associate it with some factor that players have a chance to control.

Chess, for example, is a symmetric game with a big advantage to first-mover (white). Other games may have an advantage for last-mover. When I playtest a symmetric game with a set turn order, I try to record the score by move order so that I can look for patterns of advantage.

Recently playing a four player Wii game involving Olympic events (I don't recall the name of the game), I saw a symmetric game that gave a big advantage to later movers. This is not so much inherent in the game as inherent in the situation, where none of the players had played before, and some had not played the Wii before. So as we played we had to figure out the different controls for each event, and how we could succeed. Those who played early in turn order were disadvantaged because they had not seen as many attempts by all the players as those who played later.

The solution would be to randomize turn order. So the player who goes first in the first round of an event, might go third in the next round, then second, and so forth. I'd suspect, though, that Nintendo would respond that this would confuse the players, so just go with the disadvantage.

Once the players are familiar with the event's controls, the advantage is still with those who go later, as they have some idea of how much they have to do to win the event, which tells them how much risk to take. Here I might decide that in each round after the first, the players play in order of the standings, so at least the last-mover would be the player in last place.

A second game design class

In the community college system SGD curriculum there are two game design classes and two level design classes. In the first game design class, much effort is spent learning Gamemaker, so that students can produce simple electronic games.

The most recent syllabus for "Game Design Two" that I have seen states that students will make eight electronic games, two weeks per game, using different genres, and different student groups, during the class. In practice this apparently means the students will spend a great deal of time on games, probably get to a more-or-less working prototype, then move on to the next game.

This promotes the idea that the designer has succeeded when he arrives at a working prototype of a game. In fact, this is blatantly untrue. 80% of the designer's time is spent testing and altering the prototype in order to get a really good game from it (the prototype is NEVER a really good game). This is just another instance of the "80/20" rule, in this case the first 80% of the work (getting a working prototype) takes 20% of the designer's time, and getting it right (the last 20%) takes 80% of the time. (Perhaps in the electronic world the percentages are more 70/30 or even 60/40, but the point is nonetheless the same.)

This also encourages the idea that highly-derivative games--the ones practical to make in Gamemaker--are good games.

Moreover, this turns the class into a game-production exercise rather than a game design exercise. The students will spend most of their time worrying about getting graphics made (art, not design), about writing marketing documents that have nothing to do with actual design, and about producing a working prototype (which is programming, not design). They cannot concentrate on gameplay, the heart of design, nor do they have the time to adjust gameplay after testing, which is the mechanism that can make a game acceptably good.

So most of their time will be spent on subjects other than game design. Game design is in large part a practical skill ("10% inspiration, 90% perspiration"), something that requires efficient practice. That cannot happen in the "Eight Gamemaker games a term" format.

In comparison to time spent, students learn much more about game design from non-digital games than from digital ones. Gamemaker is a fine simple tool, but not something that will be used in the real world to make commercially-viable games. And even when students use Gamemaker, getting to a working prototype of an electronic game that amounts to anything takes a long time. Already in one Game Design One class, one group tried to make a game that Gamemaker Pro simply could not cope with. They tried many tricks, but found that the only hope they had was to write code that loaded and unloaded graphics and other auxiliaries, for which they had no time nor much expertise.

Finally, as one student also said, Gamemaker is not something you will ever put on your resume.

Consequently, in "Game Design Two" the objective should be to "finish" games or mods, more or less, and that means lots of time-consuming testing of prototypes.

This is not exactly "quality over quantity". This is a case of "completion" (a relative term!) rather than doing half a job. And completion is where the men are separated from the boys. I've already said this, but this time I'll quote from a gent who came from the game industry to teaching (Ian Schrieber): "One of the hardest things when dealing with students is to convince them to work on small games and complete them, rather than working on a single huge sprawling mess that dies under its own weight. It's also hard to convey the 80/20 rule, that 20% of the work gets you the first 80% of the game... but getting that last 20% of the game (which is the polish factor) takes a lot of time after the game already feels like it "should" be done, and pressing on when you're sick of working on the game already is what separates the developers from the wannabes."
(http://teachingdesign.blogspot.com/)

The testing generally will not occur in class, except insofar as the instructor wants to comment on what is happening in the game. The instructor will probably play all the games at some point during testing.

If students are to get jobs as designers, their practical path for classes is to make non-digital games, and to make mods of existing games. The non-digital games will teach them far more about game design and provide games for their portfolios, while the mods will give them experience to make further mods that might get them noticed.

Those who do not wish to be designers will still benefit from working through the entire process, understanding the entire process. And they'll have more time to polish their contributions, whether art, programming, sound, or something else.

So in this class I would have student groups alternate non-digital games and mods of electronic games, perhaps three non-digital and two electronic, perhaps even fewer depending on how this works out in practice. They would FINISH the games, as best can be done in that environment (which is to say, not really finished at all). I'd want a minimum 10 tests for non-digital games, and hours of testing and modification for electronic games. I'd require extensive documentation of testing and of the modifications resulting from testing. In other words I'd want to see clearly the progress of the students after they produce the initial playable prototype.

My first assignment, in such a class, would be to give students individually (or possibly in groups) the task to report on one game engine or moddable game. This report would be presented orally in class, to benefit all the other students. In other words, the students will help each other become familiar with the methods of producing simple electronic games or mods, so that they can decide what to pursue.

Then when the students do their electronic projects, the students will have to provide the game to be modded, or get the game engine to use, since the school won't have those resources and may not be able to install such on the computers being used in most Game Design Two classes.

Results of non-electronic game projects

I assigned groups of three or four students (generally self-selected groups) the task of creating one non-electronic game and one electronic game. Among other things, I wanted them to see how much easier it is to produce a non-electronic prototype and be able to play it. I wanted them to see how important it is to play a game again and again, modify it again and again, to get a better product.

(There's a serious problem in the game design literature that implies that game design is writing up ideas, and once a prototype is produced--not a preliminary stand-alone prototype, but the prototype that becomes the finished game--the designer's work is just about over. In other words, there's a tendency to think that when the prototype works, you're nearly done. Even books that state clearly how much time is required to work with the playable prototype to achieve a good game, don't illustrate it in practice or in the amount of space devoted to these vital ideas.)

I tried to enforce milestones during many weeks of this process, but in the end I gave students the opportunity to fail. At one point I took each group out in the hallway, sat on the floor (their choice whether they did or not), and had them show me the prototype they had so far. For the "final" version, not final as in done, but final as in we've-run-out-of-time even though it isn't complete, I decided to have them "present" to the entire class, so people could see what others were doing.

Two of my classes are too large for everyone to "gather round a table" and watch, so in those classes the students had to stand up front. And it rapidly became clear that it is very hard to adequately describe a game without playing it, or at least setting it up. One group did produce a set of Powerpoint slides to help illustrate how the game worked, and another took digital photos of a playtest session.

A smaller class gathering around a table works better; then the "presenters" actually play a little of the game, which generates lots of questions. I can also see easily whether they've actually played it before, as those who have not run into lots of mechanics questions they had not thought of.

In general, the more practical games were the simple ones. Not only is this hardly surprising, it helps illustrate the point I'm trying to make, "keep it simple". My motto is "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." (Antoine de Saint-Exup'ery)

The simple games were also easier to playtest multiple times, of course.

There were many analogs of electronic games, such as boardgame shooters. There were also analogs of card games, such as collectible/tradable card game and a couple of my own games that students had played in the game club. There was even a game that strongly resembled Candyland! Despite my discussion of the faults of traditional games (still be to posted here), some of the games started with the dreaded "roll and move" mechanic of Monopoly, though I did talk some students out of it. Certainly, where most students are not boardgame players and are just starting to design games, the games they produce are likely to be analogs of/derivative of other games.

Some of the games were not playtested, some were playtested a lot. I think those who did do playtesting recognized how important it was. In a few cases a group threw away their first effort after playtesting. I don't encourage this, but in some cases it was certainly justified.

It's very difficult for anyone to "grade" these games without playing them several times, for which there is no time. My main criterion, aside from what I can see about the gameplay, is whether the students playtested the games and benefitted from that.

I also give them a peer evaluation sheet to fill out. The idea is that I may find out which people in the group actually contributed most, or least. It has its flaws, but is better than nothing.

Later in "lecture" class we made a list of lessons learned from the non-digital game project:

• Playtesting really makes a difference
• You can’t know whether the game is much good until you play several times.
• Working in groups is tough
• It always takes more time than you think
• Miscommunication is common
• The last point is more technical, but important:
Symmetry in starting positions removes most worries about balance/fairness (you still must worry if a first-mover or even last-mover in a round has an advantage).