I believe others will need them anyway after all these duplicated conversations about Entity System. For the sake of clarify, @pspeed and guys can help me to correct the terms and ideas of the category, as I my self 've read tons of papers and codes, struggle to let the COP drug run through my neurons…
This should also end up a better wiki page with categorized ideas and corrected explanation!
Categories of Entity System and Comparasion between implementations
Introduction:
Basic idea of ES : Entity, Processor(System), other terms.
Core elements and its alternative
What is NOT an ES…
Why, when, where ES matter.
Pros - cons?
Know issues
OOP to COP
Change of mindset
Implementation, and scope of each projects:
Initial philosophy
Pure data or not?
Multi-threading, concurency enable or not?
Communication: Event messaging enable or not?
Is database (and other kind of persistent) friendly or not?
Is enterprise friendly (expanable/ extensible/ modulizable) or not?
Script possibilities?
Restrictions and limitation
Dependencies
Current status: Long term, stable, community?
[More]
[HELP. Really need a concise definiton here!!!] Component:
Entity
System
System = everything that isn’t an Entity or a Component but uses Entities and Components.
Ideas similarity:
from Component oriented architecture:
Decoupling
Reusable
Primitive Unit
from Data driven architecture:
Data who decide
from Data oriented architecture:
Everything is data
Repository existence
Homogeneous data
Regular workload
Simple dataflow
The ideas similarities here actually is resulted from with decades of history of revolving of the paradigm. Check Pros and Cons chapter for full idea and design goal and success.
Short explanation
Decoupling : each piece can work together without aware of each other.
Resuable : can be easily bring to use again somewhere else
Primitive unit : each piece from a simplest form which contain, fullfil it self.
Data who decide: data decide each and every result, activities of the software
Everything is Data: all piece in the software system is Data
Repository existence: exist a place to keep all the data, the one door to reach them
Homogeneous data : data is treat the same
Regular workload : software that run at regular rate, kind of ballance trade off between performance and complexity
Simple dataflow: the flow of the data is easy to watch, inspect, start stop, manipulate. As the root reason for regular workload!
Other terms. (short)
Object Oriented Programming
Object-oriented programming (OOP) is a programming paradigm that represents concepts as “objects” that have data fields (attributes that describe the object) and associated procedures known as methods.
Component Oriented Programming
This is “the rising force” we are talking about!
It’s a “rather new” programming paradigm. Despite of its name and even the fact it’s was born from the marriage of “Component base architecture” and “Data oriented architecture”, but something different.
COP’s Entity System in OOP java
Entity System in turn is the Core and fundamental and most obvious implementation design of COP!!!
In fact the implementation detail of Entity system is various, some may resembling database core, some may have troubles with OOP incompatibility, some may appear to get all the good of Functional language…
but note that Entity System really stand on its own terminology on this single page: We are talking about the ES within COP, but implemented by an pure OOP like Java.
Data driven programming:
You may refer to this “Data driven programming” incorrectly in this ES topic, you may talking about: Data driven design insted
In computer programming, data-driven programming is a programming paradigm in which the program statements describe the data to be matched and the processing required rather than defining a sequence of steps to be taken
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.
Data driven solution (architecture) is a software solution (architecture) where everything is from data and to data, data who decide!
It has the “data force”, that’s why it call ‘driven’, the force sometime a “generative force”!
Data oriented (design) architecture:
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.
From atomix 's overview:
Data oriented architecture is focus in Data arrangement and process(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, process, 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.
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, Process…
So normally Data oriented architecture go along with Data driven… but they are two different thing!
Why so much people in java world get this wrong at first?
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 . But EJB and SOAP are essential pieces of BPM “Data oriented architecture”!!!
- Core elements and its alternative
From more open perspective the core elements can be viewed as, but remember the name as a noun can be mislead:
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.
This often result in mislead skeption about the design. So get back to read it carefully one more time and some gotchas and practical wisdom below.
- What is NOT an ES…some insights and pratical wisdom
This area contain some best gotchas and practical wisdom when working with ES.
System ~ Processor?
In a pure ES, this is not a thing, really. Some implementations force this on you because they couldn’t think how to do the ES job efficiently… but it’s still not a thing. All of your code that isn’t an ES is a “system”, technically.
System = everything that isn’t an Entity or a Component but uses Entities and Components.
Entity ~ GameObject?
Entity should just be interpreted as a bunch of its Component. GameObject or anything else represented by an Entity is by accident. So no force to represent “all-every” gameobject as Entity; and no force that “all-every” Entity is gameobject.
Has ~ Is?
From software designer POV, Relationship in COP is a sensitive topic; by nature, Component is against (or overide) Relation.
The deception ‘Has’ relationship between Entity and its Component actually represent everything in various meaning from the literature ‘Is’ , or literature ‘Has’… to ‘related to’. BUT keep in mind, this is blury and its almost always implemented as indirect acess, not like a property in an object but envolve processing-lookup under the curtain! So you may find this difficult to extract and detect these different from your tranditional OOP software design!
[HELP!!! Need more of this]
- ES Done right?
Because this topic is so debatable, there is no solid candidate for ES done right now in my POV, but Zay-ES and Artemis are closest one, Zay-ES a little bit better as its the later born.
Theoricaly an Java ES done right should be: - Pure data :very debatable
Mutable : as bean with setter and getter
Immutate : as bean with getter, should be replace if changed. - Multi-threading, concurency enable : very debatable
As my experience, pure data or not is not clear contract to multi-threading success. Consider other things happen outside of ES scope, so it not an solid waranty that those component will not be touched by any other thread.
Also if there is a contract that no other thread touching those data, in Java style via synchonization or other paradigm like actor… multi-threading also consider success but just more complicated! - Communication: very debatable
Event messaging enable
No event or messaging : update beat, no need of inter-com or events. How can we do network messaging? - Is database (and other kind of persistent) friendly
Save to XML?
Send over network?
Change sets are resembling Databse concept, what about tranactions? - Is enterprise friendly (expanable/ extensible/ modulizable)
Spring, as lazy loaded, injected? - Script possibilities
Can be script, non trivial work in pure data!
Can be use with other JVM language than java like groovy, or scala, jython? - Restrictions and limitation
No dynamic Java object methods in Component ? What about Entities and Systems ( Processors)
An overal way to manage and config Systems, freely chose? How to hook to its routine? - Depedencies
The separation of components are clear, as no dependencies at all. Hard cored, scripted or injected will break the overal contract!
The separation of Entities. What about depedencies of entities? Ex: parent/ child relationship in JME spatial. How the framework handle that?
The separation of Systems. Ex: any contract about that?
BLOB aka The fall of inheritance: Complex type can not be represent as class in java OOP!
Tired of OOP. Compose over old-skool programming . Like artists.
Reusable via prefab (well, this is very debatable as compare OOP!!)
…
When?
Trade off between complexity and performance is carefully considered.
Input and output are well setup. Assets are all in good format, output are well defined, workflow and routines are fixed. Seen in commercial 3D game engine.
It’s easy to get it wrong as you often come from OOP world (of course, because you are Java developer).
Can result in done wrong too much time, that un affordable!!
It’s not an certainly proved technology (that why we here)
Its have bad issues
Only suite for cases (not every)
No good IDE, GUI support in Java or JME3 world currently
When not?
Limited time and first try! ( can be good if in limited time but ES is production mode ready)
Small game, simple gameplay …
Pros – cons?
Here, I listed the pros - cons of the COP and Pure data ES. You can see I try as the one who repeat sentences that speak out by others in various sources as a short manner! So this list and information need clarification of correction afterward!
No OOP: COP Done “right” means forget about almost all OOP things: Pure data, Class become Type, no inheritance, encapsulation…etc , no best of both world!
Spliting dilemma: Same with OOP Classify problem: How to split, how to change the data when you change the splits?
-Duplicated component: Same root as confusion in component spliting but, this problem about how can we made a more than one component of a kind per object entity… Ex: Car with 4 wheels, the component will be a 1stWheel, 2ndWheel, or a single list of WheelComponent… ?
Data resampling problem in game, data such as textures, text, 3d models everything … should be crafted: made, converted again to suite with existing data model - that’s the component in the ES.
Mindset change problem: One will have to re-code a fews time to implement an ES, in initial, half ass and full level.
Flat table problem: Because ES is a big table by nature, with component set is a row. It’s as efficient even less than a big table, which form the flat table problem as seen in many indexed base database. Tree, Graph and other data structure will almost immediately break the ES contract!!
Observation problem: As update beat over listening method, ES restrict the observation methods a lot.
Sercurity problem : No encapsulation, kind of no private POJO mean no java power in protecting data, a lot of security holes! ES implementations and COP forget all about sercurity danger as Component contracted to be processed by Processor but not hiding its content.
Scale : In theory, ES should scale well…!!! But read this carefully or mislead it, enterprise system need much more than just a way to orginize your data!!! [Peace! :p]
- ES consider good design in real-time app?
Of course, ES has its mising features!!!
Read Pros and cons for more detail.
But for some reason its design 's consider good for real=time application like a “common” video Game, or “common” simmulation; especially common in MMO world.
Here is a short of ‘why’ answers from a software architecture designer view, explain based on its borrowed ideas: [This is very different from various source you’ve read, because it’s not embeded any implementation details!!!]
Decoupling : each piece can work together without aware of each other.
Resuable : can be easily bring to use again somewhere else.
Composable : each piece can work together
have fundamental relationship with decoupling.
Primitive unit : each piece from a simplest form which contain, fullfil it self.
have fundamental relationship with decoupling.
(*) These lead to advantages in development:
do it in one place only when doing implementation (coding, configs…), .
intuitive and ease of development jobs (compose entity with component drag and drop)
distributed jobs, assets
reuse data, code which in existed component
unit test
[more]
Data who decide: data decide each and every result, activities of the software
Everything is Data: all piece in the software system is Data
Repository existence: exist a place to keep all the data, the one door to reach them
(*) These open the world of complex gameplay and distributed persistent like seen in MMO. A single data change can result in change in the gameplay; a
Homogeneous data : data is treat the same
Regular workload : software that run at regular rate, kind of ballance trade off between performance and complexity
Simple dataflow: the flow of the data is easy to watch, inspect, start stop, manipulate. As the root reason for regular workload!
(*) These lead to a lot of simple but efficient algorithm to get high performance in runtime for a software such like a “common” video game, which run in console, GPU, CPU which envolve and share the same model with cache and batch intructions, an a certain hearbeat…Notice the bottleneck of CPU-GPU and between different processing unit, platform is the most headache of Game designer for decade is ease with the regular workload; let the game run smoothly and stable, result into nice visual representation…
- ES consider bad design in …?
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.
-----------------------------------------------------------
Known issues:
============================
Even if done right, the ES also have it underlying issues which noticed by its authors.
Communication:
Happen in non pure data solution, when Components don’t function independently of each other. Some means of communication is necessary
• Two approaches (both viable):
– Direct communication using dynamic cast and function calls
– Indirect communication using message passing
In pure data solution, by not query or just loop through interested component at one update cycle, the Processor eases out the need of other communication, but in complex scenario, such as combine with outter event handling such as Network, where message passing is nature, the problem still persist!
Script
The “script problem” happen by the same reason with the “communication problem” mixed with “pure data or not” problem. When an component is hard to inspect, its outter relationship hard to define and its property is rejected to change, how can you script it?
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. 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
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…
What should be change to adapt to this new paradigm?
This chapter dedicated to people still who really want to switch to this new paradigm after all the warning and awarenesses.
I’m not even sure where to start in commenting. I’ll just spew random things out…
Processor(System)
In a pure ES, this is not a thing, really. Some implementations force this on you because they couldn’t think how to do the ES job efficiently… but it’s still not a thing. All of your code that isn’t an ES is a “system”, technically.
Multi-threading, concurency enable
It’s a core and fundamental feature that each system gets its own view of the data at least at the collection level. This enables a form of loose concurrency and scalability similar to a database. This makes sense when you realize that entity systems grew up from data oriented designs where all of the data that a particular operator requires is packed tightly together in a cache friendly array. Data that isn’t needed isn’t included.
You application sometimes still needs to be aware that it is operating in this sort of environment but if the ES data structure doesn’t support threading then it is doing something wrong internally and you should be very suspicious. It is likely a poor implementation or they misunderstood the fundamentals.
– Event messaging enable
This is not an ES feature. It’s not debatable… it’s just not. It’s a hold-over from non-data-oriented OOP based designs. If you find yourself passing events around then that’s part of your systems and not part of the ES.
Data resampling problem in game, data such as textures, text, 3d models everything … should be crafted: made, converted again to suite with existing data model – that’s the component in the ES.
Entity Systems are used for game objects. Not scene graph objects.
Flat table problem: Because ES is a big table by nature, with component set is a row. It’s as efficient even less than a big table, which form the flat table problem as seen in many indexed base database. Tree, Graph and other data structure will almost immediately break the ES contract!!
I think this isn’t true but I’ll admit that I don’t understand it.
Observation problem: As update beat over listening method, ES restrict the observation methods a lot.
Observer pattern is an OOP mindset. If you find yourself missing it then your design is probably still broken from an ES perspective.
Communication:
Happen in non pure data solution, when Components don’t function independently of each other. Some means of communication is necessary
I don’t understand this one either. It’s never been a problem for me if I read it right.
Script
The “script problem” happen by the same reason with the “communication problem” mixed with “pure data or not” problem. When an component is hard to inspect, its outter relationship hard to define and its property is rejected to change, how can you script it?
I also don’t understand how this is an ES problem. I script against my ES just fine with Groovy.
This is a good example of showing a rethinking of the problem and how an “arbitrary routine query” is already a kind of wrong idea from the beginning. It’s a sign of missing components or missing system code. The “routine” part is what means you’re missing something in the design.
There may be cases but since they are inherently not data oriented, they already fall outside the scope of an ES.
@atomix said:
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?
For Zay-ES:
A pure ES that is high performance.
Pure data.
Fully concurrent.
Irrelevant.
Includes an SQL persistence layer currently targeted at hsqldb which is the best fit for its typical use-cases. It would not be difficult to inject other SQL dialect support. Moreover, specific components could be handled differently as needed with user-supplied adapters.
Ummm… sure, I guess… whatever this means.
All ES scripting interfaces will balance dialect with flexibility, I think. In groovy I was able to extend the meta-classes to support this but I opted for a less expressive but clearer dialect over property-wrapped hiding. myEntity << new Name(“foo”) instead of hiding it away like myEntity.name = “foo”… (though for common things like ‘name’ I actually did do it.)
Don’t know.
jme-networking for @Serializable but I plan to move this support out. I depend on guava, too, because everyone should.
Released and production ready. Network support coming soon.
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
@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
To those wishing to actually have a serious conversation about performance, you will have to point to specific issues and I can address them. I’m not going to get sucked into a “performance” hand waving exercise… or at least my stock answer will be “actually, many times performance is better.” The entire motivation of data oriented design is performance and simpler code… and the ES layer doesn’t suck that much away.
So, if you’re argument only amounts to “but there are performance concerns” then the answer will be “actually, many times performance is better.”
@t0neg0d said:
/agreed... and use FRP instead. As should everyone else. ;)
No, I recommend developers in general look into an ES with an open mind and see if they can understand it and if it fits to their development style. You’ve already shown that it is incompatible with yours so you should not use it.
re: FRP, functional programming is very data-oriented friendly. I suspect FRP and an ES would fit very well together.
@atomix said:
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 completely disagree with this statement. Bandwagon != Brainwagon
There are other alternatives to OOP… this is the current trend, not definitively the wave of the future. COP assumes that every application is data-DRIVEN. Data-reliant and data-driven are two totally different things.
@t0neg0d said:
I completely disagree with this statement. Bandwagon != Brainwagon
There are other alternatives to OOP… this is the current trend, not definitively the wave of the future. COP assumes that every application is data-DRIVEN. Data-reliant and data-driven are two totally different things.
Data driven != data oriented. Please just stop. You can spout off stuff without doing the research but it’s hard to keep responding.
Data oriented originally arose to achieve high performance on consoles where cache misses are a seriously bad thing. You do need to seriously stop hand waving arguments. Either present something concrete or just stop it. Bandwagon != brainwagon but also bandwagon != wrong.
If you don’t want to use it then that’s fine. But let’s continue to let others learn about if they want to.
@pspeed said:
No, I recommend developers in general look into an ES with an open mind and see if they can understand it and if it fits to their development style. You've already shown that it is incompatible with yours so you should not use it.
re: FRP, functional programming is very data-oriented friendly. I suspect FRP and an ES would fit very well together.
I disagree… I have not shown that it agrees or disagrees with me… I’ve argued points from perspectives that I don’t even necessarily agree with to see what the answers would boil down too. If answer = You just don’t get it… then answerer = full of shit and jumped on a bandwagon without properly researching the alternatives.
I have yet to have a conversation with someone concerning ES that did not end with “You just don’t get it”. This is the popular response in place of the more accurate one “I just don’t know”.
I DO agree that FRP would make ES far more attractive all the way around. It’s not the component side of COP (or ES) that bothers me… it’s the lack of consideration for the system side of things. You are free to make a total fucking mess out of these as long as you don’t break the ES code of conduct.
This is called extremism. i.e. I’m SO concerned about how I represent my data, that I’ll mismanage the fuck out of it in the process.
@t0neg0d said:
I disagree... I have not shown that it agrees or disagrees with me... I've argued points from perspectives that I don't even necessarily agree with to see what the answers would boil down too. If answer = You just don't get it... then answerer = full of shit and jumped on a bandwagon without properly researching the alternatives.
I have yet to have a conversation with someone concerning ES that did not end with “You just don’t get it”. This is the popular response in place of the more accurate one “I just don’t know”.
I DO agree that FRP would make ES far more attractive all the way around. It’s not the component side of COP (or ES) that bothers me… it’s the lack of consideration for the system side of things. You are free to make a total fucking mess out of these as long as you don’t break the ES code of conduct.
This is called extremism. i.e. I’m SO concerned about how I represent my data, that I’ll mismanage the fuck out of it in the process.
I try to answer all questions that aren’t already covered 12 times. I may start out with the “you still don’t get it” but then I respond with why. It’s important because breaking out of the OOP mindset is extremely (EXTREMELY) difficult.
I’ve been coding with my ES for over two years now and I catch myself still making this mistake from time to time. 100% of the time I break out of the ES model by accident I regret it some number of weeks/months later and have to go back and redo it.
You are hard to respond to because you never state specifics. You are kind of the master of FUD in a thread like this.
@pspeed said:
Data driven != data oriented. Please just stop. You can spout off stuff without doing the research but it's hard to keep responding.
Data oriented originally arose to achieve high performance on consoles where cache misses are a seriously bad thing. You do need to seriously stop hand waving arguments. Either present something concrete or just stop it. Bandwagon != brainwagon but also bandwagon != wrong.
If you don’t want to use it then that’s fine. But let’s continue to let others learn about if they want to.
This is actually pretty funny. It’s starting to teeter towards the “You just don’t get it” response.
Data driven really != data oriented. There is a difference. And employing a data driven architecture for a data oriented application is a poor design choice. Using ES just to USE ES is as well.
@t0neg0d said:
This is actually pretty funny. It's starting to teeter towards the "You just don't get it" response.
Data driven really != data oriented. There is a difference. And employing a data driven architecture for a data oriented application is a poor design choice. Using ES just to USE ES is as well.
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.
@pspeed said:
I try to answer all questions that aren't already covered 12 times. I may start out with the "you still don't get it" but then I respond with why. It's important because breaking out of the OOP mindset is extremely (EXTREMELY) difficult.
I’ve been coding with my ES for over two years now and I catch myself still making this mistake from time to time. 100% of the time I break out of the ES model by accident I regret it some number of weeks/months later and have to go back and redo it.
You are hard to respond to because you never state specifics. You are kind of the master of FUD in a thread like this.
How much more specific can I get?? My question was… See case A… isn’t ES overboard for this?
And you ignored my initial question… took a couple swipes at me… and here we are.
EDIT: See my initial post for the question part of the post (which was all a question…)
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?
