Re: 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

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