Creating nodes after update cycle is finished

[Daniel Krejčí]

Hey guys,

I haven't talked here for a while. I am in current development of WebGL game using AshJS port. Currently we are making our own "Ash" from the scratch, but using many guidelines established by Ash Framework itself. It will be open source eventually.

As subject already said, currently I am thinking about rather big design decision. I know that Ash creates new nodes on the fly when new entity is created or components changed. I am wondering if that's actually that good idea. In practice when using AshJS, we had found issues when some system made change some changes and nodes were created right away. Some systems that were working later suddenly had new nodes that weren't there just few steps back. It looks like very inconsistent state and it's somewhat hard to debug. And I am not even mentioning signals like nodeAdded or nodeRemoved that just synchronously interrupted everything and went for other batch of changes. These are major cause of many mistakes.

One sort of solution is to make sure that systems are ordered correctly. Frankly that kinda sucks. It creates one big layer of system dependency that is hard to maintain over time because it's really easy to forget that this particular system had to be run before this one. Of course I am not talking about changing values in components here. That's kinda essence of the whole thing and should happen as suspected. It creates small system dependency too, but not that major probably.

So I am thinking about solution that pretty much buffers added/updated/removed entities and they are processed at the end of current update cycle. When next update cycle starts there is some assurance that the state is consistent as the whole and it will no change somewhere in the middle.

Can you please tell me your opinions on this? Aren't there some possible caveats that could cause more trouble in the end?

Thanks!

[James Wrightson]

Sorry for the late reply, I have been very busy :D

I actually create all of my "nodelists" before any of the systems are even added.

And store them statically for easy access.

No issues what so ever, systems can use nodes from any node list they like and its very easy to maintain.

Not sure if "differing" the nodes is the best choice, but it is an interesting idea.

[Daniel Krejčí]

Hey,

I think you have misunderstood me. Node lists are fine and I don't care about these. I am talking about situation when new entity is created or existing one changed so it fulfills node list requirement (fits into family). Ash simply creates that node right away. I am thinking about creating it after all systems made its update.

Dne čtvrtek, 14. srpna 2014 1:16:59 UTC+2 James Wrightson napsal(a):

[James Wrightson]

I think the best way is to not defer the creation of nodes, but instead, the entities there selves. (which is what I do).

Essentially, I have two functions that I have modified within the ash engine:

"addDefered(entity)" - which will add the entity AT THE END of the system update.
"addImmediate(entity)" - which adds the entity instantly just like the default "add" behaviour does.

[Daniel Krejčí]

Yeah I am planning to do deferred entity by default. I am not managing full list of all entities, I rely only on node lists. Anyway adding is easy, but what about case when components in entity are changed. Some nodes are made based on that and some are removed. I would like to make that consistent and propagate such changes to node lists at the end of update cycle.

Also you are talking about at the end of system update? I want to do it after all systems are finished with their rounds.

Dne čtvrtek, 14. srpna 2014 12:42:14 UTC+2 James Wrightson napsal(a):

[James Wrightson]

Well so far I have not personally found a use for postponed node creation, but you are right - it will make things more predictable.

Give it a go, let us know how it went and maybe we can branch it or something ;)