So… from eingy, what I do at my job:
On a project-wide basis, it’s my job to guide the development of a game’s design. This is a mix of solo and collaborative work. On the solo side, it entails figuring out, at a high level, what the heck we’re going to make. This is often best accomplished by walking the dog, gardening, cooking, driving, or lying in a bathtub. This is where the fact that I’ve basically internalized a couple decades worth of gaming, a bunch of wacky engineering experience, and a lifetime of reading, interacting with a wide variety of art, and a whole lot of random knowledge come into play.
Still, all that stuff happens, by and large, outside work, and it only happens at very rare stages of a project.
On some projects, you start with a design written by someone else. In those cases, it’s my job to make sure the design works. This means reading through the document with an eye for the underlying behaviors, making an attempt to try to understand what the player is going through while playing the game, and determining whether the experience as I envision it is fun or not. It also often involves reading for consistency – if something behaves one way in one part of the design document, does it behave that way all the time? If not, is it clear when some sort of shift happens?
This sort of consistency checking and concept review is probably the thing I’m best at. I tend to read with an extremely critical and skeptical eye – generally coming at a document like the game is absolute garbage, and it’s up to the document to convince me otherwise.
Once inconsistencies have been spotted, it’s then a problem of trying to figure out where inconsistencies occur, what the overall *goal* of any part of the design is, and trying to rectify any problems while keeping the overall goal in mind. That’s a big part of the early stage of working on a game where you’re working from someone else’s design pitch. It’s the same if it’s your own pitch, but it’s much, much harder to do that sort of editing on something that lives in your head.
If it’s not a pre-existing design, or if there are areas that need to be substantially fleshed out, I’ll spend some time doing a personal brainstorm on the subject, and try to come up with interesting ideas. Generally, this involves sitting at a computer with an open Notepad window, putting on some music, and then typing in a sort of stream-of-consciousness way until I’m happy with the results. Generally, about a 10 minute process on a good day.
Once I have a starting point, there’s a point where you have to decide who else to involve. If it’s a small thing, it’s often better to write a design spec for the feature on your own, then take it to the rest of the designers for review. However, for larger features, I’ll then organize a meeting with the rest of the designers for a brainstorm. Even if I’ve got some ideas from my personal brainstorm, I’ll generally start the meeting with a blank slate, giving the other designers a quick rundown on the subject, and let them go to town. Sometimes the process requires a bit of a kickstart, which is where the personal brainstorm comes in handy – I can throw out some starting points, and people can build off that.
Once the brainstorm’s done, I’ll either then use those ideas to write a spec, or I’ll delegate the task to one of the other designers. Once a spec is written, whether I wrote it or not, it gets reviewed by the design team as a whole. After it’s reviewed by the design team, and the idea’s been okayed, that spec then goes out to the other team leads, where artists, animators, modelers and engineers have their say. We’ll meet together and break down the feature into each team’s relevant tasks, and talk about implementation details. Sometimes, a concept artist will over the next couple days, generate a few concepts, which can then be reviewed.
Hm. This is sort of deviating from the idea of the meme. I’m just walking through the day-to-day process, and not saying necessarily what *I* do on a day to day basis.
- Concept Generation: I’ll generally spent an hour or so a day writing stuff on the project Wiki, detailing desired features, filling in gaps where detail was missing, or reviewing existing designs.
- Meetings: Each day, I attend between one and five hours worth of meetings. In the early stages of a project, there are a lot more meetings – brainstorms, reviews, etc. Takes up a lot of time.
- Scheduling: Right now, I’m doing a lot of task generation and scheduling using the company’s nigh-incompetent tracking tool. This is sort of an odd situation to be in, because it really isn’t my job to track the schedule. But fixing that requires:
- Putting out fires: This is a combination of seeing problems, trying to figure out how to resolve them, then resolving them. This can vary from someone wondering about a feature that’s missing to a personality clash between team members, or any variety of miscommunication from minor to horrific. This involves a lot of talking to people, making sure exactly *what* they’re having a problem with, figuring out a solution, and then talking to more people to make sure that solution gets implemented.
- Walking through minefields: Unfortunately, this job also requires a lot of navigating weird personality issues, ego, company history, and the like. In most creative processes, the various people who have a stake in the result are defensive or protective of their ideas. My job is to make all this stuff *work*. If someone likes an idea, but it’s unworkable, my job is to either make it work, find an alternate solution, or kill the feature.
- Dealing with people throwing bombs: A lot of people in this industry seem to think that anyone can be a designer. As a result, everyone offers design suggestions. Some are good, some are bad. Often, the good ideas come from the same people, and the bad ideas come from the same people. I have to work to incorporate the good ideas where possible, and deflect the bad ideas where possible. Unfortunately, bad ideas often seem to come from above. This means that as much as I’d like to sensibly deflect an idea, I’m often required to incorporate it to some degree. I’ve been getting better about effectively deflecting bad input from wherever it’s coming, but it’s often the most stressful part of the day.
Most of this happens with me sitting in front of the computer, either staring at the Wiki, making diagrams in Keynote (not the right tool for the job, but the rightest tool for the job that I have), looking at the schedule, reading or writing e-mails, or listening to music with my keyboard in my lap, writing.
The rest of it happens with me talking to various other people on the team either informally, or in meetings.
This isn’t a very good description of what I do, but honestly, it’s what you get at 1:50 on a Saturday morning. So F off. I’ll write a better summary of it all later. 😛
So, how do you check (and develop) your design sense? It’s always difficult to get outside your head and see how something will fly in the real world.
Do you have any interesting mistakes (things that your sense told you should work but didn’t) or successes (something that you really feel you nailed)?
In terms of “developing” a design sense, I’m not really sure what one does, or doesn’t do – it’s one of those things that I can recognize in someone within five minutes or so, but I don’t really know how to teach someone.
Mostly, it’s trying to understand what a player will be going through – what *I* would want to see as a player. There’s a lot that makes a game interesting – good mechanics, a sense that *I*, as a player, bring something that makes the experience unique, a good story… mostly, it’s about creating some sort of emotional tension in the player.
Part of that comes from consuming a wide variety of media and having a pretty broad palette of experience to draw from to create that emotional tension, and part of it is developing a good process for throwing a bunch of stuff at the wall and knowing what should stick.
In terms of interesting mistakes… I dunno that I’ve had anything I’d consider a real mistake yet, but there’s definitely been some unusual reactions to certain things. In Brooktown, for instance, I created a really flexible system to have characters tell you stories about extracurricular stuff they were doing.
The problem was that there was such a limited amount of scripted dialog that you’d start to hear repetition really early on in the game. With this secondary “tier” of topics, we could throw a bunch more stuff in that was partially generic, and partially generated by the character’s class. So you might hear the same subject come up, but the different people would put a different twist on it.
Small talk, basically – people would ask you about the weather, and depending on who they were, they’d have different responses based on their general clique categorization. It worked in the sense that the repetitive stuff would at least be stuff that *should* be repetitive – the trivial bullshit you talk about to kill time – but it still ended up not being enough content to disguise the system at work.
So, you’d have people basically being “trained” to talk to someone only once – they understood pretty quickly that the first conversation was the only one that contained “real” information, and any subsequent conversations were basically filler.
So, the later stuff, where the filler developed into more detailed storylines ended up being largely ignored because by the time they would have gotten to the more interesting bits, they’d already been trained not to actually ever trigger those conversations.
Blah.
So, the lesson might be to front-load that sort of content, or the other lesson might be that you’ve actually gotta mix up the overall game structure more, because players are really quick to understand what has “meaning” and what doesn’t in a situation like this.
*shrugs*
seppo