Entity System topic (united)!


Developing with other COP framework

Dedicated to who want to build ES tools and who what to use them “properly”.

These comments from my experience working with other Game engine which employ COP and ES. It’s not COP fault I have to say. But our (java game dev) fault who notice it too late, so we don’t have any good tools to help developing it at the momment!

[1] Composing tool and Code tool
Unity SDK (UDK and CrySDK… also) have Composing tool to make a world of entites with its engine predefined components.

[2] Code tool
Custom component/ System are made via Boo Script and C++ … for example, and require underlying processing (hot compiling) to make a useable component in real time.

[3] Scripting
Because it’s hard trade off to make COP type-safe as in OOP term. Even more difficult while scripting usually employ duck -typing. The Script almost resulted in run-time errors from time to time.

[4] Debuging: can be consider easy with GUI tool. As value change appear in the GUI; and because of beat nature theorically the game can be start,stop,pause at any momment without interupt in the middle of something. So this provide more than a way (Java way) to debug the game.

[5] Profiling: can be consider easy because of COP nature of arranged data, and ES has regular workload.

[6] AssetMaking: if Input and output are well setup. Assets are all in good format, output are well defined, workflow and routines are fixed. You are good to go! If not, or you have to change your assets to suite the spliting of components, you are doom!


Realworld problems: Split & Asset(Re)Sampling & Re-link

Real Example:

You have 10000 of car, each car with 4 wheels, each will be processed/ served as an entity or a Component of the PhysicSystem.

Approach 1: as Entites [normal approach]

  • You have to split your model to 4 separate wheels and body 3d Models.
  • Make 5 entities!
  • Then link them by ad-hoc script define entites relationship. May be in the System.
  • After that copy to ten thousand instance link to a single parent Prefab of 5 entities.-> 50000 entities!

Approach 2: as Components [ugly as hell, but good for script]

  • You have to split your model to a separate wheel and body 3d Models.
  • Make 1 entity!
  • Then has BodyComponent; 2 MeshComponent point to the Wheel, and Body; 1 FourWheelCarPhysicComponent; or 4 WheelCarPhysicComponent
  • Then ad-hoc script define Components relationship.
  • After that copy to ten thousand instance of a single Prefab of single entity.

In approach 1, System process entites and consider their relationship in meaningful way. Script spread ad-hoc relationship between entities, which will suffer re-link problem later.

In approach 2, System process entites and consider their component relationship in meaningful way. Script spread ad-hoc relationship between components, and terminate pure-data specification. But the script work intuitive per entity, re-link is avoided because the script added in Prefab.

In this example, first you can see the Split and DuplicatedComponent problem because ES naturally denide Component relationships, and the split sometimes unclear.

Asset(Re)Sampling problem happen:
when you change the car to 5 wheels, and have openable windows.
You have to:

  • Split the Windows in 3D Model.
  • Change your script/ code to re-define the relationships again.

Remember the root reason is your Data (real data) is sampling by your component description, and in addition, no Class concept existed. And this is a strict contract. So it result in 1-1 change per entity!!!

Also notice, the same situation is not strict in OOP world, so may be n-1, 1-n, m-n,… but usually if you change your whole class than your every Car (10000 of them) is good!

In Unity for example, they have Prefab concept to ease out the Class concept. Almost everytime, Prefab can replace Class.

But when the Prefab relationship is lost, eg: add the openable windows to 5000 of instance, not in other 5000 after their position is inplace. Even we can make 2 prefabs for each kind of car, we can not solve the top-down (one direction) relationship between Prefab and instance again at this momment. This called the Re-link problem. So you end up re-do 5000 of cars with a new Prefab. The same frustrations happen in almost non-predefined component.

You can also see a lot of these kind of problems in a database modeler’s everyday life. Modeling, resample, remodeling, imigration can cause frustrations if there is no OOP built-in support!

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).

Spatials/Physic objects…So where you save them anyway?

In Unity, they have a Assets singleton where save a serilized version of the objects with a “hash index” to look up them when need, resemble our AssetManager but more Meta-type and directory (tree) fashion. So technically, they not save the object in the Component but just a link to its source!

In fact, not too much people have this mistake because almost every engine have sostiphicated way to manage their assets, their also just save a link.


Enteprise playground: AKKA and Scala

Have some same points with ES but borned in OOP world. AKKA and Scala trying to solve the problem “Java OOP can not be enteprise” in elegent way. [Groovy and GPars as candidate]

What about AKKA vs other home-grown solution. Yeah… you can see its for Enteprise, like big simmulation with large scale of everything. Its have IDE support, much more type-safe, sercurable, unit test… You get the point. Read more because I don’t into doing free advertisment for AKKA here.

P/s:
@Empire Phoenix: How can I name your ES? do you want to bring it to the comparasion table, now in GoogleDoc but will be posted in public Wiki soon?
@toolforger: Feel free to add your points of concerns to the GoogleDoc table. I see your knowledge of wide range topics will help other a lot… Thank

