Sign in to follow this  
valleyman86

MMORPG Client/Server Architecture ? Such as Movement

Recommended Posts

Ok so I have a question that is pretty much the only thing bothering me atm. I am planning and developing a simple mmo probably just mo but you get the idea. I am wondering what technology or design would I go about implementing data sync with the server from the client. Like mostly if a player clicks a location and walks there the server has to validate this but send the command to others nearby. But how do I make sure both players are seeing the same exact thing especially if there is stuff in the way and path finding is used to get around it. If a play attacks another player it really has to be sync or there could be a dispute... Like "Dude you killed me before I knew you were there". I could implement a guess and it really doesn't matter if the player is close but then I would have to let the client say things like "I attacked this player" which I don't want as to prevent cheaters... They could just randomly send that if they figured out the tech involved. Its a measure of security I guess to not let the client do any important thinking. I would rather the server get the location and command chosen and decide yea you hit that player. Server is always right... Anyways what are your ideas on this. How do games like WoW and what not do data sync I guess. Im looking for simple explanations and ideas thanks.

Share this post


Link to post
Share on other sites
well when the player clicks somewhere to move you send a message player x wants to move to xy. on the server, you check to see if this is a reasonable request(player alive in the right area etc.) generate the path the player is going to follow then send a message to all clients in the area: player x is currently at location xy and performing action move in direction st.

Share this post


Link to post
Share on other sites
This might not be 100% obvious from what the last poster said, but client only send input. What this means is that the player clicks and a command is sent to the server. On the next server update the data is crunched and sent to ALL the players including the person that sent the message. The person that sent the message should not assume they should move. Not to mention a 100 ms delay isn't something they are going to notice.

This also corrects for a player clicking the screen a bunch. The client can cull away some clicks before sending it, but even if the server gets 100 clicks to go in 100 directions it will simply just replace the current goto position for the player. In this example nearly everyone will see the same thing give or take a few ms.

Oh yeah and don't forgot to put constraints on data. For instance, only allow new position numbers that are a certain distance from the player. You can see how this would help in keeping down path finding times.

<random thought>
Oh yeah and if your game is repetitive add small random numbers to the goto positions. Stops most newbs from creating macros, while the normal players would never realize. I believe runescape did this, but I can't say for sure.</random thought>

[Edited by - Sirisian on January 29, 2008 11:10:14 AM]

Share this post


Link to post
Share on other sites
It always depends on implementation but usually it's all done server side.

In games like shooters, games that are "twitch" in nature you can allow the player to move on his own a bit and send his new current position to the server. The server then validates the new position by making sure it was possible to get there in the first place. You're not saving much CPU cycles there it's more about making very responsive.

Share this post


Link to post
Share on other sites
Quote:
Original post by valleyman86
Should the server do the path finding or should this be client side? Seems cpu heavy to have the server do it? Is there any level of predicting that may be going on?


Yes the server should do the pathfinding to verify the move. However, if you are asking if the server should send the pathfinding data to the client, then your answer is no, unless you have random numbers involved or something dealing with AI. A* is deterministic.

Share this post


Link to post
Share on other sites
yeah. You should have realized this when you did A* tests. Only thing you must make sure of is that all the players have the same start and end players. If for some unforeseen reason a player has a unit moving from point A to B and a new destination is sent for the player then you can run into problems. Quick fix is to send the starting position when a new destination is sent. If the player is displaced too much then snap the player or interpolate it to the position fast then make it go to the new position.

Share this post


Link to post
Share on other sites
I always set up my movement packets to allow the client to be able to hit the correct end destination. Most of the time this can also be used to find the correct starting position, too. For example, if I say "Player is moving to (X,Y) in direction D", in a tile-based game it is pretty easy to assume the starting position. Correction often isn't needed for the starting position if you ensure they always end on the correct position. Even if they do not start on the correct position, it will just be an often no more than a very slight visual error.

Share this post


Link to post
Share on other sites
Quote:
So I can safely assume all the clients will generate the same path based on the information provided by the server?


If the server and client have exactly the same information, and the numerical environment is exactly the same, then they will generate the same path. However, making sure that both of those are true is actually pretty hard (and impossible for the general case, because of latency and interest management).

If you run path finding on the server, then you might as well send the result of that to the clients. A few dozen bytes to describe the path (or the next 5 seconds of the path, sent every 3 seconds or whatever) is well worth it to make sure everything stays consistent.

Share this post


Link to post
Share on other sites
This was my idea... I figured if the server was already doing pathfinding then it should send the path to the client... But if the server is just checking to see if they can be at the new destination then maybe not but this would allow users to modify the client and create wall hacks as long as they never stopped inside a wall loi.

