Re: sparse components

I've found that the smaller and more conceptually state oriented you make
your components, the more likely you can reap the benefits of doing
component type oriented processing. I call it existence based processing
because if it exists, it's in a list, but I don't process entities, I
process lists.

An example of a component for me can be a very small part, such as
HasBeenHurt component, which maintains the current non-default health value,
processes health regeneration, and processes <0 health by requesting the
component destruction on the Alive logic, and creating Dead logic component
for the implicit entity.

On 28 May 2010 16:28, Felix Kerger <[email protected]> wrote:

>  Hi,
> here is a discussion in a similar direction
> http://www.ogre3d.org/forums/viewtopic.php?f=1&t=36015 .
> Im also developing a component system but due to time constrains the
> development is on hold right now, but it would be interesting to read more
> about your system. I have a paper about mine, but sadly its in German.
>
> have a nice day
> Felix
>
>
> On 28.05.2010 16:44, 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.
>
>  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]://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
>
>
>
> _______________________________________________
> Sweng-Gamedev mailing list
> [email protected]
> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
>
>


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