Hard Decisions

Realized it has been a very long time since the last Lazy Designer post! So here’s a new one:

Overview

As a lead in a game development studio a significant portion of your time will be spent making decisions. Often these decisions will come naturally from discussions with your team, the logical result of debate.

Sometimes though, as the person responsible for final design decisions, you will need to make an unpopular decision.

Here are some tips, based on my own experiences with being in this kind of situation. None of these will make the hard decision any easier but hopefully they minimize some of the potential ‘aftershocks’.

Realizing a Need for Change

For me the hardest decisions were those that revolved around drastically changing how the game was played (i.e., having to remove something fun even if it was enjoyable by a subset of the audience when it turned out the more general audience didn’t like it) or cutting content that had already had a lot of time and effort spent on it but was still not complete enough to ship.

How did I realize things needed changing?

1. Be aware of test data I always reviewed the bugs filed to the team, not just within design but across the board. I used searches and custom queries to try and build a picture of what all players were experiencing. This combined with focus testing and more advanced data tracking helped me make general game design observations.
2. Schedules Keep on top of your own schedules and those of other departments. If you see slippage in other departments you need to realize that it might fall to you to make design cuts to give them more slack. The more proactive you can be about this the better.
3. Listen to the Team An even harder decision to make is when you are not the one to initially realize the change needs to be made. All of us, managers especially, want to feel like we are always on top of things. But sometimes a team member comes to you and explains a problematic gameplay element or a resource bottleneck. You can’t dismiss this. And this is also why you need to be circulating through your team regularly, asking questions… some team members won’t be comfortable telling you there is a problem unless you ask them directly.

The earlier a hard decision needs to be made, the better. This requires constant analysis of the game-in-development.

Evaluating

Before you make the decision — and hopefully well before you have to make a hard decision — your game engine should be tracking user gameplay data. With solid data it is easier to make big changes, easier to communicate those changes to management and the rest of the team, and easier to evaluate whether the change was worthwhile.

This requires data hooks, testing where the player is playing, how long they are spending there, and what they are doing. This should be correlated, if at all possible, with in-person interviews. I used to create reports with snippets of what the tester has said to me about the gameplay element, a list of the bugs they’ve sent on it and whatever other data I could collect about their gameplay experience when using the feature under consideration.

This data, in bulk, can help form an opinion about what is happening with the game. This data is important — if you are going to convince others that a hard decision is required, you need to convince yourself first.

What are some kinds of data hooks that are useful? A full list would be a chapter in and of itself but here’s some quick suggestions:

1. Achievement Systems Most console games have achievement systems built into them. When designing the achievements for Dragon Age we definitely kept in mind what questions we might want answers to *after* the game was released, to help guide decisions on making a sequel. Lists like this one, showing how many users won particular achievements is quite useful. Even though I’m no longer with BioWare I spent some time reviewing it and comparing it against what my own assumptions were when making Dragon Age.
2. Usage Stats If your team has created a web-based product, a simple measurement to use is to measure site activity data before the change and compare it to activity data after the change. This is a simple and effective measurement of the effectiveness of the change that can be followed up with more robust investigation.

No matter how or what you are tracking, the information should be communicated to the team.

Communicating Internally

Letting the team know the reasons behind a decision and the reactions to the decision are important for many reasons but from a straight efficiency point of view, letting them know how the decision was reached, and its effects, helps train them to use data in their own analysis.

Your use of data, and your team’s use of data, will increase both their confidence in you and later your confidence in their ability to take charge of their own sub domains. Basically it creates stronger, more efficient game designers and managers.

Some Hypothetical Examples

Okay, all of the above is a little bit vague so here are some somewhat less vague examples wherein a hard decision might be required.

• Gameplay not fun for non-testers Some advanced players (i.e., testers that have been on the project since the beginning) might become enamored with a gameplay system that deters newcomers. Users in focus tests are telling you the game, or a subset of the game, is not fun.

This can be a tricky issue to fix because the system appears to be ‘fun’ for some players but not fun for others. What I’d do in this situation is try and grab as much data as I can (large focus tests) and sit down with the experienced testers to find out what they like about and why. When proposing a solution I’d look at keeping the core enjoyability of the system while improving, or expanding its appeal. It is a good idea to keep in mind that some experienced users really enjoy difficult and obtuse systems… if your game has such a system, great (so long as experienced users are your target audience). If on the other hand you are building a more casual style of game, you may have to make a hard decisions and change the gameplay.

• Progression Stops This is tricky. In level-based RPG game systems where a character progresses through levels, they will eventually hit a ‘wall’ — the level-cap. For certain player types once progression stops, they stop playing, regardless of whether the story still continues on. It can be tricky to find a reasonable level-cap.

If you find players encountering a level-cap too early there are a few possible solutions.

1. Remove the level-cap! This is usually more difficult to do than it seems. Many games give discrete rewards for reaching certain levels (a new power, a new move, a new visual look)… it is (almost) impossible to build game assets that scale forever. A secondary decision is to implement a floating level-cap, expanding it through later downloads.
2. Change the progression Basically make it harder for players to gain levels (i.e., it takes longer to go from level 5 to level 6). Tweak the numbers so that progression matches the pace of the story. The drawback to doing this though is that if progression becomes too slow (i.e., too much time before advancing levels) some players may become bored… they need constant rewards! This can be mitigated by providing secondary rewards in the dry spell between levels (new items, et cetera).
3. Break the levels Increase the level-cap by spacing out the existing level rewards across more levels. If currently 6 things change when a new level is encounter, spread these rewards across 6 levels instead!

Conclusion

Anyways that’s enough on this subject for now. As I’ve mentioned before I do plan on rolling out a couple articles on building a more testable game engine, and some tips on what kinds of data to track. I’ll let you all know when I get around to that :)