sparse components

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.

Many thanks for reading to the bottom.

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