Jump to content
  • Advertisement
Sign in to follow this  
tuffing

Multiplayer network design

This topic is 1014 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

 

I'm currently working on a school assignment where we've been given a local multiplayer game that we are to make into an online multiplayer game.

The game is very basic, it's top-down where every player controls a circle that can be rotated with left and right arrows, move forward with up and brake with down. (Similar controls for other players, WASD e.t.c.).

 

There are two players in two teams whose goal is to knock the ball into the opposite side of the screen. I've attached a screenshot so it might make things more clear.

 

The solution must be client/server-based.

 

Now, my issue is that I can't seem to come up with a good design and am in need of some inspiration. So my question is, how would you design it?

 

EDIT **

SORRY, REALIZED THIS THREAD MAY HAVE ENDED UP IN THE WRONG SECTION. 

Edited by tuffing

Share this post


Link to post
Share on other sites
Advertisement

You might want to give more details, and as more specific questions.

 

Details:

- Do you have more about the existing game than just a screenshot and a vague description? Language it was written in? Framework or Engine used?

- Do you have more constraints that come with your assignment? Are you allowed to use an Engine, or Middleware? Do you have to code everything from scratch? Are you completly free to port the game over into a different Framework/Engine/Language, or is the currently existing part fixed?

- Do you have any UML diagram of existing classes, or directory listings of existing files?

 

 

I would encourage you to at least do your own research first, or try out to implement your own ideas before asking questions in a forum.

I am sure people are happy to help you with specific problems when your try to implement your solution, or give you hints about good books or tutorials about the topic.

Think about what exactly is the problem you are having, and ask more specific question. It will make it easier for people to answer (and give them the warn and fuzzy feeling that you actually DID try to solve your assignment yourself), and it makes sure you get to the point answers instead of having to wade through a thread full of irrelevant answers.

Share this post


Link to post
Share on other sites

I would use a snapshot system.

1: Clients connect to the server game and get a player number.
2: Each frame the clients send it's input commands to server. Server use the player number for the client to update the correct circle on the server.
3: Server packs information about the game (player position/rotation, ball position, team scores) and send to the clients.
4: Clients use the information to update it's game world.

Share this post


Link to post
Share on other sites

I would use a snapshot system.

1: Clients connect to the server game and get a player number.
2: Each frame the clients send it's input commands to server. Server use the player number for the client to update the correct circle on the server.
3: Server packs information about the game (player position/rotation, ball position, team scores) and send to the clients.
4: Clients use the information to update it's game world.

 

Thanks, my ideas so far have been based on dead reckoning-ish implementations and didn't consider snapshots due to the bandwidth usage. However I did some calculations and found that if the server were to send 60 updates a second with a full world snapshot it would be about 33.6 kb/s or 268.8 kbit/s with 4 connected players, is that reasonable? I can't really find any statistics on what network games usually output. I know that number can be decreased using deltasnapshots e.t.c. so it can probably be reduced a bit.

Share this post


Link to post
Share on other sites

Quake 3 was up to 40kbps (Enemy Territory Traffic Analysis) but i do not think you need to worry about it yet. When you have a working version you can focus on lowering the amount of updates you send and try to send as little as possible in each one.

 

Edited by Spinningcubes

Share this post


Link to post
Share on other sites

Like Spinningcubes suggested, I'm using a variant of the snapshot implementation. I've managed to get the clients synched with the server upon start now. That is when one client connects or drops the game resets. The server sends out the reset message which makes the clients clear the score and remove all entities.

 

Next the server rearranges the teams by using the connections that are left and distributes the player over the two teams. Now I am able send snapshots, I haven't settled yet on how to interpolate/extrapolate between the snapshots yet I figure I'll look at that once I get there.

 

I'm more interested in solving the input from the clients at the moment. I've been reading about the snapshot design but still don't really have a good idea about how to do this. The controls are just the arrow keys on the keyboard so I could fit them in half a byte. In general, for snapshot implementations on the client, does the input have to be reliable?

 

I mean, if the input is reliable I feel like TCP won't do the trick because I don't want to wait for a confirmation for each input sent before sending the next input, I'll have to implement some sort of reliable message passing over UDP? Also, I'd have to need to use some sort of rewind/replay algorithm so fight the lag, no?

 

Or are there better ways to implement the client input being sent to server? I was reading the Valve/Counter-Strike implementation and looks indeed like the server uses rewind/playback but they don't talk very much about client input, nor does Gafferongames. :/

 

Thanks for any help/suggestions.

Edited by tuffing

Share this post


Link to post
Share on other sites

for a simple game like this, snapshots should be fine, but normally to send as little as possible you'd just send each objects' movement vectors each time they change and let the client figure out where each object should be at the current frame using that information. Each movement vector would be either 64 (two floats) or 128 (two doubles) bits large, so with the assumption that movement vectors are unlikely to change each and every frame, you can significantly cut down bandwidth use.
 

for client inputs, rather than send each individual input, I'd just send an updated movement vector and any other action they might be able to perform, only as necessary.
With this model, make sure you use select() before attempting to recv in the client to prevent unnecessary blocking.

I mean, if the input is reliable I feel like TCP won't do the trick because I don't want to wait for a confirmation for each input sent before sending the next input

This is because of Nagle's algorithm on the sending side and delayed ACKing on the server side. Disabling Nagling is not the best practice, but if you find it necessary, you can disable it by setting TCP_NODELAY option on your clients' sockets.
If you are running the server on Linux, you should instead set TCP_QUICKACK on the server's socket for the client before each read. This prevents delayed ACKing, which is responsible for a majority of the delay experienced with TCP connections.

Also, make sure your client sockets are non-blocking, unless you're calling recv on its own thread.

Share this post


Link to post
Share on other sites


for client inputs, rather than send each individual input, I'd just send an updated movement vector and any other action they might be able to perform, only as necessary.
With this model, make sure you use select() before attempting to recv in the client to prevent unnecessary blocking.

 

Still it would depend on the fact they they're guaranteed to arrive for a reasonable client prediction, no?

 

Also; at the moment I don't synchronize the clocks or pass tick# with every snapshot sent. For the client input to register properly I'm guessing I'm going to have to considerboth clock skew and drift as well as making sure client and server are on the same tick using the turnaround time?

Share this post


Link to post
Share on other sites

 

Still it would depend on the fact they they're guaranteed to arrive for a reasonable client prediction, no?

Yes, you would need a guarantee that these update packets will arrive (you also need a guarantee that other clients will see them). This requires either TCP, or for the use of a reliability framework over UDP (which is basically just implementing TCP over UDP, minus nagling and delayed ACKing).
 

 


Also; at the moment I don't synchronize the clocks or pass tick# with every snapshot sent. For the client input to register properly I'm guessing I'm going to have to considerboth clock skew and drift as well as making sure client and server are on the same tick using the turnaround time?

If all connections are guaranteed to be on the same local network (IE connected to the same router), roundtrip time should be less than 1ms, so you could just include the current position when sending movement updates from the server to cover up any cumulative errors and be fine. I only recommend this because you mentioned this is a school project and will probably only be tested over LAN. It's good to know when you can cut corners.
If you ever plan to release this game to the world at large, I definitely recommend syncing to the server's time.

Edited by nfries88

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!