Jump to content

  • Log In with Google      Sign In   
  • Create Account

Data structure design


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
1 reply to this topic

#1 bstach   Members   -  Reputation: 122

Like
Likes
Like

Posted 23 July 1999 - 07:45 AM

I know that one of the keys to efficient network programming is proper data structure design. However I am not sure how to aproach the task in the context of game development. Does anyone know of any good examples of, or docs on multiplayer data structure design. In paticular, structure design in realtime strategy games. The amount of information that has to be sent to keep game sessions in sync seems to be quite large, but I know that it can be minimized. (all of the other RTS games can do it so why can't I?) Any resources on methods to minimze data across the network would be apreciated.
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).]


Sponsor:

#2 DavidRM   Members   -  Reputation: 270

Like
Likes
Like

Posted 23 July 1999 - 07:45 AM

I actually have some experience in this, but it's with a client-server setup rather than peer-to-peer.

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





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS