SocioLife is an advanced artificial life simulation exploring emergent social behaviors, tribal dynamics, economic systems, warfare, diplomacy, and technological evolution in a complex multi-agent ecosystem.
SocioLife is written in javascript and runs in your browser. It's graphics and compute intensive, so it's best run on a modern multicore PC.
Actually - on that particular topic - you might want to read the articles and the math before forming an opinion - start from information geometry and fisher information metrics of information processing - which is what that particular line of thought is all about...Everything on that particular line of exploration is built up from fisher information where "consciousness" is defined as a high complexity information processing geometry and so its measurable. Because its defined as a measurable physical process, not as a magical quality, it's a mathematical argument. But of course that would require reading, and sufficient knowledge to understand it.
You're right that Realm of Lace edges are derived from node eligibility, making it theoretically equivalent to a complex multi-state CA. I've updated the documentation to reflect this honestly.
However, your Shadertoy port doesn't produce equivalent behavior to the original rule—I've tried several corrections in your shader and none match.
While you've demonstrated the theoretical point, this actually highlights why the abstraction matters: implementing these dynamics correctly is non-trivial even when the algorithm seems straightforward. The three-phase execution, metric calculations, and mutual eligibility create subtle interactions that are easy to get wrong.
Why the shader port doesn't work:
I've successfully implemented this same rule in Taichi (also GPU-based), and comparing the two reveals the issue.
The three-phase execution model requires intermediate storage between phases that Shadertoy's ping-pong buffer architecture can't provide.
In my Taichi implementation, each phase has its own buffer:
- Phase 1 reads node_degree (previous state) and writes to node_next_eligible
- Phase 2 reads node_next_eligible and writes to node_next_degree
- Phase 3 reads node_next_degree and writes back to node_degree
Shadertoy only has two buffers (previous frame read-only, current frame write-only), so the shader tries to collapse all three phases into one pass. But this breaks the execution model: when Phase 2 checks if a neighbor is eligible, it needs the neighbor's just-computed eligibility from Phase 1 of the current step, not the previous frame's data.
To properly implement this in a shader, you'd need either:
- A multi-pass setup with three separate render passes and intermediate textures
- Clever state packing to encode multiple values (eligibility + degree) in one buffer
The fact that the algorithm works correctly in Taichi but requires careful buffer management even on GPU demonstrates that "theoretical equivalence to traditional CA" doesn't mean "trivial to implement."
The three-phase execution model with intermediate states is a real architectural requirement, not just an abstraction.
Regarding edge rule tables: LACE has complete UI infrastructure for true edge-to-edge dynamics (edge states evolving based on connection patterns, independent of node eligibility).
The Rule Editor even has a full tab for it (which appears if a rule implements rule tables). But no rule implements the execution logic yet—it's a dormant feature that would provide the dynamic topology you're suggesting.
Thanks for pushing me to be more precise about all this though :)
I've updated the shader – I think the issue was just that I was initialising the states to random values instead of running a proper degree calculation. The behaviour looked pretty similar to me either way, but now it matches exactly and I added colours to make that clear: https://imgur.com/a/4gZKlSg
Looks better... the one thing I am not seeing is the behavior where they expand in two directions at the same time - but it might be that it's too small. Also it would be better if you started from a much lower density initial condition like 15% density. Also note - while Amazing Dragons shows really interesting behavior microscopically it is not the most balanced rule - there are other variants that are sparser and have a more interesting balance (see gallery, see repo to try them out). I found density of initial conditions is very important and different rules need different densities.
The difference is that it is not merely using dynamic neighborhoods - it's using topological properties of neighbors and neighborhoods as metrics that rules use. For example, sum of degrees of neighbors, or betweenness, or other measures of networks. It's not, for example, simply using the links as virtual neighborhoods and modulating states over them.
Fair enough, especially considering it looks like a passion project. That said, I think you'd have a greater reach if you'd modularize, allowing a better overview of the project. I'd love to take a deep dive, but truth be told, that big of anything is a little daunting.
Yes you are missing something. The first examples do that, but later examples do something different - they are using the neighborhood topology instead of traditional cell states, to generate the behavior.
If we had a grid of cells where each cell was a number from 0-8, representing the number of neighbours, would that be equivalent to what these "links" are? I'm still finding it hard to understand.
links are first-class entities. Some rules have cell states AND links. Some rules treat cell states as topological metrics of neighborhoods or neighbors. See the detailed .md cited above for more details.
This is interesting and may reveal additional properties of certain class of CAs.
Yet, as some comments already stated what you do is basically study a subclass of multi-state 2D CAs where specific states from the finite state set have a specific meaning associated.
In general a CA is defined as a dynamical system governed by a local rule operating on the neighborhood configuration and yielding a new state. State set is typically finite. But the actual structure of the states can be anything you like. A valid state can be a tuple of a form (visible state, number of neighbors, sum of neighbors degrees, …). As the maximum neighborhood size is finite and the visible cell states are finite - there is a finite number of such tuples which constitute the state set on which a CA can operate.
Summing up - you are studying CAs in which your multi-state setup has some implied meaning. Still cool and interesting.
The observation that other CA can be equivalent is a weak critique at best, this CA may be a nice compact way of describing types of CA that have interesting properties. It is not terribly interesting that it may be subsumed by some other CA. It may be some interesting unstudied subset.
For instance the Game of Life is a subset of 2-d binary state CA, the rule only takes the totals of neighboring cells, and so is a subset of those CAs with rules that care about specific patterns of neighbors.
These rules use very different principles than traditional cell-based rules - for example neighbor degree, number of connections, and eligibility criteria based on connectivity.
So in short, the cells are not becoming alive or dead based on the states of their neighbors, but rather on the topology of their neighborhoods.
The details are beyond the scope of a short write up, but are easy to explore in the rule-editor in the GUI of the code.
The level of structure and self-organization is striking, to me at least.
Also in all the rules - the links are visible and can have binary or real-valued states as well as the cells. So this enables pretty rich topology which rules can utilize.
Could you try explaining it in a comment? Not the general principle, but just the rules for one particular automaton. Whichever one is your favourite. Or Amazing Dragons, if you don't have a favourite.
The amazing part of cellular automata is the emergence of complicated behaviour from simple rules. Life's rules can be written in three sentences, maybe less.
Forgive my quibbling, but I don't understand what this is doing that other projects in this space haven't done before. Adding states and transition rules to edges is new to me...
I did try running your project, but I had to tweak it to get it to work with the instructions in the repo. I seem to be missing a few packages -- mpmath, sympy, typing_extensions. Can you add those to the requirements.txt file?
Let's see if I understood this right. For the Betweenness Amazing Dragons rule:
* Compute the "betweenness" of each living cell, which is 1 divided by its degree. Cells which are not connected to anything have infinite/undefined betweenness, but it doesn't matter.
* Then, for each cell, sum up the betweenness of its connected neighbours.
* If the total betweenness of a dead cell is in the range [(1.3, 3.6)], it is born and becomes alive at the next generation.
* If the total betweenness of a living cell is in the range [(0.9, 2.6)], it survives and remains alive to the next generation.
* Exception: any cell with 0, 1, 7 or 8 neighbours (in total, ignoring betweenness) dies anyway after the rules above were applied.
... That's not quite right, there's some references to "eligibility" that I can't make sense of. What else am I missing?
It'd be better to have fewer videos on the page and select for more striking examples like this one, and put them early. I got fatgue from see so many examples.
Also, consider getting off the grid and maybe doing some topology-based automata in combination with a more traditional network presentation paradigm like a force-directed layout. That would give you a much more 'biological' look which would draw a lot of people's attention.
SocioLife is written in javascript and runs in your browser. It's graphics and compute intensive, so it's best run on a modern multicore PC.
Read more here: https://www.novaspivack.com/science/sociolife-a-socio-econom...
Run it here: https://www.novaspivack.com/wp-content/uploads/2025/11/Socio...
Learn about the Game Mechanics in the About page.
reply