1) Introduction
- Basic idea of ES :
[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.
Data Oriented Programming
[This just not exist]
If you use Data-oriented_languages, you can call it Data Oriented Programming! You may talking about Data Oriented Design (Architecture) instead
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 solution (architecture):
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!
http://www.enterpriseappstoday.com/business-intelligence/3-rules-for-data-driven-architecture.html
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
-
-
- 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
-
-
-
- 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?
