FACULTY OF INFORMATICS

Simulating Game Worlds Using

Cellular Automata

Master’s Thesis

TOMÁŠ PAGÁČ

Brno, Spring 2022

 FACULTY OF INFORMATICS

Simulating Game Worlds Using

Cellular Automata

Master’s Thesis

TOMÁŠ PAGÁČ

Advisor: doc. RNDr. Barbora Kozlíková, Ph.D.

Department of Visual Computing

Brno, Spring 2022

Declaration

Hereby I declare that this paper is my original authorial work, which

I have worked out on my own. All sources, references, and literature
used or excerpted during elaboration of this work are properly cited
and listed in complete reference to the due source.

Tomáš Pagáč

Advisor: doc. RNDr. Barbora Kozlíková, Ph.D.

iii
Acknowledgements

I would like to thank doc. RNDr. Barbora Kozlíková, Ph.D. and Mgr.
Jiří Chmelík, Ph.D. for their help with this thesis and for guiding me
through my studies. I am also grateful to my family for supporting
me both emotionally and financially all this time.

iv
Abstract

The thesis aims to study games featuring simulated worlds and ex-
plore the possibilities of simulating worlds using cellular automata.
Several games simulate liquids, gases, boolean logic, or electric cir-
cuitry on a grid. The thesis examines the functional requirements of
these simulations and the limitations of their techniques. Different
variants of cellular automata are explored for the suitability of simu-
lating similar behavior. Defining transition rules that lead to desirable
behavior is difficult. I implemented two variants of cellular automata
and created a visual editor to assist rule creation. The viability of the
visual editor is evaluated by potential users.

Keywords

Cellular automata, Game world simulation, Game development tool

v
Contents

Introduction 1

1 Theory 3
1.1 Cellular automaton . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Lattice . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Neighborhood . . . . . . . . . . . . . . . . . . . . 4
1.1.3 Cell states . . . . . . . . . . . . . . . . . . . . . . 4
1.1.4 Configuration . . . . . . . . . . . . . . . . . . . . 4
1.1.5 Transition rules . . . . . . . . . . . . . . . . . . . 4
1.1.6 Computation . . . . . . . . . . . . . . . . . . . . 5
1.2 Reversibility . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Four classes of cellular automaton rules . . . . . . . . . 6
1.4 Rule 110 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Game of Life . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Computation and visualization . . . . . . . . . . . . . . 7
1.7 Implementation in games . . . . . . . . . . . . . . . . . 8
1.8 Block cellular automaton . . . . . . . . . . . . . . . . . . 9
1.8.1 Billiard ball model cellular automaton . . . . . . 10
1.8.2 Advantages for games . . . . . . . . . . . . . . . 10
1.9 Lattice gas cellular automaton . . . . . . . . . . . . . . . 11
1.9.1 Visualization . . . . . . . . . . . . . . . . . . . . 12
1.9.2 Advantages for games . . . . . . . . . . . . . . . 12
1.10 The boundary condition . . . . . . . . . . . . . . . . . . 12
1.11 Overview and discussion . . . . . . . . . . . . . . . . . . 13
1.12 Further impact of cellular automata . . . . . . . . . . . . 14

2 Case study 15
2.1 Falling-sand games . . . . . . . . . . . . . . . . . . . . . 15
2.2 Noita . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Terraria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 Minecraft . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Implementation 21
3.1 Development setup . . . . . . . . . . . . . . . . . . . . . 21

vi
 3.2 Naive model . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 General model . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.1 Chunks . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.2 Layers . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.3 Computation . . . . . . . . . . . . . . . . . . . . 23
3.3.4 Visualization . . . . . . . . . . . . . . . . . . . . 24
3.3.5 Basic optimizations . . . . . . . . . . . . . . . . . 26
3.4 Block cellular Automaton . . . . . . . . . . . . . . . . . 27
3.5 Lattice gas cellular automaton . . . . . . . . . . . . . . . 28
3.6 Two-layer top-down experiment . . . . . . . . . . . . . . 30
3.6.1 Creating a top-down environment . . . . . . . . 30
3.6.2 Cellular automaton setup . . . . . . . . . . . . . 31
3.6.3 Transition rules . . . . . . . . . . . . . . . . . . . 31
3.6.4 Number representation issues . . . . . . . . . . . 33
3.6.5 Result . . . . . . . . . . . . . . . . . . . . . . . . 33
3.7 Simplifying transition rules . . . . . . . . . . . . . . . . 34
3.7.1 One algorithm for all materials . . . . . . . . . . 34
3.7.2 Chaining simple operations . . . . . . . . . . . . 35
3.7.3 Grouping materials . . . . . . . . . . . . . . . . . 35
3.8 Visual rule editor . . . . . . . . . . . . . . . . . . . . . . 37
3.8.1 User Interface Setup . . . . . . . . . . . . . . . . 37
3.8.2 Materials and groups . . . . . . . . . . . . . . . . 37
3.8.3 Rule editing . . . . . . . . . . . . . . . . . . . . . 38
3.8.4 Rule generation . . . . . . . . . . . . . . . . . . . 40
3.8.5 World editor . . . . . . . . . . . . . . . . . . . . . 41
3.8.6 Lattice gas cellular automaton editor . . . . . . . 43
3.9 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.9.1 Block cellular automaton editor . . . . . . . . . . 44
3.9.2 Lattice gas cellular automaton editor . . . . . . . 46

4 Discussion and future work 49

5 Conclusion 51

A An appendix 52

Bibliography 53

vii
List of Figures

1.1 Common CA lattices (from left): 1D, triangle, square,

hexagon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Neighborhoods (from left): elementary CA, von Neu-
mann, Moore, Moore without the center. . . . . . . . . . . 4
1.3 An example of elementary CA transition rules. The next
state of the central cell is defined for each neighborhood
configuration. . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Visualization of 1D (left) and 2D (right) CA computation.
Arrows indicate flow of time. . . . . . . . . . . . . . . . . . 8
1.5 Asymmetrical behavior in asynchronous execution. Blue
states move right, and green states move left. Because
of execution from left to right, blue states get executed
repeatedly, while green states leave space for other green
states to move into. . . . . . . . . . . . . . . . . . . . . . . 9
1.6 Using flags to limit movement in one step. . . . . . . . . . 9
1.7 Transition rule form and block shifting in Margolus neigh-
borhood. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.8 An example scenario where bugs are easily introduced in
standard CAs – water flowing down a hole. . . . . . . . . 11
1.9 Computation in a LGCA. Particles arrive in a cell, poten-
tially collide, and continue into the next cell. . . . . . . . . 12
2.1 Chunks are processed in stages to avoid race conditions.
Each processed chunk (beige color) can access half the
adjacent chunks (up to the dashed lines). . . . . . . . . . 16
3.1 The CA world organizes the chunks and directs the simu-
lation. The CA world handles access to the CA from the
outside. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 A chunk with multiple layers. How neighborhoods in-
clude these layers depends on the use case. . . . . . . . . 23
3.3 A large part of a chunk can be processed in parallel (blue
color). Areas reaching into other chunks need to be de-
signed carefully to avoid race conditions (red color). . . . 24
3.4 The process of displaying a CA with multiple layers on
the screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

viii
3.5 In-engine screenshots of the top-down CA (explained in
Section 3.6.1). There is a terrain layer with shadows and
semitransparent water visible. . . . . . . . . . . . . . . . . 25
3.6 Water flowing down the terrain. Active rectangles are
visualized in red color. . . . . . . . . . . . . . . . . . . . . 26
3.7 Neighborhoods in BCA computation. Orange-colored blocks
modify neighboring chunks. Red-colored blocks reach
outside the world boundary. . . . . . . . . . . . . . . . . . 27
3.8 Neighborhoods in LGCA computation. Orange-colored
cells modify neighboring chunks. Red-colored cells reach
outside the world boundary. . . . . . . . . . . . . . . . . . 29
3.9 A cube in isometric, cabinet, and top-down projection
(from left). . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.10 Height of each cell and its interpretation. (Implementa-
tion allows for more angles between the ones shown.) . . 31
3.11 Equalizing water level on a terrain. . . . . . . . . . . . . . 32
3.12 Top-down terrain painted using a square brush and a
smoothing brush. . . . . . . . . . . . . . . . . . . . . . . . 33
3.13 Defining rules using simple operations and groups (screen-
shot taken in Visual Studio Code). Simple operations are
assigned to group configurations in order of definition. . 35
3.14 Material editor user interface. . . . . . . . . . . . . . . . . 38
3.15 BCA rule editor user interface. . . . . . . . . . . . . . . . . 39
3.16 Two examples of equivalent rules that get normalized into
their leftmost form. . . . . . . . . . . . . . . . . . . . . . . 40
3.17 World editor and generator user interface. . . . . . . . . . 42
3.18 Naive and greedy collider (left), marching squares col-
lider (right). . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.19 LGCA rule editor user interface. . . . . . . . . . . . . . . . 44
3.20 A random scenario where water interacts with sand. The
sand sinks in the water. Simulation progresses from left
to right. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.21 A random scenario where water, oil, and two gases inter-
act. The oil floats on top of the water, and gases mix and
rise. Simulation progresses from left to right. . . . . . . . 45
3.22 A scenario where fire burns forests, burned forests turn
into dead land, and eventually regrow. Simulation pro-
gresses from left to right. . . . . . . . . . . . . . . . . . . . 46

ix
3.23 A random scenario where water flows down. In areas with
too many water particles, the particles can move through
the stone. Simulation progresses from left to right. . . . . 47
3.24 A random scenario where dark and light particles interact.
When they collide, the dark particle goes down, and the
light particle goes up. Simulation progresses from left to
right. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.25 A random scenario with a green material drawn over. The
particles rotate and reflect in different ways. The green
particles replicate in some situations. . . . . . . . . . . . . 48

