*
The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.*

The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

There is an important mathematical principle known as the square–cube law. Quoting the Wikipedia article, “as a shape grows in size, its volume grows faster than its surface area.” This is because surface area grows to the second power, while volume grows to the third power. While this can cause headaches for those working with physical objects, for game designers, the relationship between functions of different powers can dramatically increase our efficiency.

At the highest level, the way to use power function relationships in game design is as follows. For a

given design problem, define multiple axes of differentiation. Design multiple usable solutions along

each axis, then arrange them in a matrix. Thus the name, **Matrix Design**. That matrix is a visual

representation of the available design space, and it has a square growth function, versus a linear growth function for single axis designs.

I'll give an example. Imagine a simple JRPG combat system. Two teams of multiple units engage in

turn based combat against one another until one team has eliminated all of the units on the other. To

make a single player experience, enemy units must have an AI driving their combat decisions. Sure,

you could just implement a single attack pattern that applies to all units, but that would get old real

quick. A palette of AIs is called for to make the game more interesting.

One way of doing this would be to simply create, in whole, every AI pattern that can be encountered

within the game. This scales poorly, by which I mean, linearly. Every AI function you implement

increases the amount of enemy behaviors by one. We can do better by utilizing matrix design. First, we break down the question of enemy AI: What are the decisions a JRPG enemy must make? They must determine which unit to target, and which ability to utilize. Each unit will be assigned one function for each of these purposes, whose combined use will determine the behavior of that enemy. If we implement three of each of these functions, that gives us nine AI patterns to use for the cost of

implementing six functions. And the more functions we add, the more patterns we gain with each

additional function!

*Figure 1: In matrix (a) six functions results in nine possible patterns. By adding a targeting function in*

matrix (b), three additional patterns arise.

Each cell in the matrix represents a unique behavior pattern. Assigning different units to different cells

will result in distinct experiences for the player. Note that there's no requirement to have an enemy in

each cell; it may not even be desirable. Some combinations may not be fun, or may break the game,

and thus should be excluded from the final work. There's also no need to distribute enemies evenly

throughout the matrix. Some patterns may be broadly applicable, and therefore utilized by many

enemies. Others may be useful only in extremely narrow cases, in which case they should be reserved for boss battles or other special encounters.

The same principal applies for building a broad design base for gameplay objects. Let's continue with

our JRPG. Units can be differentiated not just via their behaviors, but by their statistical properties as

well.

The first step here is to create stat clusters. This is particularly important in games where characters

have many different stats. The goal here is to create a few templates. For example, a “heavy” cluster

with high health and damage, but low speed and evasion. It's not important to work out the actual

numbers at this stage; t-shirt sizes are the level of precision called for. This gives us one axis of our

grid.

Next, factor out different combat properties. This is a place where a strongly defined elemental

alignment system can be valuable. What type of damage does the unit do? Of course, such a question is only relevant if there are multiple defense types as well. Those become another axis.

We now find ourselves we three axes for character differentiation. Is this a problem? No. While we can no longer represent the design space as a simple grid, the cube we've created expands faster than our prior grid did, since it's operating in additional dimension.

*Figure 2: Matrix (a) is a familiar design matrix, with stat cluster and attack type as the axes. In matrix*

(b) a third axis, defensive type, is added, creating a cube. The addition of three defensive properties

triples the amount of unique cells, from nine to twenty-seven.

Adding a dimension makes a matrix much more powerful, as it increments the exponent by which the

amount of unique cells grow with the addition of each function or property. While directly representing

higher numbers of dimensions visually isn't an option, what's important is creating a broad design

space, and knowing which parts of the design space are occupied and which are empty. This can be

document in the developer's preferred fashion.

Multiple matrices is a completely valid option. In our present example, one 2D and one 3D matrix can

represent the major enemy classes for our JRPG. Between the two we can create __468 mechanically__

unique enemies simply by assigning them the functions and properties we've defined! That's before

taking into account any special abilities or variation from the template stat clusters, let alone the visual, audio, and narrative properties that will further define and emphasize their personalities. If more variations are desired, adding onto our matrices will do the trick. Not only that, but each addition

increases the rate of growth for all other axes along all of the unit defining matrices!

By now, it should be clear how matrix design can help both to conceptualize design spaces, as well as rapidly expand them with minimal amounts of effort and implementation complexity. Break down

features into constituent sub-features, design multiple independent options for each sub-feature, and

then place these sets of sub-feature options into a matrix with each other to create a broad and rapidly expanding design space. Use these matrices to produce archetypes and easily produce a tremendous variety of content for use in your game!

*Have you tried matrix design or similar methodologies in your games? Leave a comment below to*

discuss your experiences!