Hooks

I work at a real games company doing real games coding. I've been doing it
long enough now to know that my real barrier to getting stuff done is never
about finding the perfect abstraction, it's about knowing how to get at the
transition from one state to another for some variable inside a class that
hides it's implementation.
After all the architects have gone home, and the engine has been in use for
a a couple of games, you get in that situation where adding stuff doesn't
involve coding any more. It's more like detective work. Most of the time.
The reason it's most of the time is probably because all the good coders
that could be doing cool new coding are spending their time figuring out how
to unlock the mysteries of coder X who left the company two years ago, and
had a really clever way of encapsulating his data.

Now, I'm not saying this is because of OO, but from each of my experiences
where I can't figure out how an object's state got how it got, it's been
because someone decided that the object should encapsulate its state and
hide it from the rest of the world. Thoroughly.

This used to be a mantra of mine. Hide the data, the internal state of an
object is it's problem.

But, the last few years have taught me that really, what I always needed was
to have a way of hooking into all variables and catching them changing
state. We accidentally had this "variable registry" for globals, but until
the last few months I hadn't really given it too much thought from an entity
point of view. Someone pointed me at aspect oriented, and though I thought
it was nuts, it did make me think that it would be nice to have a generic
publish and subscribe mechanism built into all our objects.

Going back to data oriented stuff: transforms do provide (as do SOs and POs)
a solid way to hook into the state changes in a system. They automatically
let you subscribe to all state changes quite easily. Whatever your
implementation, as long as you write out your code as data transforms,
you'll always have an opportunity to catch modifications to state.

OO C++ might be nicer to look at than data oriented C++ (if it's done right)
but it seems that as it so seldom is done right, can't we just move to a
paradigm that newbies will be able to understand enough to not cause us
massive grief later on when we pick up the pieces?

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