I get it… me = not welcome in this discussion. But, @toolforger asked for definition of drive vs. oriented. Best way to describe this would be:

Data-driven: Data is primary, and the operations on the data are secondary
Data-oriented: Operations on the data is primary, and the data is secondary

So which do you see ES as being? Systems = anything else (translated… not defined in ES… so have it how you see fit)

My point in each one of these “conversations” is:

Is ES the best fit for all scenarios? No… like everything else, it has it’s place. If you use it in all design, then you = one of a few things.

  1. Lazy
  2. Blindly on the bandwagon
  3. Someone who should not be in systems architecture

But say this to this crowd and watch out… you just called someones baby ugly.

@Empire Phoenix said: 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.

Yeah, I have a similar system. It’s not really part of the ES… but it is useful. There is a plugin service where specific implementations can be registered for a particular interface (really simplifying). Any code that wants to use that service will grab it by interface from the plug-in service. I could have done an IoC style container but this fit the model a little better and allows a more flexible initialization strategy.

I don’t think this really addresses Toolforger’s issue.

When you let modders in, they will be able to fail in so many ways… whether it’s modifying the scene from another thread or sending bad buffers to the GPU. There are millions of ways that they can do bad things. Abusing the ES is just one of many of these.

@t0neg0d said: I get it... me = not welcome in this discussion.

If you actually join the discussion then I will follow in kind. So far you’ve complained that I didn’t answer your question and then I pointed out that there was no question. Then you said there was and I used your exact post word-for-word to ask for clarification on where the question was. Still don’t see it. When you have a question that’s real and not just hand waving with a question mark on the end… feel free to ask it.

For example, this post actually has meat to address…

@t0neg0d said:But, @toolforger asked for definition of drive vs. oriented. Best way to describe this would be:

Data-driven: Data is primary, and the operations on the data are secondary
Data-oriented: Operations on the data is primary, and the data is secondary

So which do you see ES as being? Systems = anything else (translated… not defined in ES… so have it how you see fit)

Many system code will follow a data-oriented pattern. Some will follow a data driven pattern (if program state can be considered data. I consider it so but some wouldn’t.)

The ES is fundamentally based on a data-oriented approach but it is one step up from that. It’s a way to better manage data-oriented loops across concerns while also providing other stuff like total decoupling, easy extensibility, etc…

@t0neg0d said:My point in each one of these "conversations" is:

Is ES the best fit for all scenarios? No… like everything else, it has it’s place. If you use it in all design, then you = one of a few things.

  1. Lazy
  2. Blindly on the bandwagon
  3. Someone who should not be in systems architecture

But say this to this crowd and watch out… you just called someones baby ugly.

I don’t think anyone ever said it works in all cases. That’s just hyperbole on your part.

However, often when someone says “It isn’t the best fit in all cases” what they are really saying is “I’m not really interested” or “I don’t understand it”. So it’s worth asking the questions on why it doesn’t fit or pointing out examples where it does fit that might be similar to their space.

Others will state that it actually can’t be used in all cases. Like anything else, this is simply untrue. You can shoehorn whatever crazy thing you like, after all. It can be used in all cases… it just might not make sense to do so. However, the requirements or structure that will make it less sensible are more narrow than some might think.

@tonegod : If you talking to me directly , I’m not a fan boy of any technologies , not even one!

Also with all respects, settle down a little bit… We have an intellectual kind of discussion here, and remember this ES war also start flame in academy playground for a whole decade

Of course your are welcome as anyone, and I also share your common sense about this problem; so as I said: I’m not into ES at this time but I want to learn the more the better, because it’s a good chance and my statement about the “COP” trend is true.

I DID work for Database solution in the past to see big projects using:

Data-driven solution, with Component Oriented Programming, with Data-oriented architecture , and these terms are much different in my POV. Dont be mislead by the wordplay; the name didn’t matter much in this case; the meaning, definition and specification of these concepts are actually from their initial group of authors. If you want I can point you to the right documentation but you could find it your self.

In the game world, consoles and even GPU architect designer attracted by Data-oriented architecture a lot… In higher level, mean programming level, Entity System was born from the trend of Data-driven solution with Data-oriented architecture, that form the Component Oriented Programming paradigm. Even one who came from academy playground can mis understand these terms easily if they don’t actually working with the orginal specifications.

Anyway, don’t be easy to get angry, I saw no offensive intended in this topic!

It is hard to address your long posts because they are full of good stuff to address… but I will try…

@atomix said: 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 :p 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 :stuck_out_tongue:

I try to help people with all specific ES design problems that they post. If I’ve missed answering one then please point it out and I will fix it.

@atomix said:

So here we go.

