Jump to content
Posted 03 July 2012 - 07:57 PM
Posted 03 July 2012 - 09:57 PM
Posted 03 July 2012 - 10:15 PM
Posted 03 July 2012 - 11:13 PM
I think that this is quite common, you often have an object attached to its parent (member->party, item->npc,guild->town) which acts depending on the state of the parent.
where children have their position and velocities relative to and dependant on the parent
Posted 04 July 2012 - 02:56 AM
Posted 04 July 2012 - 02:36 PM
Posted 05 July 2012 - 01:12 AM
I suggest to consider the idea of dropping extensive update process. I once read an article suggesting to not update at all.
I have a system where game objects can contain other game objects as their children, and have an update(float DeltaTime) function in my game objects which does the per-frame updates (ticks, or whatever your favorite engine calls it). I'm wondering whether it makes more sense to update child objects before their parents or the other way around
Posted 05 July 2012 - 07:12 AM
Ideally, the physics should work with 2 states: current that is read only and future that is write only; this helps to make use of multiple CPUs (by making the physics independent of the order of updating). It may be useful to separate e.g. AI updating from physics updating. Ahh, and also, if physics gets different values depending to the order (e.g. two masses connected by a spring, and result depends to which is updated first), that is rather bad and makes it difficult/impossible to ensure conservation of momentum (and energy).
Dmytry, that's usually what I do in a clear owner->child type of a scenario, but it may not work in the aforementioned physics attachment system, since whatever function goes on updating all your objects would probably update the child already. Hence why i said, it depends on the nature of the relationship.
Edited by Dmytry, 05 July 2012 - 07:15 AM.