Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

117 Neutral

About tuffing

  • Rank
  1. Hey,   I'm currently working on a school assignment which is in short explained in a thread I started here: http://www.gamedev.net/topic/676440-multiplayer-network-design/   But to recap, it's a simple top-down game. Four players each control a "ship" and they're divided into two teams and each one spawns in a separate corner. There is a ball as well which both teams should try to push into the screen edge of the opposing team spawn thus scoring. It's "physics based" meaning collisions causes bounces and accelerations e.t.c. - Very simple game.   However, the school assignment is to convert this four player local game into an online multiplayer game. So I have the game, physics already written and it's working locally but I need to implement online multiplayer. It's written in java, no network libraries e.t.c. are allowed. Main parts of the assignment is to:   1. Fight lag 2. Fight cheating   So far I have a server which sends a full world snapshot at a given rate. Since the world is very small and I am under a bit of time constriction I'm not going to bother with delta-snapshots but instead just keep sending the whole world.   The clients at the moment send their input every frame, that is, which buttons they're pressing at the given frame. I know this isn't optimal but I need to get things going before I start to optimize. The server reacts to the input once it receives it which in whole just gives clients a delayed input but everything is perfectly synched.   However, now that I've got that working I'm trying to implement client prediction but it's not working very well at all. The client side prediction at the moment is as follows:   1. Client stores input for each frame and sends the input along with the frame number. 2. When client receives a world update from server, it sets the clients m_frame variable to what the update says (provided that it's the most recent update, otherwise client ignores it.)   Client then checks the turnaround time to the server and updates local world (latency / time_per_frame) times and also increments the m_frame variable for each update. For every update, the client also checks the input buffer mentioned in step 1 and replays the input for each frame being predicted.   3. At this point I'm thinking that the client should be processing ahead in time. So if the client now sends, let's say input for frame 1000 and the server is currently at 960 the input should arrive in time for the server to process frame 1000.   Now my problem is that the local players is jittering, a whole lot. When I'm testing I'm running it all locally but with a simulated latency. So packet loss shouldn't be an issue at this point. Maybe this is wrong, but if there is only a single player connected, there should be no visible artifacts at all, no matter how much latency? Since the server is only playing back the input given by the player on a deterministic game.   Any suggestions on how to proceed from here?
  2. tuffing

    Multiplayer network design

      Okay, but let's say on the client side, I'd accumulate user inputs in a buffer for each frame. Then the client sends the entire buffer x times per second and every time an acknowledgement is received from the server the client clears the buffer up to the last confirmed input. What do you think about that?   Do the other clients really need to see them? I'm thinking the server just updates logic by using the received input and sends from time to time the position, direction and velocity of each player and the ball. I don't feel like snapshots from server to client should need to be reliable in that sense?         Main part of the assignment is to fight lag, even if we run it over LAN I bet they'll be using some latency/packet loss software (like Clumsy) to test it.
  3. tuffing

    Multiplayer network design

      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?
  4. tuffing

    Multiplayer network design

    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.
  5. tuffing

    Multiplayer network design

      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.
  6. 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. 
  • 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!