June 29, 2009

Glossary: Efficiency

Defining terms is an important step in the design process. There are some concepts for which I find it useful to create new or more specific definitions when discussing game design. See a collection of all glossary posts, here.

Every reward comes with a cost

Writing this blog has been very rewarding so far, both personally and professionally. Writing about game design helps me clarify my thoughts, makes me a better writer, and helps improve my game design skills. It's also been a great way to make connections with other designers, and to market myself in a tough job market.

Blogging is financially the cheapest hobby I've ever had. I already had a computer, and an internet connection, and Blogger is free to use. However, blogging can cost a large amount of time and energy. Every post I write costs some time to write it, and an idea for a post, which is usually generated out of some time playing games, making games, reading, or discussing design.

Blogging about games is a good choice for me from both a rewards standpoint and a costs standpoint. The rewards it offers me are rewards that I care about a lot, which makes any time I spend working on this blog time well spent. On top of that, many of the costs it requires are things I'd already be doing anyway: I play games for fun, make games for a living, and enjoy discussing design with my friends and colleagues. I even kept a journal of design notes for years before starting this blog, which means that all it really costs me is the time to write the posts.

Because it doesn't cost me much additional effort to create this blog, and the rewards it generates are things I value highly, blogging about games is efficient for me:

Efficiency: The ratio between the cost of an action and the perceived value of its reward.

Not all rewards are valuable to everyone

All our resources (time, money, energy, concentration) are finite, so it's not enough to generate rewards. We have to make sure that the rewards we're generating are rewards we care about. Which of course means we have to know what it is that we really care about.

It wouldn't be a great idea for my brother to write a game design blog. He's not a writer, plays few games, and has no background designing them, so the time cost of writing a game design blog would be very high for him.

But even if he could snap his fingers and magically have a game design blog, the rewards it would give him aren't rewards he particularly cares about. He has no real desire to make games for a living. He's training to be a police officer, so the rewards of writing a game design blog would seem very low to him. In other words, my brother wouldn't find writing a game design blog to be an efficient use of his time at all, even if he could magically do it in 5 minutes per day.

4 kinds of efficiency

There is no recipe for efficiency. It's more like an equation, in that there are several different inputs and outputs, all of which can vary. There are different ways to achieve lower costs, or to achieve greater rewards, and in an ideal situation both can be achieved at once.
1 - Process efficiency
My degree is in writing and I've been writing for a long time, but unfortunately the process of writing is something that takes me a lot longer than I'd like. There are some amazingly prolific bloggers out there that manage to post several long posts per day, which for the sake of this example I'll assume means they are much faster writers than I am.

This is good old fashioned efficiency as most people would define it: generating greater rewards from the same cost, which usually results from an improved methodology or process. As the saying goes, "work smarter, not harder."

2 - Volume efficiency
Mixed among the game development blogs I read are a few that would be more aptly described as news aggregators. These sites don't really create much of their own content, they just link to other blogs or reprint press releases from companies with a minimum of commentary. These websites tend to be marked by their huge volume of posts per day.

This method of efficiency involves decreasing all costs as much as possible, in the hopes of increasing volume. This may sound similar to process efficiency, but I believe the difference is an important one.
3 - Piggyback efficiency
Before I started blogging, I already designed games professionally. I played and dissected lots of games, and took notes on things I found interesting. In effect, I was already doing most of the work required to write this blog, so its cost is very low. It's a lot like using a river or a windmill to generate electricity; because those resources are already there, harnessing them to generate a reward costs very little.
4 - Luxury efficiency
On the other hand, there are bloggers like myself who don't post particularly often, but (I'd like to think) generate results of a higher quality. I think this is partially because I spend so much time worrying about process efficiency at work all day, and taking a leisurely pace for personal projects is a nice change.

That aside, it's also because I think that's what distinguishes my blog from the sea of other game development blogs out there. I write my blog as though I were writing a book, both because that is the kind of blog I like to read, and also because I have half a mind to turn it into a book at some later date.

This is not to say that I wouldn't like to turn out quality writing more quickly. I still want to improve my process efficiency when it comes to this blog, but hopefully that's just a question of practice.

Efficiency in game development

Any successful team or company you can think of in the game industry is likely to be succeeding on at least one of these types of efficiency, and really great ones are likely to be efficient in 3 of the 4 ways. I don't think all 4 types at once is possible, because luxury efficiency and volume efficiency are usually mutually exclusive.

There are quite a few teams in the game industry that try to compete based on process efficiency. The ones I've seen that are the best at it are expansion pack teams and other teams that have to release games on an extremely short and regular schedule. When I worked on The Sims, my team pushed 2 expansion packs and several other SKUs per year. There was no way to come close to this volume without a very disciplined process.

