drummyfish/less_retarded_wiki
5
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Update

Browse source
This commit is contained in:
Miloslav Ciz 2023-11-26 21:32:39 +01:00
parent 8899b4ff7f
commit 5d2126a4ee
6 changed files with 50 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

38
game_of_life.md
View file

@ -41,6 +41,8 @@ The following is a sum up of some basic properties of the game, many of which sh
- It is very fun to play around with. There are many creatures to discover, observe and document (making this kind of a Pokémon game lol?).
- ...
**Where to try it out?** You can easily write your own game of life simulator, it's very simple -- you can even just copy paste the code below ;) However a nice, more advanced [FOSS](foss.md) program is e.g. [Golly](golly.md).
## Rules
We have an [infinite](infinity.md), regular two dimensional grid of cells, each of which may be in one of two states: alive or dead. Each cell considers its nearest eight cells its neighbors. The game runs in discrete steps, or rounds. Every round each cell counts its neighbors' states and will set its state for the next round according to these rules:
@ -54,10 +56,34 @@ This is basically it as for the definition of rules -- as we can see, the game i
## Rule Implications And Properties
There are thousands of documented structures, kind of "life forms" or "species" behaving in interesting ways, that can exist in game of life, some appear commonly and naturally (from a randomly initialized start state), some are rare and often have to be manually created. Common classes of such structures include **still life** (structures that persist and won't disappear on their own, some may just persist without even changing -- possibly simplest such structure is a 2x2 block of live cells), **oscillators** (structures that stay in place and periodically change their appearance, one of the simplest is blinker, a 1x3 block of live cells) and **space ships** (structures moving through space on their own, one of the simplest and most famous is glider), further include for example **guns** (structures that produce, or "shoot" space ships). Some patterns can [self replicate](self_replication.md) (create an identical copy of themselves), some can [grow without limit](cancer.md).
There are thousands of documented structures, kind of "life forms" or "species" behaving in interesting ways, that can exist in game of life, some appear commonly and naturally (from a randomly initialized start state), some are rare and often have to be manually created. Common classes of such structures include **still life** (structures that persist and won't disappear on their own, some may just persist without even changing -- possibly simplest such structure is a 2x2 block of live cells), **oscillators** (structures that stay in place and periodically change their appearance, one of the simplest is blinker, a 1x3 block of live cells) and **space ships** (structures moving through space on their own, one of the simplest and most famous is glider), further include for example *guns* (structures that produce, or "shoot" space ships), *puffers* (kind of spaceships that leave a trail behind them), *waves*, *rotors*, *crawlers* etc. Some patterns can [self replicate](self_replication.md) (create an identical copy of themselves), some can [grow without limit](cancer.md). Here are some basic life structures:
```
[] [] [][] [][] [][]
[] [][] [] [] [] [] []
[][][] [][] [] [][] [][] [][]
glider block blinker beehive mirrored table
[][] [][][][] [][]
[][] [] [] []
[] []
[][][][] [] [] [][]
[][] [] []
[][] [][] [] lightweight beacon
[] [] [] [][] spaceship
[] [] [] [][] [][]
[][][][] []
[]
[][] pin wheel [][]
[][] toad
```
A typical run of the game from a randomly initialized grid looks a bit similar to the evolution of our [Universe](universe.md): initially (after the [Big Bang](big_bang.md)) the world exhibits a [chaotic](chaos.md) behavior, looking like a random noise of cells switching on and off seemingly without order, then, after a short while, more orderly patterns of the three basic kinds (still lives, oscillators and space ships) emerge and start interacting, either by being too close to each other or by shooting space ships and hitting each other -- this is a kind of "golden age" of life (interesting events, for example spontaneous emergences of [symmetry](symmetry.md)). After some time this usually settles on a repeating set of states with just still life and oscillators, far enough from each other to influence each other (a kind of heat death of the universe).
Staying at analogies with our Universe, game of life also recognizes its analogy to **[speed of light](speed_of_light.md)** (or *speed of life*), the fastest speed by which [information](information.md) can propagate through the game of life universe -- in the basic version this speed is simply one cell per turn (as any possible pattern, no matter how complex, can only ever influence its immediately neighboring cells in one turn). This speed is exploited by some algorithms to [optimize](optimize.md) the game's simulation.
As game of life is [Turing complete](turing_complete.md), some things about it are [undecidable](decidability.md), for example whether a given pattern will ever appear.
**Statistical properties**: the following experiments were performed in a world with 128x128 cells and wrapping space. From a random starting state with 50% live cells populations mostly seem to soon somewhat stabilize at around a little bit more than one third of cells being alive. The following shows 16 runs, noting percentage of live cells after each 256 steps (notice how in one case a population just dies out immediately and in another it very much struggles to stay alive):
@ -83,6 +109,8 @@ run 16: 50% 33% 39% 37% 34% 43% 32% 38% 36% 45% 32% 35% 28% 35% 32% 35% 43%
## Code/Programming
Programming a simple version of game of life is quite easy and may take just 10 minutes, however if we aim for greatly optimized efficiency (speed, memory) or features such as truly infinite space or reversible time, matters will of course get very complex. Let's start with the simple way.
The following is a simple [C](c.md) implementation of a [wrapping](wrap.md) version of game of life (i.e. the world is not actually infinite):
```
@ -175,7 +203,11 @@ int main(void)
The world cells are kept in the `world` array -- each cell holds the current state in the lowest bit. We perform drawing and update of the world at the same time. Notice especially that while updating the cells, we mustn't overwrite the cell's current state until its neighbors have been updated as well! Not realizing this is a **common beginner error** and results in so called [naive](naive.md) implementation. We avoid this error by first storing each cell's next state in the second lowest bit (keeping its current state in the lowest bit), and then, after all cells have been updated, we iterate over all cells again and perform one bit shift to the left (making the computed next states into current states).
TODO: extensions, continuous, code, optimizations
For real serious projects there exist highly optimized [algorithms](algorithm.md) such as [QuickLife](quicklife.md) and [HashLife](hashlife.md) -- if you are aiming to create a state-of-the-art program, check them out. Here we will not be discussing them further as the are beyond the scope of this article.
**Implementing infinite world:** it is possible to program the game so that the world has no boundaries (or possibly has boundaries imposed only by maximum values of the used integer [data type](data_type.md); these could of course be removed by using an advanced arbitrary size integer type). The immediate straightforward idea is to simply resize the world when we need more space, i.e initially we allocate some space to the world (let's say 128x128 cells) and once a cell comes to life outside this area we resize it by [allocating](memory_allocation.md) more memory -- of course this resizing should happen by some bigger step than one because the pattern will likely grow further (so we may resize e.g. from 128x128 right to 256x256). This can of course be highly inefficient, a single glider traveling far away in one direction may cause resizing the world to astronomical size; therefore more smartness can be applied, for example we may allocate spaces by big tiles (let's say 64x64) wherever they are needed (and of course deallocate/free the ones that no longer have any live cells) -- this will require a lot of code for managing the tiles and being able to actually quickly simulate such representation of the world. It would also be possible to have no world array at all but rather only keep a [list](list.md) of cells that are alive, each one storing its coordinates -- this might of course become inefficient for a big number of live cells, however good optimization could make this approach bearable; a basic optimization here would have to focus on very quick determination of each cell's neighbors, which could be achieved e.g. by keeping the list of the cells sorted (e.g. from northwestmost to southeastmost). Another idea (used e.g. by the QuickLife algorithm) is to use a dynamic [tree](tree.md) to represent the world.
Some basic **[optimization](optimization.md)** ideas are following: firstly, as shown in the code above, even though we could theoretically only allocate 1 bit for each cell, it is better to store each cell as a whole byte or possibly a whole integer (which will help memory alignment and likely speed up the simulation greatly) -- this also comes with the great feature of being able to store the current state in the lowest bit and older states in higher bits, which firstly allows rewinding time a few states back (which as seen below will be useful further) and secondly we don't need an extra array for performing the cell updates. Next, as another simplest optimization, we may try to skip big empty areas of the world during the update (however watch out for the border where a new cell can spawn due to a neighboring pattern). We may take this further and also skip areas that contain static, unchanging still life -- this could all be done e.g. by dividing the world into tiles (let's say 64x64) and keeping a record about each tile. This can be taken yet further and also detect e.g. periodically repeating still life (such as blinkers); if for example we know a tile contains pattern that repeats with period 2 and we are able to rewind time one step back (which we can easily do, as shown above), we can simply do this step back in time instead of simulating the whole cell. Next we may try to use [dynamic programming](dynamic_programming.md), e.g. [caches](caches.md) and [hash tables](hash_table.md) to keep results of recently performed big pattern simulations to reuse in the future, so that we don't have to simulate them again (i.e. for example remembering how a glider evolved from one frame to another so that next frame we simply copy-paste the result instead of actually simulating each cell again); HashLife algorithm is doing something like this. Also try to focus greatly on the [bottle necks](bottle_neck.md) such as counting the cell's neighbors -- it will be greatly worth it if you speed this code up, even for the cost of using more memory, i.e. consider things like loop unrolling, function inlining and [look up tables](lut.md) for counting the neighbors. Further speedup may be achieved by [parallelization](parallelism.md) ([multithreading](multithreading.md), [GPU](gpu.md), [SIMD](simd.md), ...) as isolated parts of the world may be simulated independently, though this will introduce hardware dependencies and [bloat](bloat.md) and is therefore discouraged.
## Extensions, Modifications And Generalizations
@ -186,5 +218,3 @@ Game of Life can be extended/generalized/modified in great number of ways, some
- **[Lenia](lenia.md)**: A relatively recent, highly generalized continuous version of Game of Life -- it is yet more generalized version of Smooth Life where all variables are continuous, including space, time and states, AND furthermore adds multiple channels ("plains" of existence that interact with each other). This system produces incredible patterns and great many organisms.
- **different grid geometry, more states, additional rules, ...**: Slight modifications one can make to experiment, e.g. trying out hexagonal grid, triangular grid, [hyperbolic space](hyperbolic.md), 3D and higher dimensional grids, more states (e.g. cells that remember their age) etc. Modifying the base rules is also possible, creating so called life-like automata: the basic game of life is denoted as B3/S23 (born with 3, stays alive with 2 or 3), some life-like variants include e.g. High Life which adds a rule that a dead cell with 6 live neighbors comes alive (B36/S23) -- this gives rise to a new pattern known as *replicator*.
TODO