===============================================================================
If not mention, i’m talking about aspects of an ES as result of the current COP trend.
REQUEST: @pspeed, @Empire phoenix : Please explain your scripting, networking solution a little bit more…

Additional in Terms & features

(*) Philosophy vs Restriction ( by design) mean
The abstract level listed of phylosophies of Design to enable all its good:
Eg:

  • Pure data
  • No component dependencies
  • No entities relationship built in
  • System implementation detail (initial, routines,…) not forced
  • Changeset of entities are managed
  • No OOP fancies, Class as Type, no encapsulation as good idea… etc
  • No Bottlenecks - Regular workload ( see as good part of real-time app)

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

Atermis has specific System implentation detail which force to sub-class its System, and introduce SystemExecutor, which is bad as your opinion. But from what I see, empty specification also consider bad… (as read you wiki and your code also!)

To me, Artemis’s approach is the equivalent of if I let the database call my code. It feels backwards and it’s kind of limiting. I kind of know/guess why they did but I solved that problem in a different way in Zay-ES. In Zay-ES you ask for the conceptual equivalent of a JDBC resultset… except that you can reissue the query whenever you want and it will do it more efficiently than the first time (and provide extra info about what changed).

@atomix said: ---------------------------------- (*) Limitation mean Noticed issuses you have that beyond the design. - Such as memory issues to have all entities as indexes (big table problem) at run-time - Security holes - No Bottlenecks - Regular workload ( see as bad part of Event driven embeded app) - Hidden traps in design - or what ever...

For this are you stating examples of what issues might be or are you stating actual issues. I wasn’t really clear on this and I don’t want to address them if it’s wasting time in an already over-long thread.

@atomix said: ---------------------------------- (*) 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..

Forget the specific game genre like MMO, COP is better than that but PureData ES is very strict.
Remember the strict contract between System and Components, it’s the framework responsibility to provide valid way and routine to process them properly.

Yes, and there seem to be a few different philosophies here. I guess the boil down to the two approaches: database calls you or you call the database.

@atomix said: ---------------------------------- (*) Extensible mean: - You usually say what people come up is wrong (not follow the design), so tell us what is correct if we want to extend the framework in some direction or model a component properly for the sake of futher developement.

If I see someone propose an incorrect design then I actually do correct it. If you find posts where I haven’t done this then please show them to me and I will respond. Hypothetical “what ifs” that have no concrete information are hard to respond to but if you can put the design problem into specific components, etc. then it’s easier to respond to.

But questions like “What if I have a case in the future where two systems might call the same thing?” or whatever. Those are not design problems… that’s a thought experiment.

@atomix said: ---------------------------------- (*) Enterprise enable: Dont tell me you don't use Guice, Spring, other Distributed framework if you can. Game server and other large scale simulation evovle much more than a real-time core, come with delayed, lazy, non avaible service ...So the way your framework live together with the current enterpise technologies is under concerning. Database - bigtable or GraphDB in other hand have much more sostiphicated method to handle that kind of situation.. The changeset is just one of them I've to say. If you come with small scope, as use in real-time enviroment only, speak the true; :p 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!

But I’ve provide a lot of this info already so without specific questions, I cannot address them without just cutting and pasting from docs or other posts. I provided enough information that another developer on these forums was able to write his own ES that was almost exactly like mine. To the point that I took some of his ideas, incorporated them, and then he rebranded his docs for Zay-ES.

@atomix said: ---------------------------------- Communication feature & Problem Explained ================================== 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]!

Why is this bad? Generally, components are immutable. You can pass them around safely wherever you want. Components are just data… so they don’t “do” anything.

@atomix said: As in Network scenario, where message passing is nature. If you don't come up with something better than that: - You should have a listener implementation in your System. - Your system delayed the messages till its process its interested entities in meaningful way. Delayed here means save to memory or more specific a queue. - A queue is a blocking style of networking, so how this compare to non-blocking solutions? ( check AKKA for more inspired ideas)

Talking about Networking, I not talking about Multiplayer’s world where speard the entities data over computers (JVMs) that matter, because they are proved to be efficient and easily done in ES. I’m talking about the processing routine of the messages, suite for the ES architecture! Remember even if your POJO component are easily serialized, it’s not meant that the way processing them and sent via internet suite for nature of ES, or enable multi-threading at the same time!!!

So, to be clear: you aren’t talking about normal client-server networking here. You are talking about federated systems on the back end?

@atomix said: ---------------------------------- Script feature & Problem Explained ==================================

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:

  • Component are pure bean, also stand for a Type -> easy to inspect;
  • Entity in other hand are index, composions of Types with no contract to have relationship to each other.
  • System are what ever not Component and Entity, no need to inspect that;

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.

I’m trying to figure out why one would want to do this. In my case, I expose the ES more than this in the syntax. I think it’s a good idea to make it clearer what is going on. At any rate, if you want to wrap components in nice setters or whatever then that’s something I think you’d want to control. There may be some components you don’t want to expose this way, after all.