Volume efficiency isn't something that was prevalent in the game industry until pretty recently. Iphone games made by very small teams for very little cost in very little time are the best example I can think of of the "fast food" mentality in game development.

Using the same engine for multiple projects, reusing code on a sequel, and releasing expansion packs are all also good examples of piggyback efficiency. A great example of piggyback efficiency in the game industry is EA, who ports their games to multiple game platforms and creates incremental sequels. I consider the Madden Football franchise the pinnacle of piggyback efficiency.

There are two companies that should come to mind when I mention luxury efficiency: Valve and Blizzard. Both of these companies take large amounts of time and money to make their games, but every one of them is of extremely high quality and is generally very successful. This is the most difficult form of efficiency to pull off, because it relies on the ultimate success of each new project. A failed Blizzard title would be a much bigger failure than a failed EA game or a failed iphone title. For a classic example of luxury efficiency gone wrong, see Duke Nukem Forever.

June 10, 2009

Design Lessons from Performing Arts Jobs

I've learned several important design lessons from my work in various non-design jobs. See the full introduction, here.

Job: Acting, Singing, Dancing

I spent ten years or so (from age 12 to 21) studying the performing arts in various forms. I played instruments, worked as a dance coach, performed in plays, sang in choirs, and spent my first two years of college studying classical voice.

Most of the lessons from each of these disciplines apply to the rest as well, so I'll just write these up as though they were all one job.
1 - Lazy practice makes for lazy performance
A classic problem among performers who are just starting out is that they feel embarrassed giving a full performance in rehearsals, preferring to "save up for the show." It feels strange during rehearsals to break into tears or to passionately kiss someone, but the people who hold back for weeks before a show are never really able to commit fully on the big day.

In any activity, the habits we build from day to day condition our mind and body to perform those actions by reflex later on. In game design, I think it's very important to hold ourselves to the standard of whichever role it is that we want.

If you want to become a professional designer, lead designer, etc., don't wait until you've achieved that role to start thinking and behaving like one.

2 - A shared vocabulary is important
When watching an expert group of dancers or musicians rehearse, it's astonishing how quickly they can communicate. Various forms of music and dance all have their own highly specific language to aid in communication. A musician who has learned their discipline, but not its language, will never be able to collaborate successfully, and this is also true for game designers.
3 - Small goals are more satisfying
Becoming a virtuoso dancer, actor, or musician is a such a gradual undertaking that it's almost incomprehensible. After a day of rehearsal, it's impossible to really know if you've gotten any closer to your eventual goal - it can take decades.

Performers solve this problem by focusing on much smaller goals: learning choreography to a specific dance combination, practicing scales, learning new songs, etc. Game designers need to apply this same strategy when it comes to making sure that players feel satisfied. Doling out small tasks that lead toward a larger goal is something that RPG designers do very well, although it can be difficult to not overcompensate and give the player such small tasks that they never feel they've achieved anything.

4 - Reputation counts more than skill
I once saw one of the dancers in my troupe drop his partner on the head. He was generally a very good dancer, but he had quite a hard time finding partners for the next few months. All the girls saw him as someone who might injure them.

Game development is similar, in that actual skill level is almost completely ignored in favor of how easy people are to work with. Or rather, skill level is important to your reputation, but can be cancelled out by having a reputation for being hard to work with.
5 - Smart leaders delegate to trusted experts
Directing a play is a ridiculously complicated job. No one in their right mind would attempt to handle staging, set construction, lighting, music, choreography, and publicity on their own. The best directors find trusted experts, and shop out responsibility and power to them. Those leads then delegate further: The musical director is appointed by the director, and in turn appoints an orchestra leader, a vocal coach, and a choreographer. The choreographer then appoints a dance captain.

When successful, both plays and videogames are the product of multidisciplinary groups, unifying their efforts toward a common goal. Wagner referred to this as Gesamtkunstwerk, or total artwork. Strong creative leadership is essential to such a synthesis, but micromanagement is destructive.

6 - Know when to blend in
There are times to show off, and times to be part of the group. Singing ten-part harmony in a chorale is very different from singing a duet, which is very different from singing a solo aria. Likewise, dancing as a Rockette is very different from dancing as a prima ballerina.

Great performers always take advantage of their moment to shine, but also know how to collaborate unselfishly. Game designers are particularly bad at this. Ask yourself how important the feature you're working on is. How central is it to the game as a whole? Your painstakingly-simulated weather system may not be warranted in a game about riding dinosaurs off of sweet jumps.