Share this post


Link to post
Share on other sites
There's plenty of MMO's (as in truly massive) where the client is authoritative when it comes to player position. Yes this enables certain types of hacks but it allows players to have a much smoother game experience with no rubber banding and reduces load on the server. The earlier MMO's tried to let the server be completely authoritative with a confirmation like suggested and it didn't work out very well.

Share this post


Link to post
Share on other sites
Quote:
Original post by asp_
There's plenty of MMO's (as in truly massive) where the client is authoritative when it comes to player position. Yes this enables certain types of hacks but it allows players to have a much smoother game experience with no rubber banding and reduces load on the server. The earlier MMO's tried to let the server be completely authoritative with a confirmation like suggested and it didn't work out very well.


Can you name an example?

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
Quote:
So I can safely assume all the clients will generate the same path based on the information provided by the server?


If the server and client have exactly the same information, and the numerical environment is exactly the same, then they will generate the same path. However, making sure that both of those are true is actually pretty hard (and impossible for the general case, because of latency and interest management).

If you run path finding on the server, then you might as well send the result of that to the clients. A few dozen bytes to describe the path (or the next 5 seconds of the path, sent every 3 seconds or whatever) is well worth it to make sure everything stays consistent.

Sending the start position of the pathfinding when sending the destination will create the same path. Sending the path is completely useless unless the path is generated by AI

Share this post


Link to post
Share on other sites
Quote:
Sending the path is completely useless


You either didn't read, or didn't understand, my post.

I explained several cases where the "client will arrive at the same result" assumption could be wrong, and couldn't possibly be right. I also explained why sending the path, or at least the next few parts of the path, would be desirable.

Perhaps I didn't go into enough detail?

[Edited by - hplus0603 on January 30, 2008 9:43:02 PM]

Share this post


Link to post
Share on other sites
Im not sure but I would guess games like WoW do not have authoritative clients. I would imagine that they have predictive techniques such as the client will go ahead and do what it needs to such as path finding before the server says anything but if the server disagrees the client will fix itself (hence rubber banding). This would allow smooth movements of normal gameplay and rubber banding would only happen when the server disagrees... This seems smart because the client isn't held up by the server connection/speed and im gonna guess that 90% of the time the client would be right... I can only see this being wrong if something was changed or if the data was different for both client and server... This was just an idea I had im not sure if WoW uses this but I imagine they don't let the client make ANY decisions... This is defiantly an interesting topic though...

Share this post


Link to post
Share on other sites
I'm not guessing at all. Unless things have radically changed lately but I doubt that. Validating movement is extremely expensive.. and with so many movements going on all the time it would be hard to it well enough. You're basically a space ship with 6 degrees of freedom as far as the server is concerned. There's also no collision detection server side. There's ray casts for visibility testing though.

You have to compromise to design a system on the scale of these games in my experience. How far you want to go depends one what these compromises enable. In my experience having the client authoritative over position isn't something that opens up for huge issues if you design with this property in mind. The client also doesn't have to be completely authoritative, it can be within reason.

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
Quote:
Sending the path is completely useless


You either didn't read, or didn't understand, my post.



For interest management are you thinking of cases other than simple moving to static location coordinates? Like moving to attack a player, or moving while a moving collideable object intersects their path or something? If so, then yeah I agree those situations can be problematic. That's one of the reasons I mentioned "If the player is displaced too much then snap the player or interpolate it to the position fast then make it go to the new position." Some things are just gonna need to be fixed with snapping if the system isn't deterministic enough.

Quote:
Original post by hplus0603Perhaps I didn't go into enough detail?
I wouldn't mind hearing of some situations you might know of. I haven't put much deep thought into the concepts. Might help the OP (or me :) )

Quote:
Original post by asp_
I'm not guessing at all. Unless things have radically changed lately but I doubt that. Validating movement is extremely expensive.. and with so many movements going on all the time it would be hard to it well enough. You're basically a space ship with 6 degrees of freedom as far as the server is concerned. There's also no collision detection server side. There's ray casts for visibility testing though.

You have to compromise to design a system on the scale of these games in my experience. How far you want to go depends one what these compromises enable. In my experience having the client authoritative over position isn't something that opens up for huge issues if you design with this property in mind. The client also doesn't have to be completely authoritative, it can be within reason.
I'm gonna have to see sources. I've played WOW a few times (like 3 times) and once during a highly congested gathering (300 something people) and their congestion kicked in. (updated players once every 30 seconds about, very noticeable), but kept my character moving constant. I'm thinking that they just did it to save bandwidth for players and that their servers ran the simulation fine with no hiccups. Yeah I'm pretty sure the servers are performing collision and everything for clients. It's not as expensive as you might think.

