Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (768)
Games in Android Showcase (230)
games submitted by our members
Games in WIP (854)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 2 [3] 4
  ignore  |  Print  
  Component Systems: Artemis style systems vs. traditional fat entities  (Read 44982 times)
0 Members and 1 Guest are viewing this topic.
Offline seismic

Senior Devvie


Medals: 4
Projects: 1



« Reply #60 - Posted 2014-07-24 05:16:01 »

Mhhh okay...Still not too convinced here I guess. Let's wait for that performance benchmark  Grin Grin
(Not that it matters too much because Artemis is already pretty fast? So if you want to use an ES you already have a pretty good option there imo)
Offline Roquen

JGO Kernel


Medals: 518



« Reply #61 - Posted 2014-07-24 07:36:27 »

To repeat myself: Problem dictates data.  Data dictates code.  If you do the reverse you're writing business software targeting mid-to-large companies with a faster turn-over of engineers vs. product life-cycle.  What you're not doing is "thinking low level, writing high level" which is needed for system programming.
 
Offline princec

« JGO Spiffy Duke »


Medals: 1053
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #62 - Posted 2014-07-24 08:58:04 »

Or, in 3 words, a solution looking for a problem.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Catharsis

JGO Ninja


Medals: 75
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #63 - Posted 2014-07-24 19:18:51 »

BAH!! You wouldn't believe what I've seen; beautiful accelerating heuristics dynamically unfolding through time.

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Offline Roquen

JGO Kernel


Medals: 518



« Reply #64 - Posted 2014-07-24 19:23:08 »

Proebsting's Law: Compiler Advances Double Computing Power Every 18 Years.

Don't write a system to guess what you know.
Offline Catharsis

JGO Ninja


Medals: 75
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #65 - Posted 2014-07-24 19:47:32 »

Technically what I've done is taking stock Java 5 language level features and inverting OOP on its head to make Java as functional like as possible without requiring taking the step of moving to a JVM based language to achieve this level of dynamic behavior. Runs everywhere including all versions of Android. The problem, having a large differentiated OOP SDK to deploy across the Android ecosystem, existed before the solution. It's nice that this direction also fully supports a fully dynamic CA based ES too without hard locking the API to one particular use case allowing dynamic optimization possibilities. I tried everything OOP (well except dependency injection; shudder / eh! We can at least agree DI reeks and is of the devil right?) under the sun to ease the pain before finding something that significantly eased the pain and brought joy to coding again. You too will have your pain eased in time.. ES4L!  Pointing ES 4 Life, Yo...  Cool

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Offline Riven
Administrator

« JGO Overlord »


Medals: 1356
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #66 - Posted 2014-07-24 22:36:47 »

I think it's fair to say most ES tutorials barely contain interesting information. They talk about Components and Systems for: position, velocity, sprite, health, and that's about the depth of the article.

The problem is that these things are no problem whatsoever in OO, when using encapsulation/composition, where you can toggle functionality at will (using inheritance is a rookie mistake). This approach obviously doesn't scale with the number of components, but... does it need to scale in this manner?

What would be a simple use case for a game with limited scope, where an ES clearly excels over proper OO? Given your lengthy posts, ESs are clearly saving you enough time to elaborate, yet again Smiley

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline princec

« JGO Spiffy Duke »


Medals: 1053
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #67 - Posted 2014-07-24 22:41:51 »

lol Smiley

The "classic" use case in games is particles. There are usually a lot of them.

Cas Smiley

Offline Catharsis

JGO Ninja


Medals: 75
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #68 - Posted 2014-07-25 01:47:36 »

I think it's fair to say most ES tutorials barely contain interesting information. They talk about Components and Systems for: position, velocity, sprite, health, and that's about the depth of the article.

Indeed it's a bummer that most ES articles are so basic. The ones that are out there for Java at least are far more speculative than data oriented in benefits and lack implementation details.

The problem is that these things are no problem whatsoever in OO, when using encapsulation/composition, where you can toggle functionality at will (using inheritance is a rookie mistake). This approach obviously doesn't scale with the number of components, but... does it need to scale in this manner?

We agree that composition is the bees knees so to speak. A CA and thus ES brings implicit composition to the table and there are benefits to having this in the toolbox in addition to normal explicit composition and even a touch of inheritance, but not as a central organizational mechanism. The current Java ES implementations more or less have very limited CA features.

You get this sort of scaling for free built into a proper CA.

