>> No implementation problem. Right now, only ~80x24 grids are life grids, and they aren't yet connected.

> That is disappointing.

Okay, I feel like this is some weird negative spin here. You will be able to have as large a finite area as you want. A single "life field generator" will support ~240x75. You will be able to have as many "life field generators" as you want. You will have to invest in in-game resources, though. It won't be pay to win. But it will serve to throttle the number of occupied grids.

"As large as you care to have" is fine and generous, I think. If you want "effectively and effortlessly infinite," I'll just leave that for someone else to pay for the server time.

> I think you could find other, more creative, ways to prevent infinitely growing formations from crashing the server.

Hey if you want to volunteer an implementation in Go, this is well travelled territory. You can look those algorithms up and implement them yourself. That's not my main focus, so I'll not spend the time right now. As for a game world, it's fine to let people mine resources and stake out as large a region as they care to. I'm going to do a Life-world sort of as an art project/portfolio piece. The Ultimate Shared Life World is just not my present goal. But who knows? We'll see where this leads.

> Okay, I feel like this is some weird negative spin here. You will be able to have as large a finite area as you want. A single "life field generator" will support ~240x75. You will be able to have as many "life field generators" as you want. You will have to invest in in-game resources, though. It won't be pay to win. But it will serve to throttle the number of occupied grids.

So with multiple LFGs you can create a larger linked active area? If so, color me no longer disappointed.

> Hey if you want to volunteer an implementation in Go, this is well travelled territory. You can look those algorithms up and implement them yourself.

I have been planning on doing just that (not in Go though). I want to play around with updating each cell on an as needed basis (e.g. cell at time T only needs it's neighbors to have been updated to T-1, and their neighbors only need to have been updated to T-2) and then making that outwards sandpiling of update-ticks a commodity/game mechanic in the game. Perhaps something similar to your LFG, but instead of enabling a fixed neighborhood size, it would simply push out update-ticks at an established rate to limit processing load.