Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (537)
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 6454 times)
0 Members and 3 Guests are viewing this topic.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Posted 2014-06-23 15:53:09 »

I'd like to start a discussion on how people are currently using entity systems, and how they're structuring them. I've personally moved away from traditional inheritance-heavy ('old') game structure a while ago, but only recently tried using a more formal entity system to handle the gameplay logic side of things. I've also had two projects running concurrently, one using Artemis which uses 'thin' components (like the position example here) with no logic and just uses systems to do the logic, and one built in Unity, which uses a more 'traditional' approach where the components are 'fat' and contain their state and logic.

Initially I really got along with the Artemis style, defining aspect-like systems really helped with functionality that spanned multiple component types. However the more I use it the more I feel like I'm butting up against limitations. Often I'll end up having to set flags in components in one system for another system to pick up on later, resulting in lots of polling-style code and the inability to have much event-based gameplay code (at least, without doing some slight mental contortions).

Of course, I could just use Artemis and write 'fat' components, which is what I'm going to do as an experiment in my next project. But I'm wondering what other people have made of the thin vs fat approaches, and if one really paid off one way or another.

The polling style wouldn't be too bad except on android it *really* sucks up a lot of extra cpu time, just to enforce a seemingly arbitrary design separation. (Yes, I'm aware of artemis-odb and will be switching to that soon). Along with that, some task that feel like they should be simple end up being much harder than they should be.

Artemis still lists itself as "an experimental framework based on an experimental concept". Do you think the experiment is a success or not?

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2014-06-23 18:15:43 »

I suppose it depends why you're using an entity system... if it's to make your code more readable and understandable and easy to maintain... then that's a fail, as it doesn't really do any of that at all, most especially not in Java where you just don't have the available syntactical constructs to help you, not even structs. I think the only reason for entity systems generally to exist at the moment is if you've got so many entities that you're having trouble processing them all in a timely fashion.

Cas Smiley

Online Roquen
« Reply #2 - Posted 2014-06-23 19:27:18 »

I declare problem space inversion.  Screw all of this shit.  Problem first.  Potential solution(s) second.  Solutions yield data.  Data defines want the code should be.  So: code comes last.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 757
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #3 - Posted 2014-06-23 19:46:39 »

Ah, and I tought I was the only one thinking purely data-driven designs are an exceptionally poor fit for realtime games. There are huge advantages for entity systems for specific (serverside) use cases, when plowing through gigabytes of indexed data. Clientside, to me, it's a nice toy worthy of kick and a squeeze on a rainy afternoon.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Online Roquen
« Reply #4 - Posted 2014-06-23 21:51:03 »

Quote
There are huge advantages for entity systems for specific (serverside) use cases, when plowing through gigabytes...
The advantage is from being cache friendly.  Nothing to do with component base which increase complexity.  Not my point though.  My point being:  "I've friends coming over tonight.  Should I buy a keg of beer or one chicken?"
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 757
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #5 - Posted 2014-06-23 21:56:10 »

Cache friendly for small data (memory bound I/O), indexes for large data (disk bound I/O).

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

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #6 - Posted 2014-06-23 23:03:31 »

I think entity systems often confuse two separate design goals - being cache-friendly, and managing the complexity that comes with lots of different object types and gameplay behaviours.

On the first, I agree that entity systems tend to be overkill for client programming, particularly for Java where you can't precisely control memory layout, so cache coherency is mostly a guess anyway.

The second however I'm firmly behind. Any game of moderate complexity really benefits from the separation of gameplay features that an entity system brings. Yes, there are other approaches that yield similar results, and that's fine, but the component system seems to work pretty well and other people are instantly familiar with it which is handy as well.

Entity systems also really pay off when you've got multiple gameplay programmers trying not to step on each other's toes, or designers who put your components together in interesting ways and come up with behaviour you hadn't even thought of yet.

However I'd rather not debate all of that - if you don't want to use an entity system that's fine, but I'd like to discuss the higher level approaches people are taking to their entity systems.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline junkdog
« Reply #7 - Posted 2014-06-23 23:14:45 »

I don't really have much experience coding games that don't use an ECS; maybe I've just been exposed to poor design, but imo an ECS does help structure the design and - thanks to the emphasis on compartmentalizing game logic in distinct entity systems - isn't as sensitive to spaghettification/ridiculous coupling.

Benefits of using an ECS - or stuff one pretty much gets for free:
- Since components are pure data, serialization comes almost at no cost (code-wise).
- Entity systems can easily be reused outside the game, very handy for level/game editors.
- New types can be defined on the fly - another boon for editors. Furthermore, it's pretty straightforward writing a generic reflexive editor for manipulating component data.
- Behavior reuse > code reuse.
- Easy to profile, both via profiler and in-game.
- Entity Systems can be toggled at runtime; pretty useful for debug renderers, disabling collision handling etc.

Lastly, to respond to the OP and fat components; it's certainly doable, but it tends to make the code a little more rigid and hence harder to refactor.

It's true that one of the potential benefits of ECS is writing cache-friendly code, but aside from us being in java-land now, it's not quite as simple as strapping on an ECS and automatically reaping the benefits of a happy cpu/cache relationship - Adam Martin wrote an interesting post on it recently: http://t-machine.org/index.php/2014/03/08/data-structures-for-entity-systems-contiguous-memory/

Most of the early work with ECS appears to have more to do with fast iteration times, rather than fast execution.
- http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/
- http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/


artemis-odb: bugfixing and performance optimized fork of artemis ES
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #8 - Posted 2014-06-23 23:23:12 »

Good stuff!

Lastly, to respond to the OP and fat components; it's certainly doable, but it tends to make the code a little more rigid and hence harder to refactor.

Yes, I am seeing a bit of this - an artemis-style system seems to be optimal in terms of code reuse and flexibility, but I'm seeing that come at the expense of some readability and having to resort to polling behaviour over event-driven code.

Of course there's nothing to stop me putting event-driven code into the thin components and mixing the two approaches, but I suspect that would get messy and confusing quickly.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline junkdog
« Reply #9 - Posted 2014-06-23 23:28:55 »

No need to poll, better sacrifice some memory and have each system maintain a list of all entities with a matching component composition. Entity Systems are notified whenever an entity has components added or removed, keeping the list up-to-date. This is how artemis and most ECS frameworks do it.

Edit: Sorry, misread your post. If dealing with a lot of entities... simply setting a flag here and there as a marker for being processed by another system, I could see why it might be a problem (are you sure it is the bottleneck though?). One solution might be a custom EntitySystem to which you manually insert entities that need to be processed as a result of some state. Alternatively, make the components even thinner, effectively having marker components and more specialized systems.

artemis-odb: bugfixing and performance optimized fork of artemis ES
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #10 - Posted 2014-06-24 00:19:10 »

One solution might be a custom EntitySystem to which you manually insert entities that need to be processed as a result of some state.
Yeah, I've seen this solution a couple of times. It kinda makes sense, but the resulting code is definitely harder to read, and adding an entire new EntitySystem for this behaviour is pretty heavy in terms of boilerplate code for what really should just be a method call.

It probably depends how finely you slice up your logic though - if you have bigger, chunkier entity systems that do more than you don't need signalling flags as much, but then you're left with more specialised code and you veer toward the Blob system that does everything.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline junkdog
« Reply #11 - Posted 2014-06-24 00:48:28 »

I try to keep both my entity systems and components as specialized as possible: naturally, different games warrant different solutions, but I haven't found the need for optimizing in regards to marker components in a long time.

Marker components aren't *that* expensive, normally. Where and why is your CPU time consumed - because of a high entity count, sporadic insert/remove bursts, something else? It's hard to reason about an approach without seeing some example code or knowing more about your design - the risk is that you end up getting vague recommendations that don't really apply to your project.

A recent discussion over at reddit gave some ideas on how to more efficiently deal with batch insertion/removal of entities. It will find its way into 0.7.0 (sometime during the summer) - it might cover your use-case, or at least be slightly easier on the CPU.

artemis-odb: bugfixing and performance optimized fork of artemis ES
Online Roquen
« Reply #12 - Posted 2014-06-24 07:44:55 »

Cache friendly for small data (memory bound I/O), indexes for large data (disk bound I/O).
What's a disk?  Oh yeah...that thing WAY over there.  Am I on the "java-datamining" forum? Wink
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #13 - Posted 2014-06-24 08:59:43 »

Marker components aren't *that* expensive, normally. Where and why is your CPU time consumed - because of a high entity count, sporadic insert/remove bursts, something else?

For my situation it's a high (+500) entity count that I'm trying to keep running at 60hz on android, so the cpu is a bit limited to start with. It absolutely flies without even trying on my ancient desktop, but not so on android.

Mostly I'm seeing a significant amount of time burned in just entity/component iteration, looping over entities to check if things are changed and pushing data from one component to another. It's not that this is bad per se, it's just that it's unnecessary work eating up my cpu budget, especially when most of the entities aren't visible right now but due to the nature of the system it's hard to not process everything all the time.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Online Roquen
« Reply #14 - Posted 2014-06-24 10:24:11 »

Information.  Good.  Android: changes everything.  What min version?  500+ entities: what's that mean.  Logically active?  Estimate of number "in the hot-seat" (need to be reactive and running at full rate).  Only the latter really matters.  And if that's large it'll dictate the design.

Quote
... looping over entities to check if things are changed and ...
Exactly my point.  Why are you asking about something you know?  Code to the statistically significant.
Offline junkdog
« Reply #15 - Posted 2014-06-24 12:53:33 »

500 entities isn't that much. I've managed just below 60 FPS on an old Desire Z (android 2.3, single core 800 MHz Scorpion) with 500 +/- 100 entities and ~25 entity systems.

- Don't use getters/setters for components. The JIT will inline them, but it will take time before everything is inlined
- Override processEntities and optimize which entities get processed; either by splitting the processing over two ticks or by some clever filtering (this implies that you manage the entities yourself in an optimized list, override inserted/removed in EntitySystem or roll your own)
- Direct array access is faster than getting each entity individually (processEntities): artemis-odb does this by default.

artemis-odb: bugfixing and performance optimized fork of artemis ES
Online Roquen
« Reply #16 - Posted 2014-06-24 13:05:59 »

Another pet-peeve of mine.  FPS = f**king Pointless System of measure.  Interest measures are nano/micro seconds per data transform.  Like X nanoseconds to update N entities motion (or whatever). 
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #17 - Posted 2014-06-24 13:07:48 »

Also, does the figure include actual rendering or is that just logic or is it logic and preparation to render?

Cas Smiley

Offline junkdog
« Reply #18 - Posted 2014-06-24 13:22:44 »

FPS isn't a benchmark, rather an overall performance target. On mobiles, I think one can easily get away with 30FPS, as long as it doesn't dip below it.

Also, does the figure include actual rendering or is that just logic or is it logic and preparation to render?
Cas Smiley

Logic + preparation, I didn't/haven't investigated how to reliably get the FPS on android.

artemis-odb: bugfixing and performance optimized fork of artemis ES
Online Roquen
« Reply #19 - Posted 2014-06-24 13:28:08 »

Yes.  And that's the only place it has any meaning.  Does the whole system meet my target?  It useless for anything else.  Worse it's misleading.

I have this fantastic HDR, physically based, screen space shading code!  It runs at 200FPS!!!  So you can just drop it in any old game and not worry about performance!!!  Except that ain't so.  It ignores the math...even assuming the "user" has the same (or better) GPU.
Offline junkdog
« Reply #20 - Posted 2014-06-24 13:41:33 »

I have this fantastic HDR, physically based, screen space shading code!  It runs at 200FPS!!!  So you can just drop it in any old game and not worry about performance!!!  Except that ain't so.  It ignores the math...even assuming the "user" has the same (or better) GPU.


Of course, but I don't think anyone claimed anything to that extent in this thread? The original touched CPU processing speed in regards to component/system design; certainly it doesn't make any guarantees about how often the screen redraws.

When developing for mobiles, I'm assuming everyone has (alternatively wants) a few lower-end devices to test on.

Edit: Ok, I kinda did *hrm*.

artemis-odb: bugfixing and performance optimized fork of artemis ES
Online Roquen
« Reply #21 - Posted 2014-06-25 09:18:56 »

Just in case I wasn't clear:  100(60/200) = 30% of the GPU budget is consumed for a 60Hz target if you add something that runs in isolation at 200Hz.  FPS is a useless and misleading measurement.  Peoples brains work well on linear data and the 1/x nature of FPS requires stopping and thinking about it.

Doesn't matter what your talking about or where the computation occurs.
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #22 - Posted 2014-06-25 09:46:45 »

In any case I'm a bit perplexed by the use of an entity system and then coming up with problems... rather than the other way around. I had thought that the problems would be driving the development of a solution. I must be old fashioned too.

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #23 - Posted 2014-06-25 10:02:39 »

In any case I'm a bit perplexed by the use of an entity system and then coming up with problems... rather than the other way around. I had thought that the problems would be driving the development of a solution. I must be old fashioned too.

Cas Smiley

