At GDC I attended a brilliant lecture by Stone LeBrande, Creative Director of EA/Maxis, entitled One-Page Design Docs. You should really go read that post for the details, but in short his talk described a very visual approach to game design communication as a superior alternative to the text-heavy method of more traditional design documents.
I've since been experimenting with this sort of approach in my own work, and the results so far are promising. Naturally I can't show off what I've been doing at LightBox, but I can illustrate what I've been doing with my independent project, Cortex.
I released the first public playtest of Cortex last month and many of you provided awesome feedback via this blog and on Twitter. That version had some significant game design issues, and I was spinning my wheels trying (and failing) to resolve them within my self-imposed constraints of "simple and elegant".
Regarding the problems, Conor Reid noted:
It’s very easy to just Blitzkrieg your enemies by rapidly clicking their neuron and you send a huge barrage of charges which easily capture the neuron. I found that I was easily able to win on all difficulties, including 100%.
And @miningforfish suggested part of the underlying problem:
Even if you made it more ‘difficult’ to effective spam click, it still comes down to who has the most neurons wins... due to relative power levels and a lack of alternate strategies, hidden information, or randomness.
I spent some time envisioning the game's interaction matrix. Here's what you played last month:
It seems pretty clear that I took "simple and elegant" a bit too far. The simplicity of the diagram lays bare that there is no depth in this game. There are hardly any meaningful interactions, and each is singular and deterministic. The only choice I gave you was where to deploy: no what, no how, no why.
Here's my first pass at resolving the problem:
Most immediately apparent is the increased number of mechanics and, by extension, the increased complexity. Now you can choose what to deploy: there are now four charge types instead of just one, and the spread of their abilities necessitates a combined-arms approach.
There are a couple of problems with this iteration, though. Can you spot them?
This demonstrates an advantage of visual design: it's immediately obvious that for each target type (excepting friendly synapses), there is exactly one relevant choice. Would this have been obvious in a text-heavy document? I doubt it; or at the very least, it would've taken significantly more cognitive effort to identify the problem.
As you can see in the diagram, despite the added complexity I'm still not presenting you with truly meaningful choices. All I'm doing is requiring you to learn which charge matches which synapse/neuron state. If you deploy the right one, hooray; if not, then nothing happens. As soon as you've memorized this matrix -- which in active gameplay would take all of five minutes -- you've effectively mastered the game.
These interactions are still singular and deterministic. In visual terms, I need to get some more options into those columns!
I've added another mechanic here -- disabled neurons -- and shifted the roles of the four charges around a bit. Now each charge type has a few more options, but more importantly you can see that for several key interactions there are multiple relevant charges. Let's look at these in more detail.
The most common interaction you're going to do in Cortex is attack enemy synapses, so that interaction should definitely present an interesting choice. In both previous iterations the interaction was singular: capture the synapse. Now you can successfully attack with two different charges, each with a different bonus effect on top of the capture: do you want to attack and expand, or attack and fortify? You'll make this choice many times over the course of a single game.
Similarly, you can see an interesting combined-arms strategy emerge in the enemy neuron column: Attack charges can temporarily disable the neuron, but only Capture charges can actually capture it. This is a different kind of choice because it's much more situational than that for enemy synapses: one choice eases (but is not a prerequisite for) the other.
Of course, in both the most recent iterations you also have the choice to grow or reinforce friendly synapses (and in fact can do both, by deploying both types of charge), and if one of your neurons is disabled, both types can reactivate it as well. The latter case isn't particularly interesting, however, because the effect is the same regardless of which you choose. (I'm not entirely happy with the disabled neuron column at the moment, incidentally.)
You can derive even more information:
I don't know whether I'm going to use this "utility" metric at all, but it is an interesting piece of data. The number of contexts in which a charge type is useful might be an input to a deployment cost or a cooldown, or it might suggest the relative frequency with which you're likely to deploy each type. I might be able to use this kind of information to decide things like how each charge should look and act.
This really illustrates the power of visual design. How likely would you have been -- and how long might it have taken -- to identify these relationships from reading a text-heavy document that described all the charge behaviors in prose, but didn't explicitly call out the utility metric? This kind of stuff becomes intuitive and obvious when presented in a visual form.
Some things I should clarify...
First, Stone LeBrande's GDC talk wasn't really about flowcharts and diagrams. I created these diagrams with OpenOffice Draw, but most of his examples were done with Adobe Illustrator and their central elements were much more "arty": isometric map layouts, icons representative of in-game creatures and items, and in some cases even screenshots and mockups. What I've shown you here is just a very basic interpretation of the visual design approach, but (and this is important) it doesn't include anything extra just for the sake of looking pretty. The whole point of visual design is to communicate more ideas with less bloat, and more complex ideas with greater simplicity. It's critical not to get carried away with these things and start "arting them up".
Also: I've described a number of new mechanics for Cortex, but very little of this stuff is actually implemented right now. That means two things: you're going to have to wait a while longer to play it, and some (or even all) of these ideas could fail catastrophically in practice. Welcome to game design. ;)Posted In: