[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Game Loop and Simulation




You might be interested in links to a military
simulation spec: 
Distributed Interactive Simulation (DIS)
and/or
High Level Architecture (HLA sometimes called DIS++)

DIS is also an IEEE spec.

The literature re: this topic might tell you more
about what you're interested in.  Its a little
different from your focus, DIS allows multiple
distributed simulations to interact together to
simulate a common environment.  Each simulation
handles its own domain of expertise.  E.g. a missile
simulation may just simulate that missile performance
and a larger air-combat theatre.  If you're interested
in a practical application of DIS look for an
open-source game called ACM (Air Combat Simulation). 
I don't know if the DIS support is actually complete
yet.

Some papers on distributed simulation detail
syncronization by allowing some events to unroll
backwards in time. 

--- "Marc A. Lepage" <mlepage@antimeta.com> wrote:
> I'm interested in the game update loop as applied to
> networked RTS
> games. I would like to start some serious discussion
> on this issue. To
> begin, I have reference material from a few sources.
> 
> First, Andrew Rollings and Dave Morris write about
> game loops in their
> book Game Architecture and Design:
> 
> ----- BEGIN QUOTE -----

 quote removed...

> Second, Dave Pottinger of Ensemble Studios discusses
> different lengths
> for the main game update loop in his article
> Coordinated Unit Movement:
> 
>
http://www.gamasutra.com/features/game_design/19990122/movement_01.htm
> 
> So, assume I wish to run a distributed
> (peer-to-peer) discrete event
> simulation. That is, I want the exact same thing to
> happen on each node.
> Forget animation, and consider just the simulation
> itself.
> 
> The simplest method, the one I've been planning on
> until now, is to use
> a fixed frame rate. For example, suppose I choose
> 20fps. Then every node
> runs the simulation at 20 ticks per second, and
> attempt to draw a frame
> of animation for each tick. If the computer is
> faster, then it waits. If
> it is slower, it drops frames of animation. If it is
> too slow, then the
> entire distributed simulation runs at the speed of
> the slowest node, or
> that node is dropped.
> 
> In this case, the fixed frame rate is critical to
> the synchronizing of
> the distributed simulation. Every node must perform
> the same
> calculations.
> 
> Suppose a unit is at location (100,100). It wishes
> to move to (200,200).
> Its movement speed is 4 per tick. Pythagoras tells
> us the distance is
> approximately 141.42. Rounding up, it will take us
> 36 ticks to make the
> 
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com