What would be a simple use case for a game with limited scope, where an ES clearly excels over proper OO? Given your lengthy posts, ESs are clearly saving you enough time to elaborate, yet again Smiley

The chitchat monster is a demanding beast. As mentioned a limited scope game where no design changes are expected OO design is perfectly suited for the task.

The CA aspects are what really make things a pleasure during development. I'm not necessarily speaking about the currently available Java ES implementations. A lot of the killer use cases for me are modularization at the SDK / engine level which goes beyond the game focused limited CA ES implementations available.

In my efforts these are the things I like:

- Similar to Spring and such TyphonRT features a declarative loading mechanism to load up the runtime from external configuration files. This is great because conditional dependencies are externalized and not peppered through the codebase. System components can self-wire themselves and traverse implicitly the entire runtime environment let alone ES specific use cases.

- I use XML for the config files since it's available everywhere, but really it can be replaced with anything including a binary format. The really cool thing especially considering Android Studio Gradle integration in regard to build flavors is that it's super simple to provide just one XML file defining the app and completely load different functionality for product versions or any other mutation in development via providing a new flavor that simply has a different app XML config file rather than duplicating a code base. This is also very useful for multiple developers working on a shared codebase since new development can occur in parallel with less disruptions or requirements to embed factories and nasty other hacks to not disrupt developers depending on the old codebase while the new one is in progress.

- In combination with implicit message passing it's possible to completely separate dependencies between system components while maintaining functional connections. This isn't new and aligns more closely with Alan Kay's original ideas on what constitutes OO design if anything. Getting away from the listener pattern is key in conjunction with a CA / ES. This is something that bums me out when I look at Ashley since it uses the listener pattern which reduces flexibility considerably.

- Velocity of development is much faster with a proper CA and code changes don't require large refactorings. It's great for rapid development where data can be implicitly passed around.

- It makes large codebases manageable along with providing the basis for explicitly knowing dependencies of code at hand and being able to limit side effects. This valuable in testing and multi-developer environments. Get something working 100% correct and know with certainty that there are no unintended side effects with code changes not linked to the modules at hand. This includes keeping individual classes small and understandable.

- A CA provides dynamic / functional like characteristics that run on all Java platforms maintaining type safety which is a huge boon over scripting languages in general.

- The CA provides a standard API for accessing logic and data and there is far less method based boilerplate creation. While the concepts need to be grokked by devs it is consistent.

- As mentioned by others data components are DAO and facilitate journalling, serialization, and concurrency concerns.

- CA supports tooling better than rigid OOP code bases.

- A proper CA provides the magic sauce to implement runtime modularization that goes beyond the service pattern (re OSGi). A fast / dynamic CA implementation plays nice with OSGi and other future modularization frameworks.

--- I can go on, but indeed I procrastinate and have some work to get back to.. ;P

I think it's something that once you really need it and give it a go it's hard to return to old development practices when possible. I constantly get bummed out when I do any client work as most of it is very bottom basement regarding OO design. Re: 90's are calling and they want their design patterns back.

The "classic" use case in games is particles. There are usually a lot of them.

Modeling particles as objects is obviously not the proper way to handle things nor is it appropriate with ES on a per particle basis.

Being able to attach to any entity a single data component with an array of particles being tracked is nice without having to add accessor methods / explicit composition.

---

Building a next-gen CA / ES is not easy and very time consuming... Using a well constructed one for dev for games or otherwise is liberating.  A lot of this is still forthcoming for Java. I'm an early adopter so to speak. I look forward to getting my CA / ES efforts out in the wild.

The chitchat monster says I'm being baited.. ;P again... :: sigh ::

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Offline Roquen

JGO Kernel


Medals: 518



« Reply #69 - Posted 2014-07-25 05:51:10 »

Component based and Data oriented are independent.  Data oriented is pretty much required for high performance for anything over modest data sets.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen

JGO Kernel


Medals: 518



« Reply #70 - Posted 2014-07-25 07:49:04 »

The whole component based thing is really rooted in modern "best practices/design pattern-y" think...aka every thing you write is a nice reusable generic mini-library.  That's the only situation where it makes sense. You create a solution which you then apply to your problem.  Flip it around into type-think.  When in a specific game do you need a type which can contain an arbitrary number of arbitrary types?  Answer: never.  Slight change the wording of that and everything changes.  For example I frequently have an entity type which can logically contain an arbitrary number of (by name) variables where are logically typeless but are concretely one of a very small number of types (like entity, int, float, string).  Data segregation (for data oriented) might be handled by monomorphic access to hide implementation details at the scripting level.

This one again:


Don't write middleware if that isn't your product.

Offline Riven
Administrator

« JGO Overlord »


Medals: 1356
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #71 - Posted 2014-07-25 14:01:28 »

CA
CA
CA
CA
Emo

Google says NO. Care to expand this acronym?

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline princec

« JGO Spiffy Duke »


Medals: 1053
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #72 - Posted 2014-07-25 14:06:32 »

I think it means component architecture.

Cas Smiley

Offline matheus23

JGO Kernel


Medals: 138
Projects: 3


You think about my Avatar right now!


« Reply #73 - Posted 2014-07-25 15:22:25 »

Google says NO. Care to expand this acronym?
I think it means component architecture.

HA! I knew something Riven didn't know! Cheesy

Okay, I go back in my cave now.

(I really like this discussion and I really like the idea of Entity Systems, I wonder how well they work in haskell)

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline Roquen

JGO Kernel


Medals: 518



« Reply #74 - Posted 2014-07-25 17:07:57 »

..and I really like the idea of Entity Systems...
I really like the idea of a language which I spend zero time working around it's deficiencies.
Offline Catharsis

JGO Ninja


Medals: 75
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #75 - Posted 2014-07-26 08:35:36 »

Component based and Data oriented are independent.  Data oriented is pretty much required for high performance for anything over modest data sets.

Actually when I mentioned "data oriented" above in regard to blog posts on ES what I meant was a metrics based approach. IE actually measuring the efficiency of various designs.

Regarding your comment above I'm sure you will not like my answer as I don't agree with your conclusion. A component architecture (CA  persecutioncomplex) at least in how I've gone about it is high level data oriented design. I'm not the only one mentioning this: http://www.dataorienteddesign.com/dodmain/node5.html

Splitting data from logic at any level of an architecture allows one to focus on how to access it and better organize it for processing. In my efforts I actually store components via meta-type and type. This allows all data components to differentiate themselves even though this is manually enforced in component design. It allows one to query a component manager (CM) / container and get back an iterator over all components stored by their meta-type (all data, all systems).

The new ES implementation in my efforts splits apart entities (which are just a CM; there is no "Entity") and indexes all components from all entities added to the entity manager CM. This allows traversal over a particular component type for all entities directly instead of processing each fully composed entity sequentially. As previously mentioned there is also the opportunity when adding an entity to an entity manager to transform the data stored in one or more independent components and store it in a tightly packed array or perhaps byte buffer or whatever data structure that is the low level DOD form.

Basically a CA provides a high level / human accessible form to organize and manipulate data. It also can also deliver plenty of performance without transforming anything to a low level format.

----

I suppose that brings up an interesting distinction in classifying ES. None of this is rock solid terminology, so I'm curious if folks have any input. I'll classify Artemis / Ashley as type I ES. Type I basically lending themselves to having distinct structure such as having specific classes like "EntityManager", "Entity", "EntitySystem" where processing of entities occurs sequentially in a fully composed state. A type I ES often has hard coded classification schemes baked into the API that can't be altered. This is the aspect / family classification in Artemis / Ashley. In this case the CA elements that may be marginally present are hampered by a hard coded relationship to the classification scheme.

Type II ES are fully generic and are based on an implicit CA that has self-modifying capabilities. There is no "EntityManager" or "Entity" class that contains specialized logic or any hard coded classification scheme. The potential self-modifying behavior of the CA itself provides dynamic classification of entities along with an optional transform of high level data components to an optimized format automatically when an entity is added to the CM which is extended by its own internal system component that activates in this process. This allows for bespoke system components of the entity manager CM to work over this optimized data set of all entities at once.

In my efforts my first stab creating an ES ended in a type I ES (sequential processing of fully composed entities).  Since I saw the usefulness of the approach for proper modularization I promoted the CA to be a superset of the ES implementation. I added the self-modifying aspect to the CA for other purposes not directly ES specific. In that case a way to inject a parent CM into children components without hard coding that into the CA implementation itself; IE it can be turned off by excluding the injection self modifying system from a CM. It turns out this is useful for a lot of things and definitely comes into play for a type II ES which is where I'm headed when I get back to working on the game engine aspects of my efforts.

The whole component based thing is really rooted in modern "best practices/design pattern-y" think...

Is that a bad thing? For JGO it seems like a poison pill for more than a few.

It's not like we are "gleaming the _scale_ cube" and microservicing our way to valhalla.

Technically though yeah... The implicit CA + EventBus route is similar to the microservice architecture in purpose except in process oriented.  Grin

aka every thing you write is a nice reusable generic mini-library. That's the only situation where it makes sense.

Isn't that the promise, traditional OOP in the 90's included, that is sold to management regarding adopting new principles and technology.

The big difference is that the traditional OOP direction didn't deliver on this promise. Implicit CA + EventBus does.

Message passing between functional groups / modules is best followed by only passing around a generic container interface (IE in my efforts IComponentManager). This way you can pass structures implicitly between modules without leaking a ton of concrete types and poisoning the larger codebase through unchecked dependencies.

Flip it around into type-think.  When in a specific game do you need a type which can contain an arbitrary number of arbitrary types?  Answer: never.

! When an artist is in control and not a coder.

- Makes advanced tooling possible / easy

- It's useful when you don't know exactly what you are building and the design may change.

- It's handy for event / message distribution where one message type can hold any data.

- If your goal is to not to make a big ball of mud SDK, engine, or project / source code effort it makes a difference; supports modularity, clean code / single responsibility principle, etc.

- It also supports high level DOD where data can be queried to be transformed into a low level representation. Hence a type II ES.

- It also supports naturally DAO / serialization, etc. etc.

For example I frequently have an entity type which can logically contain an arbitrary number of (by name) variables where are logically typeless but are concretely one of a very small number of types (like entity, int, float, string).  Data segregation (for data oriented) might be handled by monomorphic access to hide implementation details at the scripting level.

Type safety is handy for many reasons. I'm curious about the last sentence though regarding data segregation and "monomorphic access" in regard to a scripting interface because the latter is not clearly defined. "Monomorphic access" brings up connotations of immutability or marking classes or accessor methods final. Could you explain this more?

Don't write middleware if that isn't your product.

Phew, glad this is what I'm doing and is an approved machination.  Wink

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Offline princec

« JGO Spiffy Duke »


Medals: 1053
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #76 - Posted 2014-07-26 09:40:24 »

It doesn't half sound like using Java for this is like whacking a round peg into a square hole with a sledgehammer. It's crying out for a DSL. All the complexity and cognitive blocking appears to stem from the problem that Java, the language, is totally unsuitable. Trivial example - runtime composition. There is simply no way to express this in Java at compile time let alone an easy way to compose things from separate classes. Furthermore there appears to be considerable emphasis on what amounts to manual memory layout in certain circles; again the sort of things a machine should be best placed to figure out at runtime. Java was designed to do small-scale problems in the OOP domain efficiently; you really need something completely different to express what you're trying to do in a way that is a) efficient and b) comprehensible and c) better than the OOP paradigm

Cas Smiley

Offline princec

« JGO Spiffy Duke »


Medals: 1053
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #77 - Posted 2014-07-26 09:41:13 »

In fact the more I look at the problem the more it becomes apparent that SQL would probably have been a better place to start from.

Cas Smiley

Offline princec

« JGO Spiffy Duke »


Medals: 1053
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #78 - Posted 2014-07-26 09:43:49 »

Let me count the ways...

SQL gives us:

The ability to specify the data but hides the actual implementation of its storage and access away
The ability to specify how the data relate to each other in the form of relations
The ability to relatively quickly and easily rearrange data*
The ability to select arbitrary subsets of that data and process it in parallel

and so on. Win.

Cas Smiley

* Occurs to me that no modern SQL engine currently has any serious refactoring support. There's an opportunity...


Offline Catharsis

JGO Ninja


Medals: 75
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #79 - Posted 2014-07-26 10:50:14 »

It doesn't half sound like using Java for this is like whacking a round peg into a square hole with a sledgehammer. ... All the complexity and cognitive blocking appears to stem from the problem that Java, the language, is totally unsuitable.

Except that it is and has been for almost 10 years. Generics pushed to the edges via generic methods provides the language mechanism and is supported everywhere Java is these days.

It's crying out for a DSL.

I'm actually quite excited to one day getting around to combining my Java CA w/ Scala. DSLs being driven from the Scala side of things.

Trivial example - runtime composition. There is simply no way to express this in Java at compile time let alone an easy way to compose things from separate classes.

In my efforts there is a well defined CA API that can be used programmatically. Annotations are used at the class meta-data level for specifying certain constraints as necessary. For runtime loading I use XML since it's available everywhere with a basic key value organization along with conditional directives (IE Android OS version, device family, screen size, etc. etc). This allows the runtime and all conditional variations to be defined clearly externally thereby a uniform runtime. This loading mechanism could be driven by anything including a DSL via Scala or whatever is clever.