x
Introduction

A cellular automaton (CA; plural cellular automata, CAs) is a model

of computation initially proposed by John von Neumann [1]. CA
consists of a lattice of cells that can be in a finite number of states.
Each cell changes state in a computation step depending on its local
neighborhood. CAs are naturally parallel and are unique in that the
computation can be easily visualized. It was found that simple rules
operating in a local neighborhood can lead to complex behavior at the
global level. With the right rules, the behavior of real phenomena can
be approximated. Thanks to this, CAs have been successfully used
for modeling phenomena in physics, chemistry, or biology; examples
include fluids, magnetism, cell division, or road traffic [2]. With pow-
erful hardware becoming widespread, it is possible to perform these
simulations for entertainment in real-time.
Several games use models similar to cellular automata to make
their worlds dynamic, interactive, and unpredictable. Their worlds
often consist of many materials (or elements) with different properties
that all interact together, unlike scientific models that mostly focus on
one phenomenon. They frequently include simplified fluid physics,
electric circuitry, or logic gates. They give players agency and space for
creative gameplay outside the bounds of the intended design. At the
same time, this severely complicates the designing and development
of a game. By making the behavior of the world complex, it becomes
difficult to predict and test all situations that could arise. Therefore, it
is not surprising that games with dynamically simulated worlds often
use simulation as their main feature. The advantages are uncertain
for games with a different focus, while the increased development
complexity is real.
The goal of this thesis is to make creating simulated worlds more
approachable. In the first part, I explore formal cellular automata.
I look at research into a simulation of different phenomena and at
variants of cellular automata that use different neighborhoods and
transition rules. These variants could be better suited for creating logic
found in games. In the second part, I study games that use similar
models and note the advantages and limitations of their approach. In
the third part, I implement two cellular automata variants and create

1
 Introduction

a visual interface for defining cell states and transition rules. This
interface should allow for creating behaviors more intuitively, making
the development of custom simulations easier and less error-prone.
Lastly, I get feedback on the implementation from professionals in the
industry.

2
1 Theory

This chapter defines CAs, their properties, and how they can be mod-
ified. We look into past research and how it can be used in game
development.

1.1 Cellular automaton

For this thesis, a simple definition of a CA is sufficient. This CA will be

referred to as the standard CA. There are many possible modifications
to this definition, and only relevant ones will be mentioned. An in-
depth definition and study of CAs with a focus on compressible fluid
dynamics can be found in Agrawal [3].
Standard CA consists of:
• A lattice of cells.
• A cell neighborhood.
• A set of states.
• A set of transition rules.

1.1.1 Lattice

CA operates in a regular n-dimensional lattice. It usually consists of

triangles, squares, or hexagons (Figure 1.1). The lattice can be infinite
or bounded. CAs have been explored mainly in 1D and 2D space.
One of the strong points of CA is its simplicity of representation in
a computer. Visualizing a square lattice is similarly straightforward –
we can display cell states as colored pixels.

Figure 1.1: Common CA lattices (from left): 1D, triangle, square,

hexagon.

3
 1. Theory

1.1.2 Neighborhood

The neighborhood usually consists of cells adjacent to the central cell.

The central cell is often included but does not have to be. In 1D, a
common neighborhood used by the elementary CA consists of the
central cell and two adjacent cells. The standard neighborhoods in a
2D lattice of squares are the von Neumann and Moore neighborhoods
(Figure 1.2). The neighborhood can have any finite shape, but simple
and small neighborhoods are easier to reason about.

Figure 1.2: Neighborhoods (from left): elementary CA, von Neumann,

Moore, Moore without the center.

1.1.3 Cell states

Each cell in a CA has one of finitely many states. Binary states are often
used to symbolize empty and filled, or dead and living cells. Sometimes
continuous states or states consisting of multiple values are used.
When discussing models with many states, namely those mimicking
particle interactions, these states will be referred to as materials.

1.1.4 Configuration

A configuration is the state of all CA cells at one point in time. When

talking about a concrete neighborhood, a configuration refers to the
state of cells in the neighborhood. An initial configuration is a con-
figuration before computation starts; usually, all cells begin with the
same state, except finitely many cells with different states.

1.1.5 Transition rules

Transition rules provide a new state for each configuration of neigh-

boring states (example in Figure 1.3). The same set of transition rules

4
 1. Theory

is used for all cells. All transition rules can be listed because both
cell states and the neighborhood are finite. Therefore, a new cell state
for each neighborhood can simply be selected from a table. An in-
teresting modification is to select from multiple possible new states
based on probability; this CA is called a probabilistic or stochastic CA
[4]. Defining transition rules to achieve desired behavior is not trivial
because the system’s behavior cannot be easily predicted. Usually,
rules are defined by hand, but there have been attempts to create them
programmatically by using evolutionary algorithms [5].

Figure 1.3: An example of elementary CA transition rules. The next

state of the central cell is defined for each neighborhood configuration.

1.1.6 Computation

Synchronous CAs advance by applying the transition rules to all cells

simultaneously. Asynchronous CAs are being researched too, and
they are closer to the models used in games, described in the Chapter
Case study. However, the computation in synchronous CAs is easier
to comprehend because each new configuration depends solely on the
previous one.

1.2 Reversibility

Reversibility (or invertibility) is an important property that a CA can

have. CA is reversible if, for each configuration, there exists a single
previous configuration (the transition rule is injective). Formal proofs
can be found in a study by Kari [6]. Reversibility is of interest because
many physical models are reversible. Additionally, it is theorized that
computation performed using reversible models could consume less
energy than is possible with irreversible models [7]. It is hard to deter-
mine whether a standard CA is reversible. However, there is a variation
where it is simple – the block cellular automaton (Section 1.8.1).

5
 1. Theory

Reversibility has a strange consequence: a reversible CA cannot

repeat any configuration it has gone through until it repeats the initial
configuration. Conversely, a non-reversible CA could enter its past
configuration at any point. A reversible CA would typically run much
longer before repeating [8, sec. 1.4]. There are two obvious conse-
quences for games:
• Reversible CAs can create more unexpected behavior, which can
be good or bad.
• Reversible CAs are less likely to create stationary or repeating
configurations, making it harder to increase performance by
only processing active parts of the CA.

1.3 Four classes of cellular automaton rules

Wolfram [9] separated CA transition rules into four classes. The classes
depend on the apparent structure of configurations arising in longer
computations from most initial configurations. Rules in these classes
lead roughly to:
1. Homogeneous state.
2. Simple or periodic structures.
3. Chaotic patterns.
4. Complex structures.
The classification is not exact, but it serves as a basis for possible
behaviors. In games with many states serving as materials, the CA
would likely fall into the 4. class, where most of or all CAs are capable
of universal computation. In isolation, different materials would fit
into different classes, for example:
1. Stationary materials.
2. Piling materials and simple fluids.
3. Gases.
4. Logic circuits.
Games not only need to program behavior for each of the materials
but also interactions between the different materials.

6
 1. Theory

1.4 Rule 110

Even rudimentary CA models are capable of creating interesting pat-

terns. The so-called elementary CA uses one of the simplest setups; it
has a one-dimensional lattice, two states, and a neighborhood of the
central and two adjacent cells. Elementary CA has been thoroughly
studied. It only has 256 possible rule sets. In particular, rule 110 is
Turing complete [10, chap. 3][11]. It is one of the simplest computa-
tionally universal models – creating interesting behavior, even with a
small neighborhood and few states, is easily possible.

1.5 Game of Life

Game of Life is a CA experiment by John Conway. It uses a two-

dimensional square lattice with two states and a Moore neighborhood.
The experiment’s goal was to make a CA with unpredictable behavior
and self-reproducing structures. Game of Life had a significant impact
on the popularization of CAs and related concepts. Conway said it
had taken eighteen months of coffee times to arrive at the current rules
for Game of Life [12]. His story shows how hard it is to design rules
with desirable properties. It is partly because predicting the behavior
of computationally universal models is impossible, and these models
are the most interesting ones.

1.6 Computation and visualization

Computation in CAs lends itself well to visual representation. The

usual way of visualizing square lattice CAs is using raster images – a
row of pixels for each computational step in 1D or the whole image
animated in time in 2D (Figure 1.4). The color of one pixel represents
the state of one cell. This way, we can easily see structures and behav-
iors in the CA. It may seem as if each cell represents some singular
entity. However, not all CAs model systems where this intuition makes
sense. For example, in the dual encoding in the billiard ball model,
two ’balls’ together compose one ’signal’ [13]. This section merely
serves to remind us that the visible structures may have a different
meaning than we expect.

7
 1. Theory

Figure 1.4: Visualization of 1D (left) and 2D (right) CA computation.

Arrows indicate flow of time.

In my implementation, I consider each cell as containing a material

particle, so there should be no confusion about what is being displayed.
In a game, it is essential that the visual representation clearly commu-
nicates the state of the world. In other use cases, the computational
ability may be more important than visualization.

1.7 Implementation in games

The most common game implementation using CAs mechanisms that

can be found on the internet works as follows. There is a square lattice
of cells with states, the same as in formal CA. The difference is that
computation is asynchronous (cells are iterated in order), and the
transition rules can be arbitrarily complex. Each state uses a separate
logic for its computation, and it can read or change any other cell.
Cell neighborhood is restricted only by technical considerations. This
approach is easy to implement and can work well, but it has at least
these two shortcomings:
Mental complexity of transition rules
There are no limitations to which cells influence the state transition
in this model and no limitations to which cell states the transition can
change. The basic way of defining rules is to have a separate routine for
each state and use a series of if statements to inspect a neighborhood of
interest. If we interpret states as particles, they can move by removing
their state from their current cell and setting it in a different cell. For
example, a ’water’ state could check if a bottom adjacent cell has the
’empty’ state and if that is the case, set the current cell to ’empty’ state
and the bottom adjacent cell to the ’water’ state.

