In addition to this blog, Brenda has given me the ability to post on the Applied Game Design blog, so I will occasionally make posts over there about the theory and practice of game design.

Why not just post here? I want this blog to remain a resource for students and educators about teaching game design, and my own rantings on how to actually make better games are best done elsewhere.

Any post over there by 'ai864' is me. I've already made my first post.

I will still be writing here about teaching game design, of course.

Raph Koster's A Theory of Fun for Game Design has been out of print for a few years, making it obnoxiously difficult for anyone to actually buy it for less than 200ドル or so.

Happily, it is now back in print for about 15ドル.

I suspect a lot of teachers will suddenly be adding another book to their required texts next term...

For those of you who are wondering what was going on during the Global Game Jam, Stephen Jacobs wrote up a fantastic blow-by-blow account of the action. His article is on Gamasutra.

I'm even quoted a few times in the article.

The other day, I met some people who are thinking of hiring a game designer, I mention that I'm available for contract work.

One of my students who was present stepped in front of me and mentioned that he's also available, and cheaper to hire than me.

I know that I always say to pay attention, be observant, be ready to pounce on an opportunity... and apparently some of them actually listen. I'm thinking that, in the long run, this is probably a good thing.

The question was recently raised on the IGDA Game Educators mailing list: how can students find summer internships in games? If you're a student, this is probably on your mind; if you're a professor, students will probably ask you. I posted a response there, but I thought it's worth saying here.

First, let me say that internships in the game industry are rare. This is not about game companies being mean, or hating students. It's because game projects typically take longer than a summer, and development teams don't particularly like it when a key project member leaves in mid-project. It also takes people time to ramp up, which means just around the time the intern is finally able to contribute something to the team, they leave. Also, interns take a lot of management time that a typically-overworked producer does not have, so many studios decide that it's just not worth it.

This is not to say that internships don't exist, merely that the companies that offer them tend to be low-key about it (lest they be flooded with tens of thousands of resumes from eager college students). That means they aren't advertising, so you have to find them other ways (see below).

My advice to students seeking summer employment:

First, do your homework. Research a lot of game companies, go to their corporate websites and see if they have internship programs. Best bets are local companies, since realistically you aren't going to get housing or relocation expenses (some companies won't even consider you for an internship unless you live in the area). Be willing to look at lesser-known companies (not just the big names that you drool over), and look in related fields like serious games -- fewer students are looking there, so there's less competition.

How do you find local developers? First, check GameDevMap. Second, check if there's a local IGDA chapter. Third, check Google with a search string that implies game developers in your local area. Fourth, check with your school's career services office... but you probably won't find anything there that you couldn't have found on your own, which is why I list it last.

Some "internships" may not be listed as such; rather, they may be called "QA" positions that just happen to span the summer term.

If you can't find anything in games, consider a related industry. Programmers can do a programming internship at any software company and still gain valuable experience. Artists could work in fields like advertising or industrial design.

If you absolutely can't find any paid work, finances permitting, "hire" yourself full-time to work on your own game projects! Force yourself to work 40+ hours per week on your own game, as if you were at a full-time job. (This works even better if you have some friends you can team up with.) Keep your scope small, so that your projects are achievable. The point here isn't to "start a game company" or "make a great game and sell it" -- the point is to get valuable experience making games. If your project sucks, that's fine, as long as you learned something from the process. If your project does end up being awesome, enter it in the IGF student showcase, which is just as juicy a resume bullet-point as an internship (if you win).

It seems to me that every school that offers online courses does things a bit differently. For the classes that I teach online, I try to have as much interactivity as I have time for. I'll post on discussion boards, I host virtual "office hours" through an online chat program, and I send out regular emails with my own personal spin on the topic. I also offer feedback through grading papers, even if it takes me longer.

I realized today that in theory, the entire thing could be automated:

