>> If your game can handle a slight lag, you could put out a timestamp
>> with your commands, and all the commands are delayed a couple of
>> seconds, to make sure that they all get executed at exactly the same
>> frame on each machine- then you could have the AI being executed on
>>each machine. But with a fast action game this wouldn't be practical.

>okay, heres the "closer to original" idea... The server would gather up
>the commands for 10th of a second or whatever delay you wanted to use.
>The server may have 10 commands from different players. It would post
>these commands to all of the players and the players would read them in,
>sort them and excecute them. The players would also get an extra packet
>telling them how many commands they should expect. In this case 10. So
>they stay in a loop until all 10 commands have arived. This would force
>some kind of "time sync" every 10th second where all players will accept
>incomming commands and execute them. This means the environment is
>kept in perfect sync so even the cpu AI will be using the same data
>on each machine. This verion has the drawback of forcing a delay until
>the packets have arived but with carefull choice of 'delay time' the
>lag could be beaten. While I recomended the server would be running
>with some kind of time delay (10th of a second or whatever) the games
>would be running in "frames" so if a game is running at 20fps it
>would read incomming commands every 2 frames. Carefull thought would
>be needed to avoid the case where the server and the games are running
>at the wrong speeds :)

   Hmm, yes that would work. The only problem I see here is with your monstas running around- if the delays from the server are different they might change direction at different times on different machines, as the frame might get executed at different times on the different machines. The internal AI is executed the same, as all the commands are executed in same frame in each machine. As long as it doesn't really matter to the gameplay, and they're just a visual clue, it should work ok, - especially as you have many peasants wandering around, there normally should be enough to get the idea across.
   Also, more importantly, I assume all their movements are pre-calculated (ie: go to point x,y) in each frame so they'd all wander around identically.
   Your system is then synced by frame, rather than by all running the same synced time. As your system has some time between frames, it would allow your computer to `catch up' so to speak with the other machines, if your machine got behind because of a slow lag time time, or being slowed by multi-tasking (assuming that the multi-tasking wasn't taking too much CPU time for too long :-/
   The 1/10th of a second delay of the Server (100ms) would be too much of an overhead for a speed game I would think, but wouldn't be noticed in your game :-)

On 18-Apr-98, Paul Burkey wrote:

>> - especially as you have many peasants wandering around, there
>> normally should be enough to get the idea across.
>> Also, more importantly, I assume all their movements are
>> pre-calculated (ie: go to point x,y) in each frame so they'd all
>>wander around identically.

>No, the people calculate their routes as they walk. This avoids the
>case where a building is placed in the middle of a pre-calculated path
>causing him to walk through it. It also allows him to escape or
>attack any enemy characters who could also cross his path. Then maybe
>he is following another character who is moving about. These are
>just a few simple reasons why the routes should be caulculated in
>real-time. This doesn't affect the TCP commands system because of the
>way it is synced up on a 'frame by frame' basis.

   Yes, all commands are started at the same frame on each machine, so any characters would start off on a journey (say) on the same frame, and would wander around the same way, as the AI is being executed identically on each machine.

>> The 1/10th of a second delay of the Server (100ms) would be too
>>much of an overhead for a speed game I would think, but wouldn't be >> noticed in your game :-)

>The time lag only affects the "control" of the game. So the time when
>you'd notice a large amount of lag would be when you issue a command
>and it doesn't actually take effect for a second or two.

Yeah, that's what I meant, not actual CPU time :)