I''ve read various general articles around the internet on protocols and network game design and such like, and I''m about to start reading the DirectPlay tutorials. However, I wonder if anyone could answer a couple of game design questions which they''re not going to answer: 1. If converting a game to be multiplayer, should all data structures be reduced to the minimum possible size? I currently use (long) ints and doubles for everything, but changing everything to shorts and floats would literally halve the size of information about the state of the game world. 2. Peer to Peer vs Client to Server: My game is based on AI scripts. As such, it would be technically possible to the game running 100% on a server, with clients treating the battle as nothing more than a movie. Alternatively, I could have just a skeleton server dealing with people entering and leaving the game, and have the processing of the game done 100% on peoples'' clients. The game might freeze occasionally if the computers were trying to synchronise, but this wouldn''t matter anything like as much as it does in a FPS. There are also various inbetween versions, I''m sure, but having never done any network programming before I''m not really sure what to go for. Any advice appreciated, thanks,

> should all data structures be reduced to the minimum possible size?

Data structures should be constructed for speed in the game code and compressed for size for transport. If both contraints can be met at the same time in your case, the better, but that opportunity seldom arises in the real world. For example, one byte for rotation or acceleration is usually accurate. Another example, a 3D position in an FPS represented by 3 floats can be converted into a 2D coordinate and a few bits for the floor level you are at and if you are jumping or not. Even the 2D coordinate can be split into a fixed series of bytes: a byte has 2 nibbles giving you a 16x16 position matrix, and each additional byte gives you another 16x16 refinement into the previous cell; with 3 bytes, you can represent a position in a 4096x4096 matrix area.

> it would be technically possible to the game running 100% on a server,
> with clients treating the battle as nothing more than a movie.

This is how most FPS games work. They following the ''never trust the client'' rule and thus the client app boils down to rendering the current game state and player input is transferred to the server for processing and incremental game state changes are read back. RTS games are different because each and every client run the entire game simulation and only player commands are exchanged; the implicit trust in such a P2P setting comes from the ability to detect discrepancies in the commands wrt the game state.

-cb

Thanks for the reply.

W.r.t. the data sizes thing:

- I''ve read that unless you understand floating point doubles are safer than floats, but this wasn''t in books on games. In games is a normal float enough?

- I also read that 32 bit processors are designed to handle 32 bit values, so I use normal (long) ints even for things which are never going to be any bigger than you can hold in a short. If I changed them to shorts, would the amount of time lost in shifting values to the processor be more than made up for by there being no need to convert them for sending to other computers?

W.r.t peer-to-peer vs client-to-server:

My game is RTS-like, in that each player has ownership of a large number of units that wander around shooting each other.

Yet though you say RTS games don''t rely on a central server, they could do if they wanted, couldn''t they? I take it the reason they don''t is that bandwith is always in shorter supply than processor speed, hence if you have the option of dividing the network load between multiple computers then you do so.

In my game the total dependence on AI scripts means your input doesn''t effect the running of the game - you can open windows to display different sorts of information, but you can''t order units to act differently - once started the game is independent of the players. So clients wouldn''t need very much upload bandwith to a central server at all. Still, I guess even then the download requirements on the server might be too great - I guess normal RTS peers only tell other peers about what their own units are doing, whilst a central server design would have to be sending clients information on everyone''s units.

Hmmm...any more advice anyone?

> In games is a normal float enough?

In games, whatever you do that makes a game go fast and fun to play superseeds scientific exactitude. ''float'' is generally acceptable, but if you deperately need ''double'' precision for whatever reason then use that by all means.

> so I use normal (long) ints

This is fine for internal struct as long as it is not for loaded game data (in general). Game data usually takes megabytes of RAM and if you''re not careful you will end up in swap city. Game data (BSP trees, textures, etc.) is generally not exchanged in a multiplayer scenario, just incremental changes to the ''game state'' (positions, player stance, etc).

For game state information, that depends on what those ''long'' represent. Take a look at this article for more info on this particular topic.

> My game is RTS-like,

A more complete explanation of P2P use in RTS along with solutions can be found here.

-cb

Wow, thanks, that Age Of Empires article is really interesting. I''d never even considered that you could do it like that.

This may take some time...

I''ve just had a thought...if there isn''t any player input, I don''t need to have a multiplayer mode as such at all.

Not only does it not matter how out of synch the games are running, who even cares when the games are running. If someone wants to find out if their AI scripted army can beat someone else''s, all they need to do is agree on a map, share their army set up and AI scripts, and decide on a random number seed to use.

After that any players involved can play the battle whenever they want, what happens will always going to be the same.

I''ll want some way that the results of the battle worked out by the different computers can be validated against one another for any official statistics about who won and lost, but other than that I don''t actually have to program a multiplayer game at all.