Game Network Concept

9fab1c13d624235855435b626b9cc2a2
0
lek0 101 Oct 26, 2012 at 06:54 networking

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.

9 Replies

Please log in or register to post a reply.

6eaf0e08fe36b2c23ca096562dd7a8b7
0
__________Smile_ 101 Oct 26, 2012 at 08:50

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?

Fd80f81596aa1cf809ceb1c2077e190b
0
rouncer 103 Oct 26, 2012 at 10:21

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.

9fab1c13d624235855435b626b9cc2a2
0
lek0 101 Oct 26, 2012 at 11:27

@}:+()___ (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?

It’s realtime, using Microsoft XNA and Lidgren Network

B5262118b588a5a420230bfbef4a2cdf
0
Stainless 151 Oct 26, 2012 at 14:57

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

6eaf0e08fe36b2c23ca096562dd7a8b7
0
__________Smile_ 101 Oct 26, 2012 at 15:39

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.

B5262118b588a5a420230bfbef4a2cdf
0
Stainless 151 Oct 27, 2012 at 09:05

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.

9fab1c13d624235855435b626b9cc2a2
0
lek0 101 Oct 28, 2012 at 14:00

@}:+()___ (Smile)

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.

6eaf0e08fe36b2c23ca096562dd7a8b7
0
__________Smile_ 101 Oct 28, 2012 at 19:46

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).

9fab1c13d624235855435b626b9cc2a2
0
lek0 101 Oct 29, 2012 at 23:49

@}:+()___ (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).

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.