Skip to main content
gamedev.net
🔒 Locked

MMORPG Client/Server Architecture ? Such as Movement

Started by valleyman86 23 replies 24k views
Original Post
valleyman86
valleyman86
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.
stonemetal
stonemetal
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.
Sirisian
Sirisian
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.


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.

[Edited by - Sirisian on January 29, 2008 11:10:14 AM]
valleyman86
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?
Dark Rain
Dark Rain
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.
Sirisian
Sirisian
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.
valleyman86
valleyman86
So I can safely assume all the clients will generate the same path based on the information provided by the server? The server just checks to prevent things such as walking through walls or teleporting...
Sirisian
Sirisian
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.
Spodi
Spodi
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.
NetGore - Open source multiplayer RPG engine
hplus0603
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.
enum Bool { True, False, FileNotFound };
valleyman86
valleyman86
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.
asp_
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.
Antheus
Antheus
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?
Sirisian
Sirisian
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
asp_
asp_
Antheus, World of Warcraft and Vanguard: Saga of Heroes are two off the top of my head.
hplus0603
hplus0603
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]
enum Bool { True, False, FileNotFound };
valleyman86
valleyman86
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...
asp_
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.
Sirisian
Sirisian
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]

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.