Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (480)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (547)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Could someone explain Component based entities and managers?  (Read 5009 times)
0 Members and 1 Guest are viewing this topic.
Offline SkyAphid
« Posted 2012-05-26 01:17:10 »

I was googling and reading up on it, and from what I understand, you have one major base entity, then you just add components to it.

Although, I don't really understand how to go about implementing this. I really want to build my own entity system so I can modify and understand it on my own while knowing all the little tricks I can pull of with it. I'm making a game that will have a pretty large amount of entities, so the normal ArrayList inheritance thing won't work, it get's way too messy.

Anyway, please do explain, or lead me to good comprehensive pages on it; preferably written explicitly for the Java or C language.

“Life is pretty simple: You do some stuff. Most fails. Some works. You do more of what works. If it works big, others quickly copy it. Then you do something else. The trick is the doing something else.” ~Leonardo da Vinci
Offline Geemili

Senior Member


Medals: 9
Projects: 1
Exp: 2 years


No Games Finished


« Reply #1 - Posted 2012-05-26 01:20:38 »

I don't understand the advantages of a component based Entity system, but basically, if you want to add gravity to a player, and not to another, you make a gravity component and add it only to the one that needs it. Something like that. Don't quote me on that.
Offline sproingie

JGO Kernel


Medals: 202



« Reply #2 - Posted 2012-05-26 01:26:35 »

I was googling and reading up on it, and from what I understand, you have one major base entity, then you just add components to it.

Not quite, at least not as a "pure" system goes, though a lot of them are hybrids and do work this way.  In a pure entity system, an entity is nothing but a collection of components, and is represented by at most an opaque ID into a collection of these component bundles.  You can think of it as analogous to a row in a relational database.  The advantage of this is that you can slice your entities such that you extract only the components you need, giving you more flexibility (you can substitute different components) and more compact memory layout (handy on consoles which are tighter on space).  

Whether such component systems are actually useful in Java is a subject of not inconsiderable debate.  Consensus though is that they're not for novices, and that you shouldn't be using them for their own sake, but only if you already have a plan to take advantage of the different object model.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline actual

JGO Coder


Medals: 23



« Reply #3 - Posted 2012-05-26 03:26:17 »

Check out Artemis, it's an Entity Component system written in Java. Appel, who is the author of the system, frequents these boards. I have played with E/C systems some. There is theoretical aspect that is very appealing (everything is a component) but one of the big issues I run into is that the "type" of entity has too strong a sway over how things run. So I end up having a "Tank" shooting component, an "Infantry" shooting component, etc.

I see it now as an optimization, not something you reach for right away (especially not for a simple hobby game). If your inheritance heirarchy is getting out of control, my first step would be to see if you could simplify via normal means, only reaching for an E/C system if it is necessary.
Offline Roquen
« Reply #4 - Posted 2012-05-26 17:44:31 »

I'm too lazy to repeat every thing I've said on this subject.  I can think of zero reason to use a component based abstraction model in java and almost zero in a language like C++ (which is much better suited).  I think the real problem here is that there are so-called tutorials that say you can do it the stupid way or the component way.  That simply isn't the case. There are no silver bullet in computer science...ever.
Offline princec

JGO Kernel


Medals: 361
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2012-05-26 18:03:28 »

+1 to Roquen's sentiments; SkyAphid, just don't bother with it, you're wasting your time - even for educational purposes, as you will learn nothing from it.

Cas Smiley

Offline actual

JGO Coder


Medals: 23



« Reply #6 - Posted 2012-05-26 18:03:54 »

I think the real problem here is that there are so-called tutorials that say you can do it the stupid way or the component way.  That simply isn't the case. There are no silver bullet in computer science...ever.

I agree. Some E/C models make it sound like there are only 2 choices, full on Component model or deep, messy, tangled hierarchy. They ignore the vast middle ground of selective use of inheritance + standard aggregation.
Offline theagentd
« Reply #7 - Posted 2012-05-26 18:14:22 »