8
 1. Theory

Defining rules this way gets cumbersome with more states and
rules. Finding the code responsible for a bug can be challenging be-
cause the rules can change cells other than the cell they operate on.
Asymmetry in asynchronous execution
To advance the model, we iterate over the lattice. The order in which
the cells are processed matters. Because states can move between cells,
one state will be considered multiple times if it moves ahead of the
iterated cells. One state can move all the way to the boundary in one
computational step. If the rules are symmetrical along an axis, the
iteration order will make the outcome asymmetrical. An example of
this is shown in Figure 1.5. A flag could be added to each state to
ensure the state is only considered once, but it does not solve the
asymmetry, as shown in Figure 1.6.

Figure 1.5: Asymmetrical behavior in asynchronous execution. Blue

states move right, and green states move left. Because of execution
from left to right, blue states get executed repeatedly, while green
states leave space for other green states to move into.

Figure 1.6: Using flags to limit movement in one step.

1.8 Block cellular automaton

Block CA (BCA, plural BCAs) is a CA variant that computes the next

state for whole blocks of cells instead of individual cells. For cells in
different blocks to interact, the partitioning of the lattice into blocks
changes between steps. This thesis will be focusing on a case with a
square lattice and blocks of 2x2 cells called Margolus neighborhood

9
 1. Theory

Figure 1.7: Transition rule form and block shifting in Margolus neigh-
borhood.

[14] (Figure 1.7). It was first proposed in a study of reversible CAs.

Unlike in standard CAs, in BCAs, it is easy to test for reversibility and
conservation of mass. A BCA is reversible iff each rule is reversible.
Similarly, considering mass as the number of cells with a particular
state, BCA preserves mass iff each rule preserves mass [13].

1.8.1 Billiard ball model cellular automaton

The billiard ball model in a BCA (BBMCA) and the BCA itself were first
introduced by Margolus [14]. The billiard ball model was originally
a continuous model. Margolus had shown that it could be adapted
for discrete space and time, given some restrictions. It is a model of
hard-sphere movement and collision. In the BBMCA, the spheres can
carry signals and perform boolean operations. A computer can be
built using moving spheres and stationary states acting as mirrors.
The BBMCA is reversible.

1.8.2 Advantages for games

The BCA has certain advantages over the standard CA. Conservation of
mass is vital – matter should not spontaneously multiply or disappear,
which is harder to ensure in a standard CA.
In a BCA with Margolus neighborhood, designing rules is compar-
atively simple. We only need to handle the interaction of four states,
and all others are ignored. We change all four cells together, and there
is no other rule impacting these cells. As a disadvantage, we cannot
see all adjacent cells for any cell in one step. Conversely, in a standard
CA (for example, with Moore neighborhood), each cell gets informed
by adjacent cells but can only change itself.

10
 1. Theory

Figure 1.8: An example scenario where bugs are easily introduced in

standard CAs – water flowing down a hole.

In a standard CA, all cells are evaluated at once, but they can only
decide their own state. For example, imagine a situation where water is
pouring down a hole. The empty cell knows it will be filled with water,
but the cells above do not know which of them should be emptied
(Figure 1.8). Suitable rules could be designed, but it would be very
easy to make a mistake and break the conservation of mass. The rules
would have to prioritize movement between some cells, while in BCAs,
this prioritization is handled by block partitioning.
On the other hand, when using the Margolus neighborhood, the
change in cell state depends on the currently used partitioning, which
could also lead to confusion.

1.9 Lattice gas cellular automaton

Lattice gas CA (LGCA, plural LGCAs) was introduced by Hardy;

Pazzis; Pomeau [15] for gas modeling. The gas model is called HPP
after the authors’ names. It uses a square lattice with two states and
simple collision rules. To reduce its shortcomings, FHP [16] model,
which uses a hexagonal lattice, was introduced. These models behave
according to the Navier-Stokes equation at large scales. They preserve
mass and momentum.
In an LGCA, each cell contains particles moving from neighboring
cells. There can only be one particle moving from each neighbor. The
computation is split into two steps: first, particles collide and change
directions in each cell, then the particles are moved in a new direction
(Figure 1.9). The cell state in an LGCA consists of all particles entering
it – one for each cell in the neighborhood. Particles constantly move
between cells; there is no ’stable’ state, making it easy to preserve

11
 1. Theory

Figure 1.9: Computation in a LGCA. Particles arrive in a cell, potentially

collide, and continue into the next cell.

momentum. An LGCA preserves mass iff the transition rule does not
change the number of non-empty particles.

1.9.1 Visualization

Because the cell state in an LGCA is made up of multiple particles,

visualization is not as straightforward as in a CA or a BCA. In a two-
state LGCA like HPP, shades of gray can signify the number of non-
empty particles in a cell (density).

1.9.2 Advantages for games

LGCA seems like a viable approach because of its focus on particle

interactions. The mental model stays simple by having the transition
rule act inside a cell. Like in BCA, this kind of transition logic makes
it easy to conserve mass and momentum.
Aside from visualizing LGCA, there is another issue. Everything
in LGCA is inherently moving. In the original definition, there is no
way to have stationary obstacles. It is possible to add an additional
stationary particle into the cell state. This enlarges the rule space but
solves the problem.

1.10 The boundary condition

Computers have finite memory, so we cannot use an infinite lattice

in practice. Computation at the edge of the available lattice has to be
handled somehow. The boundary conditions usually used [17, chap.
2.4] are:

12
 1. Theory

• Constant boundary (usually empty state)

• Periodic boundary (the lattice wraps around)
• Adiabatic boundary (edge cell is duplicated)
• Reflexive boundary (use edge cell neighbors)
• Intermediate boundary (use edge cell neighbors’ neighbors)
In games, the worlds can be very large or progressively generated
without end. These worlds cannot be loaded all at once for memory
and performance reasons. It is common to simulate a subsection of
the world around the camera and load or generate the world further
when the camera gets close to the boundary. Computing only parts
of the world breaks the determinism of the CA. For example, falling
water would form a clump at the boundary, and the clump would fall
at once when the boundary is removed. Without access beyond the
boundary, there is no way to fix it.
A lower level of detail computation beyond the original boundary
could be used to reduce the issue, but that could lead to unintuitive
’glitches’ where behavior impossible in the full detail computation
could occur. Loss of information is also a possibility. In BCAs, we can
skip steps that are partly beyond the boundary, removing the need for
a boundary condition. Skipping the steps still changes the behavior
near boundaries, however.
If the world is not infinite, a possible workaround for better per-
formance is to only progress the CA in areas where changes occur
(assuming these areas can be determined). I explain one approach in
Section 3.3.5.

1.11 Overview and discussion

We looked at different variants of CAs. In the standard CA, a cell has

information about its neighborhood but can only modify itself. The
whole block can be modified in the BCA, but we have no information
from outside the block. In the LGCA, particle interactions can be easily
defined, but there is no way to position and stabilize the particles. A
more in-depth look into CA modifications can be found in a study by
Bhattacharjee; Naskar; Roy; Das [17].

13
 1. Theory

1.12 Further impact of cellular automata

The usefulness of CAs is apparent from their use in scientific modeling.

Wolfram [10] argues that CAs are further reaching, bringing ’a new
kind of science’ that could revolutionize many branches of science.
Although interesting, these claims are widely controversial [18]. In
the end, it can only be said that CAs are a useful modeling tool with
some beneficial qualities like exactness of computation or inherent
parallelism.

14
2 Case study

This chapter studies world systems of specific games and how they
could be implemented using CAs. The selected games are well known
for their dynamic and highly interactive worlds. Except for the falling-
sand games, all games listed use procedurally generated worlds that
are destructible by the player.

2.1 Falling-sand games

Falling-sand games are 2D sandbox games in which the player exper-

iments with interactions of elements. They simulate the movement
and interaction of particles in a fixed 2D grid. The particles interact
when they touch, and there is a finite number of materials – the basic
principles are that of CAs. Some falling-sand games give particles
properties like velocity or pressure; some even use additional wind or
fluid simulations. The behavior of the particles can be quite complex.
For example, these are some of the rules used in one of the oldest titles
[19]:
• Moving particles fall due to gravity
• Wall does not move
• Water pools, sinks in oil, extinguishes fire, and dissolves salt
• Plant grows when touching water, can be destroyed by fire
• Sand piles, sinks in water
• Wax burns and leaves a byproduct that can be burned again
• Oil pools and can burn through walls when set on fire
Creative transition rules make these games interesting. The addi-
tional particle properties, fluid simulations, or randomness in tran-
sition rules make the particle movement feel natural. Because the
interactions are local, they easily translate into CAs. Using a stricter
structure akin to a CA would make designing and debugging the tran-
sition rules easier but could make it harder to combine with non-CA
elements.
Although falling-sand games are a niche genre, there are many
modern takes on the idea, as the possibilities are endless while the
implementation is relatively simple. A modern example is Sandspiel
[20].

15
 2. Case study

2.2 Noita

Noita is a successor to falling-sand games and uses the same principles

for world simulation. Unlike the original falling-sand games, Noita
focuses on action and exploration in a procedurally generated envi-
ronment. Interactions of different elements are still an instrumental
part of gameplay in the form of interactive environmental hazards.
Noita is one of the inspirations for this thesis.

Figure 2.1: Chunks are processed in stages to avoid race conditions.

Each processed chunk (beige color) can access half the adjacent chunks
(up to the dashed lines).

The world in Noita does not have static boundaries. Instead, it is

