Re: sparse components

The crux of it is that you have system/manager classes that deal with one specific type of component/aspect data.  They are keyed by entity ID and can be daisy chained together reasonably well by an in place linked list.  In a database you would store them as tables of each specific component/aspect type primary keyed by entity ID.  'There is no entity' - the entity is a collection of components tied together by an ID or linked list.
There are some articles/books I forget that describe component systems using an entity class that hold a collection and a map to IComponent stuff with virtual functions etc etc.  I would suggest just don't do it that way.  If you have virtual functions anywhere they should only be in your system/manager classes which each time you call should be doing operations on large groups of their contained data.
Look at what the systems/managers hold as tables of data with various types of indices and that they provide operations on sets of data and queries on them.

In practice I have used a component based system for many years from iphone games to mmo games where it is of even more benefit due to the larger number of objects.  It's benefited greatly also from Insomniac's presentations in later versions so I suggest you should give them a read too.
Organising things in such an 'aspect orientated' fashion I believe is of great benefit to the overall structure and design of your project and really you should be doing it that way already.  It also very useful from the game design perspective as many other people have stated.


Date: Sun, 30 May 2010 17:57:43 -0700
From: [email protected]
To: [email protected]
Subject: Re: [Sweng-Gamedev] sparse components



Can someone expand upon what it means to orient the component processing to a per component type rather than per entity? Is it basically changing the relationship between entities and components; instead of registering a component with an entity, the entity is registered with the component and added to a list of entities?
From: Tony Albrecht <[email protected]>
To: [email protected]
Sent: Sun, May 30, 2010
 7:49:21 PM
Subject: Re: [Sweng-Gamedev] sparse components


On 29 May 2010 00:14, Richard Fabian <[email protected]> wrote:

In my component system, I oriented the component processing to a per component type rather than per entity, which meant I was keeping the I cache warm all the time. 
This is how I've always thought component systems worked and was their main benefit
 I was lucky, I hadn't noticed this benefit at the time, and now I do. Also, because components only existed for entities which needed them, there was no processing done for entities without that component. 

Its an awesome benefit - like you said your cache is warm and it lends itself very well to parallel processing. Dependencies are far more obvious than in traditional entity based processing. (Note how I avoided mentioning OOP for fear of dragging this thread even further off topic)
 So, what's this stuff called normally, and also, why aren't we taught anything about it, and why aren't we using it?

I don't know what its called, but I think the main reason that its not being used is because it hasn't been used much. Most programmers aren't familiar with it and would prefer to continue with their old thought processes - especially when time and budget are tight.
 I've seen speed ups in my own code due to rewriting small sections in this style, so can't fathom why we're not using it in general, or for that matter, taught it at all.

I think all it will take is a few people to actually write games using this type of (dare I say it) pattern and to share the benefits of it for it to be adapted by more people. Up until recently the benefits of component based programming weren't really evident, but with our painfully slow cache misses and multiple core systems, the benefits are really starting to outweigh the negative (mainly lack of familiarity).
 


I've breathed even more life into this technique with my current work on writing up my experience with data oriented development by adding or at least clarifying what this sparse existence component technique can offer, 

I applaud this type of work and look forward to reading what you find. 



I'm currently doing general research to find out if there are other old science techniques that we've forgotten, or not repurposed, while also writing a proof of concept rogue-like in 3D. This does mean I have to write two whole games that are exactly the same, as best I can, just to prove any of my research, but I hope that doing so I may come across some other unexpected discoveries.




Writing two games, while painful, is the best way for people to really appreciate the benefits of your component technique. It provides an easy way for people to contract performance, memory use and usability - although you'll find that many will still miss the point completely and start arguing about OOP.

One of the reasons I think that component based architectures haven't really taken off is that they only really start to benefit once your systems scale up significantly. For example, dealing with 100s or 1,000s of object rather than 10s. What interests me is what is the pivot point at which component is better performing than an entity based system? Take your rogue-like for example; Are you really better off treating health regeneration as a separate component and incrementing all live health components at once, or since the health regen is such a trivial calculation, should that be rolled in with something else? Where do you draw the line?

I honestly think that as people see more well written component systems that work well on current HW and scale well onto multiple cores, we'll see more and more component based solutions. From what I remember, Pandemic used a simple, high level component based system on PS2 for Destroy All Aliens 2 (and possibly 1) and Mercenaries 2 on PS3 and X360 used a much lower level component based system. I wasn't closely involved in those projects so I can't really provide an info on the pros and cons of those implementations.

-Tony




 		 	   		  
_________________________________________________________________
http://clk.atdmt.com/UKM/go/195013117/direct/01/
We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com