In Mythruna, my groovy scripts look a bit like:
[java]
someEntity = ed.createEntity()
someEntity << new Name(“foo”)
someEntity << new ModelInfo(“bar”)
someEntinty << new Position(x,y,z)

prinln “entity position:” + someEntity[Position.class]
[/java]

This way I avoid the “import world” problems of a more overaching scripting API.

For most common scripting functions, I’ve actually wrapped things in a nicer API that manages the components necessary and so on. So to create an object (like a placeable object or item) you call createItem(“book”) or something similar. There are template entities that then define how the components get put together for that entity.

@atomix said:

–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.

PSpeed says: (not sure why formatting gets screwed up here)
Runtime errors are impossible to avoid in scripts.

Yes, there are cases where a script would need to check for the lack of a component. Just like a script might need to check for a null property.

That’s one place where groovy is kind of nice.
println myEntity[Name.class]?.name

@atomix said:

[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.

By Scripting, I mean employ existed JVM language technologies, not one write by our own self.
It’s too error prone and at last, when can I focus in game making anyway?

Pspeed says: (more formatting badness)
Yes, much of what you say is true but perhaps not as ugly. If you find you transform components a lot then you can add such methods to provide a new version of the component with those changes:
newPos = myPos.move(xDelta, yDelta, zDelta)

There is another thing about your example that is kind of subtle because I would never do this logic in a script. The physics system or some other system will already be doing this low level shuffling. Scripts mostly operate at the user level. They will generally only be setting the components that are the inputs to the other systems.

And to answer the question, this is precisely where you focus on game making. It’s not really extra work over a non-ES approach. We just haven’t spread it around to 100 different classes. It’s all in one place so it feels onerous. But say you chose to wrap up your entities in some nice script-facing interfaces… this is already work you would have had to do in a non-ES approach. Say you want to include validation and business logic in those interfaces… this is already work you would have had to do in a non-ES approach. If you want these things in your scripts then you can have them.

You undo some of the low level decoupling but you are only doing it at the “user level”. All of your systems and other code can still be taking advantage of the decoupling.

It’s true that you can’t just throw your whole object model at the scripting language and give the scripter total access… but I’ve always felt that’s kind of lazy and dangerous anyway. If you were writing C++ code and exposing things to lua you wouldn’t do it that way either. So that fact that we just expect everything to always be there is kind of us being spoiled a bit.

@atomix said: ------------------------------------------------------------------------------------- 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: 1) The way they query Components in Script (not as clear as a relationship but as a named piece of code, Ex: CarWheelsScript) 2) Script help to define outter relationship between Entities, also worth to mention in Unity is native to have entities relationship, such as to form a SceneGraph or link Material to is Mesh. 3) Script define extra meta component, As public Wheel[4]; in script appear as a four Wheel component in the GUI 4) They eventually have event hook, I suppose lied in in a specific System. But they can script it! onInit(){ } // for example

Notice: Here I try not to mention Unity too much as an AAA game engine, but an ES implementation candidate.

Pspeed says: (more formatting badness)
I have event hooks in my scripts too but they are for game-level events and not entity events. “Player joined”, “world cell changed”, etc.

I’m not really familiar with Unity’s solution here so I can’t comment too much.

Yeah, I know you try so hard to help people around, so if eventually you don’t have time I will take your comments and statement and carefully bring it to the wiki with your observation.

I see my points are too long, but I can’t help because ES as the core, it should work with others…
Now to let the points a little bit more pratical and short, please answer one by one as in an interview:

Limitation

  1. Big table problem : noticed that your ES is kind of in memory database and resembling a lot of table indexed database concepts; table database have “big table problem”; the problem is not meant “bad case” but “a problem to solve”; as the way indexing really have to speedup and caching efficient for lookup or query. How your implementation of changeSet or other compare to a common database solution( usually with an index tree or special kind of data structure); or just a naive approach.

  2. Sercurity : This is not a COP problem but an Puredata ES problem. Because of no encapsulation, no private, the System have all power over the Component; almost no java power to protect sensitive data…; is there any java way to prevent bad intended threat… [This is long, may be I will revise it more detail in other topic]

Expanable

  1. GUI enable: Can your component, entity or system modeled / composed via GUI tools, if can, is there any tools like that availble freely (except in your Mythura)

  2. MVC : Any idea of let your component to be use as “GUI” component in an MVC architecture which familiar with Java devs.

  3. AIs: We almost don’t want to write an AI libs but use existed one. How can an java AI library; with an AIProcessor (general speaking) usually assume that the component is mutable work with your immutable components…

Enterprise enable

  1. Guice, Spring enable: Can you system and component be config, load, init by Spring or any dependency injection framework. We need this because the In app purchase or other service normally come from outside, as delayed by nature service.

  2. Transaction enable: noticed that your ES is kind of in memory database and resembling a lot of database concepts, what about transaction. Why we need this in a real-time enviroment because the game world in server and client can be conflict and need a safe way of fall back…

