Evolving continuous cellular automata for aesthetic objectives
Abstract
We present MergeLife, a genetic algorithm (GA) capable of evolving continuous cellular automata (CA) that generate full color dynamic animations according to aesthetic user specifications. A simple 16byte update rule is introduced that is evolved through an objective function that requires only initial human aesthetic guidelines. This update rule provides a fixedlength genome that can be successfully optimized by a GA. Also introduced are several novel fitness measures that when given human selected aesthetic guidelines encourage the evolution of complex animations that often include spaceships, oscillators, still life, and other complex emergent behavior. The results of this research are several complex and long running update rules and the objective function parameters that produced them. Several update rules produced from this paper exhibit complex emergent behavior through patterns, such as spaceships, guns, oscillators, and Universal Turing Machines. Because the true animated behavior of these CA cannot be observed from static images, we also present an online JavaScript viewer that is capable of animating any MergeLife 16byte update rule.
Keywords
Cellular automata Genetic algorithm Generative art Multiobjective optimization1 Introduction
Cellular automata (CA) [51] are a class of computer model that are made up of a grid (or other organization) of cells that move between discrete states as dictated by an update rule [58]. The quintessential example of a CA is Conway’s Game of Life (GOL) [13]. Though many CA, such as GOL, were introduced as recreational mathematics or generative art [3, 32], there are practical applications [2]. In 1996 a team performed computations with a genetic algorithm (GA) for global coordination [31]. In artificial chemistry, scientists have implemented selfreplicating cells through a CA [18]. GOL was shown to be Turing complete—capable of computing anything that can be computed with a Turing machine [5]. Likewise, Elementary Cellular Automaton (ECA) rule 110, which was studied extensively by Stephen Wolfram, was proven to be Turing complete [10, 57].
Continuous CA are a generalization of the more common discrete CA where the states are expressed as continuous numbers [23, 57, 58]. GOL has previously been adapted from discrete to continuous. One notable generalization of GOL is SmoothLife [37], where GOL is adapted to a continuous domain; however, the resulting animation is still monochrome. MergeLife is a continuous CA where each cell is a 24bit RGB encoded color. These cells are arranged on a 2D rectangular grid of cells where each interior cell has 8 neighbors that influence how that cell is updated. This arrangement of 8 neighbor cells is referred to as a Moore Neighborhood, named in honor of Edward F. Moore, a pioneer of CA theory. The number of alive cells present in a CA neighborhood is referred to as its neighbor count.
Families of update rules are typically expressed in some sort of encoding. For example, an ECA is usually encoded as a decimal number that represents an 8bit pattern that specifies a new cell value based on the 8 possible combinations of the three cells immediately above the target cell [57]. Wolfram MathWorld lists ECA update rules 30, 54, 60, 62, 90, 94, 102, 110, 122, 126, 150, 158, 182, 188, 190, 222, and 250 as the most frequently studied ECA rules [53]. The fact that many of these rules are no more than one or two binary digits away from each other is indicative of a smooth search space that increases the chances of a GA finding its way to locally optimal solutions.
Other examples of a smooth search space for CA exist. Researchers have generalized GOL to a family of update rules that specify the neighbor counts at which a cell should be born or survive. The update rule for GOL can be written as B3/S23, which means a cell is born with a neighbor count of 3, survives with a neighbor count of 2 or 3, and dies in all other cases. Larger than Life is a GOLlike family of CA that allow the size and type of neighborhood to be varied [11, 12]. Larger Than Life has even been scaled to neighborhood sizes of radius 25 and beyond [49]. For example, the CA Bugs, is written in the Larger than Life form of R5,C0,M1, S34..58, B34..45,NM [54]. This string specifies a neighbor radius (R) of 5, 0 history states (C), the middle cell (M) is included in the neighbor count, the neighbor count for survival (S) is between 34 and 58, the neighbor count for birth (B) is between 7 and 11, the neighborhood is an extended Moore (NM) neighborhood. An extended Moore neighborhood for radius 1 are the 8 cells around the center cell; a radius of 2 include the 24 cells that form two rectangles around the center cell. This encoding and generalization of GOL provides a smooth enough search space to be optimized by a GA. The smooth search space is evident because small changes to many of the components in the Bugs rule produce a CA that appears visually similar to the original Bugs CA.
Literature includes many examples of CA that can produce visually appealing animations as artifacts [11, 15, 37]. The artifact produced by MergeLife is the animated sequence, not a still computer image. Other evaluation methods also place emphasis on the process leading to the final resulting image [8]. The visual appeal of this artifact must be evaluated over several CA generations to grasp the full intricacy of the animated patterns that these automata can produce. For example, GOL supports spaceships, which are patterns that move across the grid. Guns are even more complex structures that are capable of producing spaceships. Oscillators are patterns that repeat over a certain number of CA generations. None of these pattern types would be evident from a single CA generation. Multiple frames must be analyzed because one of the goals of MergeLife is to produce CA that exhibit such patterns. These aesthetic MergeLife moving patterns are not meant to be representative of any natural phenomenon.
Many techniques, such as Picbreeder [40] allow users to guide a GA to evolve Compositional PatternProducing Networks (CPPNs) [44] that create generative art. Many of these algorithms require the human to serve as the objective function and are sometimes referred to as Human Based GA (HBGA) [24] or Interactive Evolutionary Computation (IEC) [48]. This sort of iterationlevel control has yielded greater artistic control for interactive evolution of images and animation [15]. By tweaking the MergeLife objective function, the user can define the aesthetic aspects of a new CA. These CA will produce generative art in the form of a sequence of still images that become an animation. We have implemented MergeLife in several programming languages, the source code can be downloaded from our GitHub repository.^{1}
In this paper, the abbreviation CA refers both to singular form cellular automaton and plural automata. Each application of the update rule in a CA is called a generation. Some literature refers to the generation as a step or tick. GA evolve a population over many generations. Likewise, CA perform an update rule over many generations of cells. Because of this the term generation has two meanings in this paper. For clarity, these generations will be referred to as CA generations and GA generations. This paper contains scalars, vectors, matrices and rank 3 tensors. For clarity, this paper follows naming conventions generally applied to linear algebra. Scalar values are lowercase and italicized (a), vectors are lowercase and bold (\(\varvec{a}\)), matrices are capital and italicized (A), and tensors are capital and bold (A).
This paper begins by introducing the MergeLife CA update rule and comparing it to existing CA update rules in literature. The paper continues by explaining how each MergeLife rule is encoded into a hexadecimal string that becomes the genome representation that will be evolved by a GA. Continuing to build the pieces needed for a GA, the paper introduces the MergeLife objective function that is guided by initial human provided aesthetic guidelines, but alleviates the human from manually scoring each rule. With the CA update rule, genome encoding, and objective function in place the paper can now present the design of the GA that will actually evolve the update rules. Next, the results from several runs of the MergeLife GA are presented, along with the rules that were discovered. A discussion of how MergeLife is a generalization of GOL and therefore Turing complete is presented. The paper concludes with a review of previous work, conclusions and next steps.
2 The MergeLife CA
Like GOL, the MergeLife universe is a rectangular grid of cells arranged in a Moore Neighborhood. Unlike GOL, individual cells are not simply on or off. Each cell is a vector containing three integer values between 0 and 255 (inclusive) that represent the intensities of red, green, and blue. A value of 0 indicates that the RGB component is fully off, and a value of 255 means the color component is fully on. For example, white is encoded as [255, 255, 255] and black is encoded as [0, 0, 0]. Similarly, a blue color would be [0, 0, 255]. This is consistent with standard RGB encoding. The universe grid is always initialized to a completely random state, with all RGB components initialized to values uniformly sampled (with replacement) between 0 and 255. This is the state upon which the first CA generation occurs.
For a discrete CA, such as GOL, the neighbor count is simply the number of nearby cells that are in a live state. To perform a continuous neighbor count, MergeLife merges (or averages) the red, green, and blue components of each cell together—MergeLife is named for this merging characteristic of the algorithm. Though similar, this is not the same as a grayscale operation. Grayscale conversion algorithms usually convert an RGB color to grayscale by taking an unevenly weighted average of the RGB components. The MergeLife neighbor count is calculated by taking a regular average of each cell’s RGB values. The maximum that any one value in the averaged matrix can hold is 255. This average is an integer value that is obtained by taking the floor of the sum of the three color components divided by 3.
At each CA generation, the matrix mode is taken of the merged grid. The matrix mode is the most commonly occurring RGB averaged value in the grid. Some CA will have large background regions of empty space that are occupied by a common color. The matrix mode of a grid is effectively the RGB average of the background color of the CA for a given CA generation. For some MergeLife update rules this background color will be constant and for others it will fluctuate. The current background color averaged value is the contribution to the neighbor count for any cell that does not have 8 neighbors. Cells that are in the interior of the grid will have 8 neighbors. However, cells at the grid edges will have fewer. Corner cells will have only 3 neighbors. All edge cells will be assumed to have 8 neighbors by treating any missing neighbors as having the background color. The neighbor count is calculated by summing the 8 neighbors in the averaged matrix. Because each neighbor can have a maximum value of 255, the maximum neighbor count is 2040 (\(8 \times 255\)). This is the only concept of background color that MergeLife has. Background colors may appear by virtue of the update rule; however, they are not specifically defined in any way.
2.1 Update rule
The MergeLife update rule is a generalization of GOL to a continuous RGB space. MergeLife and GOL’s update rules share a similar structure. GOL counts the number of alive neighbors to select between four subrules that each specify if each cell should change its state to either alive or dead. Similarly, MergeLife sums the RGB values of the 8 neighbors to select between up to 8 subrules that each specify the amount to change the current cell’s color to one of 8 keycolors that correspond to each subrule. Each MergeLife subrule is defined by two values—the neighbor count range that the rule covers and the percent that the current cell should move toward the rule’s keycolor if the rule applies. At most one MergeLife subrule will apply per CA step. It is possible for no subrule to apply, in which case the current cell does not change its value.
MergeLife update rules are defined by hyphendelineated hexadecimal strings, such as cb976a7488c028aa1b6a834b4fe860ac. This string is composed of 8 hyphendelineated octetpairs that define 8 subrules. Table 1 shows these subrules decoded from a hexadecimal update rule string. These 8 subrules define the state transitions for the MergeLife grid and hold all of the information necessary for a MergeLife update rule. For a different MergeLife rule, the values and ordering will be different; however, the column structure will remain the same. The exact means by which a hexadecimal string is decoded to a subrule table is described in the next section. The columns \(\varvec{\alpha }\), \(\varvec{\beta }\), and \(\varvec{\gamma }\) are provided to the MergeLife update rule as vectors. The remaining columns are provided for clarity and are not used by the update rule algorithm. All columns are decoded directly from the hexadecimal rule string that is given in the octet1 and octet2 columns.
Decoded MergeLife update rule (cb976a7488c028aa1b6a834b4fe860ac)
High (\(\varvec{\alpha }\))  Range  Keycolor  Pct. (\(\varvec{\beta }\)) (%)  Index (\(\varvec{\gamma }\))  Octet1  Octet2 

216  0–215  Blue  83  5 (blue)  1b (27)  6a (106) 
320  216–319  Blue  − 67  4 (yellow)  28 (40)  aa (− 86) 
632  320–631  White  − 18  7 (cyan)  4f (79)  e8 (− 24) 
768  632–767  Black  − 65  8 (white)  60 (96)  ac (− 84) 
848  768–847  Red  91  2 (red)  6a (106)  74 (116) 
1048  848–1047  Purple  59  6 (purple)  83 (131)  4b (75) 
1088  1048–1087  Yellow  − 50  3 (green)  88 (136)  c0 (− 64) 
1624  1088–1623  Red  − 82  1 (black)  cb (203)  97 (− 105) 
MergeLife keycolors
Octet index  Keycolor  RGB red  RGB green  RGB blue 

1  Black  0  0  0 
2  Red  255  0  0 
3  Green  0  255  0 
4  Yellow  255  255  0 
5  Blue  0  0  255 
6  Purple  255  0  255 
7  Cyan  0  255  255 
8  White  255  255  255 
The pseudocode presented for MergeLife refers to the above equation (K) for the RGB values of the keycolors. This matrix contains the same information as what Table 2 conveys. The rows of the matrix are the 8 keycolors and the columns are the RGB components of red, green, and blue for each color. The RGB color model was chosen because it is well known and requires no transformation for the video displays that this algorithm will most likely be viewed upon. It would be possible to encode the grid into other color models, such as hue, saturation, lightness (HSL), hue, saturation, value (HSV), or cyan, yellow, magenta, black (CYMK).
The vectors \(\varvec{\hat{x}}\) and \(\varvec{\hat{y}}\) define the directions that are needed to move from the cell being updated to visit each of the 8 neighbors. The vector \(\varvec{\hat{x}}\) specifies column movement and the vector \(\varvec{\hat{y}}\) specifies row movement. Taken together, these two 8value vectors specify to visit the following directions: N, S, W, E, NW, SE, NE, and SW. The keycolor matrix (K) and neighborhood vectors allow the MergeLife update rule defined in Algorithm 1 to lookup the keycolor for a particular subrule.
The update rule accepts the current grid (G) and returns an updated grid (\(\mathbf {G'}\)). These are both rank 3 tensors of the shape \(h \times w \times 3\). The depth of 3 accounts for the red, green, and blue components of each cell’s RGB color. The subrules specified in this table are processed in order, one at a time. Changes to the grid are not visible to the update rule until the processing of the following CA generation. This prevents these changes from affecting the subsequent update rule changes in the same CA generation. This separation is a common requirement for most CA, including GOL. As each cell is processed, the update algorithm must calculate a neighbor count which is defined by Algorithm 2.
The applicable subrule is the row in Table 1 whose range includes the neighbor count. There can be no gaps or overlaps between these ranges. Therefore, at most one subrule row can apply to a given cell for a given CA generation. Sometimes no subrule will apply. If the neighbor count is beyond the range of the highest subrule, then no change is made to that cell. For example, Table 1 has a gap beyond 1624. Any cell that has a neighbor count that is greater than or equal to 1624, will not be affected by the update rule. Each subrule contains a target color and percent. These colors are the keycolors defined by the MergeLife algorithm. Keycolors are constant and are not defined by the update rule or evolved by the GA. The keycolors are listed in Table 2.
The value \({\mathbf {G}}_{y,x}\) contains the current RGB value, which is a 3value vector at x and y. The keycolor (\(K_{d'},\ldots\)) for the current subrule is also a 3value vector. The subrule row’s percent (\(\varvec{\beta }_{d}\)) is a proportion that governs how much of the distance between the current color and keycolor should be covered in each CA generation. Because the percent is a decimal value it is necessary to take the floor of the product to obtain an integer RGB vector.
2.2 Decoding a MergeLife update rule
MergeLife update rules are encoded into hexadecimal strings made up of 8 pairs of octets that occupy a total of 128 bits. These strings serve two purposes. The first is that this notation allows users to easily represent and exchange MergeLife update rules. The second is that this hexadecimal string becomes the genome that the GA applies crossover and mutation to.

cb976a7488c028aa1b6a834b4fe860ac
MergeLife decodes the hexadecimal string given earlier in this section into a form similar to Table 1. This provides Algorithm 1 with the vectorparameters of \(\varvec{\alpha }\), \(\varvec{\beta }\), and \(\varvec{\gamma }\) that are needed for execution. These parameters correspond directly with the columns of the same name in Table 1. The remaining columns are provided to illustrate the decoding process of the update rule.
Each subrule row in the table is represented by one of the 4digit hexadecimal numbers in the string. The first octet pair in the string is cb97, which contains the octets cb (unsigned decimal 203) and 97 (two’s complement decimal − 105). The first octet is an unsigned number and the second octet is a signed two’s complement number. The high (\(\alpha\)) is \(203 \times 8 = 1624\) and the merge percent (\(\beta\)) is \(105 \div 128 \approx 0.82\).
Despite the fact that cb97 is the first number in the hyphenated hexadecimal string, it is sorted to the final position of the decoded update rule. This position is because the rows are ordered by the \(\varvec{\alpha }\) column, which specifies the high end of the neighbor count for each subrule. The fact that this row occurred first in the original hexadecimal string is represented by the 1 in the index (\(\varvec{\gamma }\)) column.
For convenience, Table 1 shows the neighbor count range covered by each subrule, which is the previous row’s \(\alpha\) value up to, but not including, the current row’s \(\alpha\) value. The subrule with the lowest \(\alpha\) starts its range with zero. If a subrule’s range is a single number (e.g. 0–0), then that subrule row is inactive.
The sign of octet2 is simply a flag that allows two subrules to be mapped to the same keycolor. A positive percent subrule is mapped to the keycolor that corresponds with the subrule’s index (\(\varvec{\gamma }\)) within the hexadecimal string. A negative percent subrule is mapped to the next index’s keycolor. A zero percent subrule will not affect the current cell. The next keycolor for the final row of white (index 8) will be wrapped around to black (index 1). This equation obtains the percent (p) by dividing the value of octet2 by the magnitude of either the maximum value of a signed or unsigned byte. The final percent is always a positive number. The ability of a negative percent to change the keycolor is a needed complexity to allow multiple ranges to apply to a single keycolor. This is needed to emulate GOL and will be discussed in further detail later in this paper. The column named KeyColor specifies the keycolor that each subrule is ultimately mapped to after the sign of the original percent is handled.
3 Objective function design
Creating an objective function that evaluates the aesthetic ranking of MergeLife rules presented two difficult problems. The first problem is that the objective function must execute the MergeLife update rules over a potentially large number of update steps to see what patterns these rules produce. This requires considerable computational expense during the running of the MergeLife GA.
The second problem is that the evaluation of aesthetic qualities by a computer requires a level of creativity that is difficult for a machine to reproduce. To provide a consistent vocabulary for this Computational Creativity Theory (CCT) frameworks such as FACE, IDEA, and SPECS have been proposed [9, 22]. These frameworks provide a model to describe the creative component of a computer program. These models also examine what it means to be creative [21] and explore the spectrum from minimal human guidance to situations where the human essentially becomes the objective function. MergeLife is only an extension of the human’s own creativity. The objective function statistics covered in the next section simply automate and alleviate the human user from needing to manually score a large number of genomes produced by crossover and mutation.
Literature contains a number of different aesthetic measures for the evaluation of computer generated art. Heijer and Eiben [17, 19] propose four aesthetic measures that can be applied to static images: Machado and Cardoso (image complexity), Ross and Ralph (bell curve), fractal dimension, and combined weighted sum. MergeLife evaluates some fitness through static image analysis. However, the bulk of MergeLife’s fitness assessment occurs through the analysis of the image transition between CA steps.

Class 1: Nearly all initial patterns evolve quickly into a stable, homogeneous state. Any randomness in the initial pattern disappears.

Class 2: Nearly all initial patterns evolve quickly into stable or oscillating structures. Some of the randomness in the initial pattern may filter out, but some remains. Local changes to the initial pattern tend to remain local.

Class 3: Nearly all initial patterns evolve in a pseudorandom or chaotic manner. Any stable structures that appear are quickly destroyed by the surrounding noise. Local changes to the initial pattern tend to spread indefinitely.

Class 4: Nearly all initial patterns evolve into structures that interact in complex and interesting ways, with the formation of local structures that are able to survive for long periods of time. Class 2 type stable or oscillating structures may be the eventual outcome, but the number of CA generations required to reach this state may be large, even when the initial pattern is relatively simple. Local changes to the initial pattern may spread indefinitely.
Wolfram conjected that many, if not all, class 4 CA are capable of universal computation. This has been proven for GOL, which is a class 4 CA [10]. These classes are subjective, making it difficult to determine an update rule’s Wolfram class programmatically. The objective function chosen for MergeLife attempts to give higher class update rule’s similarly high scores. However, these scores must be continuous, rather than a discrete number of classes. As is common with evolutionary algorithms, the higher scored update rules will have a greater chance of contributing components of themselves to future CA generations of update rules.
3.1 Configurable multiobjective function
MergeLife does not attempt to be creative in and of itself. Rather, a configurable objective function gives the user the ability to define objectives that might result in an aesthetic CA. For the purposes of this paper, we considered an aesthetic CA to be one that exhibits complex emergent behavior through patterns, such as spaceships, guns, and oscillators. A different human user would likely have different criteria. However, spaceships, guns, and oscillators are some of the patterns that have spawned the greatest interest in GOL. The process of creating such an objective function involved much trial and error as we developed new statistical measures and introduced them as multiple objectives. By evaluating the CA that achieved high scores and also visually displayed complex emergent behavior, we were able to tune the objective function to produce visually pleasing CA’s with the desired behavior. The fact that the higher scored MergeLife rules display this sort of behavior speaks to the ability of these objective statistics to score the aesthetic appeal of MergeLife rules.
The provided objective function for MergeLife can be adjusted to fit each user’s own aesthetic tastes. This is done by adjusting the importance weighting of a number of statistics from the grid as the updates are evaluated. These statistics form a multiobjective function that provides the score that allows the MergeLife GA to find the most desirable update rules for crossover and mutation. These multiple objectives are created by a user and then stored in a table such as Table 3 that is executed by Algorithm 3. The values contained in this table are the parameters that guided the evolution of all MergeLife update rules discovered for this paper. These values can be tweaked to individual preferences.
The MergeLife objective function begins by initializing the CA grid to random values and running the update rule until the grid pattern stabilizes. Once this grid has stabilized the statistics needed for the multiple objectives can be collected. The number of update steps that occurred prior to stabilization is one of the objective statistics. The means by which stabilization is defined is covered in the next section where the update steps statistic, as well as each of the other objective statistics are defined. It is not necessary to use all of the provided statistics—the update rule used in this paper did not use every statistic. The objective function given by Table 3 did not make use of either the colors or background statistics. Though unused in this paper, both of these statistics can be used for other aesthetic guidelines.
MergeLife objective function for this paper
Stat  Min  Max  Weight  Weight min  Weight max 

Generations  300  1000  1  − 1  1 
Foreground  0.001  0.1  1  − 0.1  − 1 
Active  0.001  0.1  1  − 1  − 1 
Rect  0.02  0.25  2  − 2  2 
Mage  5  10  0  − 5  0 
The objective function is stochastic because the initial state of the grid is random. Because of this randomness there will be some variance in the score obtained over multiple calls to the objective function. To mitigate the randomness of these scores the objective function is executed over 5 cycles. The max score from these 5 runs becomes the score for the current update rule being evaluated. We tried a number of different cycle counts and ultimately decided on 5. With this number of cycles the standard deviation between 10 runs of the objective function score of the same update rule was typically less than 0.5. This provided consistent enough scores for rules to evolve that sufficiently met the criteria specified in Table 3. While additional cycles provide more consistent results, this causes a linear increase in the computation time requirements for each objective function evaluation.
3.2 Choosing objective parameters
The overall goal of the parameters that we chose was to create long running CA that had objects moving over distinct background regions. Additionally, these CA should run for upwards of 1000 CA generations before stabilizing. The chosen objective function parameters encourage the generation of update rules that will remain active for at least 300–1000 CA generations. The amount of stable foreground structure should be small, between 0.1 and 10%. Similarly, the amount of active cells should be small, between 0.1 and 10%. There should be enough space that a rectangle of the background color should be able to take up at least 25% of the grid. Additionally, the background color (mode of the averaged matrix) should not have changed for 5 CA generations. The exact definition of these measures is given in the next section. The format of the config section will be defined later in this paper.

Good pattern with potential activity for spaceships and other patterns (similar to Wolfram Class 4).

Simple sustained pattern (similar to Wolfram Class 3).

Expansion to s single pattern (similar to Wolfram Class 3).

Shrinking to single color (similar to Wolfram Class 1 or 2).

Quick convergence to a dead grid with no patterns/single background color (Similar to Wolfram Class 1).

Any patterns quickly descend into chaos (similar to Wolfram Class 3).
From an initial random sample of 100 rules 55% were chaos, 37% were dead, 6% were shrinking, and 2% were expansion. None of the 100 random rules were good or sustained. An optimization algorithm beyond random sampling is needed to obtain better CA rules. Obviously, sufficiently large random samples would produce occasional good rules. These classes were used for observation only and are too discrete to be effectively used for an objective function [30].
Evaluated MergeLife update rules
Hex rule  Category  Score 

a07fc0000000000000000000ff80807f  Good  2.6979885814668423 
7b58f7b4c5b4fd8722faeb106de8107c  Good  1.8599999999999999 
d44f9ba553e77373fb079984b444727b  Good  3.0164163372859023 
eaa3fb3c4d19e73273769601764be810  Good  3.0774703557312257 
E5425F799341F31E6C6B7F0887737068  Good  3.792929292929293 
0de6349685077cc734c6d5a9bcfd2355  Good  3.9313131313131313 
85035eb6084c04df7657a5b360443524  Good  2.3944664031620553 
658ebef06adac5b76ad22984383d2f0e  Good  3.6494949494949496 
67695dd67d03564ea5eccae254c4810c  Good  3.625841018884497 
df1dbba18e06aa6648ff74146a2f6237  Good  4.545226174791392 
d8a78915629b22486055fc87ef9215f5  Good  3.9434343434343435 
E5425Fc02041F31E6C6B7F0887737068  Good  3.4676767676767675 
b77493f4ac95f5b386f0dc6ee39737de  Good  3.7339833113746157 
309d92a3e31b3b635e24c9d22dcc8168  Good  4.224242424242425 
8b053be0e9aa996aee612529646b2fff  Sustained  3.7298902064119455 
60077d4205e51b9b2899e0431cd42f7b  Sustained  3.9954325867369347 
fd3d8ef7d4a43a7a70abe7cb03ba5760  Sustained  2.3237944664031622 
4ec62584fc1f0456ceee152c39926fee  Expansion  2.7715590689503733 
1e6b9afa16f223bc33969fb346f4cb4f  Expansion  − 3.9757575757575756 
7c6a1fa374aa6d87eb8cd12ba4efdda5  Expansion  − 2.889566472175168 
f7f7bda5e41cf9657a724aa1bafdf4c9  Expansion  1.377830478700044 
6d1de41a841ee983b6ea53f59eff7c1a  Shrink  2.1669565217391304 
19c9756568f082c0abab474a2a7deab1  Shrink  1.7330158730158731 
722385f83c9a70586b7a92ee3efcd1f7  Shrink  1.5742857142857143 
39075c95b56144e9b4b04fc3adf48895  Shrink  1.9 
de0c19601030ab0a810538d61c6bf85f  Shrink  − 3.9676767676767675 
d02866d855635958582435baf6040d2d  Shrink  1.76 
6d1de41a841ee983b6ea53f59eff7c1a  Shrink  2.0990250329380764 
7107794d41f78ef80948f95fa8be00f9  Shrink  1.800210803689065 
03c362b4458a0d6e6d2d1d1d7afcec9b  Dead  1.7685714285714287 
3e6982bbee4af54e841eacb76664f541  Dead  1.949459815546772 
4af39216c79945014e5850a6ddcaae26  Dead  − 0.5436024844720497 
6b46687f488549880a56efc7c4949bfb  Dead  1.0514285714285714 
6bfb501558ab81618d70c743a8ba34d3  Dead  − 0.5126745718050066 
7cd2a302364a47adfe921eab0d8ed47b  Dead  1.917986071899115 
9cd5588b95324af07816af1f23a16683  Dead  1.9545893719806764 
31d016fd626d68ed9dfebea919977d51  Dead  2.099159294811469 
745bd7796d22a65032d7c2729cab6e66  Dead  0.7418633540372671 
31d016fd626d68ed9dfebea919977d51  Dead  2.389821193299454 
79e4d4666d3f1cb683ffdf8cc73c4154  Dead  0.04347826086956519 
3392112d6f4573bd075b522325a6e28b  Dead  0.7969609134826525 
620c0efc3d887cf214d8d96058ab9b78  Dead  − 0.10000000000000009 
56ac691fd2ba46cd80db379ba7aa0c17  Dead  0.022222222222222143 
4c267f82a6bbd3faa932d39ba5b10e8a  Chaos  − 4.1 
9b557855ba02cccc1c9e200708bb389c  Chaos  0.786824769433465 
17b58b305e0dac4cee86c95a6fd6af19  Chaos  − 3.2 
46e59fa21718bd611cccd7b99d343c9e  Chaos  − 3.9474747474747476 
The hexadecimal notation used to encode MergeLife rules into genomes provides a smooth enough search space that the GA is able to maximize the objective function and produce CA patterns that often include spaceships, oscillators, still life, and other complex emergent behavior. These patterns can be observed through the visual inspection of the CA produced by MergeLife.
Further analysis of these rules demonstrate two additional characteristics of the MergeLife search space and objective function. The first characteristic is the amount of noise in the MergeLife objective function. MergeLife scores are the maximum of 5 evaluation cycles run from randomly initialized grids. While MergeLife itself is deterministic, these randomly initialized grids are not. Rerunning the rules in Table 4 produced scores with a standard deviation of 0.5 over a sample of 10 calculations of the score using 5 cycles. More cycles will produce more consistent results for a given MergeLife rule at the cost of objective function runtime. While higher cycle counts lowered the standard deviations they linearly increased the computation time. Therefore, we found that the 5 cycles provided an acceptably consistent balance between consistent scoring and computation time.
The second characteristic is the smoothness of the MergeLife search space for the provided objective function. This smoothness is evident from the fact that small changes to each of the 16 hexadecimal digits usually produce correspondingly small changes in the score for that rule. To test this we reran all 47 rules in Table 4 and increased/decreased each digit. Because there are 32 digits each rule has a maximum possibility of 64 movements if the digit is allowed to both increase and decrease by one. Because digits 0 and F cannot move down or up respectively some of the rules had less than 64 perturbations. The change in score was greater than 1.0 in only 31% of these 64 possible changes over all 47 rules. This shows that the score is relatively smooth over small movement within the search space.
The search space is also composed of many local minima. This is not surprising, given that there are many different MergeLife CA that can exhibit spaceships, oscillators, still life, and other complex emergent behavior. We considered it desirable to find many interesting MergeLife update rules rather than attempting to find one global maximum for the objective function. The results of this research are over 1100 MergeLife rules that are all local minima.
4 Objective function statistics
The MergeLife objective function has multiple objectives. Recent research of multiple objectives for CA suggests techniques for both static analysis of individual CA generations as well as changes to the grid over a series of CA generations [33, 35]. These techniques provided some direction for the statistics collected for the MergeLife objective function. This section describes the means by which each of these objectives is calculated. Many of these calculations are based on the average (or merged) value of the RGB colors. The averaged matrix, which was calculated by the update rule, is a part of many of the objective function statistics.
The mode of the average matrix is the most common number in that matrix, and is effectively the background color of the grid. Statistics related to the background color of the grid can be important indicators for the objective function. A matrix is kept that counts how many CA generations individual cells have been the background color. A cell is considered a stable background cell if it has been the background color for longer than 100 CA generations.
4.1 Generation count

Less than 1% of the merged grid cells have had different values for 100 CA generations.

The count of stable background cells has not changed for 100 CA generations.

More than 1000 total CA generations.
If any of the above three conditions are met, the CA will stop and its objective function will return a score. The CA generation count is the number of CA generations that occurred prior to these conditions being met. The generation count statistic is useful when you would like to ensure that high scoring genomes run for an acceptably long number of generations.
4.2 Background ratio
The background ratio (named background, but not used in Table 3) is the ratio between the number of background cells and the total number of cells in the grid. A background cell is defined to be any cell that has a current merged color value that is equal to the matrix mode of the merged color matrix. Some CA, such as GOL, have relatively large background areas. This statistic allows CA with large background areas to be rewarded or penalized, as desired.
4.3 Foreground ratio
4.4 Active cell ratio
The active cell ratio (active from Table 3) is a ratio between the number of active cells and the total number of cells in the grid. An active cell is defined as a cell that has not been a background cell for the last 5 CA generations, but was a background cell in the last 25 CA generations. Active cells are those that are often background, but will typically have other patterns, such as spaceships, that travel through them.
4.5 Largest rectangle ratio
The largest background rectangle ratio (rect from Table 3) is the ratio of the largest rectangle of background cells and the total number of cells in the grid. This statistic indicates that not only is there a large amount of background cells, but there are also large unobstructed rectangles of background cells. The rect statistic is similar to the background statistic, except that rect specifies the largest contiguous area of background cells and background tracks how much of the grid is made up of background cells. If spaceships are desired, the rect and active statistics are the most important two statistics. The active statistic detects the spaceships and rect detects that they have space to fly through. If spaceships are present in a CA with a low rect they will rapidly crash into something and often cease to exist, similar to what Wolfram describes for Class 3 CA.
4.6 Mode age
The current mode age (mage from Table 3) is the number of CA generations that have occurred since the matrix mode has changed. Usually it is desired for the merged color matrix mode to remain constant. Because the mode becomes the neighbor value for edge cells, changing the mode can have a large scale effect around the outer perimeter of the grid. Additionally, some MergeLife update rules will produce patterns where a large amount of cells rapidly switch between two different colors. This can cause a potentially undesirable flashing effect, such as update rule a7f61d5695749645c3185c36fecafa0e.
4.7 Color count
The color count (named color, but not used in Table 3) is the number of distinct RGB colors currently present on the grid. This allows the colorfulness of an update rule to be scored.
5 GA design
The MergeLife GA described in this paper is based on crossover and mutation that follow the algorithms described by Mitchell [30]. Genomes are defined to be MergeLife update rules. These update rules are stored as arrays of 16byte numbers that come directly from the hexadecimal MergeLife rule format described earlier in this paper. These genomes are each assigned a score by the objective function described earlier in this paper. Superior and inferior genomes are chosen by tournament selection after each GA generation. Superior genomes are chosen to produce offspring through crossover and mutation. Inferior genomes are chosen to be killed, making room for the offspring produced by the superior genomes in the next GA generation.
5.1 Objective function
The objective function is somewhat stochastic, as the phenotype is the ultimate converged grid that was produced by MergeLife update rule genome on a random starting grid. Though multiple random starting grids can produce a variety of different converged patterns, most patterns produced from a common MergeLife update rule will appear closely related. The objective function goes through several evaluation cycles, with different starting grids, and takes the maximum score. A cycle count of five provides relatively stable scores.
5.2 Crossover of two MergeLife update rules

Parent 1: 0de6349685077cc734c6d5a9bcfd2355

Parent 2: 85035eb6084c04df7657a5b360443524

Off Spring 1: 0de6349685077cc734c6d5a960442355

Off Spring 2: 85035eb6084c04df7657a5b3bcfd3524
For these two update rules, the two parents produce two offspring that are somewhat similar to the original parents. The fact that this small mutation produces a very similar CA to the parent speaks to the smoothness of the search space provided by the MergeLife rule encoding.
5.3 Mutation of a MergeLife update rule

Parent 1: d8ab8915629722486055fc87ef9215f5

Off Spring 1: d8a78915629b22486055fc87ef9215f5
The original parent is a chaotic CA. However, by flipping the fourth digit with the twelvth we now have a similar, but more organized CA. The new CA has a much larger background region and spaceships can be seen as it runs.
5.4 GA configuration
The above settings were used for all experiments performed in this paper. The CA grid was \(100\times 100\). The GA had a population size of 100. Crossover produced 75% of new genomes and mutation the remaining 25%. Tournament selection with 5 rounds selected the parents from the population. For any renders produced, the pixels will be zoomed by 5 and 250 CA steps will occur for the render. The objective function will use 5 cycles to mitigate the effects of a random starting grid. When the GA is ran, 1000 steps can go by without improvement before the CA is assumed to have converged. The score threshold of 3.5 means to keep any CA that recieves and objective function score higher than 3.5. The final section defines the objective function. The format of the objective section was defined earlier in this paper.
6 Results and MergeLife rules discovered
We discovered over 1100 different MergeLife rules while working on this paper. Some of these rules are provided in this paper, the remainder are provided at the author’s GitHub repository. These rules were discovered mainly from the Java implementation of MergeLife. Currently, the Java implementation has better performance than the Python and JavaScript versions. The Java version makes use of multithreading and scales well to multicore systems. To produce the results given in this paper we ran the MergeLife GA on an Amazon Web Services (AWS) Elastic Cloud 2 (EC2) instance of type c5.18xlarge. This instance type is compute optimized and contains 72 cores and 144 GB of RAM. During the run, all 72 cores were utilized at nearly 99%; however, the memory was only utilized at 11%. This instance type was chosen for its large number of CPU cores. Memory is much less important. All of the higher CPU count AWS instances have more than enough RAM for MergeLife. This instance type was able to evaluate around 3000 genomes a minute.
We performed two runs on this type of EC2 instance. The first run was for 24 h. A population was allowed to continue until no new top genome had been produced for 1000 evaluations. At this point the population is considered to have converged. After convergence the top genome was recorded if its score was above a configurable threshold of 3.5. During these 24 h a total of 2702 convergences occurred. From these a total of 146 rules successfully exceeded the threshold of 3.5. Therefore the success rate is around 5.4%. Further optimization of the GA hyperparameters might increase this percentage. For this run the hyperparameters were as follows: 100 population size, crossover percent of 75%, tournament cycles of 5, and the objective function score was the max of 5 evaluation cycles. These hyperparameters were chosen though by informal experimentation and could certainly be tuned further. The majority of the time spent in preparation of this paper was the development of the objective function and the creation of a smooth encoding for the MergeLife CA.
The second AWS run was much longer. We used 5 concurrent EC2 instances of type c5.18xlarge for 33 h with the goal of finding 1000 rules that exceeded the objective score threshold of 3.5. This resulted in a total of 18,796 convergences that had occurred before 1000 rules were discovered. The results of the first run were representative in that the much larger second run achieved a similar 5.3% success rate. While conducting both of these two runs we encountered a variety of interesting MergeLife update rules that are stored at GitHub.^{3}
In the following sections, we will highlight five of these rules. The selection of rules to add here is largely subjective. We chose these update rules for their creation of spaceships, interesting still life patterns, and ability to span a large number of CA generations before converging. We assigned a name to each of these update rules, based on their overall appearance. The images of each of these update rules were produced from a random grid and applying the update rule for 1000 CA generations.
6.1 Red world

e5425f799341f31e6c6b7f0887737068
6.2 Yellow world

7b58f7b4c5b4fd8722faeb106de8107c
6.3 Shrinking cells with spaceships

85035eb6084c04df7657a5b360443524
6.4 Still life and oscillators

67695dd67d03564ea5eccae254c4810c
6.5 Sustained cellular

df1dbba18e06aa6648ff74146a2f6237
7 Turing completeness and the relationship to Conway’s game of life

a07fc0000000000000000000ff80807f
Therefore, it is possible for the MergeLife GA to discover GOL. By extension, MergeLife can represent CA that are capable of functioning as Universal Turing Machines. Because MergeLife CA can be Turing Machines, they also exhibit the halting problem, which states that whether a Turing Machine will halt or not cannot be determined by analysis of the program code. Because of this the MergeLife update rules must generally be executed to see how long they will take to converge or halt to a stable grid. This has important ramifications to the design of the objective function that was discussed previously in this paper.

Any live cell with fewer than two live neighbors dies, as if caused by underpopulation.

Any live cell with two or three live neighbors lives on to the next CA generation.

Any live cell with more than three live neighbors dies, as if by overpopulation.

Any dead cell with exactly three live neighbors becomes a live cell, as if by reproduction.
GOL truth table
Result  Living neighbors  Dead neighbors  Neighbor count 

White  0  8  2040 
White  1  7  1785 
No change  2  6  1530 
Black  3  5  1275 
White  4  4  1020 
White  5  3  765 
White  6  2  510 
White  7  1  255 
White  8  0  0 
The above table has four distinct result bands. The cell becomes white for 0 to 1 living neighbors, no change for 2, black for 3, and white again for 4 to 8 living neighbors. There are three distinct outcomes for every cell on the grid: change the cell to black, change the cell to white, or leave the cell at its current value. By its definition, GOL contains only white or black cells—dead or living. Therefore the percent column for every subrule that sets a cell to black/white will use 100%. The subrule that does not affect the current state of the cell (GOL survived) will use a percent value of 0% to simply leave the existing value alone. In addition to these 3 subrules a fourth is needed. As can be seen from Table 5 there are two overlapping bands where a white value must be explicitly set: 0 or 1 neighbors and 4 or more neighbors. Because of this, it is necessary to assign the cyan subrule a negative percent to cause it to target the next keycolor—white. This is why it was necessary to have the ability to map multiple subrules to the same keycolor to achieve GOL with white and black pixels.
The GOL update rule makes use of the white, black, red and cyan keycolor subrules. The white and black subrules specify when a cell should be moved to either white or black. The cyan subrule handles the additional white band. The red subrule has a 0 percent and therefore specifies that a cell should survive (not change). The algorithm does not use the other subrules and as a result they have percent and range values set to zero. Transitions in both directions between black and white are absolute, therefore the only absolute values for percent are 100% or 0%.
The ranges specify the number of neighbors present for each transformation. MergeLife will take the average RGB colors for each cell to compare against each row’s range. Each neighbor that is white will be 255, because white is RGB [255, 255, 255]. Likewise each neighbor that is black will be 0 [0, 0, 0]. This requires looking at neighbor counts backwards, because the neighbor count will be of the dead/white neighbors, not the living/black neighbors. A cell that had no living neighbors has a MergeLife neighbor count of 2040. Similarly, a cell that had all living neighbors has a neighbor count of 0, as indicated by Table 5.
The white subrule range of 0–1023 specifies between 0–4 dead neighbors. This is equivalent to 4 or more living neighbors. Such a condition will be set to white. This is equivalent to GOL’s overpopulation transition.
The black row range of 1024–1279 specifies 5 dead neighbors. This is equivalent to 3 living neighbors. Such a condition will be set to black. This is equivalent to GOL’s birth transition.
The red row range of 1280–1535 specifies 6 dead neighbors. This is equivalent to 2 living neighbors. Such a condition will be left as it is. This is equivalent to GOL’s survival transition.
Finally, the cyan row’s range of 1536–2047 specifies 7 or more dead neighbors. This is equivalent to 1 or fewer living neighbors. Such a condition will be set to white, due to the cyan subrule’s negative percent. This is equivalent to GOL’s underpopulation transition.
Decoded GOL update rule (a07fc0000000000000000000ff80807f)
High (\(\varvec{\alpha }\))  Range  Keycolor  Pct.(\(\varvec{\beta }\)) (%)  Index (\(\varvec{\gamma }\))  Octet1  Octet2 

0  NA  Green  0  3 (green)  00 (0)  00 (0) 
0  NA  Yellow  0  4 (yellow)  00 (0)  00 (0) 
0  NA  Blue  0  5 (blue)  00 (0)  00 (0) 
0  NA  Purple  0  6 (purple)  00 (0)  00 (0) 
1024  0–1023  White  100  8 (white)  80 (128)  7f (127) 
1280  1024–1279  Black  100  1 (black)  a0 (160)  7f (127) 
1536  1280–1535  Red  0  2 (red)  c0 (192)  00 (0) 
2048  1536–2047  White  − 100  7 (cyan)  ff (255)  80 (− 128) 
8 Related work
The unique contribution of this paper is the automatic production of generative art through the use of a CA evolved from an objective function that can be customized to what the individual user considers visually appealing. It is also important to note that the generative art is considered to be the animation produced by a running CA, not simply a single image frame. The humanuser provides initial guidance to the objective function; however, the algorithm’s performance is not hindered by needing human interaction while running. Related work in the area of generative art is considerable; however, the algorithm presented in this paper builds upon the related work described in this section.
Several projects employ humanoperators as the primary component of the objective function for evolved generative art. An early example of humanoperator guided evolution of CA rules, presented by Sims [43], used a GA to evolve CA update rules. The method employed by Sims differs from MergeLife in that it is monochrome and requires the humanuser to evaluate the CA at every GA step. Picbreeder [40, 41] is a website that evolves still images using CPPNs and an objective function that is guided by Internet users. A related project, Endless Forms [7] allows Internet users to direct CPPNs to evolve objects to be created by a 3D printer. Both of these techniques require human interaction for each GP generation. The Capow [39] project evolves continuous valued CA from wave equations to produce a variety of visually interesting still images.
The generation of CA update rules is a natural application to evolutionary algorithms [31]. Evolutionary programming has been applied to the CA [6, 25]. Morphogenesis is a problem that has CA rule evolution applications [6, 34, 43]. While Picbreeder and Endless Forms made use of CPPNs to actually produce generative art, it is also possible to use CPPNs as the update rule of a CA. Nichele, Ose, Risi, and Tufte [34] employed a NeuroEvolution of Augmenting Topologies (NEAT) [46] GA to evolve CA update rules as a solution to morphogenesis and replication. Because a neural network is the update rule for such a CA their update rule becomes complex. One of the goals for MergeLife was to allow the update rule to be represented in a short string that is executed by a relatively simple program.
Biological plants are a frequent source of inspiration for artificial life based artistic algorithms. Lindenmayer Systems (LSystems) [26, 36] describe the behavior of plant cells and model the growth processes of plant development. LSystem based algorithms have been adapted beyond their 2D origins to 3D [4]. These artificial plants are similar to MergeLife in the fact that the animation of their growth and progression is often considered either all or part of the resulting creative artifact.
A number of projects evolved update rules to cause the CA to produce output that closely matches specific training data. Evolutionary algorithms evolved rules [59] for the standard formulation of the density classification problem. Research has also shown that evolutionary algorithms can fit CA rules to achieve specific result data from a CA [47]. The researchers were able to reproduce Wolfram ECA Rule 126 from only its output. Though similar, these techniques are not useful to evolve update rules for a generative art producing CA because we do not have data that specifically describes what the output of the generative art CA will actually look like.
Objective function design is one of the most complex aspects of any evolutionary algorithm [27, 45]. Wolfram’s four classes of CA [57] lack the granularity needed for an objective function to effectively sort a population. Other techniques make use of an existing image to guide the evolution [17, 34, 42]. MergeLife evolves update rules based on multiple objectives governed by human subjective weightings of several statistical measures over multiple CA generations.
9 Conclusions and next steps
We have already translated MergeLife into several computer programming languages, which are available on GitHub. Currently MergeLife is available in Python, Java, and JavaScript. The Java version of MergeLife uses an Encog GA [16]. Contributions of code ported to other languages are welcome and can be submitted via GitHub. The current Python implementation achieves decent performance through the use of Numpy [52] and Scipy [20]. More advanced, GPUenabled frameworks such as TensorFlow [1] would likely enhance performance. TensorFlow can also offload some of the computation work to Graphical Processing Units (GPUs) which could be well aligned with MergeLife calculation needs.
The current code base for MergeLife uses a finite grid of cells. Conceptually, GOL is often described in terms of updating a grid of cells. Though easy to understand, this implementation has two flaws. The first flaw is that all processing must be contained inside of this fixed grid. If part of the pattern moves outside of the fixed grid, that part of the pattern will be lost. The second limitation is that even though much of the grid might be empty, the GOL update rule must recalculate the entire grid. These limitations led to the development of the HashLife algorithm [14]. The HashLife algorithm, developed for GOL, could be applied to MergeLife to provide both performance improvements as well as an infinite grid.
MergeLife currently uses a 2D, rectangular grid, with a Moore Neighborhood. Expansion of these design characteristics would not be difficult. Moving from 2D to 3D, or higher, would involve a change to the neighbor count. Other lattice types could also be employed and would require corresponding changes to the grid storage and neighbor counting. Both the neighborhood radius and type could be changed, requiring corresponding changes to the neighbor count function.
MergeLife could benefit from further refinement of the objective function. The objective function is noisy due to the random initial states of the grid. A better objective score might be achieved by considering neighboring GA population members [29]. This includes both fully automated objective functions and hybrid human supplemented objective functions. Automatic objective functions could be created that detect spaceships, guns, rakes, oscillators, and other desirable features. Detection of such features could be added to the current set of statistics that are calculated by the current multiobjective function. This could involve interaction with the user as the objective function evaluates more and more cases. Allowing the user to add their own objective weightings to the top members of the population could allow even further refinement upon the specific aesthetic qualities that a user is looking for.
Novelty search has recently been incorporated into a number of artistic optimization problems [50]. It might be possible to search for more novel update rules than the ones previously discovered. The hexadecimal strings for many MergeLife update rules appear quite different, yet produce very similar visual patterns. Additionally, the study of individual MergeLife update rules could yield information about other patterns supported and Turing Completeness. Many of the interesting patterns discovered by GOL are engineered and do not occur naturally from a random grid initialization. Similar engineering might create interesting structures for MergeLife update rules such as Yellow World (Fig. 4).
Footnotes
Notes
References
 1.M. Abadi, P. Barham, J. Chen, Z. Chen, A. Davis, J. Dean, M. Devin, S. Ghemawat, G. Irving, M. Isard, Tensorflow: a system for largescale machine learning. OSDI 16, 265–283 (2016)Google Scholar
 2.A. Adamatzky, G.J. Martínez, Designing Beauty: The Art of Cellular Automata, vol. 20 (Springer, Berlin, 2016)CrossRefGoogle Scholar
 3.B. Alexander, J. Kortman, A, Neumann, Evolution of artistic image variants through feature based diversity optimisation, in Proceedings of the Genetic and Evolutionary Computation Conference (ACM, New York, 2017), pp. 171–178Google Scholar
 4.S. Bergen, B.J. Ross, Aesthetic 3d model evolution. Genet. Program. Evolvable Mach. 14(3), 339–367 (2013)CrossRefGoogle Scholar
 5.E. Berkelamp, J.H. Conway, R.K. Guy, WinningWays for Your Mathematical Plays (Academic Press, London, 1982)Google Scholar
 6.A. Chavoya, Y. Duthen, Using a genetic algorithm to evolve cellular automata for 2d/3d computational development, in Proceedings of the 8th Annual Conference on Genetic and Evolutionary Computation (ACM, New York, 2006), pp. 231–232Google Scholar
 7.J. Clune, H. Lipson, Evolving threedimensional objects with a generative encoding inspired by developmental biology, in ECAL (2011), pp. 141–148Google Scholar
 8.S. Colton, Creativity versus the perception of creativity in computational systems, in AAAI Spring Symposium: Creative Intelligent Systems, vol. 8 (2008)Google Scholar
 9.S. Colton, J.W. Charnley, A. Pease, Computational creativity theory: the face and idea descriptive models, in ICCC (2011), pp. 90–95Google Scholar
 10.M. Cook, Universality in elementary cellular automata. Complex Syst. 15(1), 1–40 (2004)MathSciNetzbMATHGoogle Scholar
 11.K.M. Evans, Larger than life: digital creatures in a family of twodimensional cellular automata, in DMCCG (2001), pp. 177–192Google Scholar
 12.K.M. Evans, Larger than life: thresholdrange scaling of lifes coherent structures. Phys. D Nonlinear Phenom. 183(1), 45–67 (2003)MathSciNetCrossRefzbMATHGoogle Scholar
 13.M. Gardner, The fantastic combinations of John Conway’s new solitaire game life. Sci. Am. 223, 120–123 (1970)CrossRefGoogle Scholar
 14.R.W. Gosper, Exploiting regularities in large cellular spaces. Phys. D Nonlinear Phenom. 10(1–2), 75–80 (1984)CrossRefGoogle Scholar
 15.D.A. Hart, Toward greater artistic control for interactive evolution of images and animation, in Workshops on Applications of Evolutionary Computation (Springer, Berlin, 2007), pp. 527–536Google Scholar
 16.J. Heaton, Encog: library of interchangeable machine learning models for java and c#. J. Mach. Learn. Res. 16, 1243–1247 (2015)MathSciNetzbMATHGoogle Scholar
 17.E.D. Heijer, A. Eiben, Using scalable vector graphics to evolve art. Int. J. Arts Technol. 9(1), 59–85 (2016)CrossRefGoogle Scholar
 18.T.J. Hutton, Evolvable selfreproducing cells in a twodimensional artificial chemistry. Artif. Life 13(1), 11–30 (2007). https://doi.org/10.1162/artl.2007.13.1.11 MathSciNetCrossRefGoogle Scholar
 19.C.G. Johnson, Fitness in evolutionary art and music: a taxonomy and future prospects. Int. J. Arts Technol. 9(1), 4–25 (2016)CrossRefGoogle Scholar
 20.E. Jones, T. Oliphant, P. Peterson, et al., SciPy: open source scientific tools for Python (2001–). http://www.scipy.org/
 21.A. Jordanous, A standardised procedure for evaluating creative systems: computational creativity evaluation based on what it is to be creative. Cogn. Comput. 4(3), 246–279 (2012)CrossRefGoogle Scholar
 22.A. Jordanous, Four PPPPerspectives on computational creativity, in AISB 2015 Symposium on Computational Creativity (2015), pp. 16–22Google Scholar
 23.K. Kaneko, Pattern dynamics in spatiotemporal chaos: pattern selection, diffusion of defect and pattern competition intermettency. Phys. D Nonlinear Phenom. 34(1–2), 1–41 (1989)CrossRefzbMATHGoogle Scholar
 24.A. Kosorukoff, Human based genetic algorithm, in 2001 IEEE International Conference on Systems, Man, and Cybernetics, vol. 5 (IEEE, 2001), pp. 3464–3469Google Scholar
 25.M. Lewis, Evolutionary visual art and design, in The Art of Artificial Evolution, ed. by J. Romero, P. Machado (Springer, Berlin, 2008), pp. 3–37CrossRefGoogle Scholar
 26.A. Lindenmayer, Mathematical models for cellular interactions in development I. Filaments with onesided inputs. J. Theor. Biol. 18(3), 280–299 (1968)CrossRefGoogle Scholar
 27.P. Machado, T. Martins, H. Amaro, P.H. Abreu, An interface for fitness function design, in International Conference on Evolutionary and Biologically Inspired Music and Art (Springer, Berlin, 2014), pp. 13–25Google Scholar
 28.O. Martin, A.M. Odlyzko, S. Wolfram, Algebraic properties of cellular automata. Commun. Math. Phys. 93(2), 219–258 (1984)CrossRefzbMATHGoogle Scholar
 29.R. Miikkulainen, H. Shahrzad, N. Duffy, P. Long, How to select a winner in evolutionary optimization? in Proceedings of the IEEE Symposium Series in Computational Intelligence (IEEE, 2017)Google Scholar
 30.M. Mitchell, An Introduction to Genetic Algorithms (MIT Press, Cambridge, 1998)zbMATHGoogle Scholar
 31.M. Mitchell, J.P. Crutchfield, R. Das, Evolving cellular automata with genetic algorithms: a review of recent work, in Proceedings of the First International Conference on Evolutionary Computation and Its Applications (EvCA’96) (Russian Academy of Sciences, Moskva, 1996)Google Scholar
 32.A. Neumann, B. Alexander, F. Neumann, Evolutionary image transition using random walks, in International Conference on Evolutionary and Biologically Inspired Music and Art (Springer, Berlin, 2017), pp. 230–245Google Scholar
 33.C.P. Newland, H.R. Maier, A.C. Zecchin, J.P. Newman, H. van Delden, Multiobjective optimisation framework for calibration of cellular automata landuse models. Environ. Model. Softw. 100, 175–200 (2018)CrossRefGoogle Scholar
 34.S. Nichele, M.B. Ose, S. Risi, G. Tufte, CANEAT: evolved compositional pattern producing networks for cellular automata morphogenesis and replication. IEEE Trans. Cogn. Dev. Syst. (2017). https://doi.org/10.1109/TCDS.2017.2737082 Google Scholar
 35.M.C. Olmedo, Multiobjective land allocation (MOLA), in Geomatic Approaches for Modeling Land Change Scenarios, ed. by M.T. Camacho Olmedo, M. Paegelow, J.F. Mas, F. Escobar (Springer, Berlin, 2018), pp. 457–460CrossRefGoogle Scholar
 36.P. Prusinkiewicz, A. Lindenmayer, The Algorithmic Beauty of Plants (Springer, Berlin, 2012)zbMATHGoogle Scholar
 37.S. Rafler, Generalization of Conway’s “game of life” to a continuous domainsmoothlife. arXiv preprint arXiv:1111.1567 (2011)
 38.P. Rendell, Turing Machine Universality of the Game of Life (Springer, Berlin, 2016)CrossRefzbMATHGoogle Scholar
 39.R. Rucker, ContinuousValued Cellular Automata in Two Dimensions (Oxford University Press, Oxford, 2003)Google Scholar
 40.J. Secretan, N. Beato, D.B. D Ambrosio, A. Rodriguez, A. Campbell, K.O. Stanley, Picbreeder: evolving pictures collaboratively online, in Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (ACM, New York, 2008), pp. 1759–1768Google Scholar
 41.J. Secretan, N. Beato, D.B. D’Ambrosio, A. Rodriguez, A. Campbell, J.T. FolsomKovarik, K.O. Stanley, Picbreeder: a case study in collaborative evolutionary exploration of design space. Evol. Comput. 19(3), 373–403 (2011)CrossRefGoogle Scholar
 42.J.K. Shin, Application of Cellular Automata for a Generative Art System (Leonardo, Cambridge, 2016)Google Scholar
 43.K. Sims, Interactive evolution of dynamical systems, in Toward a Practice of Autonomous Systems: Proceedings of the First European Conference on Artificial Life (1992), pp. 171–178Google Scholar
 44.K.O. Stanley, Compositional pattern producing networks: a novel abstraction of development. Genet. Program. Evolvable Mach. 8(2), 131–162 (2007)CrossRefGoogle Scholar
 45.K.O. Stanley, J. Lehman, Why Greatness Cannot be Planned: The Myth of the Objective (Springer, Berlin, 2015)CrossRefGoogle Scholar
 46.K.O. Stanley, R. Miikkulainen, Evolving neural networks through augmenting topologies. Evol. Comput. 10(2), 99–127 (2002)CrossRefGoogle Scholar
 47.X. Sun, P.L. Rosin, R.R. Martin, Fast rule identification and neighborhood selection for cellular automata. IEEE Trans. Syst. Man Cybern. Part B (Cybern.) 41(3), 749–760 (2011)CrossRefGoogle Scholar
 48.H. Takagi, Interactive evolutionary computation: fusion of the capabilities of EC optimization and human evaluation. Proc. IEEE 89(9), 1275–1296 (2001)CrossRefGoogle Scholar
 49.A. Tantoushian, Scaling larger than life bugs: to range 25 and beyond. Ph.D. thesis, California State University, Northridge (2017)Google Scholar
 50.A. Vinhas, F. Assunção, J. Correia, A. Ekárt, P. Machado, Fitness and novelty in evolutionary art, in International Conference on Evolutionary and Biologically Inspired Music and Art (Springer, Berlin, 2016), pp. 225–240Google Scholar
 51.J. Von Neumann, A.W. Burks, Theory of selfreproducing automata. IEEE Trans. Neural Netw. 5(1), 3–14 (1966)Google Scholar
 52.S. Walt, S.C. Colbert, G. Varoquaux, The numpy array: a structure for efficient numerical computation. Comput. Sci. Eng. 13(2), 22–30 (2011)CrossRefGoogle Scholar
 53.E.W. Weisstein, Elementary cellular automaton. From MathWorld—a wolfram web resource. http://mathworld.wolfram.com/ElementaryCellularAutomaton.html. Last visited on 11/6/2017
 54.M. Wojtówicz, Cellular automata rules lexicon. http://psoup.math.wisc.edu/mcell/rullex_lgtl.html. Last visited on 11/6/2017
 55.S. Wolfram, Cellular automata. Los Alamos Sci. 9, 2–27 (1983)Google Scholar
 56.S. Wolfram, Statistical mechanics of cellular automata. Rev. Mod. Phys. 55(3), 601 (1983)MathSciNetCrossRefzbMATHGoogle Scholar
 57.S. Wolfram, A New Kind of Science, vol. 5 (Wolfram Media, Champaign, 2002)zbMATHGoogle Scholar
 58.S. Wolfram et al., Theory and Applications of Cellular Automata, vol. 1 (World Scientific, Singapore, 1986)zbMATHGoogle Scholar
 59.D. Wolz, P.P. De Oliveira, Very effective evolutionary techniques for searching cellular automata rule spaces. J. Cell. Autom. 3(4), 289–312 (2008)MathSciNetzbMATHGoogle Scholar
Copyright information
Open AccessThis article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.