Life

Share your Projects
, , ,
1

This is my version of Conway's Game of Life!

Here's how Conway's Game of Life works:
There are eight cells next to one singular cell.

  • If there are 2 or 3 neighboring cells next to a living cell, the cell will live.
  • If there are three neighboring cells next to a dead cell, the cell will come to life.
  • If there are fewer than two neighboring cells next to a living cell, the cell will die.
  • If there are more than three neighboring cells next to a living cell, the cell will die.
  • If there is a living cell where none of the above are true, the cell dies.

Cool, right?

:link: Project Link

2

Cool!I just wanted to make this yesterday!

Reasons I didn't make this yesterday:

  • Snap is fast,but not nearly as fast as WASM(golly)
  • I dk hashlife algorithm
  • Too busy on rocket simulator
3

I fixed a fatal bug making the simulation inaccurate.

4

Is it that you didn't use 2 lists and id them?

5

yeah i modified the list while making the changes which is a big nono when it comes to projects like these

6

i fixed it by isolating the changes in one list and reading the data from the original list. i can make gliders now!

7

do it! you said you were board! :slight_smile:

8

i had to work on rocket simulator now

9

I’m surprised I’ve never heard of it before, looks epic!

10

Pretty cool project, great show - congrats!

Wouldn't it be even greater if the glider didn't stop at the edge of the playing field?

Suppose the game were extended by surrounding the playing field with 8 virtual matrices, each consisting of 10x10 cells. At the end of each step (or generation) the contents of the playing field are (invisibly) copied onto each of the surrounding matrices. The values (0 or 1) of the cells immediately surrounding the playing field will be taken into account when calculating the next generation of the playing field's contents. Thus a glider leaving the playing field e.g. at the below right corner will simultaneously re-enter from the top left.

Finally, I am reporting a bug, or perhaps it's actually a maldocumented feature :wink: . The project notes say: "If the simulation runs into an infinite loop it cannot escape from, it will stop the simulation automatically and enter edit mode." In reality e.g. a blinker (; period: 2) will oscillate forever.

11

Yeah, I meant that if a pattern doesn't change in the next round, it stops.

12

"Torus manifold"
There can also be a R^2 manifold,where you separate the stuff into blochs and process each bloch(so no empty bloxh processing)

13

Update

Major updates:

  • The grid now has dynamic sizing
  • Grid size can now be adjusted easily by modifying the code
  • Performance update (It runs a lot smoother now!)

Notes:

  • Effects at the bottom screen have been removed to improve performance
  • The grid is drawn differently so that it draws quicker than the previous style
  • The program only checks the cells it needs to (to improve performance)
  • Because of all these performance updates, more extensive grids are easier to edit, and the simulation runs faster
  • Bug fixes
14

I added the ability of e.g. a glider to re-enter the playing field from the opposite rim or edge:

The only real difference with @joecooldoo’s original code is that I used a customized MOD-operator to transform e.g. (9, 11) or (0, 4) to (9, 1) and (10, 4), respectively:

Conway’s Life infinite playing field script pic

I applied this operator both within Conway’s Life infinite playing field script pic 2 and Conway’s Life infinite playing field script pic 3.

15

Good job; it seems you also accounted for the grid size.