🔒 Cellular automaton.

[river galleon]

I made this tiny project in Pygame, I am a begginner and started learning recently and any feedback would be appreciated. https://paste.pythondiscord.com/5GMRCWKDAGGGFTZOYM2IBPYQAQ

[still fossil]

@river galleon

Python help channel opened

Remember to:

• Ask your Python question, not if you can ask or if there's an expert who can help.
• Show a code sample as text (rather than a screenshot) and the error message, if you've got one.
• Explain what you expect to happen and what actually happens.

:warning: Do not pip install anything that isn't related to your question, especially if asked to over DMs.

Closes after a period of inactivity, or when you send !close.

[subtle isle]

My suggestion: extract your functions into a Grid() glass or similar, so you can run multiple automatons next to each other in different/disconnected worlds

[strange dagger]

Yes. oop is very useful when you are making big programs, and it's good practice when you're making small ones.

[river galleon]

ty, after I finished this I was acc looking to convert it into class based. And I acc made this (though I got some help on it and didnt do it all by myself so I didnt share originally)

[still fossil]

Click here to see this code in our pastebin.

[river galleon]

https://paste.pythondiscord.com/ZQPUJF3C5SDMRULL5QFHGHYZVQ

[lost pivot]

Conway's Game of Life is a great choice. That's actually the project I've been recommending to beginners here.

I'm on my phone, so I can't easily read the code. One easy fix, though, is you're currently calling copy to create the mirrored game state. Calling copy every update is super inefficient, though, and can eventually become a bottleneck because that's a relatively expensive operation. Instead, create two grid in the beginning: the read grid and the write grid. Write to the write grid while updating, and read from the read grid. Then, at the end of the update, swap the two grids. That way, you at most only every create two grids for the entire operation of the simulation.

Also, if you like CA's, look into Wireworld. It's probably my favorite CA:

https://en.wikipedia.org/wiki/Wireworld

[river galleon]

Thanks, I will definetly implement that. Is there a better way to store the history for replayability instead of making copies as well?

[scenic bane]

Well, since it's deterministic, if you have the starting state then you can replay it

[lost pivot]

Although reversing the rules would be an interesting challenge. I've never attempted that before.

I'm not even sure that's that's possible.

[scenic bane]

hmm several states can lead into the same one so I don't think it's possible

[lost pivot]

Ya, it's lossy.

[lost pivot]

The only possible optimization I can think of is storing the changes that were made so you can convert one state to a connecting state. That would be complex, though.

I've done this project like a dozen times and have never added a history/undo.

[scenic bane]

hmm, the difference between two states takes the same amount of space as the state itself, so I'm not sure it's better. Unless you meant something else

[lost pivot]

A sparse dictionary that only stores differences could be smaller assuming only a subset of cells change each generation.

You'd need to measure the differences though, because I wouldn't be surprised if it could also be larger in the case of many cells changing.

@river galleon Another cool feature is colours and inheriting. See the post of mine from 11 (!) years ago demonstrating the idea: https://codereview.stackexchange.com/questions/107844/full-color-clone-of-conways-game-of-life-with-a-decent-gui

[subtle isle]

You'd want frame snapshot replay

[lost pivot]

When a cell is born, it inherits the majority colour of its neighbors.

[river galleon]

oo thats interesting

[subtle isle]

Most game of life behaviors repeat after X frames, so store a snapshot, then it's repeat time and rapidly replay/skip a few frames forwards to get to the exact placement

[river galleon]

yea I finished the main thing then I just wanted to start adding stuff so I did a history cuz it was easy lol

[lost pivot]

I love getting to that stage of projects

[river galleon]

fr its so sattisfying when ur done with the main thing then it only takes a few minutes to add a feature (in my case since i did easy ones)

I'm going to eat then work to optimize a bit and will update!

[lost pivot]

One thing to watch out for is the fact that self.game_states is allowed to grow forever. This would eventually cause problems if you left a large simulation run for bit. Only keeping like the last 100 or so states would probably be better.

[river galleon]

but then you wont be able to go all the way back right?

[lost pivot]

Right. But every state you save takes up space. I would try leaving Task Manager open to see usage over time to see if this is a concern. You could also do something like only store at most N states, but those states are spread out over the entire life of the program, but you "trim" states from the middle as you reach the limit. That way, you can go back in time, but not to every frame

[river galleon]

I would like to keep the functionality where if wanted you could go all the way back to gen 1 from gen n. Also after 2000 generations it only increased by 3MB of mem usage

[lost pivot]

I meant that you keep periodic in between snapshots of the state, including the first state, but over time, you only store every, say 10th state, then every 100th, then every 1000th. But you're right. I'm testing it now, and it doesn't eat memory that fast.

Now that I've actually run it though, here are some extra thoughts:

• Setting up states is a pain. It would be nice to have a "randomize every cell state" option so you can just insta-create a state to get things going quickly. You could also allow "aliving" entire NxN blocks on mouse press, since I know from experience that that can set up complex states when combines with other shapes. You could even go as far as to allow dropping gliders and other known patterns on click.
• The 1-9 keys don't really make sense if those are just selecting from the first 9 frames. I see what you're going for, but if a simulation is going for hundreds of generations, the first 9 are functionally indistinguishable from each other. As a similar suggestion to the above one, the "jump" hotkeys should be closer to percentage jumps. So the 4 key, for example, jumps to 40% of the way through the simulation's history.

• It would be nice if dragging the mouse also drew. Dragging is an interesting complication because it typically requires saving some drag-state between mouse events.

[river galleon]

Yea, I just had the 1-9 to have it. Mostly I wanted to be able to go back to the first state but just made all the numbers do smth. Dragging and patterns are actually something I thought about and want to do, I just finished this a couple of days ago so havent done much lol. I like the idea to do like percentage based for number keys I will add that to the list of things to implement.

[lost pivot]

Good luck. This is a pretty fun project to do. I'll just throw out that some other fun projects I like are Mandelbrot Set explorers (what I used to create my avatar), WireWorld (which I mentioned above), and genetic algorithms. When you run out of ideas for your current project, I'd look into these.

[river galleon]

Tysm I will make sure to check them out after this one!

[still fossil]

Python help channel closed for inactivity

This help channel has been closed. Feel free to create a new post in #1035199133436354600. To maximize your chances of getting a response, check out this guide on asking good questions.