How the structure of a multiplayer game should look like?

Networking & Multiplayer
#1

Hello, i am creating a 2D fighting game, (3vs3) (4vs4)…

I learned KryoNet, and tested it out, i know the concept pretty well.
Now my question is how the structure of a multiplayer game like i do should look like?

I think of a structure like this -
[b]The client will send packets when he input something. (like when the client clicks W, A, S or D it will send packet depends on what the client has pressed).
The server will send the game data, (position of every player, what side the every player is looking and the input of every player).

The client will only render the game with the data the server sends.[/b]
---------------------------------------------------------------------------

Its a good idea?
And how often the server should send the game data?

P.S - Because the server sends every player’s input, the client can easily predict and interpolate every player’s actions till the server sends the next game data packet, so the game doesn’t lag.

I hope you understand what i am talking about… lol well actually what am i thinking?! i read some genius articles in this forum, you should understand it very well :wink:

#2

[quote]P.S - Because the server sends every player’s input, the client can easily predict till the server sends the next game data packet, so the game doesn’t lag.
[/quote]
What did you think of there? :smiley: if you think the game data packet might cause lag in the game what makes you think sending every player’s input to the clients would stop the game from lagging?

[quote]And how often the server should send the game data?
[/quote]
well i do it in 50 ms steps, every 50 ms it sends the game data to each client (makes 20 times per second)

[quote]The client will only render the game with the data the server sends.
[/quote]
that’s the thing which makes the client look like it’s lagging, client should interpolate the data it got from the server to get a more precise data, which might be a bit misscalculated but it will still be better than just rendering the data from the server :slight_smile:

#3

I’m talking out of my ass, but don’t some games use a form of “prediction” on the client side? For example, if a remote player is walking, and it hits a wall, the client will draw the player stopping at the wall (guess more complex approaches could use bot ai to attempt and predict remote player reaction).

What you do see quite often (it can be hilarious in, for example, BF1942) is the client predicting remote player position, but making no updates to their status/attributes (health for example), so you will clearly see, for example, a plane crash into the ground and bounce back up intact, only for the server update to reveal the remote player actually avoided crashing… Or not.

From that point of view, rather than sending the actual player input, the server should send the player’s avatar “intentions” (it is walking, it took damage, etc…).

Again, just speculating.

#4

Yes you are right, however this is for complex games that’s send a lot of data.

For instance if the player is in a moving forward state, the game tells the server right he is moving forward, do the server goes “let’s just tell the client to take it from here until he does something different”.

Obviously this is a simple example.

#5

wow 2D fighting games online huh

those need to have the fastest connection of any games by definition, since people wanna do frame perfect combos and everything

might be hard if youre not excellent in network programming and have a reliable server

#6

What did you think of there? :smiley: if you think the game data packet might cause lag in the game what makes you think sending every player’s input to the clients would stop the game from lagging?
[/quote]
Its simple, if the server will send every player’s input, the client will easily interpolate every player’s action. For example, if the client will see that one player pressing D, it will predict that this player is going to the right, and will make him walking to the right until the next game data packet.

I hope its clear. if not, ask me.

I will make it in 50 ms steps too, it looks like a good number, thanks!

You just said here exactly what i meant when i said the server will send every player’s input, because the client will easily predict and interpolate every player’s action because it will know their input, for example if one player pressed A, it will predict he is walking to the left, and the client will render him walking to the left until it gets another game data packet from the server.

I hope its clear now, if not, as i said ask me.

EDIT : Changed the text color from red to black, especially for gibbo

#7

My eyes!

#8

That’s why i do it, i want to be excellent in network programming :wink:
If you want to help, you can tell how the structure of a multiplayer game like this should look like, or perhaps look at the structure that i wrote and tell if its good.

#9

Are you ok man? you have sensitivity to red text or something? cause if you do, u should definitely tell us… you know… it affects us.

And by the way, if you really want to be nice, get over your sensitivity and perhaps comment on the multiplayer structure and tell me if its good and where can i improve it?

Thanks :wink:

EDIT - i can change the text color, if it really bothers you.

#10

In an ideal world with zero latency it might be simple, but if your game is supposed to run on the internet and is 2D as Cero remarked and you need to take multiple latency values into account and need to prevent ugly position snapping, then it is very ambigous.

#11

:cranky:

Also, I just wanted to point out there are alot of great topics exactly like this one of which to draw conclusions about your network structure. Probably a lot of great tutorials online also.

