"Tension, Equilibrium, and Structure: A process for identifying low-risk design opportunities"
The editors didn't think that was punchy enough (or it was too long) because when the article was published the title had become "Tension Maps." Well, here we are in January of 2011, and the article has been re-published on gamasutra.
I won't quibble over a bit of editorial title-changing, but somehow the overall point of the article seems to be missed by many people. I spend 60% of it giving a long-winded specific example of how to build a Tension Map, but it's not entirely clear what I mean for designers to DO with it. Tension Maps are not simply an exercise for breaking down a game into component systems for analysis - they are meant to be a risk-assessing feature for the purposes of production control and development.
What I mean and don't mean
The reason I started using Tension Maps in my own work was that I had too many feature discussions which ran like this:
Producer: "We're running short on time - we need to cut features. Anyone have any suggestions?"
Me: "I think we cut one of the playable characters. We haven't built the assets yet, and it will save us a bunch of time tweaking the main storyline to fit with her."
Producer: "Hmmm... but our publisher says that people really want to see that character in the game. Any other suggestions?"
Programmer: "Well, we could cut one of our 8 locations from the game. That would save us 12.5% of our location-building time."
Me: "But we've already built all our locations, and if we lose a location we'll have to re-write the story to adjust."
The problem with these meetings was that I didn't have an effective lexicon of terms to describe the criteria I wanted to apply to feature review meetings - a measure of how "central" a feature was, how many other systems it touched, and how different would the game be without it? That's exactly the situation which generated the idea for Tension Maps of systems, as an analog of the force diagrams we drew in Kinematics classes.
This is dramatically more useful for developers than just another exercise in systems-mapping (or mindmapping, if you're of that flavor) because a systems-map doesn't differentiate between an important system and an unimportant system.