split into chunks (or tiles) that are loaded and simulated when close
to the camera. The chunks are processed in parallel in a ’checkerboard’
pattern (Figure 2.1), giving each cell access to the current and a half of
each adjacent chunk without race conditions [21, minute 11]. Inside a
chunk, the cells are processed from the bottom row upwards – this
is important for falling fluids – each fluid particle moves down and
leaves an empty space for the particle above to move into [22]. It
obviously only works in one direction.
The transition rules use randomness and a larger neighborhood
to make the particle movement look natural. Noita also combines
cellular simulation with standard rigid-body physics. Collision shapes
are generated for the world, and when a ’piece of scenery’ is separated
from the rest, it is moved from cellular to rigid-body simulation, falls
due to gravity, and collides with the rest of the world [21, minute
5]. In each frame, the pieces are moved between cellular and rigid-
body simulation. If the rigid-body simulation overlaps non-empty
cells, their contents are moved into a simple particle system until they

16
 2. Case study

collide with the world again; this creates ’splashes’ of particles on

collision.
Altogether the world of Noita is beautiful and dynamic. Never-
theless, there is a reason Noita became the kind of game it is: the
simulation creates so much emergent behavior that it is hard to de-
sign a game around it. The transition rules have few restrictions, and
when pieces of the world can be separated into rigid-bodies, the world
can quickly fall apart [21, minute 15]. There are many more ’random’
configurations the world can evolve into than there are interesting
configurations (akin to entropy). For this reason, Noita is designed to
be fast-paced, the environments are temporary, and the whole world
resets after the character dies.
Noita shows that highly dynamic worlds can be entertaining but
add much complexity and uncertainty into the development.

2.3 Terraria

The cellular world of Terraria is similar to Noita, but the interactions

are much simpler, and the world is more stable. Most materials are
either stationary or liquid. Liquids have levels of ’fullness’; on flat
ground, they can spread, creating a flat surface of partly-filled cells.
If a liquid spreads too thinly, it disappears. Worlds in Terraria are
bounded and generated once. An interesting mechanism is that when a
world is loaded, all liquids are ’settled’ into their eventual destinations,
increasing in-game performance [23]. There are some other rules: sand
falls down, lava and water touching creates obsidian, plants grow in
the sun.
Terraria uses rigid-body physics, but pieces of the world cannot dis-
connect from the cellular world and become rigid-bodies. Interactions
between cells and rigid-bodies come from collisions. Materials have
different effects; for example, touching lava hurts the player’s character.
The player can also manipulate the cellular world using different tools.
All these interactions occur outside the cellular simulation.
Terraria has one more interesting feature: use of multiple cellular
layers. So far, only the main layer was mentioned. There is also a
background layer, where background walls are placed. They have
no CA-like rules and do not have colliders, but they are visible and

17
 2. Case study

influence some gameplay mechanics. Then there is a layer for furniture

similar to the background layer. There is also a layer dedicated to
wires – they can be used to activate interactive objects and perform
logic operations. The signal in the wire propagates instantaneously
into arbitrary distance, so it cannot be replicated exactly using CAs.
Terraria is a good example of a game that uses a CA-like world with
fairly restricted transition rules. There is less potential for emergent
behavior, but the world is still highly interactive.

2.4 Minecraft

Minecraft is a 3D sandbox game. It uses rules similar to Terraria but in

a 3D lattice. It has many materials that could use simple CA transition
rules. Some examples include:
• Liquids flow in order of preference: down, diagonally down, to
the sides
• Water flowing into lava creates obsidian
• Lava flowing into water creates stone
• Fire spreads to flammable materials
However, Minecraft also has many materials with complex behav-
ior. Some materials have transitions depending on some distant or
global state, and materials that have an internal state. A well-known
example is redstone, a material for creating circuits. It is simple at
first glance – A powered redstone powers all neighboring redstone
and loses power. But looking more closely, it has many intricacies.
There are levels of power and different kinds of ’being powered.’ Some
materials can be activated, powered, or both. Several materials add
functionality to redstone.
To make matters worse, Minecraft uses multiple tick rates to up-
date different parts of the game, and the tick rates also interact with
redstone [24]. It would be hard to transform all this complexity into
simple transition rules without altering the behavior. On the other
hand, even with all its confusing complexity, redstone is popular in the
Minecraft community; players use it to build structures ranging from
sliding doors to computers – even a Game of Life implementation in
redstone exists [25].

18
 2. Case study

There are also many interactions between the cellular world and en-
tities such as player or non-player characters. Mechanisms like buttons
or redstone repeaters can be controlled by player action, non-player
characters can modify materials, and some materials work with global
state or distance to the player character.
All in all, Minecraft combines simple and complex behaviors and
has many interactions between the cellular world and entities outside
of it. Due to this, there are many edge cases and quirks in Minecraft.
However, it has not made the game any less popular. On the contrary,
it may have made the world seem more natural than simple CA rules
would be able to.

2.5 Discussion

In this chapter, a few successful games with CA-like worlds were

mentioned, and the capabilities of their worlds were discussed. They
have benefits such as:
• The world is suitable for procedural generation – it is a question
of setting states in an interesting way. There is no possibility of
generating invalid geometry and similar issues.
• The world is dynamic. It is possible to make the world interest-
ing outside of explicitly designed scenarios. There is space for
emergent behavior.
• The world is interactive. Even without interesting transition
rules, there are gameplay possibilities in how the world can be
manipulated from outside the CA.
Of course, there are drawbacks as well:
1) The inherent complexity of the transition rules and the fact that
the world is dynamic both make the development and testing harder.
2) The frequently used implementation (Theory Section 1.7) with
asynchronous computation, no bounds on rule complexity, and possi-
bly dynamic chunk loading make it hard to reason about and debug.
3) Interaction between the cellular world and the rest of the game
cannot be avoided. From the CA side, this interaction is an unpre-
dictable variable.
In the next chapter, I explore ways to reduce these drawbacks by
implementing a BCA (block CA) and an LGCA (lattice gas CA). I will

19
 2. Case study

focus on points 1) and 2), particularly on predictability and ease of

understanding of transition rules. I create a visual editor that simplifies
defining transition rules and helps with finding mistakes in the rules.

20
3 Implementation

This chapter describes my attempts at making CA more convenient

to work with while creating games. First, I implement a general 2D
CA. I experiment with layers and states consisting of multiple values.
Then I try different ways of defining CA rules. Lastly, I create a visual
editor for defining and testing transition rules. The editor works with
either BCA or LGCA. The suitability and ease of use of these CA is
examined.

3.1 Development setup

I chose Godot Engine as a base for the implementation. It is a free, open-

source game engine with an active community. It has less advanced
features than the mainstream engines, which can be an advantage –
it has a simple interface and small installation size. The most needed
functionality is 2D rendering and user interface creation. The code is
written in C# because it offers a good trade-off between convenience
and performance and is supported in Godot.

3.2 Naive model

In the beginning, I wanted to experiment with falling-sand simulation

as the concept is quite simple and powerful. The ’ingredients’ needed
are:
• A set of states – an enumeration
• A square lattice – a 2D array of states
• Transition rules – a switch statement with custom logic for each
state
We can simply iterate over the array of states and apply the tran-
sition rules on each state to complete one step of the computation.
The resulting simulation is not quite a CA, and its shortcomings are
described in Section 1.7. Seeing these issues, I started looking for alter-
natives and found BCA and LGCA.

21
 3. Implementation

3.3 General model

I decided to make the implementation more general to allow for ex-

perimentation with CA types and ways to implement rules. The main
goals were to enable:
• Easy modification to neighborhood and rule logic.
• Use of layers.
• Dynamic world size.

3.3.1 Chunks

The world can be divided into chunks (tiles) to allow keeping only
a part of the world in the memory. Issues with this are described in
Theory Section 1.10. Despite the issues, it is unusual to ’waste’ memory
and computational power on parts of the world that are out of view.

Figure 3.1: The CA world organizes the chunks and directs the simula-
tion. The CA world handles access to the CA from the outside.

In my implementation, the world is a grid of square chunks. Chunks

contain individual cells in an array. Loaded chunks are kept in a
hashmap, and each chunk has a reference to its neighbors (Figure 3.1).
When accessing a cell from outside the CA, we must transform the
target position from world space to the coordinates of a chunk in the
hashmap and the local coordinates of the target cell inside the chunk.
When computing the CA, chunks access their neighbors directly.

22
 3. Implementation

Chunk size (number of cells per side) has a large impact on perfor-
mance. Several contributing factors are processor cache size, number
of processor cores, chunk loading/generating speed, or camera move-
ment. Experimenting with chunk size is recommended every time a
game significantly changes.

3.3.2 Layers

Figure 3.2: A chunk with multiple layers. How neighborhoods include

these layers depends on the use case.

In a CA, multiple layers can be used to compute different things. In

Terraria, layers have different interactions with characters and allow
multiple structures to cross in the same 2D space. We can also use an
additional layer for light propagation. Initially, I wanted to experiment
with interactions of terrain, surface objects and atmosphere, for which
layers would be convenient.
In the implementation, chunks have an array of layers. Of course,
the space of transition rules changes if we include different layers’
cells in the neighborhood (Figure 3.2). The rules are different from a
3D CA, where the rules would apply uniformly to cells in all layers.
It is possible to order the layers somehow and have the neighboring
layers interact or have the rules use specific combinations of layers.
The rules can get quickly complicated; thus, I only use one layer for
simplicity in the final implementation. Still, using layers is worthy of
consideration, especially if they have little interaction, making them
similar to individual CAs.

3.3.3 Computation

To progress one step in the computation, we iterate over all chunks

and apply a transition rule to each cell in the chunk. In asynchronous

23
 3. Implementation

CA, the order of the chunks matters. When implementing chunks,

I already switched from the naive model (Section 3.2) to a BCA, so
there were no issues with the order of execution. How transition rules
are applied depends on the specific CA variant and how layers are
incorporated into the rules.

Figure 3.3: A large part of a chunk can be processed in parallel (blue

color). Areas reaching into other chunks need to be designed carefully
to avoid race conditions (red color).