• The course content is all online, so there's no reason why I need to add anything to it. Let the students read it on their own without the professor offering any extra commentary.
• The discussion boards are for students to interact with each other, not the professor. When "participation" is one of the grades of the course, there are tools where you can get post counts, average length of post, and all kinds of usage stats without ever having to actually, you know, read what one of those student people is actually saying.
• Papers can't be automated easily, but if you design the course you could go light on those assignments and heavy on multiple-choice and fill-in-the-blank quizzes which can be graded by a computer system.
• Instead of holding regular "office hours", simply post your phone number and let students call if they need help with anything. You know they never will, whether it be from feelings of politeness or intimidation.

Not that I would ever teach this way, mind you. I don't think it's really teaching if I'm not involved, it's more like a long, drawn-out certification process.

On the other hand, it's easy to "teach" a class this way, so I'm sure there are people out there who do it like that. Some might just be overwhelmed with other things in life so they fall back on something easy. Others might be greedy and want extra pay for next to no effort. Still others might think this is what online classes are supposed to be, that once you get a computer involved it somehow means humans should be removed from the equation.

I suppose the lesson here for students is: buyer beware. Make sure that you're getting your money's worth when signing up for an online class, and make sure you know what kind of instruction and personalized attention you can expect. If all you're looking for is a few quick credit hours without having to leave your dorm room that's one thing, but if you're actually looking for an education then do your due diligence. (Put at least as much effort into shopping for a class as you might into getting a high-end stereo system for your dorm, since that's probably about what you're paying.)

Interestingly, I think there's a parallel here with outsourcing in the game industry, in that many companies that think "outsourcing" really want the thing they're outsourcing to be automated (and they find out to their chagrin that game development is not so easy a process to automate).

I have an ongoing discussion with several colleagues about the basic question of where a teacher's value lies. This is particularly important in a field like game design, where a new professor is likely going to be the only one in the department with any game-related expertise and will therefore be doing some curriculum development, some course content development, and of course the actual teaching.

There seem to be two schools of thought with respect to this.

The first model, I'll call "value in output." The professor is a machine that converts money and coffee into curriculum and course materials. The real value is in these secrets of the field that the professor distills into small documents like lesson plans and curriculum documents. This is valuable information that must be protected. You can tell the schools that think this way because they have something in their contracts that makes sure the school gets IP ownership of the professor's work, or (at the very least) they would be very much against a professor releasing this material to the public, or taking it to another school.

The second model, I'll call "value in person." The idea is that it is the professor who is valuable, not the work. A skilled professor can always create more classes, revise the curriculum or what have you, and it is therefore the human being that has value. An analogy would be valuing the goose more than the golden eggs. You can tell the schools that fall into this category by their willingness to release their course content online, give their professors more control over their own work output, and are generally happy to just sit back and do nothing as long as the profs are bringing glory to the school.

We have this in the game industry, too. Where is the value in a game: the IP, the code base, or the development team? Depending on a publisher's viewpoint, they will treat their developers very differently.

If you're a teacher or a developer, think for a moment about how your school (or your publisher) sees you and your contributions. Is there more focus on your work output, or your ongoing ability to produce that output? Which view is superior? If the answer is "it depends," what does it depend on?

Yesterday, I was in Savannah giving a presentation with Brenda at SCAD to other educators about the use of games as a teaching tool. It was intended as a combination of my earlier Origins presentations and our Game Design Improv event.

I learned something interesting here: when talking about games in education, I take for granted that most of the time I'm talking to educators who already play games heavily (or teach game development), so the use of games in the classroom is not a hard sell. In this case I was speaking with professors from art history, photography, audio, film, media studies, and several other fields that are not directly related to games. We spent a lot of time discussing whether games were worthwhile for classroom use at all, and if so in what situations. It was a wonderful discussion that really challenged us all, and it's a discussion I'm not used to having. I was also impressed by the high degree of game literacy from these professors who were not gamers; participants referenced a number of game industry personalities and important games. Apparently it's not just game designers who study other media; they're paying attention to us, also.

Coming up, I've got a few speaking engagements. I'm speaking at GDC, both times during the Education Summit. I speak twice: I'm doing the next iteration of Game Design Improv with Brenda, and also speaking with Susan Gold and Gorm Lai about the results of the Global Game Jam.