@pspeed said: I don't think anyone ever said it works in all cases. That's just hyperbole on your part.

However, often when someone says “It isn’t the best fit in all cases” what they are really saying is “I’m not really interested” or “I don’t understand it”. So it’s worth asking the questions on why it doesn’t fit or pointing out examples where it does fit that might be similar to their space.

The original OP was supposed to be about the Pro’s and Con’s of ES.

My original post was asking about where ES falls into the categories of “Good design choice” / “Bad design choice”. Pretty simple idea. No one design pattern is a catch-all. Period, end of story. However, if you review this and every other thread on the subject (here at least), it is touted as so.

This makes me question the validity of the responses… you have set yourself up to be A definitive authority on the subject.

So, if you can’t talk to the “when you shouldn’t use ES” side of the equation… I think it is important that people consider the source as being biased and unreliable due to this bias.

I pointed out a quote from the original post having to do with COP inevitably doing away with OOP and received a ration of SHIT for doing so.

The statement was wrong and will mislead people. It was fan-boy-ish and worth pointing out so people don’t just blindly say yes… OOP will be replaced by COP. I must comply…

Now, I would really like to hear where ES fails. If this can not be answered here, then HERE is NOT where I should be looking for answers.

@atomix said: Realworld problems: Split & Asset(Re)Sampling & Re-link ========================================================== Real Example:

You have 10000 of car, each car with 4 wheels, each will be processed/ served as an entity or a Component of the PhysicSystem.

Approach 1: as Entites [normal approach]

  • You have to split your model to 4 separate wheels and body 3d Models.
  • Make 5 entities!
  • Then link them by ad-hoc script define entites relationship. May be in the System.
  • After that copy to ten thousand instance link to a single parent Prefab of 5 entities.-> 50000 entities!

Approach 2: as Components [ugly as hell, but good for script]

  • You have to split your model to a separate wheel and body 3d Models.
  • Make 1 entity!
  • Then has BodyComponent; 2 MeshComponent point to the Wheel, and Body; 1 FourWheelCarPhysicComponent; or 4 WheelCarPhysicComponent
  • Then ad-hoc script define Components relationship.
  • After that copy to ten thousand instance of a single Prefab of single entity.

In approach 1, System process entites and consider their relationship in meaningful way. Script spread ad-hoc relationship between entities, which will suffer re-link problem later.

In approach 2, System process entites and consider their component relationship in meaningful way. Script spread ad-hoc relationship between components, and terminate pure-data specification. But the script work intuitive per entity, re-link is avoided because the script added in Prefab.

In this example, first you can see the Split and DuplicatedComponent problem because ES naturally denide Component relationships, and the split sometimes unclear.

Asset(Re)Sampling problem happen:
when you change the car to 5 wheels, and have openable windows.
You have to:

  • Split the Windows in 3D Model.
  • Change your script/ code to re-define the relationships again.

Remember the root reason is your Data (real data) is sampling by your component description, and in addition, no Class concept existed. And this is a strict contract. So it result in 1-1 change per entity!!!

Also notice, the same situation is not strict in OOP world, so may be n-1, 1-n, m-n,… but usually if you change your whole class than your every Car (10000 of them) is good!

In Unity for example, they have Prefab concept to ease out the Class concept. Almost everytime, Prefab can replace Class.

But when the Prefab relationship is lost, eg: add the openable windows to 5000 of instance, not in other 5000 after their position is inplace. Even we can make 2 prefabs for each kind of car, we can not solve the top-down (one direction) relationship between Prefab and instance again at this momment. This called the Re-link problem. So you end up re-do 5000 of cars with a new Prefab. The same frustrations happen in almost non-predefined component.

You can also see a lot of these kind of problems in a database modeler’s everyday life. Modeling, resample, remodeling, imigration can cause frustrations if there is no OOP built-in support!

Spatials/Physic objects…So where you save them anyway?

In Unity, they have a Assets singleton where save a serilized version of the objects with a “hash index” to look up them when need, resemble our AssetManager but more Meta-type and directory (tree) fashion. So technically, they not save the object in the Component but just a link to its source!

In fact, not too much people have this mistake because almost every engine have sostiphicated way to manage their assets, their also just save a link.

So, one thing to remember is that the ES is only managing game objects. Spatials are not game objects as they are views… and I think this is where a lot of people get into trouble.

In your car example, the only reason you would split out wheels as separate entities is because there will be systems dealing with them as separate entities. The physics, damage application, and so on are all dealing with wheels as their own entity. Your visualization system may or may not be dealing with them depending on how you’ve laid your model out. If your 3D model includes the wheels then your wheels probably do not have a visualization info component.