Furthermore there appears to be considerable emphasis on what amounts to manual memory layout in certain circles; again the sort of things a machine should be best placed to figure out at runtime.

Let's consider preparing workloads for OpenCL. One would transform the data from high level components into whatever is appropriate for the characteristics of the hardware one is running on after one queries the hardware. In the graphics case perhaps it's slotting all relevant data from an entity into a UBO (& other buffer objects) friendly data structure spanning all entities.

Java was designed to do small-scale problems in the OOP domain efficiently;

Then the language evolved. It took 5 years for me to realize the possibilities and travel down this path. Generics as things go was slowly adopted in its most basic form (parameterized types) and generic method use is still not prevelent in many projects. With Java 8 we are now seeing many of the new APIs use generics in advanced ways. For 10 years though it's been possible to do some pretty advanced stuff. 

The language is evolving once again, but sadly not available on Android nor will it likely be. This is particularly even why it's super important to pull as much from generics / annotations as possible since it runs everywhere.

you really need something completely different to express what you're trying to do in a way that is a) efficient and b) comprehensible and c) better than the OOP paradigm

It's all there and A, B, C is well covered..  Cheesy Technically, I still consider what I'm doing as still OOP, but kind of more like OOPs last stand. In some ways connecting the dots from the past with an eye toward the future.

In fact the more I look at the problem the more it becomes apparent that SQL would probably have been a better place to start from.

Perhaps, but the CA is a basic database. In my case a Map of Maps. One for single component storage and another that resolves to a list of components stored by type. There is a consistent query API and its fast. The CA is an in memory structure and while there may be in memory runtimes for SQL the data still needs to be transformed to the hardware one is using. It's best to use the in memory Map of Maps in Java. The ComponentManager implementation is ~3.5k lines of code and runs everywhere Java does.

Another big win for Java and splitting out data components is that by doing this one creates schema and storage that can be versioned as necessary.

Let me count the ways...
SQL gives us:
The ability to specify the data but hides the actual implementation of its storage and access away
The ability to specify how the data relate to each other in the form of relations
The ability to relatively quickly and easily rearrange data*
The ability to select arbitrary subsets of that data and process it in parallel
and so on. Win.

These basically ring true with a proper CA too.

* Occurs to me that no modern SQL engine currently has any serious refactoring support. There's an opportunity...

And this is the big win for Java regarding the tooling available.

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Offline Roquen

JGO Kernel


Medals: 518



« Reply #80 - Posted 2014-07-27 14:36:54 »

I'm ignoring the you're working on middleware for the moment.

"data oriented".. what I meant was a metrics based approach. IE actually measuring the efficiency of various designs.
I'd say data oriented is a cache oblivious (or conscientious) approach to data layout based on how data is transformed (access patterns).  It also pretty much independent of other design choices..likewise for data driven.

Quote
Splitting data from logic at any level of an architecture allows one to focus on how to access it and better organize it for processing.
Sure, nothing to do with component based.

Quote
It allows one to query a component manager (CM) / container and get back an iterator over all components stored by their meta-type (all data, all systems).
<snip>
...and store it in a tightly packed array or perhaps byte buffer or whatever data structure that is the low level DOD form.
Performing a query for something you know. (again ignoring middleware).

Quote
The whole component based thing is really rooted in modern "best practices/design pattern-y" think...

Is that a bad thing? For JGO it seems like a poison pill for more than a few.
Yes it's a insanely bad thing.  I'm not sure what you're referring to as a poison pill however.

Quote
aka every thing you write is a nice reusable generic mini-library. That's the only situation where it makes sense.
Isn't that the promise, traditional OOP in the 90's included, that is sold to management regarding adopting new principles and technology.

The big difference is that the traditional OOP direction didn't deliver on this promise. Implicit CA + EventBus does.
Yeah and the goal of that promise it to service the bulk of programming jobs which is for project with much longer lifetimes than engineer turnover rate.  It the most expensive method in terms of both engineering and CPU time but the reduction in risk makes it worthwhile from a business standpoint.  But this isn't something to focus on in education or literature because it's roughly the equivant to coding conventions.  Anybody that can program can pick it up in approaching zero time.

Quote
<snip> This way you can pass structures implicitly between modules without leaking a ton of concrete types and poisoning the larger codebase through unchecked dependencies.
Ok and there are tons of ways to achieve this.

