How client/server architecture work?
Author
Hello everybody!
First, I am not a programmer, nor a wannabe MMORPG developer. I am a student, trying to put together a paper about the network architecture of MMORPGs. It is a very non technical paper, not about code but about design.
Basically, I need to understand what usually a server does and what a client does in a MMORPG. In other words, which tasks are handled by the client, and which ones by the server? For example, is the item database stored in the client but handled via the server, or is everything stored on the server? In other words, which systems are usually handled by the server, and does it make sense to separate the management of a particular game system from where the database used by that game system is stored? For example, are maps - needed to render the graphics of an area on the client - usually stored on a server and fed to the client when they are requested, or are they stored on a client and then rendered when the server requests them, for example like it's done with tokenized dialogues?
I do not need a complete answer, of course. Just any kind of information on the subject you can give me would help me immensely - I have been reading through some topics in here, but most of them deal with technical issues I really can't understand.
Thanks a lot, and sorry for my bad English!
To put it very simply:
There are a couple of ways to approach a MMORPG architecture that I know of - Distributed (peer to peer) networking or a centralized model, which is used in every commercial mmorpg I know.
Centralized architecture, means a single server (note: A single server is not a single machine) manages all connected clients and dictates the game state to them. The server is accountable for all databases, scripts and processing which defines the state of play, the connected clients have no authority and do not hold this information locally (thus they are referred to as dumb clients). Anything which is checked on the client - line of sight, collision - is also checked on the server and that aspect of the client state must roll back if the server comes to a different conclusion.
The centralized architecture requires that thousands of entities and vast reams of data are managed in one location, ergo, it is common that this service itself is divided among many machines in a number of tricked out configurations which aim to balance the processing load and speed up network access.
Further reading is available here
There are a couple of ways to approach a MMORPG architecture that I know of - Distributed (peer to peer) networking or a centralized model, which is used in every commercial mmorpg I know.
Centralized architecture, means a single server (note: A single server is not a single machine) manages all connected clients and dictates the game state to them. The server is accountable for all databases, scripts and processing which defines the state of play, the connected clients have no authority and do not hold this information locally (thus they are referred to as dumb clients). Anything which is checked on the client - line of sight, collision - is also checked on the server and that aspect of the client state must roll back if the server comes to a different conclusion.
The centralized architecture requires that thousands of entities and vast reams of data are managed in one location, ergo, it is common that this service itself is divided among many machines in a number of tricked out configurations which aim to balance the processing load and speed up network access.
Further reading is available here
Author
You can't imagine how much this helped me understanding things a little! Thanks! Too bad I cannot see correctly the second diagram (the one about the client).
Author
A question referring to that paper, if anybody has the time to answer it. In the server architecture, the World Component is divided in World module and World Database module. The World module is a subset of World Database, necessary to avoid consuming resources with continuous database requests; not being a true programmer, I do not understand two things:
1) Which criteria are used to choose which elements should be in the subset? I mean, since the server needs to be aware of the status of all areas in the game, it constantly needs to access all the item databases. Or does it mean that World module is a sort of index of the values inside World Database? And since the World module is not a database, how is data organized inside it?
2) According to the example in the paper, when there is a change in the game world, the Server sends a notification of the changes to the clients; clients then answer back to the server, requesting the full update only if they need it. I do not understand why this process is necessary - wouldn't it be enough to do something like a) Server needs to notify changes to the clients; b) Server checks user position in the server-side user module; c) Server sends data only to users that need it. In this way wouldn't there be just one message sent (server->client) instead than three (server->client, client->server, server->client). Or is this necessary to take into account client-side predictions?
Thanks everybody, hope this is not too tedious for experienced programmers.
1) Which criteria are used to choose which elements should be in the subset? I mean, since the server needs to be aware of the status of all areas in the game, it constantly needs to access all the item databases. Or does it mean that World module is a sort of index of the values inside World Database? And since the World module is not a database, how is data organized inside it?
2) According to the example in the paper, when there is a change in the game world, the Server sends a notification of the changes to the clients; clients then answer back to the server, requesting the full update only if they need it. I do not understand why this process is necessary - wouldn't it be enough to do something like a) Server needs to notify changes to the clients; b) Server checks user position in the server-side user module; c) Server sends data only to users that need it. In this way wouldn't there be just one message sent (server->client) instead than three (server->client, client->server, server->client). Or is this necessary to take into account client-side predictions?
Thanks everybody, hope this is not too tedious for experienced programmers.
Glad to help.
1) I haven't read the paper i'm afraid (just skimmed it to check the content), but I assume this relates to a database cache of some sort. With most MMORPG's it's a good idea to cache a good deal of the frequently accessed data, but it would be unwieldy to hold everything in memory. Anything which is constantly updated and referenced, such as items populating the immediate world, logged in character data and the items they own etc. You'd probably avoid caching things like the contents of containers, house contents and data of players who are offline. This means saving can take a long time, but general gameplay is far faster.
2)Yup, just reading your description, the system they list sounds quite pointless. Certainly the server should be aware of the players zone or field of view anyway so there is no good reason to use this mass update and request.
1) I haven't read the paper i'm afraid (just skimmed it to check the content), but I assume this relates to a database cache of some sort. With most MMORPG's it's a good idea to cache a good deal of the frequently accessed data, but it would be unwieldy to hold everything in memory. Anything which is constantly updated and referenced, such as items populating the immediate world, logged in character data and the items they own etc. You'd probably avoid caching things like the contents of containers, house contents and data of players who are offline. This means saving can take a long time, but general gameplay is far faster.
2)Yup, just reading your description, the system they list sounds quite pointless. Certainly the server should be aware of the players zone or field of view anyway so there is no good reason to use this mass update and request.
Author
Thanks a lot, it's very clear! I have some more questions, which come again from lack of experience - it is about the way player position is updated and saved in a centralized architecture.
Taking as an example an average MMORPG, with a real time battle system, how often is the player position updated on the server and on other clients? From what I have read so far:
- server side: server sends out to a client the position of surrounding actors. Frequency of updates increases as the distance between the player and these actors decreases.
- client side: while waiting for these updates, client tries to predict movement of other actors. Once the update from the server is received, client adjusts the position of the actors.
My questions are... (if this is too technical, please do not hesitate telling me)
1) This comes mostly from the database cache thing... I suppose the server stores the position of all players in memory, and only once in a while it saves this data inside a database. Constant updates of player position in the database would consume too much resources, right?
2) I can understand how a client can predict, in part, the behavior of AI controlled characters, but how can it predict the behavior of other players? I mean, trying to predict the position of other players could lead to big adjustments once the client receives actual information about another player's position; not to mention that in some cases relative positions of other players are fundamental (for example when players are fighting against each other or against the same enemy...).
Sorry again if this is a bit tedious and if most of these questions sound pointless; all the experience I have about MMORPGs comes just from a couple of days of reading.
Thanks for the help!
Taking as an example an average MMORPG, with a real time battle system, how often is the player position updated on the server and on other clients? From what I have read so far:
- server side: server sends out to a client the position of surrounding actors. Frequency of updates increases as the distance between the player and these actors decreases.
- client side: while waiting for these updates, client tries to predict movement of other actors. Once the update from the server is received, client adjusts the position of the actors.
My questions are... (if this is too technical, please do not hesitate telling me)
1) This comes mostly from the database cache thing... I suppose the server stores the position of all players in memory, and only once in a while it saves this data inside a database. Constant updates of player position in the database would consume too much resources, right?
2) I can understand how a client can predict, in part, the behavior of AI controlled characters, but how can it predict the behavior of other players? I mean, trying to predict the position of other players could lead to big adjustments once the client receives actual information about another player's position; not to mention that in some cases relative positions of other players are fundamental (for example when players are fighting against each other or against the same enemy...).
Sorry again if this is a bit tedious and if most of these questions sound pointless; all the experience I have about MMORPGs comes just from a couple of days of reading.
Thanks for the help!
Hiya, quick answers :)
1) yes. Updates can be anything from every ms to around a second, any more than that and I would guess things start feeling a little laggy.
2) The client predicts player movement based on extra information sent by the server. Google for dead reckoning. Basically, in addition to an exact position, the server will also send the velocity of the entity. This allows the client to extrude the path that entity is taking rather than stopping and starting him with each update. If the game happens to use a point and click movement system, things are even simpler, because the server only needs to send the entities destination to the client. Depending on the update speed of the game, with dead reckoning an entities position will become more inaccurate as the client waits for a new update, but in reality we are only talking about a very small distance.
1) yes. Updates can be anything from every ms to around a second, any more than that and I would guess things start feeling a little laggy.
2) The client predicts player movement based on extra information sent by the server. Google for dead reckoning. Basically, in addition to an exact position, the server will also send the velocity of the entity. This allows the client to extrude the path that entity is taking rather than stopping and starting him with each update. If the game happens to use a point and click movement system, things are even simpler, because the server only needs to send the entities destination to the client. Depending on the update speed of the game, with dead reckoning an entities position will become more inaccurate as the client waits for a new update, but in reality we are only talking about a very small distance.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