When you come back to add a fifth wheel then only the game logic side is what needs to change. This is the part that’s hidden in these examples. None of the other systems needed to change. Physics didn’t care. Damage application didn’t care. In some cases even your visualization system won’t care. Either you have 3D wheels separate from the car or you don’t. If they are separate then now they show up for free. If they don’t then you update your 3D asset to have a fifth wheel.

The only part that needs to change is the game logic. And personally, that seems like some kind of heaven to me. I only have to change the code in the places that actually care about what the entities are at the game level. And really, in this case, only those parts that care about wheels in the first place.

Personally, I have an ES based set of template components that implement a game class hierarchy. These templates are just entities like anything else. I have an API for create these game objects that creates the entity and then populates them with their components and script hooks from a full class hierarchy (even supports multiple inheritance and calling ‘superclass’ logic).

This kind of thing is largely game specific, though. And rather than writing 80% ‘not about my game’ code as I would have to do with an OOP approach just in boiler plate… it’s more like 90% ‘completely about my game’ code with only a small amount of boiler plate.

I could show examples but I risk having to defend my particular design approach versus addressing the more general concerns. There are many ways to skin this particular cat… the nice thing is that with an ES you tend to have to do it in fewer places. And where you do it is closer to where it makes sense.

@t0neg0d said: The original OP was supposed to be about the Pro's and Con's of ES.

My original post was asking about where ES falls into the categories of “Good design choice” / “Bad design choice”. Pretty simple idea. No one design pattern is a catch-all. Period, end of story. However, if you review this and every other thread on the subject (here at least), it is touted as so.

This makes me question the validity of the responses… you have set yourself up to be A definitive authority on the subject.

So, if you can’t talk to the “when you shouldn’t use ES” side of the equation… I think it is important that people consider the source as being biased and unreliable due to this bias.

I pointed out a quote from the original post having to do with COP inevitably doing away with OOP and received a ration of SHIT for doing so.

The statement was wrong and will mislead people. It was fan-boy-ish and worth pointing out so people don’t just blindly say yes… OOP will be replaced by COP. I must comply…

I believe it was based on some collective literature that is based on systems that over time have become unwieldy or collapsed under their own weight. I will let the original stater defend it, though.

@t0neg0d said: Now, I would really like to hear where ES fails. If this can not be answered here, then HERE is NOT where I should be looking for answers.

Never mind for a second that this premise is just a little flawed…

It is a bad design choice where:
-there aren’t many entities and/or the behavior is so clearly defined that you’d just implement it one or two classes. Thing card games, a lot of puzzle games, etc…
-the game is so simple that it’s just implemented as JME controls and a few app states. You could use an ES here but it would be wasted.
-the game logic cuts across all objects nearly all the time. (I think of card games and puzzle games again.) This usually implies that there are few entities, though.
-the team doing the work will have trouble understanding an ES. To me this is a huge one. Sometimes our choice of technologies is not dictated by what might be technically best… but what is technically best for the skills of the team. For example, if your artist only knows Sketchup then Blender is probably not the right tool even if it is superior in many ways.

To the premise, let’s pretend for a second that we are not talking about ESes… they don’t exist. OOP is new and we are talking about OOP and it’s beauty over procedural programming. Can you come up with examples of where OOP is a bad design choice? It’s tough because there are very few examples of where OOP is a bad choice (any?). It may not always be the optimal choice but history has shown that it is rarely a bad choice.

1 Like
@t0neg0d said: I pointed out a quote from the original post having to do with COP inevitably doing away with OOP and received a ration of SHIT for doing so.

I think he was referring to this article:
http://gamearchitect.net/Articles/GameObjects1.html

…and was perhaps being a bit hyperbolic himself to provoke a response by the ES defenders anyway. That’s how I read it, at least.

Anyway, your original response did not read that way at all.

I will attempt to summarize how I saw it:

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).

Summary: hey, guys, MMOs are dead anyway so what does it matter? At any rate, not directly related to ESes. Fun but I didn’t see it deserving of response.

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.

Summary: if you aren’t scalable then it’s just a design choice. Wavy hands: “OVERHEAD!!!”

So, on the one hand, you stated that it’s sort of a team choice. On the other hand, you mention some mystical overhead without backing it up. I’ve been in these threads with you before so I hate going down that road. The mythical overhead is a favorite beast.

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 :wink:

Summary: a bunch of insults to the responses so far despite the fact that I put a lot of time into helping people with ES questions. A lot. More than any other single topic on this forum combined.

It doesn’t sound like someone who is actually curious about what an ES is or why it is good. It sounds exactly like someone who is looking for a good excuse not to use one. Thus my initial response that you should probably just move on.

@t0neg0d said: I pointed out a quote from the original post having to do with COP inevitably doing away with OOP and received a ration of SHIT for doing so.