I'm too lazy to repeat every thing I've said on this subject.  I can think of zero reason to use a component based abstraction model in java and almost zero in a language like C++ (which is much better suited).  I think the real problem here is that there are so-called tutorials that say you can do it the stupid way or the component way.  That simply isn't the case. There are no silver bullet in computer science...ever.
From a performance point of view, I would agree, but I've found that they help keep everything more organized. I found myself rewriting my whole hierarchical entity manager every time I wanted a new feature. In the end I got stuck simply trying to figure out all the requirements for my entity manager. Not so with Artemis. It makes it a lot easier to add, replace and restructure both the data of the entities and the logic applied to them. With hierarchical systems you pretty much have to know exactly what you want from the beginning, or you'll end up with rewriting code and/or horrible hacks. Maybe it's just me, but component based systems just seem a lot better fit for DEVELOPING games, but of course it's overkill for very simple games.

EDIT: I agree with Sproingies post.

Myomyomyo.
Offline Roquen
« Reply #8 - Posted 2012-05-26 18:44:22 »

Entites -> ArchType
          -> Extensions
Offline PaulCunningham

Junior Member


Medals: 2



« Reply #9 - Posted 2012-05-28 12:43:12 »

I really want to build my own *snip*.

I approach any programming task as follows...
  1) Try and get out of doing it altogether.
  2) Get somebody else to do it.
  3) Reluctantly do it but do the bare minimum.

As others have mentioned, (1) fits this scenario perfectly :-)
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline impaler

Senior Newbie





« Reply #10 - Posted 2012-05-28 17:21:16 »

