Re: sparse components

You might enjoy this:

http://www.insomniacgames.com/blogcast/blog/mike_acton/1500756

Sorry I can't elaborate much, but I can tell you you're not the only one 
thinking in that direction.

On 5/28/2010 16:44 PM, Richard Fabian wrote:
> I'm working on some stuff at the moment, a kind of collection of 
> techniques that I've started pulling together into a more coherent 
> single way of thinking.
>
> One of the techniques is something I've been calling Existence Based 
> Processing, and it was born of my early implementations of component 
> based development. I've now heard someone call it Push Processing, but 
> can't find any references on Google, and wondered if anyone knew of 
> the right search phrase.
> 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. 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. At the time I had simple finite state machines 
> for AI that switched in and out which component the AI was using as a 
> hierarchical FSM, but I've seen now that this rabbit hole goes deeper.
>
> 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'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'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, including some work on making your components behave as 
> states for an FSM, or even, because now I only have the concept of an 
> implicit core entity, the ability to generate multiple entities from 
> one when needed (such as level of detail change), and also collapse 
> multiple entities down to one when the level of detail is no longer 
> necessary.
>
> A bit of background,: I was spurred on a bit by the "OOP is bad" talk 
> into putting a bit more effort into what I was doing so that other 
> people might benefit. The basis of my stuff is really a revisit to old 
> computer science, relational databases to be specific, and leveraging 
> what has been learned over the decades into something more useful for 
> games. I've found that there are a number of parallels in database 
> technology and current high performance game development, and I think 
> it's because we're effectively in the same hardware situation, just 
> scaled up a lot. I think of the old DB hard drives as our main memory, 
> and their old small computers as being equivalent to our modern CPUs 
> and parallel machines. That is, we're using powerful but small 
> processing machines, committing transforms on the data set that is in 
> a slow medium.
>
> 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.
>

-- 
Javier Arevalo
http://www.iguanademos.com/Jare

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