The statement was wrong and will mislead people. It was fan-boy-ish and worth pointing out so people don’t just blindly say yes… OOP will be replaced by COP. I must comply…

Now, I would really like to hear where ES fails. If this can not be answered here, then HERE is NOT where I should be looking for answers.

If you read carefully I already go directly in the Cons and a lot of real-worl problems.

My statement
“COP is undeniable trend in the next decade”…
I will keep it, but not so forcefully! Keep in mind I have enough knowledges and experiences to say it personally. But I can change my mind soon because the ‘trend’ is somewhat un-forecast-ble. So don’t focus in the wordplay too much plz.

I also have to mention I have graduated in protecting my papers about Data oriented architecture (but ‘look carefully’) in OOP! with Oracle’s EJB and SOAP…

Data oriented architecture is the architecture focus in Data, even codes, configs are data and eventually have a repository of everything… That’s true! But it’s OOP;

COP is some what raise because of the trend in CPU, GPU architecture and programming artifact evolve with COP interest become bigger. That’s true also! Now even big game company are urge to learn more about COP to catch the trend (in fact, for 10 years already).

You can have different perspective because you don’t see what I see, hear what I hear… I understand and I don’t even correct you if you think different. I’m not a fan boy in any way, don’t make me use un-kind words which is not necessary in any situation. Thank!

OOP to COP . or else?

As said, as a long term java developer and also an artist. I can not see a strong, confident reason why we should switch over to COP at the moment.

BLOB is not a problem with a carefully designed software, same as hard as split your components… Deep inheritance even multi inheritance problem can not be reached in an indie project, and even it reached, maintain it always easier than redesign a 3D model to change the export pipeline!!!

If you see java as a failure, try Scala’s trail …

Also the tangled wires between inheritance form the nature of programming and matter in the universal. :stuck_out_tongue: They have IDE support, profiler, proved technologies, lot more… We talking about a no IDE support paradigm with plain text editor, table and some black magic, tell me more about the company will approve your plan?

If you know EJB and Spring, you will not bet in home grown ES, dont you? Take a look in other alternative technologies. Take a look at reference [7] and http://lambdor.net/?p=171 , the guy suggest you to switch to Functional reactive programming :stuck_out_tongue:

But I have to admit COP is an undeniable trend we all head to in next decade, as modern GPU and CPU employ batch and cached processing techniques a lot more each years…

I quoted my own text for sake of clarify, I also said in COP and ES eventually not worth a long term marathon for serious mid-size company who try to do AAA titles. I’d not to also as indie, because I want to get investigated by some guys need ISO and proved techs.

The debatale and questionable statement about “the trend” is un intended and I should underline “I have to admit” - that already meant “personally” in my language. Peace!

@atomix said: I also have to mention I have graduated in protecting my papers about *Data oriented architecture* (but 'look carefully') in OOP! with Oracle's EJB and SOAP...

Data oriented architecture is the architecture focus in Data, even codes, configs are data and eventually have a repository of everything… That’s true! But it’s OOP;

Note: I think you are confusing “data driven” with “data oriented” in this case. I could be wrong. I’ve made the mistake myself so many times now that I watch out for it. :slight_smile:

@atomix said: COP is some what raise because of the trend in CPU, GPU architecture and programming artifact evolve with COP interest become bigger. That's true also! Now even big game company are urge to learn more about COP to catch the trend (in fact, for 10 years already).

From my perspective, data oriented approaches were to address the trend in CPU, GPU architecture. But “data oriented” alone tends to focus down in the weeds and to me the ES/COP was a way of abstracting it up a little into the larger application architecture. And then the ES provided other benefits in addition to the hardware aspects.

In Java, we can nearly ignore these hardware improvements anyway. As I stated poorly previously, I use this idea as sort of a guide post on whether my design is correct with respect to ES ideals. Other than some minor gains from fewer method calls, I don’t expect to gain too much performance in some cases. But I do expect gains.

Though often rethinking the problem changes the performance dynamic to the point where it’s no longer an apples to apples comparison and so it’s tough to directly correlate results. The “objects in tower range” was a great example of this. How can we compare the overall performance of a query against a data-oriented approach that does away with the query? It’s hard.

@atomix, I start to wonder if in retrospect these threads might be easier to follow if they’d been split up from the beginning. Of course, if you had spit them then maybe now we’d be wondering why we have to repeat ourselves everywhere. :slight_smile:

I think this kind of topic is where I miss tree-style threaded replies the most.

@pspeed said: To the premise, let's pretend for a second that we are not talking about ESes... they don't exist. OOP is new and we are talking about OOP and it's beauty over procedural programming. Can you come up with examples of where OOP is a bad design choice? It's tough because there are very few examples of where OOP is a bad choice (any?). It may not always be the optimal choice but history has shown that it is rarely a bad choice.

Well… anything that is procedural in nature. TransactSQL and PLSQL are good examples (scripting or not… there is no need for object-based design).