As the number of loaded chunks gets larger, there is a need for

parallel processing. It would be hard to implement correctly for asyn-
chronous models because the transition rules need to be applied in
order. For regular CAs, BCAs, or LGCAs, it is simpler. Each cell transi-
tion only depends on the previous states in the neighborhood. Each
new cell state could be computed independently when using a mas-
sively parallel processor such as a GPU. Because my implementation
runs on the CPU, this is impractical. Instead, I keep the iteration over a
single chunk and process the chunks in parallel using C# async tasks
(Figure 3.3). With this scheme, smaller chunks are processed more in
parallel, but their data is more fragmented in memory. Properties of
the CPU (cache size, number of cores) make choosing the degree of
parallelism a balancing act.

3.3.4 Visualization

The goal is to show cells as pixels on the screen. Mapping cells to pixels
is straightforward in a square lattice CA. In the implementation, each

24
 3. Implementation

Figure 3.4: The process of displaying a CA with multiple layers on the

screen.

chunk is mirrored by a display chunk. The display chunk has the same
number of layers as the CA chunk, but each layer is a texture instead
of an array of cells. The textures are then rendered with the top layer
in front. After each computation step, the textures are updated and
uploaded to the GPU. The textures are updated in parallel similarly to
the CA chunks, and here no synchronization is needed because each
chunk has its own texture and does not access other chunks.
The user defines the mapping from material to color in the texture.
A simple mapping is defining a color for each material by hand, which
I do in the visual rule editor (Section 3.8). For a setup with multiple
layers, I write an index of the material into one channel of the color
(the texture must support integral values or floating-point values with
unlimited range). In an experiment with material properties, I also
write them into available color channels.

Figure 3.5: In-engine screenshots of the top-down CA (explained in Sec-

tion 3.6.1). There is a terrain layer with shadows and semitransparent
water visible.

Some visual effects need access to neighboring pixels, which are

not present at chunk borders. To enable these effects, I first render

25
 3. Implementation

each layer of all on-screen chunks to a render texture, and then I

combine the layers’ render textures in a shader (Figure 3.4). It may be
an unnecessarily complicated process, but it allows for much freedom.
For example, in an experiment with two layers and height property
– terrain with height and water with depth – I was able to draw the
water over the terrain with color and transparency depending on
water depth, calculate both water and terrain (pseudo) normals from
neighboring heights and use them for lighting, and also draw sun
shadows by marching over the terrain and water while checking sun
direction against the height (Figure 3.5).
Note that it is possible to store the CA lattice directly in a texture. I
chose to use a texture only to display the CA because textures are less
convenient and performant from the CPU side than arrays (at least
in Godot). Textures are often stored in a compressed form and can
automatically generate mipmaps when modified, so they must be set
up carefully.

3.3.5 Basic optimizations

Figure 3.6: Water flowing down the terrain. Active rectangles are visu-
alized in red color.

Some basic optimizations are needed to make larger worlds run at

interactive framerates. I implemented an optimization used in Noita
[21]. Each chunk keeps a rectangle (axis-aligned bounding box) of
active cells (Figure 3.6). Only cells in the active rectangle are processed,
and in each step, the rectangle is recalculated using only the cells
whose materials changed. An important point to note is that a change

26
 3. Implementation

in one cell influences the transition of each cell it is in the neighborhood

of. Therefore, the rectangle has to encompass such cells too. Of course,
this applies over chunk boundaries too.
This simple optimization has great performance benefits because
empty and stationary materials can be ignored, and moving materials
often conserve their area (mass). Chunks with empty active rectangles
can be skipped entirely, potentially simplifying the scheduling of par-
allel tasks. Chunk size impacts the performance gain – smaller chunks
can keep active rectangles better localized on the activity (simply
because each chunk only has one active rectangle).
This approach works thanks to the deterministic nature of transi-
tion rules; if a transition results in the same material, it always will.
This breaks in CA variants such as the probabilistic CA because tran-
sition results can differ even with the same initial conditions.

3.4 Block cellular Automaton

Figure 3.7: Neighborhoods in BCA computation. Orange-colored

blocks modify neighboring chunks. Red-colored blocks reach outside
the world boundary.

Implementing a variant of CAs comes down to specifying how

transition rules are applied. For BCAs I used Margolus neighborhood
– blocks of 2x2 cells shifted diagonally every alternate step.
The function implementing transition rules operates on four mate-
rials if the CA has one layer. With more layers, it depends on the use

27
 3. Implementation

case; the easy solution is to pass all layers to the function and let it
decide on which layers can interact and how.
While computing a BCA step, whole blocks are iterated instead
of cells. We need to know if the current step is odd or even to decide
whether to use shifted blocks (Figure 3.7). The step count is an addi-
tional state that regular CAs do not need. If, for some reason, the BCA
took two steps with shifted (resp. non-shifted) blocks in a row, the
results would differ from computation with alternating steps. Saving
the configuration (world state) without this information could be a
source of bugs.
Blocks going over the world boundaries are ignored. Materials
next to the boundaries can still interact in differently shifted blocks. If
arbitrary states were used in the missing cells, materials could move
outside the boundary, making them disappear or be overwritten when
that part of the world is loaded or generated.
Care must be taken on the chunk boundaries. While the blocks
in BCAs do not overlap, making it impossible for transition rules
to affect cells of other blocks, for correct computation, the chunks
must be making the same step. It is not an issue if synchronization
occurs between steps, but if multiple steps are taken in parallel, blocks
overlapping multiple chunks could sample states of a wrong step. A
similar problem can occur with the active rectangle optimization – if
the even (resp. odd) step changes no materials, that does not mean
the odd (resp. even) step will too. Cells can only be removed from the
active rectangle when both odd and even steps have no effect.

3.5 Lattice gas cellular automaton

While BCAs operate on blocks of cells and shift the blocks to propagate
changes, LGCAs operate on single cells and swap adjacent particles to
propagate changes. Instead of a cell having a material, each particle has
a material. The cell state in LGCAs consists of particles arriving from
different directions. In my implementation, I use the four standard
directions (top, bottom, left, right) and a stationary central particle.
I added the central particle to enable cells to come to a stable state,
increasing performance.

28
 3. Implementation

Figure 3.8: Neighborhoods in LGCA computation. Orange-colored

cells modify neighboring chunks. Red-colored cells reach outside the
world boundary.

Computation proceeds in two steps. First, transition rules are ap-

plied to each cell. Then, each particle is swapped with a particle in an
adjacent cell. ’Bottom’ particle is swapped with the ’top’ particle of
the bottom-neighboring cell, and the ’right’ particle is swapped with
the ’left’ particle of the right-neighboring cell (Figure 3.8).
The world boundary in my implementation became a mirror natu-
rally. Because particles cannot be swapped to the adjacent cells, they
stay in place, and in the next step, they are interpreted as moving in
the opposite direction.
Implementing the active rectangle optimization for LGCAs is harder
than for BCAs. If the cell does not change by applying the transition
rules, it does not mean we can remove it from further processing.
Particles of the same material moving from opposite sides would be
swapped, resulting in the same cell as before. So one cell cannot be
relied on to determine the active rectangle. The same applies when
swapping particles between cells. I have not come to a suitable solu-
tion. To get at least some performance improvement, only cells where
a ’non-empty’ particle was swapped are added to the active rectan-
gle. Therefore, totally empty cells, or cells empty except the ’center’
particle, belong outside the active rectangle.
The largest issue implementing LGCAs for me was race conditions.
Because I kept the cell in memory as one value (a struct), different
threads could override the whole cell while only trying to modify one

29
 3. Implementation

particle. This can be fixed by modifying the exact particle instead of

reading and writing the whole cell.
To visualize a cell, we need to map multiple particles to one color.
The colors of the particle materials can be added together or averaged,
or perhaps only the material with the highest index can be used. In
my implementation, the colors are added together, but other methods
may be better depending on the use.

3.6 Two-layer top-down experiment

Figure 3.9: A cube in isometric, cabinet, and top-down projection (from

left).

Top-down CA is my first CAs experiment, and it brought me to

the topic of making a rule editor. I wanted to use CAs for simulating
worlds in 2D top-down games. Top-down is a genre of games that use
an orthographic camera projection where the top and front surfaces
are visible (Figure 3.9). The worlds are 2D, but they often emulate
the third dimension to some extent. This allows the creation of more
interesting terrain and possibly gameplay involving height, such as
jumping puzzles. The worlds are mostly created using textured tiles
with handmade colliders and possibly a height assigned.

3.6.1 Creating a top-down environment

If the world were a CA where materials had a height property, it would

be possible to shape the terrain directly in-engine, and the height of
each cell could be used to drive movement and collisions. Using a
square lattice with heights in each cell basically creates a heightmap.
The heightmap can be interpreted as a top-down projection of a 3D

30
 3. Implementation

Figure 3.10: Height of each cell and its interpretation. (Implementation

allows for more angles between the ones shown.)

scene as depicted in Figure 3.10. It gives an illusion of a 3D environ-

ment, though only an illusion – space ’behind’ objects does not exist.
When rendering, the difference in height between two vertically
adjacent cells determines the slope of the terrain. If the heights are
equal, the terrain is flat. The higher the upper cell is, the more the ter-
rain is tilted up to a 90-degree angle (the maximum height difference
is set arbitrarily). If the upper cell is lower than the lower cell, it is
interpreted as a terrain unconnected to the lower cell. While editing
the terrain, the heights are restricted to not go over the maximum
height difference. These rules are arbitrary but look convincing and
somewhat respect the heightmap (water appears to flow downward).

3.6.2 Cellular automaton setup

I have decided on three-layer BCA with cells in all layers having a

height property. The first layer holds terrain (ground) data, the second
layer is for surface materials (water, fire), and the third layer holds
materials above the surface (smoke). The model got too complicated
before I started implementing the third layer’s logic, so the third layer
remains empty.

