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.

8 comments:

poz said...

Not that it matters to your post, but CoH used diminishing returns on Enhancement stacking as well.

Mike Darga said...

Ah right, thanks! I knew I missed something =)

Tesh said...

Tangentially, when framing a ser of diminishing returns we should probably include a frame of reference. There's an efficiency that comes from scale when going up to a projector, for example, if you're going to use it in a theater and charge admission. The same theater projector is insanely inefficient for an individual consumer, but as a business investment, it will function differently.

Of course, within that "business investment" frame of reference, there will be different projectors with their own diminishing returns...

Tesh said...

"framing a set", bad typo, Tesh. :(

Also, great article.

Mike Darga said...

Good point Tesh. Under my framework of the 4 types of efficiency, I think I'd include that under piggyback.

NeoDodge said...

"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."

The comparison ain't perfect here.
A development team can be just about any size, with effective diminishing returns in efficiency tied to the increasing difficulty of organizing said team. But a 2 or 5-dev team will eventually get the project done (assuming you have reunited all required proficiencies, of course). A /*WoW*/ Raid team actually REQUIRES 40 people before you can hope to achieve anything. Only then come problems with composition, organization and stuff...

Mike Darga said...

That's a good point. However there are some games that just can't be made with 5 people. You could try to make GTA, WoW or Fallout 3 with a team of 5, but it's just not practical.

It's technically possible, in the same way that it's technically possible for 2 people to down a raid boss, but it's generally not something you'd do.

Mike Darga said...

Thinking about it more, the main distinction is actually that you can ONLY have 40 people in a raid group. If you bring 80 people to a 40 man raid, would anyone do that?

To me, a raid group of 60 or above is the equivalent of those giant development teams with 300 people.

I'd contend that an 80 man raid group would usually annihilate a 40 man boss, but be so much harder to get started that most people wouldn't bother.

Also, on raids where 1 person messing up causes a forced wipe, you then have a much higher chance that 1 person will be in the wrong spot at the wrong time. This part is technically diseconomy of scale, but it fits under my umbrella of diminishing returns too.