We are at the start of our development cycle so now is the best time to think about this stuff.
Thanks in advance.
[This message has been edited by bstach (edited July 23, 1999).]
Thanks in advance.
[This message has been edited by bstach (edited July 23, 1999).]
The only part of the syncing that's truly "large" is the initial setup, getting everybody on the "same page" essentially. After that, you only need to send and process changes. And most of these changes are pretty straightforward: Create Unit, Damage Unit, Move Unit, and so on.
In the client-server model I'm used to, the client only knows about those parts of the map the player has "eyes" in. In a peer-to-peer, though, I would assume that every peer has to know the entire map and all units on it and what they're doing. The end result isn't really that different, though, and it comes down to the peers keeping each other up to date.
Also, if you can afford a few milleseconds of extra latency, you can look into possibly compressing the information sent using one of the non-patented freeware compression algorithms (such as the one in zlib). The time saved in reduced transmission time usually more than makes up for the overhead of the algorithm. But that's something for *after* you have the rest of it working. =)
------------------
DavidRM
Samu Games
http://www.samugames.com