[Edited by - Sirisian on January 30, 2008 10:50:15 PM]

Share this post


Link to post
Share on other sites
It is unlikely that a well-provisioned server will run out of bandwidth before it runs out of CPU. It's more likely that each client runs out of bandwidth.

When it comes to CPU load, a highly optimized FPS that doesn't allow you to affect the environment (similar to Planetside) may allow you 300-500 players per server CPU. That's making some assumptions on server physics rate, collision complexity, etc. If you allow players to affect the environment, have very complex geometry, a richer movement model, a higher simulation rate, etc, then that number will go down. From what little I've played WoW (a one-month subscription that came with a copy I got), I would say that they do not run the full simulation on the servers.

When I said that client path finding may not be deterministic with the server, I have seen the following cases:

1) bugs, however small, in the code will cause it to diverge
2) differences in CPU implementation (Intel has 80 bit FP registers, AMD has 64) may cause it to diverge
3) unsynchronized data sources, such as geometry caches, random number generators, etc will cause it to diverge
4) differences in object position between client/server will cause it to diverge
4.1) such differences can be caused by dropped packets or lag
5) differences in knowledge about the map may cause it to diverge
5.1) Most MMOs do not send you information about all entities; they only send your client what they think might be "interesting" to you
5.2) starting up a new entity when it becomes "interesting" may have some latency

You _can_ build a system where the simulation is almost always consistent, despite these hazards. It is, however, really hard work, especially for a system like an MMO where entities will come and go. You'd still need occasional corrections for certain cases. It's somewhat easier for a "closed box" system like an RTS, but still not trivial. If I was alone or part of a small team, and just had to get it to work, it's much less work to do it once on the server, and let the clients know. That would save lots of money up front!

Share this post


Link to post
Share on other sites
Quote:
Original post by Sirisian
Yeah I'm pretty sure the servers are performing collision and everything for clients.


They really aren't. Both in World of Warcraft and other MMOs like Dark Age of Camelot, there's been several cases of "teleportation hacks". Basically spoofing a packet from the client telling the server "I'm at coordinates X, Y, Z now", which works perfectly (or at least it used to, they could've put in safeguards by now). Google for "wow teleport hack" and you should find plenty of sources :P.

Share this post


Link to post
Share on other sites
Yes, I've worked on a commercial MMO on my previous job and that's what they did. The client was 100% authoritative on the player position inside a zone. It took 2 years and half for a clever guy to use a program to change his system clock and go to 4x his normal speed. We then had to implement some counter measures but CPU was really tight so it only prevented the most glaring speed hacks.

Tracking down and deleting all of the user accounts and characters for the perpetrators also provided a certain deterrent of course.


I had a co worked who told me they did the same thing for Everquest inside zones and they had the exact same problem with a speed hack after a while. So I'm guessing it's a pretty common solution. Looking back to my very short EQ experience it did look like it was the case.

I remember I had that image in my mind before I worked on a mmo of high security practices, very optimized code etc. How far I was from the truth... And yes hplus is right, CPU was usually the biggest problem, bandwith never got into it.

Share this post


Link to post
Share on other sites
Getting back to the nitty gritty of this problem (rather than arguing about what games do what), the solution you implement really does depend on the scale of the project.

If you want to do a multiplayer online game that supports a dozen or so players you can get away with the server managing object states (and state dynamics) and clients accepting and propogating inputs and displaying proxies for the objects within the players field of view. This is the Object<->ObjectProxy paradigm; the server stores all game objects and each client maintains a list of proxies for objects satisfying a constraint set for the player (such as distance, visibility, etc). Within this framework you can include techniques for overcoming network limitations (latency, flutter, packet loss), such as client-side state prediction, server-side state rollback, client-client state sharing, etc. You're not restricted to using purely client-server architectures either.

If, however, you want to implement an MMO then you should stick with a pure client-server architecture with the addition of a network database (particularly if you want persistence). Your server is now a front end to the database. Its role is to maintain data and to make sure it is consistent with a basic set of game rules. Clients are responsible for the state of the avatar they are connected to (so a client makes a network connection to an avatar in a character database... you could use an Object<->ObjectProxy scenario here as well) and for maintaining a valid state w.r.t the world geometry during movement (the server would usually check states infrequently to validate what the client is doing). Interactions between avatars are adjudicated by the server when necessary, typically by a specific subsystem designed to manage such interactions (e.g., combat).


There's obviously a lot more to it than the few lines above... indeed whole books have been written on this subject... if you need some citations just holler. 8)

Cheers,

Timkin

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this