The month after that, I'll be at GDX (here's last year's site, the new one isn't up yet), speaking about the relationships between art history and game design -- basically, why game designers should take at least one art history class, and why they should pay attention. (Short answer: because we may feel like games are a new medium and we're blazing new trails, but an awful lot of what we're doing with games-as-art is stuff that the art world already addressed hundreds of years ago, and we need to understand this so we don't keep reinventing the wheel.)

The IGDA elections are underway, with four board seats open. I've thrown my hat into the ring.

If my personal statement sounds like something that resonates with you, I'd appreciate your vote. And if you're not a member of the IGDA... well, this is as good an excuse as any to join.

Thanks for your support.

After many months of planning, site wrangling and organizing, the Global Game Jam will take place this weekend. We have 54 host sites in 51 different cities, 24 countries and 14 time zones. We're currently looking at somewhere in the neighborhood of 2000 participants. It's pretty amazing how big it's grown in just the last few months.

I'll be providing realtime support to the sites for the entire weekend (minus the time when I'm sleeping) from my home office in Columbus.

If you're not already signed up, see if there's a location near you.

A short collection of social awkwardness as experienced by a game-designer-turned-educator, in no particular order:

• Having several students admit that they played a game you worked on, when you know the game in question wasn't particularly good. (Additional awkwardness: when the game in question is M-rated, and you know that the students were underage when they played it.)


• Giving a game design constraint for an in-class exercise, and repeatedly being asked questions about the exact boundaries of the constraint... and realizing simultaneously that my students are trying to weasel out of the constraint (and that I should be annoyed), and also that my students are trying to precisely define the constraint (which is an important skill for game designers, and something I should be proud of).


• Witnessing a student fall asleep in class, and hoping that it's because the student got no sleep and not because I've really become that boring. (Additional awkwardness: waking the student up, and hoping that I done it in a way that I haven't cruelly humiliated them.)


• Assigning a homework that's not only easy but actually fun, and seeing that half the class didn't bother to complete it. And then wondering if my definition of "fun" has changed.


• Writing something out (an assignment, a syllabus, an email, etc.) that I thought was clear as could be, and having students not understand it. This either means I'm not as good a writer as I thought, or that my students aren't functionally literate, or that my students are lazy... and no matter which it is, there's nothing I can be happy about.

Because we're both game developers, Brenda and I conducted a post-mortem of the book we wrote. Because many professors write their own textbook eventually, I thought it might be nice to share what we learned with you. (After securing the go-ahead from Brenda, of course.)

To protect the innocent, I won't say what we got "right" or "wrong"... but this is what we learned, for better or worse.

• Write with a co-author that you already know you work well with. I really can't stress this enough. Aside from halving the amount of work you have to do, it's great to have someone to bounce ideas off of, and it's kind of like having an extra technical editor for free. It's also a lot harder for the project to stall when you know that someone else is counting on you (a friend and colleague, not just some monolithic book publisher).
• Use some kind of version control system. It doesn't have to be as elaborate as Visual SourceSafe or CVS, but you will be making many changes and revisions to documents, and you will want to have a history in case you need to reference that paragraph that you deleted three months ago and now you want to use it in a different chapter. We found that simply numbering the documents (Chapter01_v1.doc) was sufficient.
• Use the Track Changes functionality in Word. It's great. It's like a version history built-in. Use the comments to communicate with your editor and other authors.
• If you're working with another author, use Google Docs for preliminary work. It's a free, convenient way to share chapters, and if you're on an instant messaging program (or on the phone) you can even edit the same document at the same time. You can always add any special formatting later, after importing into Word.
• Keep track of the current status of each chapter (not started, rough draft complete, final draft complete, submitted to publisher, accepted by publisher) in an Excel document. Update it whenever you finish anything. This is especially important if working with another author, so you know who is currently editing what (you run into a lot of "did you finish this chapter and it's waiting for me to review, or were you still working on it?" questions).
• Choose your book topic carefully, and whenever possible write about what you already know. Everything that you have to research takes extra time, and a book where you have to research everything will take a lot of time.
• When you're working with the publisher on the initial schedule, build time in the schedule for iteration. There are a lot of tasks that affect the entire book (consistent formatting, terminology, overall structure and other things) that you'll want to change several times as you write, and the easiest way to do this is just to make one final pass over everything at the end... rather than making these changes several times over the course of the project. But you only get to do this if there's time, and if you're rushing to meet the deadline then the whole thing can look a bit sloppy.
• As a corollary, keep a list of open issues for the book, so that nothing falls through the cracks. Keep it updated whenever you run into a problem that you want to defer until later, and reference it when you're doing revisions.
• Find people to review different parts of your book (friends, colleagues, grad students... anyone who you think would give you good feedback for any particular chapter) and start that process early. If you're writing a textbook intended for classroom use, teach a class from an early version to see how it will actually function (think of it as a "beta test").
• Get constraints from your publisher early on regarding number of chapters and pages, and find out the approximate ratio of pages in Word to printed pages in the book (a ten-page Word document might be twice as many pages in the book because of extra whitespace added to sections so the paragraphs aren't split between multiple pages, or to allow extra space around figures and photo images). This prevents you from finding at the end of the project that you suddenly have to add or cut a bunch of content.
• While I'm on the subject of images, get your images early. Securing the rights to photos of people, screenshots of games, company logos, and so on takes a lot of time.
• Develop a system for references to other parts of the book (for example, "See Chapter X, Page Y" when you don't know what the final chapter and page numbers will be). If you use actual numbers, you'll just have to end up changing them later... and woe to you if you accidentally miss one.
• Create a core statement for the book up front. Do you want to write in a professional or casual tone? Do you want to focus more on content or concepts? What is the underlying theme, the one thing you really want the reader to understand when they're done -- the common thread that ties everything together? Revisit your core statement when you're reviewing or revising your chapters.
• Clear your schedule if at all possible. Writing a book takes a lot of time, and if you're trying to balance that with teaching classes, doing freelance work and remodeling your kitchen, you are just not going to have the energy. If you minimize your downtime and interruptions, things will go more smoothly.
• Do your due diligence with publishers. If you've got a great idea for a book, then it should be a great idea no matter who the publisher is. Seek publishers who have a line of successful books in your field, so that you can get some decent cross-pollination with readers of other books in the same series. Look for publishers with wide distribution networks. Think of whether your publisher has the means and understanding to promote your book (or, whether they're willing to let you do some self-promotion). Find out who your editor(s) will be, and how much experience they have (if any) in your field; if you've written a book before, you may be able to request a specific editor for your book. At any rate, there's no reason why you should just take the first offer that comes along and accept all terms without negotiation... any more than you would with a job offer.
• Keep backups of everything. If all of your work is on your home computer hard drive and that hard drive crashes five days before the next scheduled milestone submission to the publisher... well, I'm sure you can imagine.
• And lastly, don't expect to get rich as a book author, any more than you would as a game developer. The advance you can expect as an author is not very much when you compare to the amount of time you're going to spend on the project. Yes, you can make a lot of money if your book sells well enough to earn you royalties, but that is the exception and not the rule. This doesn't mean you shouldn't write a book... but if you write one, do it for reasons other than money.

If there are any other textbook authors in the audience, please comment and share your own tips.

I've said before that classes are more interesting to students if you can make them more game-like, i.e. to give the students some interactivity (if not actual decision-making) rather than just lecturing at them.

If you're a teacher who is used to just speaking at your students and want to break yourself of the habit, here's an easy experiment for you to try in your next class:

1) Look over your lesson plan, and pick out one thing that is ambiguous, unknown, open to interpretation, or otherwise has no "right" side or answer. (Example in a biology class: the definition of the term "life".)
2) Design an open-ended question about the thing you chose. (Continuing the above example: "How would you define the term life?")
3) At some point in your lecture, ask the question to your class, and wait for the students to try to answer. If it takes a few seconds before you see any raised hands, that means they're actually thinking about your question, which is a good sign (or it means they're asleep, which is a sign that you've been lecturing for too long). Sometimes students will raise their hand to elaborate on (or even disagree with) a previous student's answer; encourage this, as you're creating an interactive dialogue among your students. If one student gives an answer and no one else feels like adding to it, challenge it yourself; play devil's advocate. But if at all possible, confine yourself to a role as moderator; if you chose a good question, your students will do your work for you.