I think many views are biased on the subject. I understand both sides and I agree that there is no silver bullet.
I am a big proponent of get dirty and just start doing it with the little knowledge you have and learn the hard way. But by following this mantra and working on my own game I learned about composition, entity systems and their benefits.
My conclusion is that it is rarely necessary and beneficial in small games.
Once the game expands (here I don't just mean the entities like ships, tanks, rockets but also different abilities and more complex AI) the benefits of a component based design become more and more obvious. The game has to be BIG for the entity system to save you time.

I have put a couple of articles together on this subject after I tried them out and got some quite good value out of using them. But again, I'm not proposing it and I am in favour of working games above else.

SkyAphid: here are 2 articles which may give you an explanation for 2 common patterns that make up an entity system (Java and specifically for games):
http://obviam.net/index.php/design-in-game-entities-object-composition-strategies-part-1/
http://obviam.net/index.php/design-in-game-entities-object-composition-strategies-part-2-the-state-pattern/
Offline Roquen
« Reply #11 - Posted 2012-05-28 18:47:13 »

Actually I'm pretty unbiased.  I don't care too much about what language I programming in (as long as it doesn't suck too made).  OS?  Don't care.  All of these things are toasters to me...whatever browns my bread is good enough.  I neither love nor hate most technologies...they work good enough or they don't.   What I do hate is false paths of silver bullets (which is utter B.S.) and component based is almost always over-engineering (actually I'd say always, but that's another story) wankery that is simply a current fad.  It's interesting that I've been aware of component base since the mid 1980s and there's been about zero interest in the model until recently (outside of native support..which again is another story).

As I've said before, I can think of zero situations where component based is superior (by any metric) than other other methods of composition.  We can all pretty much agree that design by inheritance is broken (for other than short trees) and that data-driven/composition is the solution (esp. in statically typed class based OO).  Beyond that reasonable answers will always be based on design needs.
Offline theagentd
« Reply #12 - Posted 2012-05-29 12:44:49 »

Actually I'm pretty unbiased.  I don't care too much about what language I programming in (as long as it doesn't suck too made).  OS?  Don't care.  All of these things are toasters to me...whatever browns my bread is good enough.  I neither love nor hate most technologies...they work good enough or they don't.   What I do hate is false paths of silver bullets (which is utter B.S.) and component based is almost always over-engineering (actually I'd say always, but that's another story) wankery that is simply a current fad.  It's interesting that I've been aware of component base since the mid 1980s and there's been about zero interest in the model until recently (outside of native support..which again is another story).

As I've said before, I can think of zero situations where component based is superior (by any metric) than other other methods of composition.  We can all pretty much agree that design by inheritance is broken (for other than short trees) and that data-driven/composition is the solution (esp. in statically typed class based OO).  Beyond that reasonable answers will always be based on design needs.
No-one said that component systems are the silver bullet for entity systems...

I've read your opinions on this in other threads too, and I've gotten really interested in what you think we all should be using. Just dismissing everything based on that it isn't perfect and doesn't solve anything isn't helping much. Inheritance is broken, component systems are bad, but composition is the solution ---> Huh

Myomyomyo.
Offline princec

JGO Kernel


Medals: 361
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #13 - Posted 2012-05-29 12:56:01 »

It's people trying to throw solutions at problems they don't even know they have or that aren't even problems which are the, er, problem.

An entity system written in Java will solve nothing for any developer here. Inheritance is so broken I've used it perfectly successfully in every single one of my games. I use a bit of composition here and there. When I change my mind about everything once again the Refactoring Fairy appears and makes my wishes come true in 5 minutes flat. QED.

How about actually trying to write a whole game, everyone, and then analysing what you spent your time on afterwards as accurately as you can, and then trying to optimise your time in that area in the next game you write? *lwjgl16k cough*

Cas Smiley

Offline ReBirth
« Reply #14 - Posted 2012-05-29 13:03:25 »

+1 to Roquen's sentiments; SkyAphid, just don't bother with it, you're wasting your time - even for educational purposes, as you will learn nothing from it.

Cas Smiley
Does that apply to UML too? Cheesy

@OP, even though you have to use it you better not create it but use what already made. It'll save your time, learning is faster than making (well not absolutely). I wonder what game you make now until an arraylist out of task.

Offline theagentd
« Reply #15 - Posted 2012-05-29 13:34:50 »

It's people trying to throw solutions at problems they don't even know they have or that aren't even problems which are the, er, problem.

An entity system written in Java will solve nothing for any developer here. Inheritance is so broken I've used it perfectly successfully in every single one of my games. I use a bit of composition here and there. When I change my mind about everything once again the Refactoring Fairy appears and makes my wishes come true in 5 minutes flat. QED.

How about actually trying to write a whole game, everyone, and then analysing what you spent your time on afterwards as accurately as you can, and then trying to optimise your time in that area in the next game you write? *lwjgl16k cough*

Cas Smiley
I spent my time perfectly well on my now cancelled LWJGL16K entry! My shadow mapper works perfectly now!

Myomyomyo.
Offline Roquen
« Reply #16 - Posted 2012-05-29 14:32:03 »

I've read your opinions on this in other threads too, and I've gotten really interested in what you think we all should be using. Just dismissing everything based on that it isn't perfect and doesn't solve anything isn't helping much. Inheritance is broken, component systems are bad, but composition is the solution ---> Huh
What's getting me more and more worked up on the subject is that component based questions are most frequently coming from people that obviously still don't have a grasp on java's base abstraction model. And I consider it to be downright cruel to suggest or encourage people in this boat to use a completely alien model...fighting with your language should always be one of the last things one attempts to tackle in the learning process.

WRT: Inheritance being broken.  This has been pretty much accepted since before hardly anyone outside of PARC even heard of object oriented programming.  The main issue here, however, is long lifetime software and evolving design.  Games should never fall into this category. If you're number of types is small..design by inheritance is reasonable and is exactly what most beginning programmers should do...learn to crawl before attempting to walk.  If their game design calls for a more complex abstraction model then there's a good chance that it's far too ambitious.  It's important that they have achievable goals within a limited time frame so they don't give up on, not only their pet project, but programming as a whole.

Learn the problems associated with only being able to crawl is important so that you truly understand them.  Augmenting this with some direct composition and you can already handle a reasonable amount of complexity.  When code designing complex systems one of your mantras should be:  CODE IS DATA.

WRT: What people should be doing.  The simplest thing available that addresses the needs of the design.  I keep attempting to motive myself to do a write-up on ArchType based, but I'm not getting around to it (basically it's a open class model).  Which of course isn't a silver bullet either...simply another option.

Now I don't want anyone to think I'm called them an idiot because they're using component-based.  Do whatever works for you.  Already got a library that works?  Fine..stick a fork in that problem and move on.  However I do question the rational for doing so in the first place.

Do you really need: "An entity IS an arbitrary container of ARBITRARY types."? 

Is that really the solution to your problem?  Why are you attempt to mimic prototype based instead of X?  Where X is another (potentially collection of) abstraction model(s).  For extendability of entity state-data can you change the above statement to: "An entity MAY be an arbitrary container of a small set of types."?


Offline princec

JGO Kernel


Medals: 361
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #17 - Posted 2012-05-29 14:47:42 »

Indeed. It's all this sort of wankery that is the reason almost nobody every writes any games in Java much to the massive embarrassment of the community. In the meantime I see more games than I can count coming out every second in virtually every other language or platform under the sun. What is it about Java that encourages such incredible procrastination?

Cas Smiley

Offline sproingie

JGO Kernel


Medals: 202



« Reply #18 - Posted 2012-05-29 15:57:58 »

In C++ you start with an engine and your style is going to fit whatever that engine demands.  Java doesn't have so much infrastructure, and forces everyone to reinvent not just wheels, but axles and suspension too.  When we see more mature engines come out for Java, we'll probably see a more common style emerge.  Presumably it'll be evolutions of the stuff targeting Android.

The other game dev forums are full of people fiddling over irrelevant details for their C++ projects.

Anyway, if your project is designed and coded entirely by one person, it hardly matters what model you use, since the best one is going to be the one the fits your brain the best.
Offline Roquen
« Reply #19 - Posted 2012-05-29 17:07:28 »

Anyway, if your project is designed and coded entirely by one person, it hardly matters what model you use, since the best one is going to be the one the fits your brain the best.
I one-hundred percent agree with this statement IFF (if-and-only-if) implementing, maintaining and using that model don't consume an excessive amount of time.
Offline theagentd
« Reply #20 - Posted 2012-05-29 17:16:07 »

Anyway, if your project is designed and coded entirely by one person, it hardly matters what model you use, since the best one is going to be the one the fits your brain the best.
I one-hundred percent agree with this statement IFF (if-and-only-if) implementing, maintaining and using that model don't consume an excessive amount of time.
Finally a response from you that I like!  Grin Grin Grin

Myomyomyo.
Offline Roquen
« Reply #21 - Posted 2012-05-29 18:13:45 »

In this thread or all thread?  Cheesy
Offline actual

JGO Coder


Medals: 23



« Reply #22 - Posted 2012-05-29 19:30:51 »

I keep attempting to motive myself to do a write-up on ArchType based, but I'm not getting around to it (basically it's a open class model).  Which of course isn't a silver bullet either...simply another option.

If it provides any added motivation, I would be interested in reading such a write up.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

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

The first screenshot will be displayed as a thumbnail.

atombrot (24 views)
2014-08-19 09:29:53

Tekkerue (24 views)
2014-08-16 06:45:27

Tekkerue (23 views)
2014-08-16 06:22:17

Tekkerue (13 views)
2014-08-16 06:20:21

Tekkerue (20 views)
2014-08-16 06:12:11

Rayexar (58 views)
2014-08-11 02:49:23

BurntPizza (38 views)
2014-08-09 21:09:32

BurntPizza (30 views)
2014-08-08 02:01:56

Norakomi (37 views)
2014-08-06 19:49:38

BurntPizza (67 views)
2014-08-03 02:57:17
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

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

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

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

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

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!