Quote
Flip it around into type-think.  When in a specific game do you need a type which can contain an arbitrary number of arbitrary types?  Answer: never.
! When an artist is in control and not a coder.
The game design is in control.  Coders, artist and worldbuilder should be in control of their tasks.  I don't disagree with any of your bullet points.  

Quote
For example I frequently have an entity type which can logically contain an arbitrary number of (by name) variables where are logically typeless but are concretely one of a very small number of types (like entity, int, float, string).  Data segregation (for data oriented) might be handled by monomorphic access to hide implementation details at the scripting level.
Type safety is handy for many reasons.
In general purpose programming, yes, you want to insure correctness as quickly was possible.  However the user here is the scripting side which personally I want to be as fault tolerant as possible.  One could go with typed, but I don't since typeless is slightly lower complexity IMO.

Quote
I'm curious about the last sentence though regarding data segregation and "monomorphic access" in regard to a scripting interface because the latter is not clearly defined. "Monomorphic access" brings up connotations of immutability or marking classes or accessor methods final. Could you explain this more?
Any instance method which doesn't override anything and is final is monomorphic at all callsites (places in code where it's invoked).  The runtime compiler can then treat it as a static method and all optimizations possible for statics are opened up (notable inlining).  If not inlined then it's a direct call.  HotSpot can optimistically determine if any instance method call is monomorphic.  If proved wrong later it will deoptimize.  For completeness it also detects bimorphic (exactly 2 versions) and in that case can covert the invocation to an 'if-then-else' construct.  Three or more will go through the virtual table.

Quote
Don't write middleware if that isn't your product.
Phew, glad this is what I'm doing and is an approved machination.  Wink
Of course the rules are different for middleware.  I don't talk about that because I prefer the not encourage middleware/library creation.


Offline junkdog
« Reply #81 - Posted 2014-07-27 17:34:27 »


I suppose that brings up an interesting distinction in classifying ES. None of this is rock solid terminology, so I'm curious if folks have any input. I'll classify Artemis / Ashley as type I ES. Type I basically lending themselves to having distinct structure such as having specific classes like "EntityManager", "Entity", "EntitySystem" where processing of entities occurs sequentially in a fully composed state. A type I ES often has hard coded classification schemes baked into the API that can't be altered. This is the aspect / family classification in Artemis / Ashley. In this case the CA elements that may be marginally present are hampered by a hard coded relationship to the classification scheme.


What exactly do you mean by processing of entities in a "fully composed state"? In both artemis and ashley, entities are only a little more than glorified integers (entityId - and some additional metadata, not necessarily stored by the entity itself).  Or is the hint in your definition of "Type II Es", being "fully generic" and having "self-modifying capabilities" (components as more than data-holders, I guess) - not entirely sure what either implies.

Mhhh okay...Still not too convinced here I guess. Let's wait for that performance benchmark  Grin Grin
(Not that it matters too much because Artemis is already pretty fast? So if you want to use an ES you already have a pretty good option there imo)

https://github.com/junkdog/entity-system-benchmarks - Nothing complete, but it's a start.

artemis-odb: bugfixing and performance optimized fork of artemis ECS
Offline Roquen

JGO Kernel


Medals: 518



« Reply #82 - Posted 2014-07-28 13:00:24 »

I keep forgetting.  The argument "OO isn't good enough so I use component based" is flawed.  Component based is OO.
Offline delt0r

JGO Wizard


Medals: 144
Exp: 18 years


Computers can do that?


« Reply #83 - Posted 2014-07-28 13:38:20 »

Well i always think these debates are pretty Meh. But i still read them.

I mostly had issues with what problem Entity stuff solved, as in i couldn't see the point all that much. I assumed because i didn't understand them. Turn out i did. Also turns out when the right problem came along then it did become clear what they are good for. I should also note i didn't use it for performance, since i got a few clusters i can use with over 5k cores. But it made the code small and fairly compact.

For smaller indie games however its less clear how it helps. Its up there with writing an engine. Write a game, not an engine. No one else is going to use it anyway.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline Roquen

JGO Kernel


Medals: 518



« Reply #84 - Posted 2014-07-28 14:05:39 »

It would be much more interesting to have a discussion about various code design structures for these types of issues and the various trade offs.  I've never run across a situation where moving past mimicing an open-class was needed.  I'd actually avoid talking about data-oriented as it's independent and starts to bog things.  Actually data-oriented is way more important (assuming sufficient scale).
Offline princec