3.6.3 Transition rules

Let us consider a transition rule in two layers of the Margolus neigh-

borhood. This rule uses eight states to decide on eight new states. The
neighborhood is pretty large when defining transitions by hand. In
addition, each state here has an integer property (inner state) which,
if we restrict the integer to some range (for example, to all values
in a 16bit integer), can be translated into finite states with no inner

31
 3. Implementation

state. While possible, that approach would create an absurd number of

states. In any case, defining transitions in this setup by hand is wildly
impractical.

Figure 3.11: Equalizing water level on a terrain.

Top-down games often feature bodies of water, so fluids flowing

down slopes and pooling in valleys could be used as a gameplay
mechanic. Let us suppose that terrain with some height is present
in the first layer and the second layer contains empty and water cells,
where water cells have height interpreted as water depth in that cell.
In each step, we have access to blocks of four cells in the first layer
and four cells in the second layer. The two layers occupy the same
space, except we consider the second layer as ’above’ the first layer.
The total height is the sum of the heights of states occupying the same
space (terrain height + water height). One way of mimicking water
behavior is to equalize the water level in a block, which can be done by
equalizing the total heights in a block (Figure 3.11). Only water height
can be changed unless we also want effects such as terrain erosion. If
water should flow into an empty cell, it should be changed to a water
cell and vice versa. Care must be taken not to take more water from a
cell than there actually is.
Calculating the water flow is fairly easy as long as there are no other
materials. The added height would complicate interaction with addi-
tional materials. Equalizing the height of different materials would
arbitrarily change quantities of the materials, which makes no sense. In
one layer, materials cannot move over each other because a heightmap
is used instead of true 3D representation.
From the first layer, only heights are used to determine the water
movement. If there were multiple materials in the first layer, they could
be used to change the second layer behavior – for example mimicking
friction. That would add another level of complexity to these rules.

32
 3. Implementation

3.6.4 Number representation issues

I use an integer to represent height to avoid complications with floating-

point numbers. However, this actually adds to problems with calculat-
ing water movement. If the water heights cannot be divided to create
a level surface, some cells will have a height larger by one. If they are
left in this state, the water can create a pyramid instead of a flat sur-
face over larger area. On the other hand, if the larger height is moved
between cells and there is no lower place nearby, it moves indefinitely,
wasting performance. Using floating-point numbers avoids this issue
as long as the heights can be represented exactly. A similar problem
can occur even in models where materials have no inner state; when a
material moves in one direction and arrives at a flat surface, it cannot
decide which way to move around the surface.

3.6.5 Result

Figure 3.12: Top-down terrain painted using a square brush and a

smoothing brush.

I found this top-down CA to be working well with just the terrain

and water. The top-down projection is novel and visually interesting
(Figure 3.12). Unfortunately, it would be hard to add more materials
as the interactions would get complicated quickly. It could work well
for simpler uses such as destructible terrain, for example, in games
similar to the old Worms or TANKS. Creating the world by hand is

33
 3. Implementation

confusing because of the underlying heightmap and arbitrary height

restrictions. In conclusion, it is an interesting concept, but its use cases
seem pretty narrow.

3.7 Simplifying transition rules

In the top-down experiment, I calculate the state changes using some

arbitrary algorithm. If I wanted to add more materials, I would have
to program their behavior and take into account interactions with all
previous materials. The same applies to simpler models too. It could
be more practical for simple models to define rules in other ways than
by programming each material explicitly.
While researching different approaches, I used a one-layer BCA
and materials with no inner state.

3.7.1 One algorithm for all materials

One way to define the transitions is to create a more general algorithm

that handles all materials based on their qualities – these can be con-
stants set for each material. These qualities would determine physical
properties like mass and friction. Using an inner state in materials (for
example, velocity) is no problem because the algorithm handles the
complexity it adds. The number of materials does not make a differ-
ence either (from a development complexity perspective) because the
algorithm handles all materials uniformly.
The limitation is apparent – how interesting the behavior is de-
pends on the algorithm’s complexity. To include a new kind of inter-
action, the algorithm would have to be modified without affecting
the old interactions. The new behavior could be added as a wholly
separate branch in the transition logic, but interactions between the
two branches become a concern. It would be hard to add, for exam-
ple, logic circuits to an algorithm that calculates the movement of
fluids. Adding more features like this could lead to a complicated and
unmaintainable code. There should be a simpler approach given the
simplicity of the transition rule principle (mapping four states to four
states).

34
 3. Implementation

Nonetheless, this approach is practical when we want to simulate

some known process (physical, chemical, biological) and will not be
adding interactions that are outside the bounds of the process.

3.7.2 Chaining simple operations

We can define some simple operations on the block and then use them
to define the transition rules. Each combination of states can map into
a series of these operations. Some of the operations are:
• Identity
• Swap two cell states
• Swap top and bottom row
• Swap left and right column
• ’Rotate’ the block contents
Instead of a complicated algorithm, there is a list of operations.
The operations can be chained or combined while keeping the clarity
of what exactly is happening when any combination of materials
is encountered. The transition rules are basically defined by hand
without any abstraction in this form. Even though the rules are easily
understandable, with more materials, the number of rules explodes;
defining them all would be tedious.

3.7.3 Grouping materials

Figure 3.13: Defining rules using simple operations and groups (screen-
shot taken in Visual Studio Code). Simple operations are assigned to
group configurations in order of definition.

35
 3. Implementation

To avoid defining rules for each material, we can group similar

materials and defined rules for the groups. If each material belongs
to one group, all materials in a group have identical transitions, and
they are distinguishable only by systems outside the CA. Allowing
materials to belong to multiple groups can significantly reduce the
number of rules we have to define and maintain. We can create a group
for each behavior in the system. For example, we could have materials
(brick, sand, water) and groups (fall, pile, pool), then we can mix and
match materials with groups: bricks fall, sand falls and piles, water
falls, piles and pools.
Having materials in multiple groups creates a possibility for con-
flicting rules. The groups can be ordered by priority to select the most
suitable rule – generally, more specific groups should have higher
priority. One interesting idea I have not tried out is to use this ’natural’
rule overlap to make the CA probabilistic.
In my first (naive) group implementation, each material only be-
longs to one group. The only advantage of groups here is an Any
group, which generates rules for all other groups when used (Figure
3.13). It reduces the number of rule definitions needed. The rules are
defined procedurally (applied in the order they are written), with
later rules overwriting earlier ones. It is important to be careful with
the order of Any group rules because a large number of rules could
be overwritten. After defining around five groups, their interactions
became pretty hard to manage for me.
My later implementation is much more promising. A material can
belong to any number of groups, even none. Rules can be defined
using groups or plain materials. Rules are then generated for each
combination of materials in the groups involved. All generated rules
only contain plain materials; the groups are not used in the CA itself.
The rules are generated so that higher priority groups overwrite lower
priority groups, and plain materials override all groups. Groups are
sorted by the user. With this setup, we can define general behaviors
as well as interactions between concrete materials. The materials gen-
erated do not depend on the definition order, making mistakes less
likely. The following section discusses further improvements to rule
definition and generation.

36
 3. Implementation

3.8 Visual rule editor

CAs lend themselves well to visualization. Defining transition rules in

code is inconvenient, especially since the transitions are visible right
on the screen. Defining rules in their visual representation instead
should be more pleasant. To show this, I create a visual rule editor
with tools that make designing and debugging transition rules easier.

3.8.1 User Interface Setup

The editor has three areas:

• Editor window for managing materials, rules, and world gener-
ation
• The CA world
• Panel with simulation information, controls, and rule persistence
The user interface (UI) is made using Godot UI elements, which are
easy to use. The main parts of the CA implementation are explained
in earlier sections. The editor supplies the CA with materials, rules,
and world configuration. I made the editor for BCA with Margolus
neighborhood first, using the implementation from earlier sections.
After that, I implemented LGCA and modified the editor to support
its rules. The rules for BCA and LGCA are defined the same way but
are not interchangeable.

3.8.2 Materials and groups

The material editor window allows adding materials and groups and
setting up their properties (Figure 3.14).
Materials have a name and a color. The name is only used for
convenience in the editor, while the color is used in actual rendering.
Color is used for simplicity; the material pixels could be textured or
visualized in other ways. Materials can be marked for collisions – rigid-
body physics colliders are generated between marked and unmarked
materials (Section 3.8.5).
Groups have a name and a list of materials. Their names are used
for convenience too. Materials can be added to or removed from a
group when the group is selected.

37
 3. Implementation

Figure 3.14: Material editor user interface.

An integer internally represents the materials and groups. In the

material editor, they use their index in the list. In the rule editor, mate-
rials and groups are represented by one number; groups use integers
above the maximum material index to avoid conflicts. The number
of materials that can be defined depends on the implementation, but
usually, they are represented by an 8-bit or 16-bit number to save
memory. I use an 8-bit integer, but it can be easily changed. In any
case, it would be difficult to manage more than a few dozen materials,
even with the visual editor.
Changing the order or removing materials and groups is possible.
However, because their order identifies them, the rules need to be
adjusted to refer to the correct materials and groups. If a game uses a
persistent world, the world data could get invalidated.

3.8.3 Rule editing

The rule editor serves for rule editing and management. The main
focus is an editable rule. It consists of two BCA blocks, depicting a
configuration before and after a transition. They can be called the input

38
 3. Implementation

Figure 3.15: BCA rule editor user interface.