You might notice a few things about this method:

• It gives your own voice a much-needed rest in the middle of a long lecture :-)
• Your students will actually be paying close attention.
• Your students will actually be thinking. In class, no less.
• As often as not, one of your students will say something particularly insightful that makes you think.

If you try it and like the results, increase the number of questions. Personally, my classes are usually about two hours, and I shoot for a goal of at least three discussion-questions per class. But if you're not used to it, you can work up to this one question at a time.

I was confronted with the opinion the other day that teachers are overpaid because they only have to work 9 months out of the year but get paid for a full year. I'm pretty sure the person who expressed this opinion has never actually met a teacher before, but it seemed like a thought that a lot of people might have. So, I thought I'd set the record straight.

First, a teacher in any field typically gets paid a bit less than a working professional in that field, even though they have to know just as much (if not more). This is why a lot of teachers feel underpaid for their work -- because with their qualifications, they could make more if they weren't teaching.

As for being underworked, I know of very few teachers who sit idle on summer/winter break. In my own experience, the time fills up fast:

• There's a lot of prep work to do for classes before they start: revising syllabi and course content, evaluating new textbooks, and keeping current with industry trends all take time.
• If you're teaching any brand new courses, you have to develop everything from scratch, which typically takes about as much time as teaching the course itself (i.e. one new course = two old courses, in terms of time commitment).
• Keeping professional skills sharp is important. Over breaks I usually end up doing some kind of freelance contract work.
• Ever heard of summer and winter classes? A lot of teachers hold classes over these supposed "break" periods.
• And of course, during the academic year teaching is a lot more than just a 9-to-5 job. In theory you're supposed to have a 40-hour work week, which is 4 or 5 classes if you're full time (that includes face time in lecture or lab, and also out-of-class time spent grading). But in addition to that, you have other duties: academic advising, office hours, faculty meetings, and (if you're really unlucky) being on a committee.

In reality, teaching is more than a full-time job.

Does that mean that these thoughts of "lazy" teachers who only work "30 weeks out of the year" are completely inaccurate? Unfortunately, no. It is possible to reduce the workload. You can hold office hours for your classes simultaneously, and then use the time to get other work done if no students show up (although this means you'll end up treating students like they're interrupting you when they show up for scheduled office hours). You can just copy your course notes from earlier classes without updating them, which reduces prep time to almost zero (but then you cheat your students out of a modern education). You can set up your assignments so that they're easy to grade (but anything easy to grade is usually not that meaningful -- for example, you can tell a lot more about a student's understanding by reading an essay than you can get from a multiple-choice question, but multiple-choice is easier to grade).

So, it is possible to have lots of time off, work 40 (or fewer) hours per week for 30 weeks a year, and have the rest of the time free to... um... do whatever teachers do when they're not working. But so far, the only way I've found to do that is to cheat your students. If you want to be a good teacher, forget any thoughts you had of annual three-month vacations...

It may be too early to tell, but already I see a cycle emerging:

• At first, many bright-eyed hopeful students want nothing more than to make the next generation of AAA games. In their spare time, they play certain games obsessively, and it is these games in particular (or others just like them) that they'd like to make.
• Some of these students graduate, get into industry and enjoy it for a time, but eventually get frustrated. They're a small cog in a huge machine, going from one crunch period to another, with no end in sight. In their spare time, they play short games because that's all they have time for, and they secretly wish they were Jason Rohrer or Rod Humble or Jenova Chen.
• Some of these frustrated developers leave the industry for academia, and are frankly amazed at how much of an opportunity the next generation of students has. Why, they could use their talents to make the next big art game that has all of the professional developers collectively salivating at its brilliance! These students have the time, they have the skills, they've got the drive... but all they want to do is make a clone of their favorite AAA titles. Oh, the tragedy of wasted opportunity!