« JGO Spiffy Duke »


Medals: 1053
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #85 - Posted 2014-07-28 14:25:41 »

Consider an RDMBS engine that does for physical data layout what Hotspot does for bytecode compilation.

Cas Smiley

Offline Catharsis

JGO Ninja


Medals: 75
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #86 - Posted 2014-07-30 21:44:08 »

Quote from: Roquen link=topic=33652.msg319819#msg319819
I'd say data oriented is a cache oblivious (or conscientious) approach to data layout based on how data is transformed (access patterns).  It also pretty much independent of other design choices..likewise for data driven.  ....   Sure, nothing to do with component based.

We'll go with "conscientious"..  Cheesy It can be independent, but if the larger architecture naturally supports data oriented concepts it's easier to apply them broadly.

Quote from: Roquen link=topic=33652.msg319819#msg319819
Quote
It allows one to query a component manager (CM) / container and get back an iterator over all components stored by their meta-type (all data, all systems).
<snip>
...and store it in a tightly packed array or perhaps byte buffer or whatever data structure that is the low level DOD form.
Performing a query for something you know. (again ignoring middleware).

You're thinking about it the traditional way.. ;P

While I'm still adding stream / filtering type mechanisms into the CA. The idea is to be able to do a query like "give me all the data components that also have the @SerializeMeOnNetwork annotation" in order to serialize an entity or whatever and send it over the wire. This implementation is a little less general purpose than the java 8 streaming API. I'll probably limit it to type and annotation based queries. Maybe some bespoke processing though I'm keen to keep things fast on Android.

It makes possible generalized systems of a larger architecture while maintaining reasonable speed. Serialization is one of the larger use cases from a design perspective. On my side.

Quote from: Roquen link=topic=33652.msg319819#msg319819
Quote
The whole component based thing is really rooted in modern "best practices/design pattern-y" think...
Is that a bad thing? For JGO it seems like a poison pill for more than a few.
Yes it's a insanely bad thing.  I'm not sure what you're referring to as a poison pill however.

I get a ton of knowledge through following general thought leaders. Most recently in the past ~3 years the whole mechanical sympathy scene / re: Martin Thompson  and co. Turns out a lot of what the HFT community is doing has applications to the game dev / interactive media scene.

I think you may be complaining that historically the "best practices / design pattern" scene for Java has been rooted in the enterprise side of things where there is mostly dubious value to game dev, etc.

Quote from: Roquen link=topic=33652.msg319819#msg319819
Quote
Isn't that the promise, traditional OOP in the 90's included, that is sold to management regarding adopting new principles and technology.

The big difference is that the traditional OOP direction didn't deliver on this promise. Implicit CA + EventBus does.
Yeah and the goal of that promise it to service the bulk of programming jobs which is for project with much longer lifetimes than engineer turnover rate.  It the most expensive method in terms of both engineering and CPU time but the reduction in risk makes it worthwhile from a business standpoint.  But this isn't something to focus on in education or literature because it's roughly the equivant to coding conventions.  Anybody that can program can pick it up in approaching zero time.

What you just recounted above is the myth of the false promise of OOP.  OOP has not reduced project failures.  Attention to detail and rigorous application of such is what succeeds and sadly anybody picking up programming categorically lacks this and most never achieve it.

I can refer you to many other debates online, but kind of feel we don't need to have one here on the matter..  Grin

Err... Actually to stop spinning the wheels here on the rest of this particular post, so I'll end my reply here.. It seems we have differing opinions and continuing will dilute the larger topic.

Well yeah... and this
Quote
I keep forgetting.  The argument "OO isn't good enough so I use component based" is flawed.  Component based is OO.

No one is saying it's not OOP at least for Java, but by adding a CA API that is well defined and generic this unlocks implicit composition which is something stock Java / re traditional OOP doesn't provide.. It's such a big game changer that it warrants being called COP (component oriented programming) versus OOP so folks don't get it confused with inheritance / or explicit composition re traditional OOP.

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Offline Catharsis

JGO Ninja


Medals: 75
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #87 - Posted 2014-07-30 23:11:57 »

What exactly do you mean by processing of entities in a "fully composed state"? In both artemis and ashley, entities are only a little more than glorified integers (entityId - and some additional metadata, not necessarily stored by the entity itself). 