But, this goes back to process or data… if data is the key… then ES would work well. If process is the key, is it the correct choice still? I would think not.

JME is OO as apposed to CO. Why is this? (Please do not read into this question… I’m being serious)

@t0neg0d said: Well... anything that is procedural in nature. TransactSQL and PLSQL are good examples (scripting or not... there is no need for object-based design).

Except those are procedural because they predate OOP. Also, it doesn’t make OOP a “bad” design choice. Just a perhaps less optimal one for implementing SQL. (Though ironically modern SQL is often implemented as oop-based state machines… but I digress)

Many object-based query solutions exist now that in the OOP domain are superior because they lack the tenuous mapping required. Furthermore, most of the UIs are OOP now and the OOP can have preconstraints on how the queries are constructed.

Also, SQL almost straddles the line between procedural and functional. While it’s not purely functional, it does lean heavily that way.

@t0neg0d said: But, this goes back to process or data... if data is the key... then ES would work well. If process is the key, is it the correct choice still? I would think not.

If the process can be broken down into data-oriented steps then there are still benefits to an ES approach. Both in performance and in simplicity.

@t0neg0d said: JME is OO as apposed to CO. Why is this? (Please do not read into this question... I'm being serious)

Because it’s more familiar and it predates CO. Actually, a 3D API would gain a lot of benefits of a data oriented approach and an ES is a logical way to get there. Scene graphs are good examples where data-oriented operations are done poorly because of being shoe-horned on top of an OOP structure. Think about the update traversal and how much easier that would be as a tight loop over all active controls rather than a graph traversal.

Still, OOP is nice for modeling hierarchies of relationships and that’s what a scene graph is. When you often have to go forward and back over your entire graph, an ES starts to become cumbersome for those operations.

However, I even start to wonder if this is my scene graph prejudices speaking. If the transform hierarchy could be solved in a friendly ES way then maybe there is a nice equivalent CO solution. At the bottom, it’s just a data oriented loop anyway (see: GeometryList)

Confusion… So, let me get them straight;

Data driven solution (architecture) is a software solution (architecture) where everything is from data and to data!
http://www.enterpriseappstoday.com/business-intelligence/3-rules-for-data-driven-architecture.html

For example in programming level such as Java:
You java code is generated from data model, your database structure is generated from data model, you spring configs is also from there… When you change your data model, the other be changed by re-generated acordingly.

In some alternative solution, they use Bean to represent the Data in Data driven solution, like in EJB, Data and its persistent nature are abstracted out of user level. What user see is just primitive data manipulating with get and set. This is where ES share the same point of interest, whenever an Component of pure data ES should also be modeled that way.

But data driven architecture is other than generative data;

In Enterpise level in real world products and systems, it’s also include technologies that perform report, analysing in data; call data mining to serve that enterpise. The architecture of that specific software system also called data driven architecture!

Data oriented architecture is focus in Data arrangement (delay of data and the dataflow) and everything is Data, with a repository! It have more aspects than Data driven architecture and not talking about “the force of generative data”.

In hardware level, data oriented appear in structure and operations of chip set, when input and output are carefullly design to get batch/cache efficient.

In software level, programming language such as Java:
Data oriented architecture appear as we save everything in a big repository (database… or file repository) then retrive it to do operations.

Important note, the consideration that everything is Data is very important. We can load everything as data, code, configs, signal from network, service…
Second the existence of the repository is also important, as it the premise of other concept about ports, dataflow, stream, event, monitoring etc…

Compare to service oriented, it care more about the delay of data and the dataflow, not the operation.
Compare to object oriented, it just only have the data concept, not object, instance or what ever…

Data oriented architecture usually envolve every generic way to descible data, common via XML. They also usually use a data oriented architecture as the base of other.

So normally Data oriented architecture go along with Data driven… but they are two different thing!

More about Data oriented architecture:
As seen in hardware level, the signal in send in CPU as the repository, via ports, in a stream, trigger interrupt as Event,…

The same in a software level system, in Java world such as Oracle’s Buisiness Process Management (BPM). They essentially use XML to describle everything and consider everything is Data, also have concept of Ports, Stream, Event… ect. But of course Oracle solution are much more complex than a single chipset, as it also envolve EJB, SOAP… with also an candidate for “Data driven architecture”… That’s why so much people in java world get this wrong at first. But EJB and SOAP are essential pieces of BPM, and that’s what I protect in my paper.

Note: I think you are confusing “data driven” with “data oriented” in this case. I could be wrong. I’ve made the mistake myself so many times now that I watch out for it. :)

Yeah, may be you think I said EJB and SOAP is “Data oriented …” but it should be more a like “Data driven…” piecies
What I really wanted to say is: I do know “EJB , SOAP” is “Data driven …” but they also peices in “Data oriented…” such as BPM! Clear? :stuck_out_tongue: