0
\$\begingroup\$

How do servers handle data? I understand the concept of the client sending the player pos and then the server sending back the area to display and also sending other player positions and such.

But how does a server save al the player positions? In its memory or how?

I was thinking about the client walks so it sends x: 100, y:100 to the server The server validates if the client didn't cheat like walking to fast or through a wall or something and then the server responds with the correct data, other player positions, monster positions and such. Am I miss understanding something how servers work? and how should a server handle / save all the player data? I was thinking at writing everything to the data base once every x minutes?

For the landscape rendering, I was thinking about the server sending back an array with numbers like 1 dirt 2 grass and so on. The recieving client will then display those numbers into goodlooking tiles. Is this a good way to render landscape?

I was like thinking of 2D game like Realm of the mad god.

\$\endgroup\$
  • 1
    \$\begingroup\$ Your ideas sound reasonable. Are you just looking for confirmation? We can't write your game for you. \$\endgroup\$ – Anko Sep 18 '14 at 13:48
  • \$\begingroup\$ @Anko Ofcourse I'm looking for confirmation / other examples of how it's best practised. I don't see me asking you to write a game for me. \$\endgroup\$ – Stijn Bernards Sep 18 '14 at 14:01
  • \$\begingroup\$ Realm of the Mad God doesn't use the "save every x minutes" strategy. Instead, some data (player stats, inventory, money) are saved immediately to a database any time they change (they change infrequently), and most data (monster/player locations, loot drops, maps) is only stored in memory. If the server crashes, a new world is generated, and players have to start again in the lobby. \$\endgroup\$ – amitp Oct 8 '15 at 12:36
3
\$\begingroup\$

It's more ...

  1. A connection is opened to between the server and the client.
  2. The server asks for some basic params like "who are you".
  3. Client sends "im this user".
  4. Server sends "ok you're at pos xyz, on map, foo, get ready!".
  5. player sets up anyhting it needs to in order to get a world rendered and the player in the right part of it.
  6. Server begins streaming updates as they happen to all clients connected.
  7. Clients push events as the player triggers them.

This is the "simplified version" of course. There are other things like validation taking place but from your question I guess you are referring to something like minecraft where a player at any point can click to add or remove a block.

In this situation the server makes a client call to each client to say "player x added/removed this block" then also makes an internal call to say "save this change to the world data".

that internal call may make the change immediately however it may not ... most game engines due to load / possible file locking / thrashing problems stack up commands and perform them in a batched fashion but there's no law that says this must happen.

So in short ...

The server always has the current up to date state of the current area in which all players are operating, and is able to "own them as you would expect from a server".

Clients react to event notifications as they are given.

With the predictive movement case exception.

Prediction means that I can (for example), when player hits forward key, send packet to server to say "player begins moving" then start the player moving. If the server comes back later and says "oi that's stupid there's a wall in the way, go to pos xyz and stop" then I react to that but in the meantime assuming I as a player didn't do something stupid then all is good and later the server confirms my good choice.

This is why on some games if you get a lag spike you can walk through walls temporarily.

\$\endgroup\$
  • \$\begingroup\$ I would not say you can "walk through walls". It is called rubber banding and you will never be able to walk through any walls, just rubber band back any time you try. This is favorite prank of many MMO games when lagging, it can also appear when walking near corners - you walk around corner and you are pushed back, even if your client walked valid path. \$\endgroup\$ – wondra Sep 18 '14 at 15:42
  • \$\begingroup\$ this is why i added the word "temporarily" to account for the fact that eventually the server will catch up and correct the "problem". \$\endgroup\$ – War Sep 18 '14 at 23:03
  • \$\begingroup\$ So, how to say, should we form a server requesting and responding on JSON and XML or sockets? \$\endgroup\$ – Eray Erdin Jun 7 '16 at 21:00
  • 1
    \$\begingroup\$ @ErayErdin typically for large scale or fast paced games you would need something lower level like a tcp socket where the data is "bytepacked" (compressed manually to send on the bare minimum) as typically XML or json would be too wordy for lots of smaller messages as is the case in gaming situations. \$\endgroup\$ – War Jun 8 '16 at 8:25
2
\$\begingroup\$

From what I've gathered, and believe me, I'm no expert, the "usual" way to do a client server game is to have the game running on both. The server can also be a player. The way you should look at it is, there's two types of data in the game; synced and non-synced.

All logic that affects how the game is played should be synced between the clients. This logic should only run on the server, and a visual representation should appear on the client. For example, imagine you have a server and one client. You have one player character in the game that can move. So, from this we know we have two copies of the player's data; one on the sever, one on the client. The "real" player should be kept on the server. So, we move the server copy only, and immediately sync the new position, rotation etc to the client so that it can correctly draw the player's current state. The client should only be responsible for a visual representation. Most the game logic is not actually running on the client.

Then there's non-synced data. This may include stuff like particles, or other visual effects that don't need to be synced as they have no affect on game play and may actually be very costly to sync.

You should focus on sending as little data as possible to the clients. If it's not important to the game play, there's not much reason to sync it. Using this method, it's not likely that someone will be able to cheat( unless the sever IS a player ), because all important data comes from the server.

\$\endgroup\$
  • 1
    \$\begingroup\$ It depends on the architecture of the game and the purpose of the server. In most games the purpose is purely to pass on the message however in somehting like an MMO (WoW) or FPS (call of duty) the server is more authoritive, but a game like minecraft the server need not be so important in the decision making respect because of the nature of the game. \$\endgroup\$ – War Sep 18 '14 at 13:42
1
\$\begingroup\$

As mentioned in previous comments and answers, there are 2 major scenarios and a few subscenarios... player hosted server and server hosted server being the major setups. However it makes little difference IMO because I feel that even for player hosted servers, the server portion of the code should be separated from the client code even on a player hosted configuration.

The next 2 questions concern how many players the server is designed to handle, and how authoritative the server is over the current state of the game. For small numbers of players (8-16) and a client authoritative design, the server can be little more than a message hub, taking in client packets and replicating them to the other players. For larger numbers of players, server hosts servers and some form of space partitioning on the server is needed so that you are only sending packets that are RELEVANT to each player. Server hosted is almost required at this point because beyond 8-16 players, even the best broadband connection to the net may not be enough for all the outbound network traffic being sent to the players... most network connections have much lower send speeds compared to receive.. for instance, my connection is 20mbits down, 2mbits up... so I can receive a lot more than I can send.

The last section talked about client authoritative design. In server authoritative designs for player hosted servers, the server code is typically very tightly integrated with the client code because the server needs access to the current state of everything that can move in the game, and needs to be at least somewhat aware of the physics of the game. For server hosted servers all of the object state, and at least some of the map state (that part required for setting up physics colliders and such) has to be replicated on the server.

You mentioned predictive motion, and that is a "feature" that can be layered on top of any of these scenarios, and basically involves having the clients and server running on a synchronized clock established when the player connects to the server.. movement update packets must have time stamps so that the client/server can say things like "if the object was HERE in the past, and is moving in this direction at a given speed, I compute where the object is NOW, and possibly where the object will be a short time in the future"... then the network layer kind of lies and tells the client code "the object is moving along this vector (direction/speed) from its current location" with that vector computed to put the object at the future computed location at the desired future time. None of the clients will see exactly the same motion of all the objects, but in general tracking will be smoother without annoying jumps because of network lag.

I found this presentation VERY informative and it might help make things more clear for you

http://www.gdcvault.com/play/1014345/I-Shot-You-First-Networking

\$\endgroup\$
  • \$\begingroup\$ I just noticed one thing you asked that I didn't address... and that is where the data gets stored on the server... in the case of player hosted servers with tightly integrated client/server code, your data will likely be the state information attached to each active graphical object in the scene graph. For Unintegrated player hosts and for server hosting, you will likely have data sets that look pretty much the same as the state information on the client side, but how you deal with that data will be somewhat different. In either case this information needs to be in memory somewhere :) \$\endgroup\$ – Ascendion Sep 18 '14 at 17:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.