Hey, remember that puzzle game I was working on? No? Well, a version of it is coming out regardless! Marble Warble is a puzzle game based on block cellular automata! See if you can find a set of rules that the marble can follow to reach the goal!
A brief gif of a puzzle game I've been working on for Pico-8! The working title for now is Morble-Worble. In it, the player must find a set of rules to control the movement of a marble, navigating it through puzzles to the goal flag.
In addition to pre-made levels to teach the basics and give increasingly difficult challenges, there will also be a number of ways for players to make and share their own levels! Aside from the 3 slots of memory for user-made levels; it'll also be possible to load levels from specially formatted text. I'm especially excited for a feature development for Pico-8 which will allow sharing levels in the game online (similar to something like mario maker)!
Implementing a kind of "attribute block" style of rendering similar to the ZX Spectrum in Pico-8. The screen is divided into a grid of 16 by 16 attribute blocks that each have a primary and secondary color. The screen as a whole also has its own background color. Pixels can therefore be one of 4 values: transparent, background, primary, or secondary. Not exactly like the Spectrum, but produces similar results.
Here I'm using attribute block that have both their primary and secondary colors set to black as a kind of free space which moving sprites are allowed to update as they pass through. Otherwise they'll take on whatever colors are already set for that block.
My latest toy project has been a hybrid simulation that takes the classical Moore neighborhood cellular automata, and combines it with the slightly unusual block cellular automata (all on a hexagonal grid). Here’s an example (using a square grid for convenience).
More on how this works below the cut:
Before I discuss the simulation itself. I want to show this little graphic to explain how hexagonal grids are actually just a square grid of cubes in disguise.
The “why” for doing this is the (x,y) coordinate system, which makes storing and working with the data much simpler. With that out of the way, let’s move on.
One of the most common types of cellular automata produces the output for the next state of the simulation by iterating over every “cell” in a grid and determining what it’s new value will be based on the values of its neighbors.
There are many ways to determine how this works. For instance, in Conway’s Game of Life the rules are as follows: any “living” cell remains living if it has 2 or 3 living neighbors, and dies otherwise, any “dead” cell with exactly 3 living neighbors becomes alive and remains dead otherwise. This is generally done on a square grid where each cell has 8 neighbors in total, but for our example we’ll use a hexagonal grid (represented on a square grid by ignoring 2 of the neighbors for each cell).
The above animation uses the following string to define its rules: “F.F..T.F.5;6;7;15;16;17;18;19;20”. We’ll get into what this means later, but it roughly defines the rules we outlined earlier. However, this only covers half of the functionality of the simulation.
A different kind of automata is the block automata, which takes groups of cells and translates them all together in a “block”. After that is done is shifts the frame of reference so now different cells are grouped into blocks, and then repeats.
One of the easiest ways to do this translation is to have a big table where you can look up a specific pattern of cells and output the other pattern that is matched with it.
The above animation uses the following rule set: “T.T.1,2;2,18;3,66;4,34;5,82;6,50;7,70;8,54;9,86;10,114;11,118;14,10;15,26;16,74;17,42;18,90;19,58;20,78;21,62;22,94;23,122;24,126;27,4;28,5;29,6;30,20;32,7;33,21;34,70;35,85;36,71;37,23;38,87;40,12;41,13;42,14;43,28;44,15;45,29;46,78;47,93;48,79;49,31;50,95.T.T.”, and here is where we can begin to talk about what each part of this actually means.
Each section is separated by a “.”, the first section being whether the look up table for block transitions has symmetry (T for yes F for no). What we mean by symmetry in this case is whether a set of patterns that can be turned into one another by simply rotating or mirroring the image should use the same rule or different rules. If we treat every pattern as unique with its own rule, then there is a total of 2^7 (or 128) rules because there are 7 cells in each block and 2 options for every cell. If we group similar patterns together then there are only 26 rules (13 for the rotations with the middle cell off and another 13 for the rotations with the middle cell on).
The second part (another T/F option), determines whether we preserve orientation when using symmetrical rules. Let’s say we have a block that is just the pattern 1 rotated right by one cell.
The rule then might be to change all pattern 1’s to this:
And if we weren’t preserving orientation, then this would be enough. However, if we are preserving orientation, then we must remember that the input was rotated to the right by one cell, so we must do the same to the output before we are done.
So, with the first two settings, we’ve defined how the table will be used, but it only has default values in it which won’t actually change anything. The next part of the is a list of patterns and their outputs (but only the ones that differ from the default). The above example takes each symmetry pattern and outputs a value representing a slightly rotated example of that pattern.
The next setting (once again a T/F), is whether the cell transitions are symmetrical. It is essentially the same thing as the block symmetry setting.
After that is a setting to determine what the default values for cell transitions should be. When “F”, the default value will be Off, and when “T” the default value will be whatever the input value was (i.e. the middle cell in a pattern).
Finally, the last setting is a list of rules that are the opposite of their default value (On instead of Off and vice versa).
Used altogether we might get a string like: “T.T.1,2;2,18;3,66;4,34;5,82;6,50;7,70;8,54;9,86;10,114;11,118;14,10;15,26;16,74;17,42;18,90;19,58;20,78;21,62;22,94;23,122;24,126;27,4;28,5;29,6;30,20;32,7;33,21;34,70;35,85;36,71;37,23;38,87;40,12;41,13;42,14;43,28;44,15;45,29;46,78;47,93;48,79;49,31;50,95.T.F.5;6;7;15;16;17;18;19;20” Which is the rules that resulted in the animation at the top of this post!
One addendum to the explanation: Red/Black blocks can use a different set of cell transition rules than the White/Cyan blocks, and that's how the Block part of the simulation can influence the cell portion. For instance, in the demonstration gif, White/Blue blocks rotate one to the right, and Red/Black blocks rotate one to the left!
My latest toy project has been a hybrid simulation that takes the classical Moore neighborhood cellular automata, and combines it with the slightly unusual block cellular automata (all on a hexagonal grid). Here’s an example (using a square grid for convenience).
More on how this works below the cut:
Before I discuss the simulation itself. I want to show this little graphic to explain how hexagonal grids are actually just a square grid of cubes in disguise.
The “why” for doing this is the (x,y) coordinate system, which makes storing and working with the data much simpler. With that out of the way, let’s move on.
One of the most common types of cellular automata produces the output for the next state of the simulation by iterating over every “cell” in a grid and determining what it’s new value will be based on the values of its neighbors.
There are many ways to determine how this works. For instance, in Conway’s Game of Life the rules are as follows: any “living” cell remains living if it has 2 or 3 living neighbors, and dies otherwise, any “dead” cell with exactly 3 living neighbors becomes alive and remains dead otherwise. This is generally done on a square grid where each cell has 8 neighbors in total, but for our example we’ll use a hexagonal grid (represented on a square grid by ignoring 2 of the neighbors for each cell).
The above animation uses the following string to define its rules: “F.F..T.F.5;6;7;15;16;17;18;19;20”. We’ll get into what this means later, but it roughly defines the rules we outlined earlier. However, this only covers half of the functionality of the simulation.
A different kind of automata is the block automata, which takes groups of cells and translates them all together in a “block”. After that is done is shifts the frame of reference so now different cells are grouped into blocks, and then repeats.
One of the easiest ways to do this translation is to have a big table where you can look up a specific pattern of cells and output the other pattern that is matched with it.
The above animation uses the following rule set: “T.T.1,2;2,18;3,66;4,34;5,82;6,50;7,70;8,54;9,86;10,114;11,118;14,10;15,26;16,74;17,42;18,90;19,58;20,78;21,62;22,94;23,122;24,126;27,4;28,5;29,6;30,20;32,7;33,21;34,70;35,85;36,71;37,23;38,87;40,12;41,13;42,14;43,28;44,15;45,29;46,78;47,93;48,79;49,31;50,95.T.T.”, and here is where we can begin to talk about what each part of this actually means.
Each section is separated by a “.”, the first section being whether the look up table for block transitions has symmetry (T for yes F for no). What we mean by symmetry in this case is whether a set of patterns that can be turned into one another by simply rotating or mirroring the image should use the same rule or different rules. If we treat every pattern as unique with its own rule, then there is a total of 2^7 (or 128) rules because there are 7 cells in each block and 2 options for every cell. If we group similar patterns together then there are only 26 rules (13 for the rotations with the middle cell off and another 13 for the rotations with the middle cell on).
The second part (another T/F option), determines whether we preserve orientation when using symmetrical rules. Let’s say we have a block that is just the pattern 1 rotated right by one cell.
The rule then might be to change all pattern 1’s to this:
And if we weren’t preserving orientation, then this would be enough. However, if we are preserving orientation, then we must remember that the input was rotated to the right by one cell, so we must do the same to the output before we are done.
So, with the first two settings, we’ve defined how the table will be used, but it only has default values in it which won’t actually change anything. The next part of the is a list of patterns and their outputs (but only the ones that differ from the default). The above example takes each symmetry pattern and outputs a value representing a slightly rotated example of that pattern.
The next setting (once again a T/F), is whether the cell transitions are symmetrical. It is essentially the same thing as the block symmetry setting.
After that is a setting to determine what the default values for cell transitions should be. When “F”, the default value will be Off, and when “T” the default value will be whatever the input value was (i.e. the middle cell in a pattern).
Finally, the last setting is a list of rules that are the opposite of their default value (On instead of Off and vice versa).
Used altogether we might get a string like: “T.T.1,2;2,18;3,66;4,34;5,82;6,50;7,70;8,54;9,86;10,114;11,118;14,10;15,26;16,74;17,42;18,90;19,58;20,78;21,62;22,94;23,122;24,126;27,4;28,5;29,6;30,20;32,7;33,21;34,70;35,85;36,71;37,23;38,87;40,12;41,13;42,14;43,28;44,15;45,29;46,78;47,93;48,79;49,31;50,95.T.F.5;6;7;15;16;17;18;19;20” Which is the rules that resulted in the animation at the top of this post!
yousharknotpass
pixelskylines
romaincrisis
snowghoul
theartofmadeline