July 27, 2009

Stop Trying to be Productive

I'd be willing to bet every game developer in the industry has worked or will work a 12 or 16 hour day at some point in their career. This happens because there's too much work to do and a big deadline coming up, and people find themselves desperately in need of ways to increase productivity. The game industry is rife with horror stories of mandatory 12 hour days and seven day weeks, aka crunch time.

It's also common for a team approaching a big deadline to suddenly become a black hole that starts sucking in developers from other teams, or absorbing other teams entirely. While I was working at EA, the Godfather team pulled in extra people from all over the company until it became monstrously huge. There are people who worked together on that game who never even met each other.

There's a reason things like this happen. Working more hours or throwing more people at a project does increase productivity, at first. The problem is, returns from such brute force methods diminish rapidly. Once diminishing returns kick in, efficiency takes a nosedive, ultimately hurting productivity. This might not happen for a few weeks or even a couple of months, but it will happen. Brute force productivity is simply not sustainable.

Don't forget, productivity = efficiency x effort. People who work 12 hour days are trying to increase productivity by increasing effort, but that increased effort can lower efficiency and cancel itself out. It's easy to get stuck in a negative feedback loop: focusing too much on productivity ultimately hurts efficiency and therefore productivity. In the long run this leads to people working under miserable conditions and not even getting any extra productivity out of the deal.

The path to true, lasting productivity is through efficiency, not effort. If you can manage to become more efficient (spoiler: you can), productivity will take care of itself. Focusing on improved efficiency allows people to either be more productive in the same amount of time, or to work less and get the same amount done. Even if people choose to work less, they'll become happier and more energetic, ultimately increasing efficiency even further.

Focusing on efficiency is a positive feedback loop, and the benefits can be huge. One investment of a week working on a usable development tool or a well-written design doc can pay off over months or even years of development.

Beware people who treasure productivity

Ironically, it always seems to be the people who pride themselves on their productivity that waste the most effort. People who focus too much on productivity will spend 12 hour days fighting against bad tools instead of spending 2 hours fixing the tools, or they'll reimplement the same feature 4 times because they didn't take the time to discuss all the details or write a design doc.

These people never want to "waste time" on things like meetings, documentation, or tools. They complain that these things take time away from doing "real work," and rightly so. Spending time on that sort of thing does hurt productivity in the short term, which is exactly why productivity is the wrong goal to have.

Don't get me wrong, some people have good reason to be wary of meetings and documentation: they've worked on a team where so much time was spent on process and meaningless meetings and overdocumentation that efficiency and productivity went right out the window. Improving efficiency has a point of diminishing returns to watch out for just like anything else, but in my opinion it's the lesser of two evils by a long shot.

Make the switch to efficiency

I learned the hard way what a red herring brute force productivity can be. I pulled allnighters left and right in college, and I brought those habits over into my work life once I left school. It actually took me a few years to realize how much effort I was wasting and to wean myself off of 12 hour days.

The funny thing is, getting more done in less time feels like cheating at first. Staying at work all hours and living like a zombie feels much more like Good Old Fashioned Hard Work, and it's hard to accept that you can go home while the sun is still up and still be productive.

Something that really helped me was to find a good compromise: I started working 10 hour days, but made sure that all my time after 8 hours was spent on something that would help my efficiency. I spent that time doing things like programming tools to help me get my work done faster, updating documentation, and mercilessly pruning my email inbox. Gradually I became efficient enough that I felt comfortable bringing my work day down to 9 hours, then 8.

The hardest thing for me to learn has been to push back on deadlines that would require work to be rushed out the door without being properly thought out. Redesigning and reimplementing work is one of the biggest wastes of time I've seen in the game industry. Take the time to get things right the first time, even if that means you've got to push your schedule out a few days. Iterate on whiteboards, on paper, and in meetings, when it's still free. The time you save in the long run will absolutely be worth it.

July 19, 2009

Glossary: Productivity

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.

Productivity versus Efficiency

One of the reasons I feel the need to define things here before talking about them is that people love to take terms and twist them to mean whatever is most convenient.

Under its original economic definition, productivity is a synonym of efficiency: getting more done with the same amount of resources. Classic productivity was hard to achieve, so people craftily and unconsciously morphed the word into something that was a more easily attainable goal. Instead of efficiency, which was what being productivity used to mean, people just started using the term to refer to getting things done in general.

Usually when I hear people use the term productivity these days, they use it to refer to the fact that they got a lot done in a day or how busy they feel. I'm going to adopt this modified definition of productivity:

Productivity: The amount of rewards generated in a particular span of time, regardless of how efficiently those rewards were generated or how much effort and resources they cost.

Productivity = (Effort x Efficiency)/Diminishing returns
A great example of productivity and efficiency together is an automated factory. However, since productivity is an equation, it's possible to be productive without being efficient, as well as to be efficient without being productive. People who follow The 4-hour Workweek and other such methods attempt to get the same amount of rewards for much less effort, through increased efficiency.