And then the cycle repeats.

I do my best to describe this to my students. In a few cases, they get it. Most of the time, it's like trying to describe working in an office job to a second-grader: the life experience necessary for total comprehension just isn't there yet.

I see other teachers forcing the issue. I hear at GDC of class assignments that involve having students create games that teach, games that inform, games that enlighten, games that have a positive social impact, games that make the world a better place, games that express an emotion (other than power fantasy or adrenaline rush), and so on. These kinds of assignments are a reflection of the instructor's agenda: these are the kinds of games that the teacher wants to make.

If you're a student, looking at the game design assignments heaped on you will give you a clue as to the kinds of things you might really want to make yourself in five to ten years (even if they seem arbitrary or meaningless right now). If nothing else, it shows you how your instructor -- the same person who wanted to make nothing but AAA games back when they were your age, if you can believe it -- has changed over time.

But it is a real shame that a lot of students today won't figure all of this out until it's too late. George Bernard Shaw's quote about youth being wasted on the young is ringing true.

Just a quick tip today from one of my earlier game design classes (we actually came up with this as a group in the middle of class while critiquing a student project):

If you're designing a paper prototype for a digital game and one of the core mechanics involves accurate positioning (examples include aiming in an FPS, positioning a paddle in a ball-and-paddle game, or maneuvering an avatar through an obstacle course), flicking a coin on a flat surface towards a target gives a reasonable approximation.

In our particular case, the student was designing a ball-and-paddle game. We discovered that if the coin was the paddle and a single flick was your allotted movement (then you repositioned the ball), it had the realistic property that it was much easier to hit a ball coming right at you than one that was landing halfway across the screen.

For an excellent example of this mechanic in action, see the non-digital game Pitch Car. Okay, so it's not Gran Turismo... but it could easily be the basis for a non-digital version of Mario Kart.

A recent article by fellow teacher/designer Lewis Pulsipher got me thinking about game ideas. A lot of students appear to assume all core concepts start like this:
"It's just like this other game that I like, only with these other elements added that I also like!"

In the real world, games are rarely made that way. There are all kinds of constraints that get a designer started. Some examples:

• A publisher issues an RFP for a sequel to an earlier game, now that the original developers are out of business.
• A publisher acquires the rights to a licensed IP and asks for concepts using that IP.
• A publisher notices there are no announced titles in a certain popular genre within a certain fiscal quarter a couple years from now. You start with a genre, timeline and budget which are all written in stone, but you're free to be original otherwise.
• A publisher notices a fast-growing, underserved player demographic and asks you to make a game to specifically attract that demographic (such as the notorious "games for girls" phase that the industry seems determined to screw up about once every ten years).
• An educational/training company approaches you, asking you to make a game to teach a given set of content more effectively than traditional classroom study.
• A political organization commissions a persuasive game to push a specific agenda or raise awareness of an important issue.
• An indie developer wants to make an "art game" to express their own emotional struggle through gameplay.

I've found the best way to break students of their habit is to introduce them to a variety of real-world constraints, giving them practice in designing games to those imposed constraints. Because game ideas may come from all over, but the ones that get made into AAA games usually come from constraints imposed from above.

A recent conversation I had reminded me of something, which I share with you now.

Students of any artistic medium should are expected to study the more famous/important works within that medium. A graduate of a film school who had never heard of Citizen Kane, a graduate of an art school who couldn't recognize the work of Van Gogh, or a graduate of a creative writing program who never read Shakespeare would all be considered rather embarassing to their schools. So, it's up to the school to make sure their students get exposure to the great works of their field. So it should be with the study of video game design.

Let's assume for the purpose of this exercise that a teacher can find some way to gain access to any game, regardless of technical constraints. Let's also assume that there are no time constraints, and "how do I fit all of this in the core curriculum?" is someone else's problem.

