Re: sparse components

I read that, but felt like it was more about the implentation of the
components rather than the philosophy of use or what granularity to run
stuff at. Also, for a game as big as theirs, only 295 components? Is he
lumping together all the finite state machine components by who they belong
to? Although related, I still consider each state to be independent,
otherwise we might accidentally end up back in OOP world. Also, it might be
harder to add new states (outside state causes a transition to a previously
not considered state), and also runtime loading of new state sets for
existent FSM state collections.

On 28 May 2010 16:35, Joe Valenzuela <[email protected]> wrote:

> Terrance Cohen (of Insomniac fame) did a presentation recently on his
> dynamic component architecture at Canada GDC.  It sounds similar to the
> system you're describing.
>
>
> https://docs.google.com/present/view?id=0ATIohmzo6z7TZGhjbmhidnFfMTg1MWNkcTJmcWZ4&hl=en
>
> (presentation starts on slide 5).
>
> --
> jv
>
> -----Original Message-----
> >From: Javier Arevalo <[email protected]>
> >Sent: May 28, 2010 8:18 AM
> >To: [email protected]
> >Subject: Re: [Sweng-Gamedev] 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
>
> _______________________________________________
> 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