On the other end of the spectrum, it's much more common to find productivity without efficiency. I used to work 16 hour days and 7 day weeks. I got a huge amount of work done, but work was all I ever did. I was being very productive, but at a huge cost. Therefore my efficiency was very low.

July 12, 2009

Glossary: Diminishing Returns

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.

Higher costs aren't always more rewarding

I haven't owned a TV for a few years, and I'm thinking about buying one soon. The other day I was at Best Buy, looking at their giant wall of TVs, and I started playing a game. I tried to look at the size and picture quality of each of the TVs, and try to guess how much they would cost.

As you can imagine, it was pretty easy to guess which TVs were the cheap ones and which ones were more expensive. Cheap TVs are small and don't look very good, and nice TVs are huge and look great.

What wasn't very easy to guess, though, was how much extra cost a given amount of size or picture quality would add to a price. On the low end of TVs, an extra 2 hundred dollars will buy you a much nicer, much better looking TV. On the high end, though, two TVs of the same size might have a price difference of a thousand dollars or more just because one has a slightly faster refresh rate or a higher contrast ratio.

At any given time, there is only a finite range of mass-market TV technology. If I decided to spend $10,000 on a TV, the difference in quality that TV would have over a $5,000 model would not be nearly large enough to be worth it, and that $5,000 TV is probably only somewhat nicer than the $2,500 model. This is a perfect illustration of diminishing returns:

Diminishing Returns: For any efficiency, the tendency of increasing costs to be less effective at increasing rewards. Diminishing returns may only apply above a certain cost level, or they may scale over the entire range of possible costs.

Different efficiencies diminish differently

The four kinds of efficiency that I defined the other day all have their own dangers when it comes to diminishing returns.

Process efficiency, my favorite type of efficiency, attempts to gain greater rewards from the same amount of resources by way of improved methodologies. This is very useful to a point, but teams that overdo it tend to find themselves in incredibly rigid structures that can start to take more time and energy to participate in than they save.

Improving volume efficiency by decreasing costs can be very effective, but eventually the amount of quality lost to increase costs further will begin to become an obstacle. Even free games will have a hard time getting players if their quality drops too low.

Piggyback efficiency can be improved by generating more and more rewards from the same set of resources. Making more spinoffs and expansion packs and ports is a great way to improve piggyback efficiency, but doing it too much can earn your franchise a reputation for making games that are just the same code rereleased every year, and begin to hurt sales.

Luxury efficiency, with its focus on spending extra costs to achieve higher quality, starts requiring more and more time and resources to create any measurable difference in quality. If a game company can make a game with a Metacritic score of 80 in 2 years, and a game that gets a 90 in 4 years, how much more time would it take to reach a score of 100? Eventually, spending more time and money may eventually stop improving the game at all, or even result in it being cancelled.

Diminishing returns in game development

Every rewarding activity can be expressed as an efficiency, and every efficiency is subject to diminishing returns of some sort. Diminishing returns come into play very often both for those creating a game and those playing it.

For both developers and players, practicing something returns huge skill gains at first, and then diminishes to very small skill gains as a high level of expertise is reached. This is also known as the learning curve.

When thinking about a problem for too long in one stretch, it takes a lot more effort to have a good idea. In this case, the diminishing returns are caused by simple fatigue. Working 16 hour days and pulling allnighters, two bad habits of game developers, are doubly damaging. These types of diminishing returns not only cause a drop in efficiency for that day, but they also cause sickness and low performance on subsequent days, lowering efficiency even further.

Diseconomy of scale, known to most people from its description in the book The Mythical Man-Month, refers to the tendency of larger groups of people to be less efficient. This can be seen both when developers try to throw more people at a project to get it out the door, as well as in the difficulties players have organizing 40 person raids.

There are also technological diminishing returns. How much more effort should be spent on the rendering technology of a game before those hard-earned rewards become hard to notice?

Diminishing returns as a game mechanic

Diminishing returns are also a great tool that game designers can use to keep any particular behavior from becoming overpowered or exploitive. They're particularly useful in combat balancing, but there are also some more general uses.

City of Heroes and World of Warcraft both use diminishing returns as a PvP combat balancing tool, but both use them in a different way. In CoH, there are diminishing returns on how effective various stacked buffs can be on different classes. After a character is already buffed, subsequent buffs are less effective.

In WoW, the durations of control effects become diminished if a character is affected by more than one in a 15 second period. If a player is stunned and then stunned again, the second stun lasts only 50% of its normal duration. A third stun lasts 25% of its normal duration, and the fourth stun won't be applied at all.

WoW's rest XP system is really just a disguised form of diminishing returns, in that players become less effective at gaining XP if their playsessions last too long or are too frequent.