infinifactory Conway's Game Of Life

Channel:

TroZ

Subscribers:

909

Published on May 3, 2015 2:46:52 AM ● Video Link: https://www.youtube.com/watch?v=ko09-uitYKA

Game:

Infinifactory (2015)

Duration: 25:29

1,533 views

15

A thread on Reddit inspired me to attempt to re-create Conway's Game of Life in Infinifactory. If you aren't deep into Infinifactory, then you will probably just want to skip this video, as this really doesn't go into any of the game's puzzles or solutions. More info below the fold.

Reddit thread: http://www.reddit.com/r/infinifactory/comments/33dj6x/the_most_elegant_cellular_automata_simulator_so/
Conway's Game of Life description: http://en.wikipedia.org/wiki/Conway%27s_Game_of_Life

I though the best way of simulating Conway's Game of Life in infinifactory would be to not use any input blocks and just simulate each cell using 'logic gates' build out of the sensors, conduits, pushers and blockers available in the game. This way, no matter how bit the field was, the only thing that would matter is the 'gate delay' of getting signals to and from the neighboring cells.

I believe I have built a life cell that is 17x17 blocks (and 15 blocks tall) which can be updated about once ever 10 or so cycles. It can be reprogrammed to follow other similar life like rules by adding or removing state sensors, although having cells be born or stay alive with more than 5 alive neighbors will take a little reworking of the cell, and may need a larger cell (as some conduits / pushers would be pushed outside the current cell size).

It works by having an input (sensor) in the four sides of the cell and in the four corners, with corresponding outputs that are pushers with blocks on their faces for triggering the sensors of neighboring cells. Each if these sensors are wired up to a central line of pushers, that push each other in a single direction, 8 in all, so that the total length indicates the amount of live neighbors. There is a 9th pusher, arranged perpendicular to the others, that is active if this cell is currently alive. on the face of this pusher is two platform blocks, which can trigger sensors above them. This results in the top platform blocks position indicating the total state of this cell and it's neighbor - on the right track, this cell is alive, and it's position along the track can be detected with sensors to indicate if it should remain alive based on the number of alive neighbors; on the left track, this cell is dead, and it's position along the the track can be detected with sensors to indicate if the cell should become alive (born) based upon the number of alive neighbors. By changing the number and position of the sensors, different rules can be implemented.

Because only one connected pusher / blocker can move at a time, and there are 9 of them connected here, it may take up to 9 cycles for the state to update based upon this cell's state and the neighboring cell's state, although in general not all neighboring cells will change state every 'step'. However, because a cell as it is changing state may pass through an 'alive' state on it's way from one 'dead' state to another, we cannot directly connect the 'alive' sensors to this cell's 'alive' display and neighbor signalling system. Therefor, I developed a simple D-Latch (Data Latch in digital circuits speak), that takes an input and a clock signal, and only copied the input to the output when the clock is active. In this way, all the cells in a big grid of cells (if you could make one!) can be triggered at the same time. I believe that this cell design could be safely triggered every 11 cycles (although a 12 clock is really simple to make and would be easier to implement) without running into timing issues.

What do you think of this design? Do you have improvements or suggestions? Leave a comment and let me know!

Other Statistics