Network game design question

Started by
5 comments, last by Inferiarum 11 years, 5 months ago
I just recently started working on my next project which will be multiplayer exclusively with support for up to 8 players. It's really important that the clients are synced since avoiding projectiles and having good micro will be a key part in the game.

I got some questions regarding the networking architecture on a game like this. I'm going to use RakNet and I'm pretty sure I will use a client-server approach. I got two different methods I'm considiring

Method 1

  • The only task the server has is to inform all clients when a client does something. The server don't have any World class, it just forwards the events to the client and let them update their own World.
  • A client right clicks on the map to add a target to move to. The client then sends a package to the server containing the event id, client id and the target position. The server then only sends the package to all connected clients and let them handle it.

The bandwidth usage will be very low since packages only gets sent on user input. I do however think that the clients very easily will get out of sync, and there's nothing that will make them synced again.

Method 2

  • The server contains a World class that gets updated when clients perform actions. This World then gets broadcasted to all clients frequently (how often?) and the clients then set the objects positions so they are the same as the servers.
  • A client right clicks on the map to add a target to move to. It sends the event to the server who then updates it's World. The server does nothing more in this stage, the changes will get broadcasted to all clients in X ms.

I'm not sure how often this broadcast will happen but it will definitly be more bandwidth heavy than method 1. This method does however make sure that the clients are synced.

This is just what I came up with after 1 day of researching and I would love if you could share things I should think about and general suggestion. How would you do something like this?
Advertisement
Method 1 is easily hackable, so I would stick to method 2.

The tick rate depends on the game type, mostly they go from 20 ticks per second to 60 ticks per second. Some servers (I read LoL is this way somewhere, can't say if the font is reliable) tick as fast as they can. My network experiments (mostly RPG based) ticked 20 times per second with good results.

If you are worried about latency, take a look at "client side prediction".

Currently working on a scene editor for ORX (http://orx-project.org), using kivy (http://kivy.org).

Thanks for the great answer KnolanCross! When ticking 20 times per second, I guess you are interpolating the positon updates to make it smooth?

I did some searching for "client side prediction" and it's exactly what I will need to use. I found this article and it seems really interesting :)

Thanks for the great answer KnolanCross! When ticking 20 times per second, I guess you are interpolating the positon updates to make it smooth?



Not really, mostly you don't send coordinates, you send a message telling that someone is moving then the server spreads the message to the other clients.
So each client interpolates the movement by themselves.
From time to time the server may send a message with each player's coordinates so the client can fix the error.

Currently working on a scene editor for ORX (http://orx-project.org), using kivy (http://kivy.org).

I see. Is it correct to say that it's a combination of method 1 and 2? Something like this:

1.) A client presses a key and an event is sent to the server. The server handles the event in it's own World class and the event is then broadcasted to all other clients. The other clients handles the event as well and updates their World.
2.) At a fixed time step the server broadcasts it World to all clients. If a position of an object on a client differs from the server by a certain value that position gets set to the servers.

Is it the step 2 that you sent 20 times per second?

I see. Is it correct to say that it's a combination of method 1 and 2?


Not really, the main point here is that the server is the one who decides who is right (unlike method 1 you described in your first post). The clients' view of the world will be near the reality, but very unlikely to be 100% precise.
This is very easy to spot in some games. If you have ever played arena in World of Warcraft you probably have been hit by some enemy skill when you were behind a pilar. This happens because in your screen you are behind a pillar, but in the server (the real simulation) you are not, and the server is the one who decides who is right.


Something like this:


1.) A client presses a key and an event is sent to the server. The server handles the event in it's own World class and the event is then broadcasted to all other clients. The other clients handles the event as well and updates their World.
2.) At a fixed time step the server broadcasts it World to all clients. If a position of an object on a client differs from the server by a certain value that position gets set to the servers.

Yes, those two steps describes what should happen. It is important to notice that the client should start moving right away (even before the server has actually answered it).


Is it the step 2 that you sent 20 times per second?


Yes, just make sure this 20 times per second is configurable, you game may require more or less than that.

Currently working on a scene editor for ORX (http://orx-project.org), using kivy (http://kivy.org).


Method 1 is easily hackable, so I would stick to method 2.

The tick rate depends on the game type, mostly they go from 20 ticks per second to 60 ticks per second. Some servers (I read LoL is this way somewhere, can't say if the font is reliable) tick as fast as they can. My network experiments (mostly RPG based) ticked 20 times per second with good results.

If you are worried about latency, take a look at "client side prediction".


If you use method 1 you should run a local simulation on the server to determine the actual result of the game. (You could of course also get the results from the clients and only replay the game, based on the inputs, if there are inconsistencies) And of course determinism in the simulation is important.

In my opinion broadcasting the inputs is totally valid. Of course with this approach each client knows the whole game state at any moment, thus it is possible to do map hacks etc. . In League of Legends, for example, method 2 is used and you only get updates for players you actually see, so is is impossible to use map hacks. I heard fight games like Street Fighter sometimes use an input based network system where they also predict the game state by using the local inputs, but maybe someone else can elaborate a bit more on that subject.

Also if you have a game where dodging projectiles is important I am not sure if client side prediction is a good thing. I guess it is better to use some other mechanic (http://www.gamasutra.com/view/news/177508/The_lagfighting_techniques_behind_GGPOs_netcode.php#.UK9xFeOe9h4) to hide the delay, and show all game objects in the same point in time.

edit: Let me correct on this. Client side prediction together with interpolation for other game objects is probably a bad idea if the relative position of the player to the other objects is important. That is, you could either display everything in the past or if you want high responsiveness you predict not only the local player but the whole game state.

So in short, if it is not important to hide some information from the clients (i.e. you have no fog of war etc.) you could definitely go for method 1, which can give you very good results for a fast paced action game.

This topic is closed to new replies.

Advertisement