Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (576)
games submitted by our members
Games in WIP (497)
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  
  doubt about entity/Component system  (Read 1857 times)
0 Members and 1 Guest are viewing this topic.
Offline Kizuke

Junior Newbie





« Posted 2011-09-13 17:36:32 »

Hi guys, I'm trying to implement a entity/component system to my game but there are things that I just don't get.

For example, where should all the data be, in the entity/GameObject/whatever-you-wanna-call-it class or in the component that uses it? With data I mean, for example the health of the player, the weapon it has equipped, the number of grenades it has, etc... Should i have a component like PlayerInfoComponent, or just InfoComponent that keeps that data?


Hope you can point me in the right direction
Thanks in advance
Offline cylab

JGO Knight


Medals: 34



« Reply #1 - Posted 2011-09-13 17:41:52 »

Should i have a component like PlayerInfoComponent, or just InfoComponent that keeps that data?
Yep. The idea of a component system is to have an Entity that consists of the absolute minimum of things that are neccessary for your engine to function properly and put everything else in componenents.

Mathias - I Know What [you] Did Last Summer!
Offline Kizuke

Junior Newbie





« Reply #2 - Posted 2011-09-13 17:47:47 »

Thanks for replying so quickly Cheesy

So if I understand correctly, components are used both for the logic, like a graphicsComponent for drawing stuff and for keep data like the InfoComponent i said before, is this right?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline lhkbob

JGO Knight


Medals: 32



« Reply #3 - Posted 2011-09-13 17:55:23 »

All of the player data, health, etc. should be stored in Components.  You may need multiple component types to store it all.  As an example, you would probably want a HealthComponent and an ArmorComponent instead of combining them.  You want the components to give you as much flexibility as possible without being annoying to use.

Continuing the above point, why limit the entities that can hold a weapon or grenades to the player.  Couldn't AI bots eventually need the same information.  You might then want components for WeaponUser or GrenadeThrower to signal the Entity knows how to use them.

Entities are meant to hold onto a set of components, by themselves they don't have any game specific data stored with them.  They are effectively the combination of all the component's data that have been added to them.

With regards to your second post:
Components are meant to hold data, so a graphics component might hold the information necessary to draw but it wouldn't contain the logic of drawing.  Part of the flexibility with the entity component system is that the components hold data, the entities organize data, and then you have separate pieces of code (which I usually call controllers or processors) that process and update the system from frame to frame.

Then you have very healthy decoupling between your data and the way it's processed.  Additionally, these practices lend themselves towards data-oriented programming, which tends to have better performance because of better memory cache use.

Offline Kizuke

Junior Newbie





« Reply #4 - Posted 2011-09-13 18:06:18 »

I think I understand it a bit better now, thanks a lot!!
Offline arielsan
« Reply #5 - Posted 2011-09-13 18:51:10 »

I suggest you take a look at Artemis Entity System Framework and discussion about it in slick forums, could be of help.

Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2


Make it work; make it better.


« Reply #6 - Posted 2011-09-13 19:45:50 »

Don't forget the WiKi.

http://entity-systems.wikidot.com/

Offline endolf

JGO Knight


Medals: 7
Projects: 1


Current project release date: sometime in 3003


« Reply #7 - Posted 2011-09-13 21:48:44 »

Hi

I've done an entity component system for darkvoid (work in progress), I have removed the entity class completely, I have a UUID for the ID of the entity. My game world has a registry of components (instead of a list of entities), this means I can quickly find all the 'position' components for everything in the area, or all of the 'velocity' components. This means my systems can easily find all of the objects that need their position updating based on a velocity, same with acceleration. My player controller system can just check for a 'playeravatar' component, and from it's object ID it can find the correct position/velocity components to update.

Endolf

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 605
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #8 - Posted 2011-09-13 21:59:07 »

I've done an entity component system for darkvoid (work in progress), I have removed the entity class completely, I have a UUID for the ID of the entity. My game world has a registry of components (instead of a list of entities), this means I can quickly find all the 'position' components for everything in the area, or all of the 'velocity' components. This means my systems can easily find all of the objects that need their position updating based on a velocity, same with acceleration. My player controller system can just check for a 'playeravatar' component, and from it's object ID it can find the correct position/velocity components to update.
You're essentially describing a relational database implemented in a OO language.