#12

I think you didn’t get my idea…

Here are the steps -

  1. The server is sending the game data packet.
  2. The client renders the world with the game data packet that the server sent, additionally, the client uses that data to predict / interpolate the game.
    For example, the client knows that Player A pressed (or still pressing) the D key, the client will render Player A walking right until the client will get another game data packet to update the current game.

Of course if the client has serious latency issues, the players will be teleporting a bit. But what can you do?

I hope you understand it now, if not. please let me know.

#13

No amount of networking magic will eliminate latency. For a signal traveling at the speed of light to get to where i am to NZ and back (say playing against my brother) takes 133ms. Actual pings are about 320-350ms.

The trick is have game play that is not sensitive to that sort of latency (see for example Eve online) or make sure people are much more local to each other. But even with the same ISP it is hard to do better than about 40-50ms because of network setup most ISPs use.

For most games that is not a problem and our primitive monkey brains adapt pretty well. But that sort of latency would make games like Marvel Super Heroes almost unplayable. At 60FPS you have 16.6ms between frames. Basically i can’t see such a game working outside a lan.

Of course you could change the networking to be higher level. ie packets say what combo you just did. Not individual movements or key presses. You could change the game play to be a little slower placed.

I would tend to use a peer to peer lock step networking model for a game like this. But with only loose lockstep. ie let slower clients fall behind the faster ones.

#14

The client predicts every player’s actions, until it gets the next game data packet from the server. so the game will look smooth even with 120ms ping, honestly i even think the game will be nice at 160ms ping either… but above that the game will start lagging.
But lets say the game will have separate server for Europe for European players, so european players will have ping mostly between 60 - 200ms ping, which means the game will be smooth for them, right?

The game won’t just pause until the client will get the next game data packet, the game will predict what the players are doing ( please read what i said in the comments ).

Thanks :wink:

#15

Just don’t see the point in putting a bright red font on a bright white background. Some peoples eyes are not perfect, trying to read shit like that ain’t helping them.

#16

Changed the text color for you :wink:
lol don’t call this shit shit.

#17

Ok so you have 2 players, A and B. Both have 200ping. Player A kicks player B, at exactly the same time player B kicks player A. Each kick is enough to kill the other player.

With 200 ping, player A see’s on his own PC himself kick and kill the enemy (player B), and does not receive the player B kick untill player B is already dead. Dead players cannot kick.

Player B see’s EXACTLY the same thing. They both think they won. How does your system deal with this?

#18

What the player actually sees it irrelevant, whoever sent the signal to kick first wins, even if the difference is in the nanoseconds. All the player sees is what the server tells him is there, regardless of the actual situation.

#19

[quote=“JESTERRRRRR,post:17,topic:48854”]
Another BF1942 example (yes, I love that game), I was dueling a friend of mine on the Desert Combat mod, both piloting modern jets. At a point I had him in my sights, fired a missile, and even though he attempted to evade, the missile hit his plane right in the middle… And nothing happened.

He then shot me down, of course.

What happened there was that, even though in my client the missile hit, in the server it missed by a few milliseconds (or manybe even nano).

So my client showed the missile explosion, but since it didn’t get confirmation that the other plane had exploded, it didn’t show it (This may be due to it being possibly more efficient to have individual clients compute the visual effects of projectiles, rather than wait for server updates).

Funny thing? This happened over a LAN. So yes, even in very small latency scenarios you will get this.

Funnier thing? My friend’s client was acting as the server, so he had a very noticeable advantage over everyone else. From that day forward, even on LAN games, we’d set up a dedicated server to host games.

As has been mentioned, the way to solve latency issues falls more on game mechanics than actual network implementation. Think how the gameplay can be modified to diminish the impact of high latency (even with good overall latency you can get lag spikes that screw things up).

For combat games I guess a technique would be to move away from one-hit-kill type scenarios, and rely on say long combos, or high health, so players have a chance to react to an incoming attack despite lag.

#20

Ok just a quick point; I was trying to get him to think about what else he will need in his system to deal with common issues like this.

[quote]All the player sees is what the server tells him is there, regardless of the actual situation.
[/quote]
When you are showing what you have done immediatly on the screen so as to hide lag for your client (unlike the original doom type setup) the player will often see what has not happened. The number of times I have shot someone on css only to find in the demo I never fired at all. The anger. Many server setups have to rewind the game state to see if the player was aiming at someone, and you end up dying even though you’re now round a corner.