- If you get a group of programmers together, they will quietly take notes. A group of artists will sit in their chairs doodling. A group of designers will loudly interact, debate and argue. (Corollary: never schedule a group of programmers to be in an adjoining or shared space with a group of designers, whether you're organizing a conference or putting together next semester's class schedule.)
- If the conference session you're moderating has the word "Improv" in the title, any number of things can go horribly wrong -- you run out of time, you have to get moved to a different room, you decide to change what you're doing in mid-presentation, whatever -- and participants will assume it's all part of the act, and applaud your brilliance.
- When a game designer (or student) first starts trying to define why games are "fun" they have trouble even conceptualizing it beyond "I know it when I see it." Then they encounter Csikszentmihalyi's Flow and/or Koster's Theory of Fun and have this huge epiphany: Eureka, all fun comes from learning a new skill! Then after awhile, they enter another stage of questioning this: wait a minute, if all fun comes from skill mastery, why aren't students driven by the promise of fun to get straight A's in all their classes (even the poorly taught ones), since that involves mastery of the material? Why is sex fun (by some standards), and yet doesn't involve mastery (ahem, again by some standards)? At any rate, you could think of this as three stages of evolution of a game designer, and different designers are going to be in different stages, and when they encounter one another there will be chaos when they start discussing the nature of "fun."
- Another evolution happens during the career path of a game designer. At the beginning, you take whatever work you can get. Mediocre Sequel 2: The Safe Publisher Bet? Sure, I'll take it -- anything to be able to say I worked on a published title. This continues for awhile. In late career (I suspect this is when your published title count gets into the high teens, but it varies with how interesting your random projects have been until then, and it does require you to have worked on at least one brilliant title), you start to realize that your name is now its own IP, and that working on additional failures actually hurts rather than helps you at this point. And for the first time, you start turning down work because you're afraid of harming your own reputation (as opposed to some other reason).
- Technical artists -- those rare people who know both art and programming -- are worth their weight in gold to a development team. At the same time, many technical artists are not particularly strong in either art or programming. I'm sure there's a corollary here, but I haven't yet figured out what.
- If you start playing any Eurogame in the hallway at a game development conference, you will soon have more spectators than players. (At one point we actually had more spectators than the heavy-metal band down the hall who were playing the themes to Mega Man 2 in realtime as someone else was doing a speedrun, live. Apparently, Reiner Knizia is geekier than Capcom.)
Wednesday, October 08, 2008
Lessons learned from SIEGE
SIEGE was an interesting experience for me this year. I learned a lot of valueable lessons, many of them related to life and career more than actually making games. Observations: