Re: sparse components

On 28 May 2010 19:41, Conor Stokes <[email protected]>wrote:

> The idea of externally abstracted state machines that talk to each other
> via a limited message interface (OOP) is a very good way of providing
> unbreakable contracts so people don't have to think of every implementation
> detail when using your code (in many ways, it doesn't go far enough). The
> shortcuts placed on top of that for re-use (inheritance, polymorphism) are
> great for certain cases where you have to do the same thing across
> heterogeneous data with similar facets. However the simplest implementation
> of these ideas becomes very constricting when you're looking for the best
> performance. To get the most performance with current OOP languages you may
> end up encapsulating more and more complex state machines with more complex
> operations on what is really quite homogeneous data, in which case you are
> giving up the benefit of higher level abstractions for performance. At this
> stage, it may seem like the encapsulation is not really worthwhile, because
> you
>  have so much complexity underneath and so much exposed to escape the
> performance constraining encapsulation mechanism that you don't feel like
> you're gaining any benefit. However, this is when you most need the
> encapsulation around the complex system, to hide the implementation
> complexity from the rest of the world.
>
>
Something that's pushed me further towards the data processing route is the
number of times I've looked at an apparently complex system to manipulate
complex data, only to find that the data was merely overly complex and it
just needed a little cleaning up. At least if you don't have the clever
containers of OO development, you can't easily get into complex data
territory. You find that you automatically think like database engineers,
and start using normal form analysis. It's quite shocking if you're working
on a mature game/engine and just run a pretty basic normalisation over your
structures. If it's not, can I come and work at your company ;)


>
> I think Corrinne Yu put it best recently in her Channel 9 interview when
> she was contrasting C against other languages; C was successful vs a lot of
> higher level languages because it presented the most logical and clearest
> representation of what the computer (essentially a single state machine) was
> doing at a low level. Now these machines work best with data concurrency and
> local state the new systems language has to represent that reality.
>
>
Yes, the old languages have already had their "scope" bugs either fixed, or
patched so it doesn't matter. Which I think is why most of my findings seem
to link to old solutions in SQL or systems development.


> Cheers,
> Conor
>
>
> ----- Original Message ----
>

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