The problem isn't so much with entity systems per se, but with the Artemis entity system's way slicing things makes some things easier, but a few things harder compared with a more traditional entity system (the Artemis website clearly states that it's a bit of an experiment to see if this alternate way is better or not).

As I said before, I think entity systems solve more problems than they introduce, but if you're happy with other (equally valid) approaches, then that's fine too.

Since as far as I know you've not used a traditional entity system, nor have you used Artemis, and you're happy with what you're already doing, why are you grumping up a thread about comparing the two?

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Online Roquen
« Reply #24 - Posted 2014-06-25 10:05:42 »

The reason I've been grumpy that past couple of days is because I did a code review for an ex-boss of mine for his current project which is circling around the toilet bowl.  If you look at the code from a high level...it looks nice and clean.  If you look at the individual parts, well they all look nice and clean as well.  But if you actually think about the problems its supposed to be addressing, then it's one big WTF were you thinking??  Modern computer science "methods" and writing are completely and utterly full of shit.  They all claim that there are a limited number of choices and that code comes first.  It inverts sound methodology.  Code comes last.

Quote
The problem isn't so much with entity systems per se...
My view is that it is.  Component based is a solution searching for a problem. .  I cannot fathom why anyone thinks it useful.  Take an RPG.  Why would a monster in an RPG need to be able to contain a "banking transaction request" or a "phone book entry"?  Code to the statistically significant.  Think low-level, write high level.  Problem comes first, then potential solutions.  If no solutions are desirable, then change the problem statement.  Solution dictates data.  Then the final bastard step-child afterthought is the code which transforms the data.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #25 - Posted 2014-06-25 10:42:28 »

Quote
The problem isn't so much with entity systems per se...
My view is that it is.

Then this is not the thread for you, sorry.

We have lots of threads on the merits (or otherwise) of entity systems, or you can start another yourself. This is not that thread.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #26 - Posted 2014-06-25 11:33:00 »

Well, going back to your original post, there's still some relevance...
Quote
I'd like to start a discussion on how people are currently using entity systems, and how they're structuring them.
One (valid) answer is that people are not using entity systems, and the reason is, they solve problems you never really had, and created a bunch more problems for you. Although you say "inheritance heavy" in your OP... I've hitherto generally got away with just one layer of inheritance mostly in OOP (an abstract Entity, and then a few derived classes describing broad interaction mechanics between them, eg. Player, Bullet, Gidrah). It's simple... it's fast. I don't have to spend time on forums asking how to do things right. (You don't either, you're worldly wise and experienced). So we're left wondering what you could possibly be doing that merits the brain-ache? ("I want to drive to London! But instead of buying a car I'm going to assemble one out of different parts first!")

Cas Smiley

Online Roquen
« Reply #27 - Posted 2014-06-25 11:42:31 »

Quote
Then this is not the thread for you, sorry.
I'm actually not attempting to enter into the debate of component based or not.  You ask a question:  Do I do "A" or "B"?  I'm saying that's the wrong question.  The correct question is: "Here are my requirements (ATM)"  What options do I have?  By arbitrarily settling on "A" or "B" you're placing the importance of code before your requirements.
Offline junkdog
« Reply #28 - Posted 2014-06-25 12:12:08 »

I'm actually not attempting to enter into the debate of component based or not.  You ask a question:  Do I do "A" or "B"?  I'm saying that's the wrong question.  The correct question is: "Here are my requirements (ATM)"  What options do I have?  By arbitrarily settling on "A" or "B" you're placing the importance of code before your requirements.

I read the question as - even if a bit vague - this is my higher level design, and what are some common, general approaches to these set of problems. It's no different than asking about approaches for avoiding heavy inheritance or other issues that are common to a specific domain.

@princec One layer of inheritance takes a lot more of skill/experience and forethought to pull off - code quality tends to degrade over time (I'm working in an 18 y.o. product - I stare into its perplexing depths every day); ECS's flat hierarchy tends to be more resistant to that. As Orangy Tang said, it also makes it more feasible having several programmers working on the  same code without getting in each others way.

Personally, I find ECS to be very intuitive - it lets me focus on the problems and scales very gracefully from a complexity POV (which was [the/a] primary reason for their being, not cache-friendliness - as is often brought up nowadays).

artemis-odb: bugfixing and performance optimized fork of artemis ES
Offline ctomni231

JGO Wizard


Medals: 98
Projects: 1
Exp: 7 years


Not a glitch. Just have a lil' pixelexia...


« Reply #29 - Posted 2014-06-26 09:41:03 »

As much as I like ECS, the video in that page is right. You have to know when to stop splitting. What is worse is that it is totally game dependent. Doing a system like this for tic-tac-toe is just overkill, but it sort of works for organizing modules.

ECS has a lot of similarities to multi-threading. There are some instances where splitting things up really makes things easier. There are others where you'd just be creating vomit. ECS is a smaller form of data threading, but you still have to make sure you take full advantage of your hardware. For the games I've programmed, I never went past Artemis. ECS works well improving modules, but fails at connecting them.

Games just contain too much logic to take advantage of this. We just don't use data trees enough to get the power data driven architecture like ECS gives. In games, ECS will always be overkill because let's face it, not all aspects of a game is data. We just use data to assist logic structures. In logic and gaming, the fastest path is always the best one. Sorry entities, but your piping path takes too long...




Pages: [1] 2 3 4
  ignore  |  Print  
 
 

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CogWheelz (16 views)
2014-08-01 22:53:16

CogWheelz (15 views)
2014-08-01 22:51:43

CopyableCougar4 (18 views)
2014-08-01 19:37:19

CogWheelz (19 views)
2014-07-30 21:08:39

Riven (27 views)
2014-07-29 18:09:19

Riven (16 views)
2014-07-29 18:08:52

Dwinin (14 views)
2014-07-29 10:59:34

E.R. Fleming (42 views)
2014-07-29 03:07:13

E.R. Fleming (13 views)
2014-07-29 03:06:25

pw (44 views)
2014-07-24 01:59:36
Resources for WIP games
by CogWheelz
2014-08-01 18:20:17

Resources for WIP games
by CogWheelz
2014-08-01 18:19:50

List of Learning Resources
by SilverTiger
2014-07-31 18:29:50

List of Learning Resources
by SilverTiger
2014-07-31 18:26:06

List of Learning Resources
by SilverTiger
2014-07-31 13:54:12

HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22
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!