I''ve created my game with multiplayer support in mind so I pretty much know (with a bit of modification) that it''s capable of doing multiplayer. But, I was just wondering if there are any tips that you guys may have before I move on. And also, with the connections, is this basically what should happen for a basic small scale network game? Server accepts all connections. Server sends all game data to clients. --- Server sends all client data to all clients. Once clients recieve data, they update using the data and update it and send back. Once the server recieves, it would once again update the data and repley to the client with the new data. ---- Does it just ping back and fourth updating data with all clients like that? And this happens seperate to the game loop right? The game loop would just use the current data given by the clients. - Rob Loach OverTech Technologies __________________________ "Life moves pretty fast. If you don''t stop and look around once in awhile, you could miss it." - Ferris Bueller

quote:

---

Server accepts all connections.
Server sends all game data to clients.
---
Server sends all client data to all clients.
Once clients recieve data, they update using the data and update it and send back.
Once the server recieves, it would once again update the data and repley to the client with the new data.
----

---

This is basically what you do.
A few coments:
1) The server should also validate any data from the client. Remember: all clients a cheats!

2) The server doesn''t need to send all data to all clients. Only what the client can currently see or interact with.

Depending on the way your game works, client/server games usually work best if the server does all the calculations and the client only draws the graphics, and sends user input to the server.

Also, you might have to be careful to take computer/connection speed into account. If my computer can send 100 messages/second and yours can send 200, am I at a disadvantage? Lag will always be a problem, but you might have to put reasonable limits in place. This is part of the server checking that all client information is accurate.

quote:

---

And this happens seperate to the game loop right? The game loop would just use the current data given by the clients.

---

Yes, that''s how it usually works. Network code is usually seperate from logic code. You can (usually) treat it as another type of input (i.e. keyboard, mouse, network).

However a lot of the details in implementation really depend on the type of game you are making.

Thanks alot for your response.

But one more thing:

quote:

---

Depending on the way your game works, client/server games usually work best if the server does all the calculations and the client only draws the graphics, and sends user input to the server.

---

Isn''t that quite alot for the server to handle? Wouldn''t you want to distribute the calculations between all servers and clients?

- Rob Loach
OverTech Technologies
__________________________
"Life moves pretty fast. If you don''t stop and look around once in awhile, you could miss it."
- Ferris Bueller

quote:

---

Isn''t that quite alot for the server to handle? Wouldn''t you want to distribute the calculations between all servers and clients?

---

Yes it can be a lot for the server to handle. Which is why you might need multiple servers, or a really fast one. On the other hand, most calculations really aren''t that complicated. Possible exceptions would be 3d calculations (line of sight, collision, etc).

The major problem with the server doing all the work usually isn''t processing power, it is bandwidth and RAM. The RAM limits how many players you can have, and how big the world can be, but can be overcome by having multiple servers. Also, remember that the server doesn''t have to render the world, play music or any of that kind of stuff, which usually takes up a lot of the CPU''s time in a game.

However, when the server has to send all the information to the client, it can be really slow and laggy. You are correct in that having the client do many of the calculations you can save resources, however it comes at the sacrifice of a loss of security. IMHO, security is much more important.

The trick is to have the server only do the calculations that are neccessary for the game to work, not for the game to be displayed.

For example, the client would tell the server "I''m moving forward". If the client can move forward, the server, internally, moves the client forward. If the client cannot move forward, the server rejects the message.

The trick is that a proper (non-cheating) client, will check if it can move before it sends the message, to save the server the need to reject it. However, the server will reject invalid requests, preventing a hacked client from cheating.

So basically what I''m saying is that yes, it is more work for the server, but inorder to properly control the game the server has to do all the real work.



Actually one thing you didn''t mention (and I didn''t ask) was whether or not you want multiplayer (say 32 players max) or massive multiplayer (100s or 1000s of players)?

The design decisions can be pretty different.

I would like to hear the different decisions for both. if you have the time to post that.

Small games (less that 100), such as Quake, Starcraft etc. are usually not dedicated servers. The person hosting the game is likely playing the game too.

Large games (100+) such as Everquest, are dedicated servers, usually made up of a number of physical machines. Also, larger games have a much better connection (T1 or better), because they need it.

Ok, you knew that, but what difference does that make to the design?

The biggest difference is that in a small game, all clients usually have all the information needed to run the game. So the information known by the client is pretty much the same as what the server knows. This means that much less data has to be sent to the client. Generally only other player input needs to be sent, so the server doesn''t do much more than route packets between clients. For some games you could just drop the client/server and go peer-to-peer, but that has other issues.

This is not the case in massive multiplayer games. In Everquest for example, the world is much too large for the client to know everything. So the client is only told about a very small part of the world, the current zone, level, etc.

Therefore the server has a lot more work to do, it has to decide what part of the world the client needs to see, and inform the client of any changes that occur within that region.

Basically in small games all clients are informed of anything that takes place in the game. Whereas in larger games, only a very limited part of the game is dealt with.

Is the above too vague? Or did you want more specific differences?

quote:

---

Actually one thing you didn''t mention (and I didn''t ask) was whether or not you want multiplayer (say 32 players max) or massive multiplayer (100s or 1000s of players)?

---

I''m designing it for a max of 16 players playing WITH the server. It is come and go as you please type gameplay (like Quake games)

Thank you guys for all this info... I''ve implemented it into the Pseudocode and here it is now. Could you just give some feedback on it?


Server Connection Request
-------------------------
- If there is less than n players then accept the connection
- Update game data with player
- Send all game data relating to player to the player


Connectivity Loop
-----------------
- Player wants to do a certain action
- Player''s client sends data to server requesting to do specified action
- Server does calculations and accepts (or denies) the action and sends confirmation
- Server sends the data of the action made by the player to all other players related (or interacting) with the player
- Client recieves confirmation and *displays* specified action.



This has it so that the server does all the calculations. Do you guys think that it''s good to go?

- Rob Loach
OverTech Technologies
__________________________
"Life moves pretty fast. If you don''t stop and look around once in awhile, you could miss it."
- Ferris Bueller

It looks good to me.
However, it''s all in the implementation.
But you have the right starting point.

Thanks again!

- Rob Loach
OverTech Technologies
__________________________
"I don''t know half of you half as well as I should like; And I like less than half of you half as well as you deserve."
- Bilbo Baggins