His post indicated that he initially tried the "every entity is an agent" idea, and had performance problems with it - although maybe his real problem was that the entire world was a single ref, and all of the agents would bash on that ref.
Another question, do you have any kind of reverse-lookup table implementation? I see that you're using component-based entities, do you have any way to quickly query your world for entities that match some arbitrary criteria, rather than iterate over all entities in the entire world? I ask because my game idea would involve potentially tens of thousands of entities, and I'm trying to figure out a way to build game logic mini-systems that can quickly find a subset of game entities and perform some function on them. For example "In the spring time find all fruit-bearing trees of a minimum age and spawn unripe fruit on them", or "every 15 seconds find all poisoned characters and deduct 1 health point"
although maybe his real problem was that the entire world was a single ref, and all of the agents would bash on that ref.
Having the whole world inside a ref sounds bad... I mean, I don't really know but if you want to take the godmap approach you really need to pass around the state and apply the parallelism somewhere else (aka in the way the state transformations are applied, like pmap for example), not have entities as external agents that hammer on the poor state.
do you have any kind of reverse-lookup table implementation?
Yes and no. I don't have anything fancy at the moment, I can query the "database" of entities (aka the individual game screens) for specific tags, lookup operations are very quick in Clojure since the entity's state is a map with tag -> value, the lookup is close to O(1). The downside is that I need to query through all the entities contained in a specific screen (or all screens) to look for the tags I'm looking for, but I don't see another feasible way to do it and maintain concurrency. I could sort entities by tags (what I tried to do on my old and half-failed attempt: https://github.com/Morgawr/CloisterJS ClojureScript engine) but I would lose the advantage of concurrency. If the performance impact gets too much, then I'll try to engineer something around the problem but so far I have more important issues (like, having an engine at all).
So the entity data structure is organized first by component tag, then by entity id. I've heard this referred to as "inside-out objects". That way functions can quickly query things like "find all entities that have a location" or "find all entities that are poisoned". The downside is that there isn't a convenient way to atomically update multiple components of a single entity.
Yes, that's exactly how my ClojureScript prototype worked, the problem is that it wouldn't allow me to use concurrent entities. (Although you could use refs for tag-types instead of individual entitites... an interesting approach nonetheless)
His post indicated that he initially tried the "every entity is an agent" idea, and had performance problems with it - although maybe his real problem was that the entire world was a single ref, and all of the agents would bash on that ref.
Another question, do you have any kind of reverse-lookup table implementation? I see that you're using component-based entities, do you have any way to quickly query your world for entities that match some arbitrary criteria, rather than iterate over all entities in the entire world? I ask because my game idea would involve potentially tens of thousands of entities, and I'm trying to figure out a way to build game logic mini-systems that can quickly find a subset of game entities and perform some function on them. For example "In the spring time find all fruit-bearing trees of a minimum age and spawn unripe fruit on them", or "every 15 seconds find all poisoned characters and deduct 1 health point"