9 replies to this topic

[lek0]

Hi,

I've recently started with my game design and I have a couple of question regarding networking. I don't need any code snippets but a concept on how to handle server <-> client.

A little more information about the game:

2D Game

Tile based maps

Multiplayer Arena based game

Characters have six spells each

All players can chat with eachother in different chats (party, global, etc)

So I just wonder is what needs to be handled on the server side of the game. If anything is unclear or if you'd like more information please add that in your comment.

[}:+()___ (Smile)]

Is your game realtime or turn based? Do you have dynamic (destructible, for example) maps or permanently stored in a game client? How much data (in bytes, approximately) are you planning to send between game client and server every second?

[rouncer]

sounds like dota, could be good.

my first networked game, i had a friend to help test it, was just this little 4 function ipx library, networking is as simple as sending bits on a wire, just what to do with the messages is the sorta variable tricky bit.

it was just players in a maze with bouncy bullets, i got it finished in about 4-5 hours, its simple.

just brainstorm ideas, remember, youve communicated bits from one computer to another and back again, and the game has to synch up. theres heaps of ways to do it.

[lek0]

}:+()___ (Smile), on 26 October 2012 - 08:50 AM, said:

Is your game realtime or turn based? Do you have dynamic (destructible, for example) maps or permanently stored in a game client? How much data (in bytes, approximately) are you planning to send between game client and server every second?

It's realtime, using Microsoft XNA and Lidgren Network

[Stainless]

Then you have two designs to look at.

Client - Server

One machine acts as a server and runs all the game logic. It creates a state vector and broadcasts that to all clients.
Modern warfare works this way, that's why the online game is sh1t. You need a very good connection to play it.

Distibuted network.

Each machine runs its own game logic. It transmits changes in the world to all other machines.


The first is the easiest to code, easy to understand and every device displays the same game state. However if you get a network drop out or lost packet, clients can hang or glitch. You can get the annoying thing you saw a lot in call of duty. You fire a whole mag into the back of someones head and nothing happens. Then the machine catches up and you realise the target had moved one yard and you fired the whole clip into the wall.

The second is harder to code, you need to be able to merge changes. In the same example as above, since on my machine the target is in the same spot as it is displayed. My bullets blow his head off. The other player may have moved and shot someone else, but when my packet arrives he dies.

The key difference in the two techniques is that the game logic and display are synced on the machine you are playing. Someone playing remotely might be seeing something different, but unless you are sat in the same room nobody will notice.

When you start plugging in destructable worlds and complex physics, the second technique can be a real pain to get right, but IMHO it's well worth the hard work

[}:+()___ (Smile)]

IMO, second technique is absolutely unacceptable: it is worse in every aspect compared with first.

In distributed system overall ping determined by worst RTT of all participants. And someone's disconnection due to faulty connection can result in global lag. In client-server model bad internet connection of one player is only his/her problem.

In distributed system every participant have its own world state and it's virtually impossible to reliable sync it. Also such system is extremely vulnerable to cheaters. In client-server model server always have correct and consistent world state.

Also, as have been said, second technique is really hard to program.

IMO, the only way to get sync between logic and display is to write good client side prediction.

[Stainless]

I agree that the second technique is much more difficult to code, I still feel that it is a fairer model than client-server.

You see this really clearly in modern warfare. The things you want to matter in a real time shooter are players reaction time, players shooting accuracy, players situational awareness, what really matters is who has the best network connection.

It depends on the game design I suppose.

[lek0]

}:+()___ (Smile), on 26 October 2012 - 03:39 PM, said:

IMO, the only way to get sync between logic and display is to write good client side prediction.

Is it possible you could further explain what you mean with a 'client side prediction'. I am extremely new in the area of network coding, so it would be good to get a gist of what you mean in form of psuedo code etc.

[}:+()___ (Smile)]

It is a technique for the realtime games with zero self lag (for example, player is firing in the exact moment he's pressing button).

In this approach the server is calculating all the game logic in a steady loop while clients send input events with attached timestamps. Important note: the server receive events ahead of time, when the server is working with the step #1000, it can receive events for #1001, #1002, etc. So when the server begins step calculation all input events for that step already received and the server don't cares about lags.

The term 'client side prediction' comes from the fact that clients must send input events ahead of the server time. If a client, for example, have RTT (ping) of 10 steps then while receiving from the server step #1000 that client must send input events for at least step #1010 to arrive in time. So, to achieve zero visible lag, that client must display step #1010 while having data only for #1000. And there client side prediction comes: given server's data for step #1000 and current player input client predicts world state for step #1010.

Prediction works good for local player (given stable RTT and low packet loss), but client haven't last input events for other players. So one of the main concerns is dealing with prediction errors (usually some sort of interpolation).

[lek0]

}:+()___ (Smile), on 28 October 2012 - 07:46 PM, said:

It is a technique for the realtime games with zero self lag (for example, player is firing in the exact moment he's pressing button).

In this approach the server is calculating all the game logic in a steady loop while clients send input events with attached timestamps. Important note: the server receive events ahead of time, when the server is working with the step #1000, it can receive events for #1001, #1002, etc. So when the server begins step calculation all input events for that step already received and the server don't cares about lags.

The term 'client side prediction' comes from the fact that clients must send input events ahead of the server time. If a client, for example, have RTT (ping) of 10 steps then while receiving from the server step #1000 that client must send input events for at least step #1010 to arrive in time. So, to achieve zero visible lag, that client must display step #1010 while having data only for #1000. And there client side prediction comes: given server's data for step #1000 and current player input client predicts world state for step #1010.

Prediction works good for local player (given stable RTT and low packet loss), but client haven't last input events for other players. So one of the main concerns is dealing with prediction errors (usually some sort of interpolation).

If I am not totally wrong this is exactly how Valve does when they code their server/clients.
So this would reduce the latency problem by smoothening it out locally from the predictions. This might take some time to code, but I will be back with some updates if I need any help or reviews.