Re: Granularity and update - RE: strategies/patterns for composition
Kyle Wilson <kyle <at> gamearchitect.net>
2007-01-06 17:49:58 GMT
Oops! I was just checking my new Sweng-gamedev mail and realized that in
the crush of holidays, milestone deliverables and business travel last
month, I never replied to this post from November. Oh, well, six weeks late
is better than never, right?
A long time ago, Nick Trout wrote:
> When you say DAG, do you mean list of lists? i.e. system A is (state)
> dependent on system B,
> so if I add a component which has a dependency on A, I know it must update
> all of the B
> component data before A?
Our dependency DAG comprises nodes in a graph, each containing a vector of
parent node pointers and a vector of child node pointers. All parents must
update before any of their children can update. Nodes which aren't dirtied
during the course of a frame don't get updated at all.
The design was somewhat shaped by
http://www.gamasutra.com/features/20030829/vanderbeek_01.shtml. And the
dependency graph description in the Maya 6.5 API whitepaper
(http://downloads.alias.com/mkt/gmk_maya_65_api_whitepaper.pdf) might also
be helpful, though our implementation is pretty different.
> I'm curious: do you think you could specify dependencies at the system
> level (assuming you
> have a fairly well encapsulated game systems that could be updated
> sequentially in a fixed order)
> and then do away with the DAG?
I don't think so. The system arose out of an issue that came up in the
development of the MechAssault games where we often had game-object
behaviors that depended on the final position of a bone in the scene
hierarchy. (Either we wanted to attach one object to a particular location
on another or we wanted to emit weapon effects from the final position of a
weapon at the end of a frame, for example). Normally we updated all game
object logic, then all scene hierarchy positions. But in these cases, we
ran additional animation and update passes on the objects we cared about so
that we could sample frame-end bone positions while we were still updating
game logic. This was a pretty hacky fix, but it worked, at the cost of a
millisecond or two of redundant animations and updates.
> Do you think the DAG is necessary because the granularity of the
> components is too small?
Pretty much. In our current game, we've switched to a component-based game
object architecture, and the relationships between objects have become even
more complicated. I think that we have a number of circumstances where a
component from object A depends on a component from object B, which in turn
depends on another component back in object A. And the relationships change
every time a new object is spawned, someone gets into a vehicle, someone
picks up a weapon, etc.
I'd love to be able to define up front an fixed order for updating
components of different classes, so I could do away with the DAG and just
have an explicit, hard-coded update order for all game systems. But I think
that would only be feasible in a pretty static game.
> Couldn't you just keep a queue of objects to create (and perhaps delete)
> whilst the DAG is
> updated and then just wire in the new objects once the DAG update is
> finished?
I'd also love to be able to do that. Unfortunately, our gameplay
programmers were adamant that they needed to be able to spawn new nodes and
update them in the order in which they're spawned. We have some systems
that basically depend on every game object. For example, there's a single
"Physics Update" node that depends on all AI/player inputs that might apply
impulses and is in turn depended on by everything that cares about the final
positions of objects in a frame. So when we spawn new objects, we have to
make sure they spawn and get updated before the physics node updates.
This is a pain, but given the kind of game we're making, I don't see how we
could get away with deferring all object creation to the next frame or
requiring objects to be spawned in a proper state without updating.
Regards,
Kyle Wilson
Day 1 Studios
_______________________________________________
sweng-gamedev mailing list
sweng-gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com