Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
December 11, 2019
arrowPress Releases







If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

Matrix Design

by James Youngman on 08/14/19 10:17:00 am

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!

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!


Related Jobs

Snowcastle Games
Snowcastle Games — OSLO, Norway
[12.10.19]

Gameplay Programmer
RMIT University
RMIT University — Melbourne, Victoria, Australia
[12.10.19]

Senior Lecturer, Games (RMIT Melbourne, Australia)
Insomniac Games
Insomniac Games — Burbank, California, United States
[12.09.19]

Lead Level Designer
Academy of Art University
Academy of Art University — San Francisco, California, United States
[12.09.19]

Game Development Instructors





Loading Comments

loader image