block and the output block. A material or a group can be selected and
’painted’ on a block (Figure 3.15).
The interface is straightforward – the situation before and after
the transition is clearly visible, and we can directly interact with it.
Preserving mass is as easy as seeing if the same colors are on both
sides of the ’equation.’ The materials have user-defined colors, and
the groups use generated colors designed to be distinctive.
To make groups more flexible, I added group variants. Each group
has four variants that can be cycled by clicking repeatedly. The variants
are a constraint for rule generation – in one rule, all instances of a
group variant resolve into the same material. There are four variants
because a block has four materials. More variants cannot be paired
between the input and the output block. This ensures that a material
does not transition into another material of the same group when it is

39
 3. Implementation

not intended. At the same time, it allows us to work with up to four

materials of one group in a rule without them getting mixed up.
The input configurations must be unique in all rules to make rule se-
lection unambiguous. Allowing multiple identical input blocks would
require probabilistic CA or another way of rule selection. The output
blocks can have any configuration. If the output blocks were all unique,
the result would be a reversible CA. However, I added no functionality
for testing reversibility or running the CA in reverse.
Aside from the rule currently being edited, there is a list of defined
rules. Created rules are shown in this list. By clicking on a rule in the
list, it is opened in the editing area. Another way to change a rule is to
paint the editable rule and apply it directly – because the input block
must be unique, the previous rule is overwritten.
In addition to the list of defined rules, there is a list of rules gen-
erated from the currently edited rule and a list of all generated rules.
These lists help find mistakes and confirm that rules are defined cor-
rectly.

3.8.4 Rule generation

The user-defined rules contain materials and groups. In this imple-

mentation, the CA recognizes rules with only materials. They need to
be generated (compiled) from the user-defined rules.

Figure 3.16: Two examples of equivalent rules that get normalized into
their leftmost form.

User-defined rules are normalized before being used. This nor-

malization only affects group variants. When editing a rule, group
variants can be set freely. The normalization re-labels the variants so
that they appear in a set order. For example, using variants labeled
by numbers one to four, if there is a block only using one group with
variants [2 4 4 3], the variants will be [1 2 2 3] after normalization
(Figure 3.16). It helps to eliminate duplicate rules that only differ by
variant labeling and makes the rules visually more uniform.

40
 3. Implementation

Rule generation begins by sorting the rules by the highest value

they contain. Rules using groups at the bottom of the group list are first,
and rules made only of materials are last. The older rule is overwritten
if a rule is generated and a rule with the same input block already
exists. A new rule is generated from each permutation of materials in
each present group. Group variants are considered as separate groups
containing identical materials.
While editing a rule, the user can select options to generate symmet-
rical rules. This convenience feature helps avoid cluttering the interface
with similar rules. Symmetrical rules are very common. Most CA rules
consider all directions equally. In games like Noita where gravity acts
in one direction, its perpendicular directions are symmetrical. There
are options for vertical, horizontal, and rotational symmetry, and they
can be combined. The block configurations are flipped or rotated, and
the resulting rules go through the rule generation process as described
in the previous paragraph.

3.8.5 World editor

The world generator and editor are made for testing and improving
the rules (Figure 3.17). The user can choose from four algorithms:
• Simplex noise – smooth noise.
• White noise – purely random noise.
• Simplex + white noise – smooth noise with some harsh transi-
tions.
• Random rules – randomly selected compiled rules.
The user can select the size of the generated world and feature
size. For simplex noise, it determines the size of generated shapes.
For white noise and random rules, feature size determines the size of
squares with one value, respectively, one rule. Except for the random
rules option, the actual materials are selected from a list of materials
that can be filtered. There is an option to display active rectangles and
physics colliders.
The world editor allows for directly changing materials in the
world by painting them. It can also instantiate rigid-body objects.
Rigid-body physics
Collision meshes for rigid-body physics can be generated when
generating the world. Whether a material is considered solid can

41
 3. Implementation

Figure 3.17: World editor and generator user interface.

be set in the material editor. The collision mesh is generated on the

boundary of ’solid’ materials as a part of the parallel chunk drawing
step. I implemented three algorithms (Figure 3.18):
• Naive – creates an edge between each ’solid’ and ’non-solid’ cell
boundary
• Greedy – creates the longest straight edge on a boundary
• Marching squares – creates one or more edges in all 2x2 cell
areas
These algorithms all have low time complexity. The naive algorithm
generates a large number of edges. The greedy algorithm mitigates
this downside. Marching squares generate more edges than the greedy
algorithm, but their colliders have rounded edges, which can be better
suited for some games.

42
 3. Implementation

Figure 3.18: Naive and greedy collider (left), marching squares collider
(right).

3.8.6 Lattice gas cellular automaton editor

The BCAs and LGCAs editors are almost identical. Instead of defining
the transition rules for a block, the rules are defined for particles inside
a cell. The materials and groups are the same.
The transition rules are generated according to the same principles
but with five materials instead of four. The generated symmetries have
to take into account the ’center’ particle, which always stays in the
center. A fifth group variant could be added, but I found no need for
it.
The default transition rule is different from BCAs (in my implemen-
tation). In BCAs, the block remains unchanged by default. However,
if transition rules do nothing in LGCAs, the particles keep moving
between two cells. Therefore, it could be better to swap the ’left’ and
the ’right,’ the ’top’ and the ’bottom’ particles, making particles move
in a straight line by default. This default behavior only applies to
configurations that have no rule explicitly defined by the user.
The world generator has to generate a direction in addition to a
material. For simplex noise, the direction is generated from the noise
gradient. For white noise, the direction is random. The world editor
allows the user to choose which direction the painted particles should
move.

43
 3. Implementation

Figure 3.19: LGCA rule editor user interface.

3.9 Evaluation

To evaluate the viability of this approach, I tried to imitate different

behaviors from existing games using the visual editor. Potential users
also tested the editor to provide feedback on the intuitiveness of the
visual editor and BCAs and LGCAs in general. For this, students of
technical disciplines and game developers were contacted.

3.9.1 Block cellular automaton editor

Creating the most common behaviors – solids, fluids, and gases – is

reasonably easy in BCAs. I created a group for each basic behavior:
falling, piling, pooling, and rising. Most rules only move the groups in
one direction. When two groups meet, they either continue in the same
direction, get swapped, or stop moving. When overall behavior is good,

44
 3. Implementation

Figure 3.20: A random scenario where water interacts with sand. The
sand sinks in the water. Simulation progresses from left to right.

Figure 3.21: A random scenario where water, oil, and two gases interact.
The oil floats on top of the water, and gases mix and rise. Simulation
progresses from left to right.

detailed rules can be created using specific materials. General rules for
groups cannot define behavior between specific materials in a group.
As an example of interaction between specific materials, I set sand to
sink in water and oil to float on water, as shown in Figures 3.20 and
3.21. I also tried creating different kinds of logic, for example, a simple
forest fire simulation (Figure 3.22). Similar interesting behaviors are
easily achievable, but it is hard to say whether they would be useful
in a game.
What could be a disadvantage for some games are patterns of
empty cells appearing in models where materials behave like particles
(visible in Figures 3.20 and 3.21). Materials need empty space to move
into, so they have to wait for adjacent materials to move away, creating
the patterns of empty cells.
A big limitation of this BCA is its small neighborhood. While it
makes the transition rules simple, it tends to create unnatural-looking
behaviors. This can be seen well in Figure 3.21 where gases and flu-

45
 3. Implementation

Figure 3.22: A scenario where fire burns forests, burned forests turn
into dead land, and eventually regrow. Simulation progresses from
left to right.

ids try to go the shortest way up or down, resulting in one-cell wide

columns of moving materials. It could be somewhat circumvented
with clever rules, but fundamentally, the materials have too little in-
formation to spread out more naturally.
As for the potential users, understanding the BCA principles was a
bit harder than I expected. Specifically, it was hard for them to visualize
how the blocks shift and how that results in the overall behavior. After
familiarizing themselves with it, the users could define some basic
interactions. The overall opinion was that this model is suited for
creating the usual interactions found in games like Terraria, and is
working well with gravity. The users’ desired interactions were often
imagined differently from how they would be defined as rules; for
example, it was hard to internalize that for something to happen
next to a wall, the wall has to be a part of the examined block. The
restrictiveness of the small neighborhood could be felt here.
Overall, visual editing feels way more convenient than using code.
The experience still could be made better, as discussed in Chapter 4.
What can be felt a lot are the CAs restrictions. With the neighborhood
so small, materials do not have enough ways to move for the movement
to feel natural. Instead of making the neighborhood larger, using
probabilistic rules could help.

3.9.2 Lattice gas cellular automaton editor

Creating the same behaviors as in BCA was an issue for me. It is easy
to define how particles react to collisions but hard to make them move
in some direction and then settle down. We often want the materials

46
 3. Implementation

Figure 3.23: A random scenario where water flows down. In areas with
too many water particles, the particles can move through the stone.
Simulation progresses from left to right.

Figure 3.24: A random scenario where dark and light particles interact.
When they collide, the dark particle goes down, and the light particle
goes up. Simulation progresses from left to right.

to stack on top of each other. However, a particle cannot tell that an

adjacent cell contains a stationary particle, and it should move itself
to a ’center’ position. It can only tell when already colliding, and at
that point, it can only bounce or override the ’center’ position that was
already filled. My attempt at making water is shown in Figure 3.23.
The water leaks through the stone in some situations, and it does not
settle down the way BCA water does. In any case, the water movement
looks pretty interesting.
Creating behaviors without gravity is easier. There may be some
use for these models in specific settings, for example, in a game simu-
lating chemical reactions. Figure 3.24 shows a simple model with two
interacting materials. It is easy to make visually impressive behaviors
in LGCA.
The default behavior of particles moving in a straight line was
slightly confusing for potential users. After understanding the tran-

47
 3. Implementation

Figure 3.25: A random scenario with a green material drawn over.

The particles rotate and reflect in different ways. The green particles
replicate in some situations.

