Sponsored By

Matrix Design

An explanation of Matrix Design, a method to use the principal behind the Square-Cube Law to maximize the amount of design space opened up by marginal increases in functionality.

James Youngman, Blogger

August 14, 2019

6 Min Read

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!

Image shows a 3 by 3 grid of A.I. properties. Next to it is a 4 by 3 grid, created by adding on property to the previous grid.

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.

A 3 by 3 grid of attack properties. Next to it, a 3 by 3 by 3 matrix created by adding defense properties to the prior grid.

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!

Read more about:

Blogs
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like