The question: if you were to make a list of games that all students of game design should know about, what games would be on that list? This should mostly involve games that did at least one thing really well or poorly with respect to game design (not technology or art), i.e. those games that we should be able to learn something from. The games that, intentionally or not, made some contribution to the field of game design.

Here's my own list, so far:

Classic Non-digital: Chess, Go, and at least one card game featuring trick-taking and trump (Spades, Bridge, Whist, etc.)

Modern Non-digital: Settlers of Catan, Carcassonne, Puerto Rico, Magic: the Gathering, Dungeons & Dragons (at least read the Player's Handbook and Dungeon Master Guide)

Arcade: at least one ball-and-paddle game (Pong, Breakout, Arkanoid), at least one LaserDisc game (Dragon's Lair, Space Ace, etc.), Pac Man, Gauntlet, Super Mario Bros., Street Fighter 2, at least one side-scrolling shooter (Gradius, R-Type, etc.), Tetris

PC: at least one Roguelike (Rogue, Nethack, Angband), Archon, any game from the Civilization series, Warcraft 2, Where in the World is Carmen Sandiego, Star Control 2, Ultima IV

Console: Chrono Trigger, Legend of Zelda: Link to the Past, any game from the Pokemon series, any game from the Harvest Moon series, any cart-racing game (Mario Kart, etc.), any realistic racing game (Gran Turismo, etc.), at least one side-scrolling adventure game (Super Metroid, Castlevania: Symphony of the Night, etc.), any tactical RPG (Final Fantasy Tactics, Disgaea, etc.), any modern Western RPG (Knights of the Old Republic, Oblivion, etc.), any modern Eastern RPG (Final Fantasy, etc.), any modern 3D platformer (Ratchet & Clank, Sly Cooper, etc.)



Feel free to post arguments against any from the above list, or any games not on the list that you'd add.

The first year I taught game design, I taught two game design courses: a fully practical one where students were given realistic game design problems (e.g. "Develop a core concept and one-page concept doc with brief description, genre, target audience, target platform, and feature list for a given IP") and a fully theoretical one where students read about the leading thoughts in the field and discuss them.

Because of administrative snafus, the practical course was taught first. Students loved the challenge, but once they got to the theory course the (predictable) reaction was: this is great, why couldn't you have told us this stuff before when we could have actually used it?

The next year, I vowed to teach the theory first, and then the students could use this strong foundational understanding of the field to go on and make excellent game projects in a practical class that followed. I ran into a different problem: without the practice of making real games, the students weren't nearly as interested. Sure, I can talk about MDA or flow theory or positive feedback loops all day long and not get tired, but the students had no easy way to contextualize all of this. Yes, I can give practical examples from real games, and that is part of it... but without having done a lot of design work themselves, the students had a lot more trouble seeing it.

Chicken. Egg. Gah! I can't win! Or can I?

This Winter, I'll be trying a third approach: combining the two into one course, alternating the theory with the practice so that we first go over a small bit of theory and then immediately apply it in a real design situation. I look forward to seeing how this goes.

It occurs to me there is a potential fourth approach: also a combined course, but with the practice first... then followed by discussion. This has the downside that students are less likely to produce anything of value (after all, I'm not teaching them how until after each assignment is over) but it should make the discussions much more valuable: we can talk about what went right or wrong on each project, and then comment on how current theories play into it all. I may try that in a future iteration.

This came up in discussion with another designer the other day (after a comment along the lines of more game design students these days being familiar with Thomas Kinkade than Reiner Knizia). I thought it would be an interesting open question to repost here.

If you're unfamiliar with Thomas Kinkade, he is one of the more (in)famous painters alive today. You might want to read his Wikipedia entry here to put yourself in the right frame of mind to consider this question.

The question: to the extent that game design is an art form, what game designer is the equivalent of Thomas Kinkade? Or, more succinctly:

Painting : Thomas Kinkade :: Game Design : ???

Some people might consider the label "Kinkade of Games" to be a great compliment. Others might consider it a grave insult. For this reason, I won't hold it against anyone if they choose to comment anonymously.