Do you find it easy to work with this 'mismatch' ? (not meaning to sound negative)

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

JGO Knight


Medals: 7
Projects: 1


Current project release date: sometime in 3003


« Reply #9 - Posted 2011-09-13 22:03:00 »

You're essentially describing a relational database implemented in a OO language.

There is an element of that yes. When you get to the point that the entity class is just a holder for a list of components, it makes many things (like persistence) easier to just remove it. I think the article that adam wrote touched on doing it that way too.

Endolf

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline sproingie
« Reply #10 - Posted 2011-09-13 23:47:59 »

The relationship (pun intended) between entity systems and RDBMS's seems to be intentional, from what I can tell.  The strengths are identical: the main one being the "open world extensibility" you get from relations (just stick in a join).  But even the memory layout benefits touted with respect to clustering related "subsystem" data together is basically similar to the performance benefits claimed vertical schema databases. 

Yes there's a bit of qualified language there when it comes to the performance implications.  They're real in some cases, but since Java doesn't give you placement allocators, the benefits might only come to light in terms of simply having smaller objects, in which case it seems you could trim unused features off your "regular objects" to get the same results.  Is there any objective benchmark data out there for Java entity systems that demonstrates performance benefits?

Offline Gudradain
« Reply #11 - Posted 2011-09-14 00:16:30 »

Hmmm, full fledged Entity System might be need for huge game. Especially if you have to store your world in a database like when doing an MMO. But, I have yet to understand the utility of separating completely the data from the functionality when you are working on a medium size game.

In small game you can just do anything in anyway you want and it might reach a working state at some point and then you can say : Hey here is my game!

In medium game you have to plan a bit and make a good OO hierarchy or your code become a mess that you are not able to work with.

The problem in planning a good OO hierarchy is that you don't know what you want from the start. And, even when you reach the point where you know what you want, you will see it is really hard to change all the big class that have hundred lines of code in them. You might want to take some functionality of one class to put it in another but can't get it out of that class because there is too many variable and method that you can only access within the class it is actually.

I did tried my own Entity-like system and, from trying it, it change a lot of what I initially think I should use it for.

The best things of Entity-like system for medium game is the module approach. Separate each functionality of a class in a module. That module should contain nearly all the data it needs to operate and nearly all the methods it needs. (The key word here is nearly). It is really hard to make good general code that can be reuse anywhere, so you should not try to do a general module that could be use directly by any class just by putting in it. (That's a false dream). But, by splitting every functionality in his own module, it is really easy to refactor that module to make it work with another class.

N.B. : You might realize that by working with module you need to put a lot more methods public that you normally does in the OO way. I thought before that putting as many things with low visibility (private or protected) was the best things to do, but it's not when you are doing game programming. You are refactoring so many things all the time that it's a lot easier to have as many things as possible public.

N.B2. : Any code that is hard to refactor for game programming is a bad idea. OO is hard to refactor. Modules (a sort of Entity system) are easy.
Offline cylab

JGO Knight


Medals: 34



« Reply #12 - Posted 2011-09-14 10:04:59 »

I would go with Entity instances holding the components and a RendererComponent directly drawing the Entity for starters. There is plenty enough flexibility to replace this later if needed. You can also add some "indixed" lists over the components later for fast lookup, if this really improves stuff.

Keep it simple and explicit (don't know id this is the right word here Wink), don't try to write an abstract Engine - you won't get anywhere otherwise - i know, I've been there Wink

Mathias - I Know What [you] Did Last Summer!
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.

xsi3rr4x (12 views)
2014-04-15 18:08:23

BurntPizza (11 views)
2014-04-15 03:46:01

UprightPath (24 views)
2014-04-14 17:39:50

UprightPath (10 views)
2014-04-14 17:35:47

Porlus (27 views)
2014-04-14 15:48:38

tom_mai78101 (49 views)
2014-04-10 04:04:31

BurntPizza (108 views)
2014-04-08 23:06:04

tom_mai78101 (208 views)
2014-04-05 13:34:39

trollwarrior1 (176 views)
2014-04-04 12:06:45

CJLetsGame (182 views)
2014-04-01 02:16:10
List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:05:20
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!