sition rules, the users spent more time playing with the editor than
was the case with BCA. They mostly created simple rules and went
on to draw particles in the world, creating interesting visuals (Figure
3.25). They considered the LGCA good for creating interactive visual
art but questionable for use in games.
Overall, LGCA may be easier to understand but harder to use in
practice. It may be better suited for visual art generation.

48
4 Discussion and future work

There is a lot of space for improvements and further research in this

area. Tools that assist with game development are becoming increas-
ingly more common. There are already several visual programming
languages, although their usefulness for general tasks is debatable.
Node-based editors are popular in visual tasks such as texture gen-
eration or shader programming. The visual rule editor proved to be
well suited to defining rules, but there is still some awkwardness and
potential for confusion in the implementation.
The rule generation could be expanded. For example materials that
transition between stages to mimic inner state (density, voltage level...)
could use a generator that would create transitions between different
stages in a defined way. Another useful addition would be to allow
creation of smaller sub-rules that do not use the whole neighborhood,
and then generate rules from combinations of compatible sub-rules.
Without sub-rules, smaller independent interactions that can fit in a
neighborhood together must be combined by hand.
There are different ways of handling group priorities that may
work better than the one I implemented. In some cases it may be
useful to arrange the order in which each rule is used in generation by
hand.
When rules are being generated, many rules are usually overridden
by more specific rules. It may be interesting to instead keep these
rules and use them in a probabilistic way. It would create interesting
behavior with no additional work for the user.
An improvement specific for the LGCA would be to somehow
incorporate velocity vectors into the model without making the use
more difficult. One possibility is to make the rule output particles
movable by the user in a way that allows free control over direction and
size of its velocity vector. The particles could move in the direction best
approximating its velocity vector, and each transition would modify
this vector. This approach would allow for particles to move according
to more than the last transition, and also to other forces to be applied
outside the transition rules – for example gravity.
A more widely useful continuation would be to focus on the simu-
lation of higher-level concepts instead of the physical world. Currently,

49
 4. Discussion and future work

it is common to simulate economies and non-player character behavior,

though it is faked more often than not.

50
5 Conclusion

The thesis explored CAs, and the use of CA-like models in game world
simulation. Such simulated worlds make gameplay more dynamic and
add space for player creativity. They are usually implemented with
little regard for ease of reasoning about the system, making extending
and debugging it hard. CAs define the result of any situation, and the
order of computation is clear; These properties make reasoning about
the system much easier. I implemented a BCA and LGCA simulation
with chunks processed in parallel and multiple layers of cells. Then I
created a visual editor for defining their states and transition rules.
During the implementation, I found that using multiple layers
or additional state in cells results in high mental complexity. Even
when using a simple CA, defining transition rules was unpleasant and
error-prone.
Because CAs lend well to visualization, I created a visual editor to
make defining materials and transition rules more intuitive. The state
before and after a transition can be viewed and edited directly. I made
material groups as an abstraction to help define common behaviors.
The visual editor works well, but the complexity is still here. To-
gether with groups, I implemented a few ways to reduce the number
of rules that need to be defined manually, such as symmetry options
and rule variants. The actual rules are generated from the defined
rules, bringing their own issues such as definitions being resolved into
conflicting rules.
There remain many ways to improve the approach. The most obvi-
ous one is to extend the rule generation to assist better and automate
more kinds of rules. There are also limitations to both BCA and LGCA,
some of which cannot be overcome. Some users have trouble under-
standing the implications of certain CA properties. Other variants
of CAs have different mechanics and limitations, so they are worth
exploring.
Overall I consider this project a success. Although there would
have to be more improvements and considerations for the implemen-
tation to be used in practice, it shows the potential of using the right
representation and visual form for the job.

51
A An appendix

The following archives, created as a part of the implementation, are

available as appendices:
• Topdown_Source.zip – The Godot project files of the top-down
experiment.
• RuleEditors_Source.zip – The Godot project files of the BCA and
LGCA with visual rule editor. It was first created from the top-
down project. The project was heavily modified, but the overall
structure remains. The BCA and LGCA editors are built into
independent executables but share most of the code.
• TopDown_Build.zip – A Windows executable of the top-down
experiment.
• BCA_Build.zip – A Windows executable of the BCA rule editor.
• LGCA_Build.zip – A Windows executable of the LGCA rule edi-
tor.

52
Bibliography

1. SARKAR, Palash. A brief history of cellular automata. ACM Com-

put. Surv. 2000, vol. 32, pp. 80–107.
2. CHOPARD, Bastien. Cellular Automata Modeling of Physical
Systems. In: Computational Complexity: Theory, Techniques, and Ap-
plications. Ed. by MEYERS, Robert A. New York, NY: Springer
New York, 2012, pp. 407–433. isbn 978-1-4614-1800-9. Available
from doi: 10.1007/978-1-4614-1800-9_27.
3. AGRAWAL, Himanshu. Construction of Molecular Dynamics Like
Cellular Automata Models for Simulation of Compressible Fluid Dy-
namic Systems. 1999. Available from arXiv: comp- gas/9905002
[comp-gas]. PhD thesis.
4. DEVLIN, Jonathan; SCHUSTER, Micah. Probabilistic Cellular
Automata for Granular Media in Video Games. The Computer
Games Journal. 2021, vol. 10. Available from doi: 10.1007/s40869-
020-00122-4.
5. MITCHELL, Melanie; CRUTCHFIELD, James; DAS, Rajarshi.
Evolving Cellular Automata with Genetic Algorithms: A Review
of Recent Work. First Int. Conf. on Evolutionary Computation and
Its Applications. 2000, vol. 1.
6. KARI, Jarkko. Reversible Cellular Automata: From Fundamental
Classical Results to Recent Developments. New Generation Com-
puting. 2018, vol. 36. Available from doi: 10.1007/s00354-018-
0034-6.
7. FREDKIN, Edward; TOFFOLI, Tommaso. Conservative logic.
International Journal of Theoretical Physics. 1982, vol. 21, no. 3-4,
pp. 219–253. Available from doi: 10.1007/bf01857727.
8. MARGOLUS, Norman. Crystalline Computation. In: 1999,
pp. 267–305. isbn 0-7382-0057-3.
9. WOLFRAM, Stephen. Universality and complexity in cellular
automata. Physica D: Nonlinear Phenomena. 1984, vol. 10, no. 1,
pp. 1–35. issn 0167-2789. Available from doi: https://doi.org/
10.1016/0167-2789(84)90245-8.

53
 BIBLIOGRAPHY

10. WOLFRAM, Stephen. A New Kind of Science. Wolfram Me-

dia, 2002. isbn 1579550088. Available also from: https :
//www.wolframscience.com.
11. COOK, Matthew. Universality in Elementary Cellular Automata.
Complex Syst. 2004, vol. 15.
12. JOHN CONWAY, video by Brady Haran. Inventing Game of Life
(Numberphile interview with John Conway. 2015. Available also
from: https://www.youtube.com/watch?v=R9Plq-D1gEk.
13. DURAND-LOSE, Jérôme. Computing Inside the Billiard Ball
Model. In: 2001, pp. 135–160. isbn 978-1-85233-540-3. Available
from doi: 10.1007/978-1-4471-0129-1_6.
14. MARGOLUS, Norman. Physics-like models of computation. Phys-
ica D: Nonlinear Phenomena. 1984, vol. 10, no. 1, pp. 81–95. issn
0167-2789. Available from doi: https://doi.org/10.1016/0167-
2789(84)90252-5.
15. HARDY, J.; PAZZIS, O. de; POMEAU, Y. Molecular dynamics of
a classical lattice gas: Transport properties and time correlation
functions. Phys. Rev. A. 1976, vol. 13, pp. 1949–1961. Available
from doi: 10.1103/PhysRevA.13.1949.
16. FRISCH, U.; HASSLACHER, B.; POMEAU, Y. Lattice-Gas
Automata for the Navier-Stokes Equation. Phys. Rev. Lett.
1986, vol. 56, pp. 1505–1508. Available from doi: 10 . 1103 /
PhysRevLett.56.1505.
17. BHATTACHARJEE, Kamalika; NASKAR, Nazma; ROY, Souvik;
DAS, Sukanta. A survey of cellular automata: types, dynamics,
non-uniformity and applications. Natural Computing. 2020, vol. 19,
no. 2, pp. 433–461. issn 1572-9796. Available from doi: 10.1007/
s11047-018-9696-8.
18. AARONSON, Scott. Book Review: ’A New Kind of Science’. 2002.
Available from arXiv: quant-ph/0206089 [quant-ph].
19. Falling Sand Game [online]. 2009 [visited on 2022-03-15]. Avail-
able from: https://web.archive.org/web/20090422185054mp_
/http://fallingsandgame.com/overview/prop.html.
20. Making Sandspiel [online]. 2019 [visited on 2022-03-15]. Available
from: https://maxbittker.com/making-sandspiel.

54
 BIBLIOGRAPHY

21. PURHO, Petri. Exploring the Tech and Design of ’Noita’ [online].
2019 [visited on 2022-03-15]. Available from: https : / / www .
gdcvault . com / play / 1025695 / Exploring - the - Tech - and -
Design.
22. PURHO, Petri. Noita: a Game Based on Falling Sand Simulation
[online]. 2019 [visited on 2022-03-15]. Available from: https:
//80.lv/articles/noita-a-game-based-on-falling-sand-
simulation/.
23. Terraria Wiki - Liquids [online]. 2022 [visited on 2022-03-15]. Avail-
able from: https://terraria.fandom.com/wiki/Liquids.
24. Minecraft Wiki - Redstone mechanics [online]. 2010 [visited on 2022-
03-23]. Available from: https://www.youtube.com/watch?v=
jaoSzCfa9OM.
25. Minecraft - Redstone Conway’s Game of Life (Simulation Game) [on-
line]. 2022 [visited on 2022-03-23]. Available from: https : / /
minecraft.fandom.com/wiki/Redstone_mechanics.

55