Re: sparse components

On 31 May 2010 00:49, Tony Albrecht <[email protected]> wrote:

> 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've been unfortunate enough to work in places where that "main benefit"
wasn't realised.


>
>
>> 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.
>

Oddly though, it's being used all the time - outside games.


>
>
>>
>> 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 saw immediate benefits from using it, it definitely saved checking to see
if I needed to start asking for energy for regenerating health, which I
guess would  otherwise have pulled another variable into the cache just in
case the health was less than max. Its quite amazing trying to figure out
why each little component has given back so much, sometimes the reasoning
can be quite obscure.


> -Tony
>
>


-- 
fabs();
Just because the world is full of people that think just like you, doesn't
mean the other ones can't be right.

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