EntitySystem and EntityProcessingSystem which forms the basis for a lot of Artemis system usage from examples I've seen (the best being Naturally Selected 2D) iterate over entities sequentially and retrieves individual components to complete the logic at hand. Regardless of where the components are stored this general approach will have limits in speed especially considering the case where when one wants to broad phase process. In this case with Artemis each separate phase iterates over all entities multiple times while potentially needing to retrieve multiple components at each stage. The only thing that makes this a problem with Artemis / Ashley is that it's baked into the architecture and is the enforced way of doing things. At least it looks inflexible from just reviewing the code.

I really do need to get more of an intuitive usage understanding of Artemis particularly your "odb" effort. I'm doing this right now actually in converting NS2D to Android / iOS builds for some demo work for a client while integrating their custom game controller (a touch screen on the back of a tablet). It's kind of neat. Touch on the back controls the jet pack / movement and touch on the front anywhere controls the gun. I'm doing the modifications in the coming couple of days, so hopefully I'll gain better visibility working with a good example, etc.


Or is the hint in your definition of "Type II Es", being "fully generic" and having "self-modifying capabilities" (components as more than data-holders, I guess) - not entirely sure what either implies.

In my efforts the self-modifying behaviour is achieved by systems that are potentially activated when the CA API is invoked on a component manager. This allows entity management and classification to be done in a more dynamic fashion than baking these patterns into the ES API (type I). In the case of packing components for more efficient traversal what I'm aiming to do is when an entity is added to a manager the dynamic classification / packing system is run and stores the packed content in a _different_ component of all combined & relevant entities added to the manager. When processing a frame a system can then just retrieve that one packed component and work over the packed data (ideally a primitive array). Remove the entity from the manager then it removes the tracking from the packed component and stores the packed data back into the original component.

You are brave with integrating byte code weaving and such. I've steered clear of that approach for developer setup / ease of use. The efficiency you are trying to achieve with PackedComponent is an interesting attempt. I'm just referencing this link (https://github.com/junkdog/artemis-odb/wiki/Packed-Weaver) for reference. The problem is not so much storing packed data, but making sure systems can iterate over the packed data and not make a bunch of method calls or component retrievals. This doesn't seem possible currently with your efforts. I'd also generally be concerned about storing the packed data as a static array / ByteBuffer in the component class itself. This will not play nice with partitioning an ES.

https://github.com/junkdog/entity-system-benchmarks - Nothing complete, but it's a start.

Thanks for doing this... I'll take a look and maybe one day have some time to do some comparisons with my efforts.

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Offline appel

JGO Wizard


Medals: 80
Projects: 4


I always win!


« Reply #88 - Posted 2014-07-31 04:53:52 »

I spent a great deal of time profiling Artemis to ensure its design wasn't bottlenecking the performance, and I did not find it lagging behind its OOP alternatives, e.g. dozens of thousands of entities.

If you have more than a dozens of thousands of entities, hundreds of thousands, then you're doing something terribly wrong. No game should have that number of entities active in its world at a given time.

All I wanted was a easy design, where I wasn't schizophrenically dependent upon some hierarchical OOP structure and was fast enough.

But that doesn't mean Artemis-design is suited for all. It's quite rigid when it comes to how entities are composed.
Offline Roquen

JGO Kernel


Medals: 518



« Reply #89 - Posted 2014-07-31 08:30:38 »

Quote
You're thinking about it the traditional way.. ;P
Yeap.  And so are the majority of game industry leads & technical directors.  It's significantly less work, complexity and is significantly faster (for the statistically significant..otherwise who cares).

Quote
I think you may be complaining that historically the "best practices / design pattern"
No. I'm complaining that CS has a whole has stepped way from problem solving and into reusable massively complex systems and generations of programmer understand very little about programming in the pure sense. As an example around 2000ish I asked new grads from highly reputable universities questions like:  "Visitor and command patterns are the same.  What's the mechanism?"  I think one 1% could give an answer.
Pages: 1 2 [3] 4
  ignore  |  Print  
 
 

 
EgonOlsen (1340 views)
2018-06-10 19:43:48

EgonOlsen (1229 views)
2018-06-10 19:43:44

EgonOlsen (939 views)
2018-06-10 19:43:20

DesertCoockie (1380 views)
2018-05-13 18:23:11

nelsongames (1112 views)
2018-04-24 18:15:36

nelsongames (1374 views)
2018-04-24 18:14:32

ivj94 (2120 views)
2018-03-24 14:47:39

ivj94 (1269 views)
2018-03-24 14:46:31

ivj94 (2286 views)
2018-03-24 14:43:53

Solater (808 views)
2018-03-17 05:04:08
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!