In my fourth post on Trinity, I mentioned something called a Chen Diagram. That was back in June, and I’m finally getting to it!
But before I jump into this very useful diagnostic tool, let’s talk a bit about the problem it was created to solve.
Bang for your buck
When considering what features to work on in a game, it is often difficult to tell how important one feature is overall to the cohesion (the “hanging-togetherness”) of the game’s design. This problem is compounded when the inevitable time arises to consider things to cut — what can you cut that will have a minimal impact on the game? Adding or cutting a single feature can often have profound knock-on effects for the rest of the game.
If you cut the XP/Upgrade system will the game still feel fun?
What about cutting the online mode?
Chen Diagrams are a way of understanding how important an aspect of a game is to the depth of that game’s design so that you can spend the appropriate resources focusing on the most important things (from a design perspective) first.
Note: Sometimes you’ll need to cut things that have a huge effect on the game’s cohesion. This happens, it happens frequently, and when it does you need to know what kind of effect that change will have, so you can shore up the design in other places that might take less work than finishing a whole new feature. Chen diagrams can help with that, too.
The legendary Jeff Chen
I worked with Jeff Chen, the eponymous creator of this analytic design tool, while working in Activision’s Central Design Department.
Jeff’s job was as a design analyst. Along with his other responsibilities, he would create very elegant comparative analyses of different features in different games, often trying to understand how much value is added to a game’s design by any given feature. The idea was that if we could pinpoint features that make the largest difference to a game’s fun-factor, we could make sure that we spent enough resources to make those features great.
What he eventually found out, though, after on sorting through all his data, was that it wasn’t the feature itself that added value. Rather, it was the degree to which any given feature influences the game’s other features.
He was able to demonstrate this by inventing what I later took to calling the Chen Diagram.
In other words, what Jeff found out was this:
A key idea here is the concept of “influencing.” A feature is influenced by another only if it is somehow changed by the other feature.
Note: The symbol ==> means “influences this other feature.” A double arrow <==> means both features influence each other .
- Killing enemies gets you coins to buy upgrades which help you kill enemies. [Combat ==> Treasure ==> Upgrades==> Combat]
- The player has a weapon or tool that allows them to fundamentally change the world’s geometry, as in Minecraft. [Tool ==> World]
- Weapons kill enemies [Weapons ==> Enemies]
- Getting XP gets you levels. Getting gold gets you upgrades. [Both are separate systems that don’t interact with each other, so neither influences the other.]
- If the world geometry is unalterable, nothing influences it.
- Killing enemies gets gold. The player can’t upgrade weapons with it, but may buy a house. [Killing and the house don’t influence each other, but Killing ==> Gold ==> House]
The way Jeff illustrated this principle was via what I immediately started calling “Chen Diagrams.” Every top-level feature is put into a box, then you draw arrows between the boxes to indicate influence. The more arrowheads there are pointing to any given box, the more important that box is to the overall game design.
For example, here’s a full diagram for a made-up Action/Adventure game like Ratchet and Clank:
One other interesting feature of this diagram is that by taking the overall average of links to features (arrowheads divided by number of features) you get what I’m calling your game’s Links-to-Features Ratio, or LtF (Jeff always referred to it as “the score”). That number is an indicator of how linked-together your features are; the more linked-together, the better (because of principle #7).
Likewise, for “categories” of features, like the three columns in the image above, you can use the LtF to tell which parts of your game are contributing the most. The “world systems” box has an LtF of 1.0, which means that every feature is linked to exactly one other feature. Compare that to the “player actions” column, which has an LtF of 3.0, which you can see by how many arrows are going in and out of those boxes.
Or let’s say you’re looking at your design and trying to figure out what to cut from your game. It’s late in development, it can’t all get done, and you want to get rid of the feature that affects the game’s design least (which isn’t always your top priority when cutting, but it is sometimes). Looking at the example Chen Diagram above, I’d suggest they cut the hub level and replace it with a menu screen. Other options might be to cut “Challenges” and “Medals/Charms” — since Charms mainly exist as rewards for Challenges, removing both of those would minimally affect the rest of the design.
Note: It isn’t really that useful to compare your Chen Diagram of a game to someone else’s Chen Diagram of the same game. There’s enough subjectivity in the process of creating these that no two people will do it alike (and that’s okay). The point with these isn’t to reduce a game to lines and boxes “correctly” — the point is to have a way to visualize your game and to understand the design cohesion repercussions of major decisions.
As always, these articles wouldn’t be possible without my supporters on Patreon: (http://www.patreon.com/mikedodgerstout):
Martin Ka’ai Cluney
Ryan Auld (Scruff)
Nils Ole Timm
Mad Jack McMad
Kim Acuff Pittman