@pspeed said: ES is data oriented not data driven.I can only respond to specific questions or issues. Since you have provided none then I can only respond with likewise handwaving.
Hmmm… according to well… just about EVERY return from a simple Goggle search. ES is referred to as Data-DRIVEN. What am I missing here?
@t0neg0d said: As far as the article talking about ES being the future of MMO... they failed to mention that in-game malls already destroyed that *future* and if you can't turn out an MMO in a matter of a month, your dev time > than your product's life span 100 fold. (This is only semi-joking... it's something anyone building an MMO should consider).So… for a small-to-mid-sized, single or multi player game being developed by a single person… I can only see this as purely a design choice, or a learning opportunity, because the scalability factor is off the table… and ES brings with it overhead that will trump any return you might see if your game stand to not grow all that big.
Am I mistaken here? And pleeeeease take off the “ES RULEZ!” tee’s before answering. I’d love to here one conversation about this subject without the typicals:
“You TOTALLY don’t get ES”
“Once you get it, you’ll understand”If ES is that cryptic and illusive… it’s just a bad idea with people refusing to give up on it
What’s the question?
Was it this:
and ES brings with it overhead that will trump any return you might see if your game stand to not grow all that big.
Or this?
Am I mistaken here?
The first is just FUD. You’ve manufactured overhead that I cannot point to and address. How am I supposed to respond to that? In past arguments, I’ve tried “What overhead?” and that’s gotten me nowhere.
You’ve already decided long before this thread that an ES is not for you so why are you even here FUDing around?
@t0neg0d said: Hmmm... according to well... just about EVERY return from a simple Goggle search. ES is referred to as Data-DRIVEN. What am I missing here?
Data driven is often confused with data oriented… see previous thread where I talked in circles with someone who was using the proper definition for data driven before realizing what the issue was.
ESes are data oriented. People who call them data driven are mixing terms… or making the same mistake I did.
Hey. This sometimes sounds like Toolforger vs. Normen. I’ve been told we shouldn’t do that…
I guess Tonegod is trying to punch holes in the arguments, to see whether Paul can be fix them or not. It’s a stressful discussion strategy and will cause the proponent to react more to the stress than to the actual points after a while; I think that’s what’s happening here.
I have a couple of questions myself; hopefully there are good answers to these:
The “OO mindset is bad and needs to be broken out of when doing ES” - I’m missing the argument here. You need to say what exactly the downside was when applying some particular OO idea (or other idea that does not go well with an ES); without that, you’re just arguing ideology and won’t reach anybody who hasn’t already made your experiences.
What IS the precise definition of data-oriented? data-driven?
What does FRP stand for? I know functional programming (FP) and functional programming language (FPL), and I know most of the FP lingo, but I haven’t seen FRP yet.
I’m not 100% sold on the performance argument that ES is cache-friendly. You’ll get cache-friendliness only if you have “hot” (often-accessed) and “cool” (less often accessed) data, and split the cool data off into a separate data set.
An ES does that automatically, but in typical uses, all components seem hot (because you typically don’t put the cool data into the ES). Cachewise, it shouldn’t matter whether hot data is in one list or in multiple lists, except that the list data structures themselves are more and do contribute to cache pressure.
Am I missing something?
Well for my ES there are some similarites to pspeeds but als some differences.
1- Initial philosophy
2- Pure data or not?
3- Multi-threading, concurency enable or not?
4- Communication: Event messaging enable or not?
5- Is database (and other kind of persistent) friendly or not?
6- Is enterprise friendly (expanable/ extensible/ modulizable) or not?
7- Script possibilities?
8- Restrictions and limitation
9- Dependencies
10- Current status: Long term, stable, community?
1-> Allow a highly modular Engine that can cope with a lot of prior not specifically designed states, as the set of possibilities change rapidly with me fooling around my codebase. (Concrete example was having a destroyable vehicle, but also undestroyable vehicles and destroyable non vehicles, after defining the damagesystem and the vehiclesystem + basic phsicsystem the rest just came free without additional coding, prior when i was using a source engine like pattern this was kinda a big time consumer)
2-> Well nearly all Data is immutable/or behaves as immutable, addidinally i have the rule that only primitives + Enums + Strings are allowed data Types. Anything more complex needs to be broken down to allow most flexible use. (Also this allows me to generate all necessary tables constraints joins ect automatically on startup time)
3 -> Absolutly prior in my old oop pattern I sometimes had the propblem that a call to update() is not easiyl parallel possible without introducing dozen of potation problems. Additional rule here is, I use a ticklogic similar to a main update loop, where a central synchronisation point for the low level datastructures happen. Changes to the Es between this points are inivisble to the rest. Also in my case only ony change per component of an entity per tick is valid, additional ones are ommited.
4 -> Um no, I have an additinal helper of entityAdd and entityRemove events, to simplifly cleanups in the systems, but they are not necessary and are mostly to reduce code amount.
5 ->Absolutly, it can create all stuff necessary and provides a savesystem, that if a savecomponent is existent, snapshots the current timefrozen view and writes it out in the background. Also it provides a Criterion System for loading saved Entities.
6 -> I don’t exactly get this, if it is not any of this it’s not really an Es, or we have different definitions of words.
7 -> ? O.o Why?
8 -> It is not directly Db based as zayes, but instead uses a inmemory presentation of the complete state and only writes out necessary to save changes, this somewhat reduces the scalability by just throwing more seperate servers on it, this is a design decision done, vecause as I write a space game, i can simply split at the sector borders
9 -> Hm external none so far
10 -> closed source so far, I might release it in a opensource like license later, but not currently planned.
For the cache friendlyness, as you usually loop only over a large set of data without additinally side jumps in most cases it reduces the bloating object structures. However I don’t use the Es due to the cache friendlyness, but due to the simple ability to scale with additional cpu cores without any deep engine changes. Anyone ever seen how many current AAA (FPS)engines struggle with multithreading can see the use for this.
That all being said, I can only agree that often you still introduce OOP patterns and thus ES errors in the design and logic. Often you have a problem that does seem to be nearly unsolvable with an Es untill you take a short break think about and see a fundamental erro in your component composition/design (Eg storing Spatials/Physicobjects or similar there).
Nice clearing up guys’n’gals xD. To anyone who’s in doubt… Believe @pspeed, most others here still seem to have issues grasping ESs and the first few posts here won’t do much to alleviate that.
The main thing about ESs isn’t the actual process but how easy its to extend. If you don’t stick with the ES rules however that advantage is gone.
@toolforger said: I have a couple of questions myself; hopefully there are good answers to these:The “OO mindset is bad and needs to be broken out of when doing ES” - I’m missing the argument here. You need to say what exactly the downside was when applying some particular OO idea (or other idea that does not go well with an ES); without that, you’re just arguing ideology and won’t reach anybody who hasn’t already made your experiences.
I will try to remember specific cases where this happens… for now I can only state that it has. It seems especially common at the point where the ES meets with the scene graph where I try to take some shortcut only to realize later that it was a longcut.
If I catch myself in this design hole again or can remember a specific instance then I will post it.
@toolforger said: What IS the precise definition of data-oriented? data-driven?
Data oriented design is an approach that extracts the operations on the data from the “objects” and flattens the things that they need to run in order to be cache friendly. According to the literature (I got my first exposure in Game Engine Gems 2, Chapter 15), in many cases it actually simplifies the code. I’m not sure I can properly illustrate that feature but I will attempt to show a relevant example at least.
Let’s say you want to implement a physics loop (just the integration of velocity for simplicity), you might structure the data like:
[java]
struct Body {
vec3 pos;
vec3 vel;
}
Body data…
// Then to loop over the data
Body *body = data;
for( int i = 0; i < DATA_SIZE; i++, body++ ) {
body->pos.x += vel.x * tpf;
body->pos.y += vel.y * tpf;
body->pos.z += vel.z * tpf;
}
[/java]
It’s cache friendly because you can fit a lot of “bodies” in a cache line. It’s also friendly to parallelization since various steps are already broken down into stages (another loop might integrate acceleration to velocity, another might transfer velocity to body, etc.). Furthermore, you can interrupt it at any time and keep going if you need to.
There is a whole page of performance justification in that chapter… most of that is largely irrelevant to us in Java.
I fall back on the data oriented patterns because a) it’s the father of entity component systems and b) it helps think about the proper decomposition of logic given that state of mind.
I don’t know if the book is worth the price in general but if you can find/borrow a copy just to read that chapter it might be interesting. I wish it was available online but I can’t find it.
Data driven, on the other hand, can mean a few different things. A common usage is one you may already be using. For example. abstracting something like:
if( a == 0 ) doFoo()
else if( a == 1 ) doBar()
into:
Command commands…
commands[a].doIt()
…is a data-driven design.
State machines are a pretty classic example. There are other approaches. The strictest definition would be where the program is operating on data in a stream and choosing what to do next based on the data in the stream. Wiki-pedia lists awk and sed as examples and those might have been the ones I would have chosen, too.
However, it’s frequently applied to abstract state as well, like in my case above. When the data drives the code versus the logic driving the data, I guess it is “data driven”.
@toolforger said: What does FRP stand for? I know functional programming (FP) and functional programming language (FPL), and I know most of the FP lingo, but I haven't seen FRP yet.
I thought she meant “Functional Reactive Programming” but I could be wrong. Functional programming could be nice for defining the transforms of a loop in a data oriented design, but FRP always seems more push-based to me.
@toolforger said: I'm not 100% sold on the performance argument that ES is cache-friendly. You'll get cache-friendliness only if you have "hot" (often-accessed) and "cool" (less often accessed) data, and split the cool data off into a separate data set. An ES does that automatically, but in typical uses, all components seem hot (because you typically don't put the cool data into the ES). Cachewise, it shouldn't matter whether hot data is in one list or in multiple lists, except that the list data structures themselves are more and do contribute to cache pressure. Am I missing something?
I think you put cool data into an ES all the time… things like a Name component or a Description component may not be touched by these sorts of data oriented flows at all. They are taking advantage of the other benefits of the ES (decoupling, etc.).
…but the cache friendliness legacy is sometimes just a way to see if an approach is “right”. If you find yourself in an inner loop doing lots of grabbing of other entities or data then there is likely a data-oriented-style step missing somewhere. It’s just a matter of rethinking the problem. The linked thread with the example of the frequent “in range of towers” query is an example where it turns out such a query may not be necessary at all.
I keep meaning to go back and research if the data-oriented literature has anything to say about the many-to-many style problems like collision detection between moving bodies. The gems book hints at some things but isn’t very meaty in that area. I suspect that will always be an ugly problem. It’s not like physics engines suddenly started doing magic here.
I will try to think of some examples where some OOP in the wrong place got me in trouble. Sorry that I’m drawing a blank.
I started out with ESes as a pretty big skeptic. Normen mentioned it to me one day offline and I initially poo-pooed the whole idea. I read the t-machines articles and still didn’t get it… then I read all of the comment threads. I started to see how it could solve some of my problems and so tried to apply it to Mythruna that weekend. By Monday, I’d cleaned up a bunch of code. Furthermore, I no longer had to think “Hmmm. feature X, where exactly should I put that now?” The answer was almost always obvious.
Additionally, I started gaining features as positive side-effects. For example, the fact that entity names and positions where in the ES meant that when I converted my in-game map over to also use the ES, I got moving map markers for free. Just for the cost of adding the entity set query + update loop and deleting a whole mess of map-specific code. I was deleting so much code that I even made a branch because I started to get scared.
It’s a new concept and it’s so easy to get wrong. We carry a lot of OOP baggage that serves us well in every other area all the time. That’s why I try to accumulate tricks to cut through my OOP prejudice. But that’s also why when someone says they tried it and didn’t like it, it’s reasonable to assume that maybe they didn’t do it 100% right. Like if someone says “Oh, I tried sex. It was a horrible mess and I will never do it again.” Immediately questions are brought to mind. Sure, there’s always a chance that is true but it’s worth drilling into.
And that’s also why it deserves experimentation. When some of the other core devs started playing with ESes in their own projects there was almost a general consensus that you couldn’t properly “get it” unless you’d tried to build your own once. I delayed releasing my code for a year or so largely because of this thinking.
But sometimes you just need to give the jedi a light sabre and see if he likes it better than blasters instead of making him construct his own.
@normen said: Nice clearing up guys'n'gals xD. To anyone who's in doubt.. Believe @pspeed, most others here still seem to have issues grasping ESs and the first few posts here won't do much to alleviate that.The main thing about ESs isn’t the actual process but how easy its to extend. If you don’t stick with the ES rules however that advantage is gone.
Yeah, and perhaps we are getting lost in the weeds a bit elsewhere.
Architectural clarity and easy extension was what turned me on to it originally and then kept me.
@normen said:The main thing about ESs isn't the actual process but how easy its to extend.
That’s what I gathered.
@normen said: If you don't stick with the ES rules however that advantage is gone.
The question is: How do the ES rules relate to the advantages?
One thing that would also help is better terminology.
“Entity”, “Component”, “System” - one could swap any two terms and they would still apply. People using an ES will easily move code into the wrong category and it will still match the terminology so they aren’t warned that they are doing it wrong; seems like that’s part of the confusion and why this needs to be explained over and over (and why otherwise knowledgeable people can so massively disagree).
Let me attempt this - no doubt showing more about my own incompleteness of understanding than being a true solution, just to show how a different terminology could look like:
Entity -> ID. It just binds the components together, in the sense that there is one function that creates a bunch of components with the same ID, and one function to destroy all components for an ID. An entity is the set of objects that have the same ID, entities don’t exist as coherent objects inside the code.
Component -> Facet. A position is a facet of an entity, as its velocity, its health, its armor, its whatever. If entities were Java objects, facets would be groups of interrelated properties.
System -> Processor. A function that operates on a slice of components.
Again, I think that’s probably off the mark in some respects, and probably not the right terminology; just my current understanding of what an ES is, or should be. Maybe. As far as I got that right.
@toolforger said: That's what I gathered.The question is: How do the ES rules relate to the advantages?
One thing that would also help is better terminology.
“Entity”, “Component”, “System” - one could swap any two terms and they would still apply. People using an ES will easily move code into the wrong category and it will still match the terminology so they aren’t warned that they are doing it wrong; seems like that’s part of the confusion and why this needs to be explained over and over (and why otherwise knowledgeable people can so massively disagree).Let me attempt this - no doubt showing more about my own incompleteness of understanding than being a true solution, just to show how a different terminology could look like:
Entity -> ID. It just binds the components together, in the sense that there is one function that creates a bunch of components with the same ID, and one function to destroy all components for an ID. An entity is the set of objects that have the same ID, entities don’t exist as coherent objects inside the code.
Component -> Facet. A position is a facet of an entity, as its velocity, its health, its armor, its whatever. If entities were Java objects, facets would be groups of interrelated properties.
System -> Processor. A function that operates on a slice of components.Again, I think that’s probably off the mark in some respects, and probably not the right terminology; just my current understanding of what an ES is, or should be. Maybe. As far as I got that right.
Yeah but its better to see it with a definite example so the advantages come into play. E.g. when you make an inventory system you can just put a component that is defining the carrier to the item. Neither the code for the carrier NPC or PC nor the code for the item itself need to be changed or extended. You just add the functionality. As by a certain time all your Systems have code to access the ES you have much less overhead. In an OOP system you might need new interfaces, a new callback / event system and listeners and in addition extend your old ones.
Edit: Btw contents aren’t interrelated per se, not more than the tables in a db are at least. The systems define the need/interconnections of the components.
@toolforger said: That's what I gathered.The question is: How do the ES rules relate to the advantages?
One thing that would also help is better terminology.
“Entity”, “Component”, “System” - one could swap any two terms and they would still apply. People using an ES will easily move code into the wrong category and it will still match the terminology so they aren’t warned that they are doing it wrong; seems like that’s part of the confusion and why this needs to be explained over and over (and why otherwise knowledgeable people can so massively disagree).Let me attempt this - no doubt showing more about my own incompleteness of understanding than being a true solution, just to show how a different terminology could look like:
Entity -> ID. It just binds the components together, in the sense that there is one function that creates a bunch of components with the same ID, and one function to destroy all components for an ID. An entity is the set of objects that have the same ID, entities don’t exist as coherent objects inside the code.
Component -> Facet. A position is a facet of an entity, as its velocity, its health, its armor, its whatever. If entities were Java objects, facets would be groups of interrelated properties.
System -> Processor. A function that operates on a slice of components.Again, I think that’s probably off the mark in some respects, and probably not the right terminology; just my current understanding of what an ES is, or should be. Maybe. As far as I got that right.
System = everything that isn’t an Entity or a Component but uses Entities and Components.
And as Normen says, there is an inherent decoupling in the components. They are joined by EntityId, yes. And that’s it. The “systems” decide how components play together and from their perspective, nothing else exists.
@pspeed nothing beats building your own for understanding something.
Well, only if you do it successfully.
E.g. with OO, if you do it yourself, you usually end getting multiple inheritance wrong. (Java took the easy way out, making it a far worse OO language than it could have been. That’s still better than trying something and getting it wrong, so I’m not going to claim that they did it wrong; I don’t think anybody could say for certain how to do that right when that part of Java was designed.)
This seems to be the case of ESes, too. At least when I’m looking at the differences in what people are claiming is an ES. For all I know, your idea of an ES could be mostly right but subtly wrong in one respect, and I’d never know.
Also, experimenting can take a huge amount of time. Finding out how MI should be done took me a decade (more if you count the days of learning OO). You say it took you a year.
So writing down the design decisions and the reasons that led to them would be immensely helpful.
Please hold the tought whenever you remember any details there 
And also hold the thought if you find where you’re paying a price. E.g. interfacing with the scene graph seems to be iffy (I had suspected so myself but not having done ES code in earnest I could never pinpoint that).
I’m not after shooting down the ES idea. I’m after guidelines what to put into an ES and what to keep out.
@toolforger said: @pspeed nothing beats building your own for understanding something.Well, only if you do it successfully.
E.g. with OO, if you do it yourself, you usually end getting multiple inheritance wrong. (Java took the easy way out, making it a far worse OO language than it could have been. That’s still better than trying something and getting it wrong, so I’m not going to claim that they did it wrong; I don’t think anybody could say for certain how to do that right when that part of Java was designed.)
This seems to be the case of ESes, too. At least when I’m looking at the differences in what people are claiming is an ES. For all I know, your idea of an ES could be mostly right but subtly wrong in one respect, and I’d never know.
Also, experimenting can take a huge amount of time. Finding out how MI should be done took me a decade (more if you count the days of learning OO). You say it took you a year.
What took me a year? It took me a year to decide to publish my ES because I thought people would learn better by doing. I developed the initial version on a Friday/Saturday and had deleted and migrated a bunch of code by monday. That includes the persistence layer (but I’ve rolled so many of those in my time it was no big deal). Since then I fixed bugs and added networking… and most bugs were related to networking.
@toolforger said: So writing down the design decisions and the reasons that led to them would be immensely helpful. Please hold the tought whenever you remember any details there :-)
I’m really not sure what else to say. If you find features in another ES I could talk about why I didn’t include them in Zay-ES. There’s just not that much code to comment about. The design is thin and light and implements all aspects of an entity system that I knew of… with a few performance optimizations hidden under the covers.
@toolforger said: And also hold the thought if you find where you're paying a price. E.g. interfacing with the scene graph seems to be iffy (I had suspected so myself but not having done ES code in earnest I could never pinpoint that). I'm not after shooting down the ES idea. I'm after guidelines what to put into an ES and what to keep out.
In Asteroid Panic, here is the class that connects the ES to the scene graph:
http://code.google.com/p/jmonkeyplatform-contributions/source/browse/trunk/zay-es/examples/AsteroidPanic/src/panic/ModelState.java
It would work for any game that doesn’t have zones and doesn’t have unsynched multithreaded physics (and then only because if the renderer and physics engine are not lock stepped then you will need to interpolate.)
Edit: or above were you referring to design decisions about my game or about Zay-ES. The former is rather context specific.
@normen said: Edit: Btw contents aren't interrelated per se, not more than the tables in a db are at least. The systems define the need/interconnections of the components.
Now you have me worried. I’m feeling rather acute pains when trying to enforce business rules that touch multiple tables.
A lot of that pain comes from the need to keep Java, triggers, and views in sync, fortunately a non-issue with pure Java code.
Still, there’s pain associated. I’m having multiple pieces of code that access the same table, and sometimes business rules need to be applied to all these pieces of code, with the ensuing “Fun” (Dwarfen-Fortress style) of keeping half a dozen routines in faraway modules in sync so they all observe the same business rules in whatever incarnation they are today. And I had several inconsistencies to hunt down, so it’s no fun - you can factor out these business rules into common subroutines, of course, but that’s extra work; a more encapsulated style would help avoiding that kind of problem.
Of course game rules are very different from business rules. Game rules are MUCH simpler.
@toolforger said: Now you have me worried. I'm feeling rather acute pains when trying to enforce business rules that touch multiple tables. A lot of that pain comes from the need to keep Java, triggers, and views in sync, fortunately a non-issue with pure Java code. Still, there's pain associated. I'm having multiple pieces of code that access the same table, and sometimes business rules need to be applied to all these pieces of code, with the ensuing "Fun" (Dwarfen-Fortress style) of keeping half a dozen routines in faraway modules in sync so they all observe the same business rules in whatever incarnation they are today. And I had several inconsistencies to hunt down, so it's no fun - you can factor out these business rules into common subroutines, of course, but that's extra work; a more encapsulated style would help avoiding that kind of problem.Of course game rules are very different from business rules. Game rules are MUCH simpler.
In general, components only have one writer. With absolute certainty, only one writer per entity. Or you’re doing it wrong. As the South Park meme would say “You’re going to have a bad time.”
Counter examples or it didn’t happen. 
@pspeed said: In general, components only have one writer. With absolute certainty, only one writer per entity.
Okay.
@pspeed said: Or you're doing it wrong.
Question now: How do I make sure it’s not done wrong?
Consider the modder scenario. Base game is pushed out and people are invited to write mods, which involves writing components. How can they do anything if they can’t do additional writers… actually I’m now confused how it’s unusal to have more than one writer per component class.
@toolforger said: Okay.Question now: How do I make sure it’s not done wrong?
Consider the modder scenario. Base game is pushed out and people are invited to write mods, which involves writing components. How can they do anything if they can’t do additional writers… actually I’m now confused how it’s unusal to have more than one writer per component class.
I have to go to bed now. It’s 7 AM here and I’ve been rehashing entity system discussions from six months ago all night.
If you can come up with an example where more than one thing needs to write the same components then I can show you how to fix it.
@toolforger said: Okay.Question now: How do I make sure it’s not done wrong?
Consider the modder scenario. Base game is pushed out and people are invited to write mods, which involves writing components. How can they do anything if they can’t do additional writers… actually I’m now confused how it’s unusal to have more than one writer per component class.
Well at least in my es the components systems / netowrk stuff is not hardcoded, but a small registry class is pregenerated wich contains a few lists for loading and preparing the es to use those.
So if a moder would like to change the physics system, he could just extend mine, and mine would be skipped as a subclass will already be used and his loaded instead. (This can a bit more finely controlled by using a few Annotations for that. It sosmwhat similar to springs autowiring, but nothing happens at runtime its all before that and apart from the startup no reflection is involved.
So in the end only one physicsystem would write to that components, just a more complex one to adapt to the changes. Another option would be to make somwhat callback like and allow mods to register on specific situations there, however htat would reduce the pureness of the es, wich is why i have not included it.
You guys are too fast! I can not follow with these speed of posting, everyone should have a good sleep then come back with healthy brain plz 
Hehe, just kidding…
I will not go futher into dicussing the Entity System core concepts and why not OOP as other. Instead I will go straight to its Cons and Practical issues and example.
Sure I’m the one who always want to apply it successfully in my project, an MMO. So in anycase I’d like to do it right this time; because arcording to what we talked for a year, what I done in those old projects (in Java, in Unity, in UDK…) is deathly wrong and I don’t know it was wrong until we have this discussion. Remember this ES war also start flame in academy playground for a whole decade
So here we go.
(*) Philosophy vs Restriction ( by design) mean
The abstract level listed of phylosophies of Design to enable all its good:
Eg:
Note: System implementaion details or practical wisdom is really worth to mention.
If your ES not force the System implementation (as Processor…) is can be not avaiable at the moment of call (null because lazy initited in another thread), or hand the reference of entities and component to evil thread, (leak reference)… etc
(*) Limitation mean
Noticed issuses you have that beyond the design.
(*) Expanable mean using other Java techs together, corporate with your lib ( OOP existed libs):
Software : as Model-able via GUI, with MVC, as Web, with upcoming Java’s dynamic, etc…
Game sepecific: AIs ( I don’t want to write all of them), physic (C++…), etc…
(*) Extensible mean:
We are still happy with it enough while not care to other Enterprise issues.Some guys can properly use your project in big a$$ game and need better observation of you design.
Not something like: erg,… same ES concept, ehr… with a nice ChangeSet… which is another kind of Concurent Obsversated Collection, ehr… kind of!
When some means of communication is necessary???
In your approach, Components function independently, so no inter-process commnication between Component.Clear!
But what about System, there is no contract about it. A system can process though Component and do what ever in the Component, even lend it to other Process [BAD]!
As in Network scenario, where message passing is nature. If you don’t come up with something better than that:
I also don’t understand how this is an ES problem. I script against my ES just fine with Groovy.
OK, The Script problem can be describled as seen in Artemis’s articles and other ES I’ve used like Unity:
Now let see if they happen in your ES or “just fine”!
[1] Hard to inspect:
So we have no clue to inspect what kind of Components are there in a single Entity when the Script sit on that specific Entity ask?
We have to query all the Components of that Entities, same as how java Reflection call getAllProperties.
–Just wait a little bit to the next questionable.
[2] Outer relationship is Hard to define
As your Zay-ES is non-dependency components by design
(remember that there is other implementation with this point non-restricted!!! They use DI, scripted relationship…etc)
Scenario:
hey, my Move component ‘should’ somehow aware of physics, some kind of these in a script.
entity.comps.pos.x = entity.comps.physic.x (…??)
(*) Ahr, no I can’t. The entity know nothing about its insider. So the Script should be a System outside, but I only want to move this single Entity:
so:
entity = system.get(entityId);
entity.comps.pos.x = entity.comps.physic.x
(*) Ahr, wait… The component know nothing about its sibling. So how can we know that the physicComponent is there for me at first place.
so:
entity = system.get(entityId);
pos= entity.getNotNull(‘Pos’)
physic= entity.getNotNull(‘Physic’)
pos.x = physic.x
(*) Fine, hehe… Done, …ahr, no. There is no physic.x property, what the hell??? Rollback to the first one, I see physic component’s property has name as “physicX” not just “x”… FU#K? Why can this happen.
(+) Because you have no IDE support dude! You query your object through your adhoc way via a String or ClassType without promise the returning result. So whenever there is a “form of dependency” between your component, you have to query them but not Java Type-safe style. Because it’s hard trade off to make COP type-safe as in OOP term. The Script almost resulted in run-time errors time to time.
[3] Property reject to change
(*) Ok, I get it… But still not work.
(+) Yeah, because you have to make a new PosComponent via property lend from PhysicComponent. Remember we dont have setter?
So:
// Option 1:
newPos = new Pos(physic.x,physic.???)
// Remmember
// newPos.x = physic.x
// is wrong!
//Option2:
newPos = new Pos(physic.x,oldPos.y,oldPos.z,…);
//Option3:
newPos = oldPos.cloneViaProxyExcept([“x”:physic.x])
entity.set(“Pos”,newPos)
(*) Ugly, …I don’t get it, … it’s nearly we dont use any goods from a scripting language…!
(+) Yes, in this simple example but end up add hacking DSL to make it look like scripting but still not, as the most obvious solution is. Mainly due to underlying method to set and nofify the changeSet of the ES is fixed.
In Unity, to enable script they end up half ass solution with setter, but multi-threading done with care.
The most valuable thing I learnt from Unity ES Script solution is:
Notice: Here I try not to mention Unity too much as an AAA game engine, but an ES implementation candidate.