- 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:
Subscribe to:
Post Comments (Atom)
6 comments:
With regard to the "fun" question, I find that Marc LeBlanc's 8 kinds of fun cover the topic much better than Koster or Csikszentmihalyi.
You've inspired me to blog on 8 kinds of fun for sex.
Ooops, that URL should be:
http://wordsonplay.wordpress.com/2008/10/09/eight-kinds-of-fun-sex/
What I still am unsure about is what it is that technical artists do on most dev teams. In the team I worked with, he seemed to primarily be managing the art pipeline (automating the conversion of art from tool-native formats to game-native formats). But then we got a dedicated coder to manage the art pipeline, which seemed like a good idea since it was really primarily a code-monkeying / IT / scripting sort of task. (I was a newbie when the TA was still around, so he probably did far more than I was aware of.)
What am I missing in the big picture here? What do Technical Artists usually end up working on?
I've always found "Technical Artist" to be too ambiguous. I've seen it applied for an artist who wrote shaders, a programmer who made asset management tools for artists, and an artist who could write scripts for his peers. It's gotten to the point that when I hear someone reference the term, I make them tell me their definition. Much like the phrase 'beauty is in the eye of the beholder' I consider the definition of 'technical artist' to always depend on the speaker. I've been a tools programmer for a variety of games. In some studios, I guess my title would have been 'Technical Artist'.
As for why someone who knows some art and some programmer is rarely good at both, one could argue that it's a consequence of specialization. I have a bicycle and a car because they're good at two different things and something that was a cross between them wouldn't be good at either thing. There are, of course, other arguments to be made (passion, temperment, ... ).
"I have a bicycle and a car because they're good at two different things and something that was a cross between them wouldn't be good at either thing."
Actually, it would be a motorcycle, and it's less good at being a car than a car is, it might increase your street cred.
More seriously, though, I always felt that the problem with 8 kinds of fun is that they don't all seem to be on the same level. "Competition" seems to be a fundamental part of games, but "Sensation" doesn't. Maybe it's just me...
Interesting comment about the three stages that designers go through.
One thing I've noticed is that even experienced designers often misinterpret the concept'fun comes from learning skills'. The stages I see go something like this:
1) New designers will come upon the concept, often in a class or a book, and gain a shallow appreciation of what it means. This is the joy of rote learning. Often 'mastery' is internalized as 'that moment of pleasure I feel when I solve a tricky puzzle'. This narrow definition of how the brain rewards certain types of learning works in a surprising number of situations. This is an exciting time for students since it is better to have some sort of working model than none at all.
2) They start building games and then realize that their simple mental model doesn't account for all the little edge cases. What about social play? What about the subtle, more comforting joys of performing what you already know? These don't cleanly fit into the basic "feeling I get when I make a hard jump in Mario."
3) At this point, many designers give up on attaining a systematic understanding of game design and fall back on the use of patterns that describe common behaviors you see in existing games. The 8 types of fun is an example of this. If you witness social fun, make a category called 'social fun'. Designers focus on recording 'what' fun exists. This works. You can thrive as a designer by having a half dozen well worn rules of
thumb backed up by years of hard won experience.
4) Over time, some designers again see underlying systems behind the patterns. We start describing 'why' fun exists instead of relying on simple heuristics. When Raph talks about 'mastery' he is writing about fundemental learning structures that are instrumental to how human beings experience the world. We implicitly use these when we make games. Do these systems come into play during social play? Absolutely. Do they apply cleanly to each one of the patterns that most working designers use every day? I've found that they almost always do. The patterns we observe emerge from the system and understanding the system lets you ask smart questions about your designs.
5) So the designers write books and essays explaining what they've learned. Which are then taught to the next generation. And the cycle repeats itself all over again. :-) Hopefully with each cycle, the time that it takes for designers to reach the fourth stage gets shorter and shorter since they are standing on the work that has come before.
And we do need to advance the discussion that fourth stage. Systematic understanding, asking 'why' not describing 'what', is important because it allows us to create repeatable, testable conceptual tools for building games that don't take 10 years of apprenticeship to put into action. This is a good thing.
Certainly, don't throw the baby out with the bathwater because you've reach stage three. Keep those ideas about skills and mastery bumping around. You may need them later.
take care
Danc.
www.lostgarden.com
Post a Comment