MMORPG and predictive movement
server with clients A,B,C
the movement of a player is 'click to destination location'
A moves to 200,300 with velocity 1
A tells this to the server, and thus tells the other clients
assuming that the server handles all object/player interactions, the server will have to internally simulate the movement of A to see if A has come close to a monster.
This means that ALL clients movements will have to be internally simulated and will thus increase server load.
is there any way get around this?
Also, what about walls.. ie, pathfinding with the server being the 'master'
Idea 1
Calculate WHEN player A would hit a monster, meaning a timer... Problem is that monsters and other clients may have moved since then and the timer will be invalidated.
any suggestions welcome.
Of course all clients have to be internally simulated by the server - how else is the server to keep track of the clients? The only other way (that I can think of) is to have the client tell the server about themselves, which just results in one sweet hack-fest.
It sounds like your problem is just that you need to cut down on the overhead of calculating a path from their current point to end-point. Just calculate the path once, then re-calculate if the path is obstructed. Many times this will result in just one calculation. Since pathfinding is often quite fast already, I don't see how this is going to be much of an issue.
It sounds like your problem is just that you need to cut down on the overhead of calculating a path from their current point to end-point. Just calculate the path once, then re-calculate if the path is obstructed. Many times this will result in just one calculation. Since pathfinding is often quite fast already, I don't see how this is going to be much of an issue.
You can do pathfinding on the client if you want and have the client send waypoints to the server, the server only has to check if the path is clear (no need to have the server calculate the shortest path).
You really shouldn't worry too much about cpu and memory usage for an MMO though, focus on making the engine scalable so you can throw additional hardware at it if needed and put your effort into conserving bandwidth as it is far more important (Mainly since bandwidth is far more expensive than hardware)
You really shouldn't worry too much about cpu and memory usage for an MMO though, focus on making the engine scalable so you can throw additional hardware at it if needed and put your effort into conserving bandwidth as it is far more important (Mainly since bandwidth is far more expensive than hardware)
Thats what I did in my last engine, I suppose I just needed confirmation for the new one.
Thanks.
Thanks.
Quote:Original post by ziplock9000
server with clients A,B,C
the movement of a player is 'click to destination location'
A moves to 200,300 with velocity 1
A tells this to the server, and thus tells the other clients
assuming that the server handles all object/player interactions, the server will have to internally simulate the movement of A to see if A has come close to a monster.
This means that ALL clients movements will have to be internally simulated and will thus increase server load.
is there any way get around this?
Also, what about walls.. ie, pathfinding with the server being the 'master'
Idea 1
Calculate WHEN player A would hit a monster, meaning a timer... Problem is that monsters and other clients may have moved since then and the timer will be invalidated.
any suggestions welcome.
Depends on details of your game mechanics/movement&map mechanism.
A project I was working on last year had a similar problem for optimization
where a movement vector was to be prechecked for collisions and it was more efficient to check longer segments (multiple turns of going the same vector) than to always do a short one step each time. (This would presupose that the object wasnt always changing vectors)
You can have the client do some move validation (assuming its kept reasonaly up to date about static terrain) to at least not have the server always have to do the validation and (after a delay) send a rejection to the client. The server still has to be the authority on the validity. Dynamic objects still have to be constantly rechecked, but you could insert a precheck (cheap) evaluation to see if the objects are anywhere near each other which would require more costly collision checking.
One different approach I've seen to reduce lag between the server and clients is for the server to be aware of each client's current time (in ms).
Then instead of saying 'This object is moving at this velocity' which introduces a slight lag.. The server instead says 'this object will arrive at this location at that time'.. That way all objects on the clients arrive at the same time.. but to archive this they might move at very slightly different velocities..
Which is best for 100's of mmorpg users? what does Everquest 2 and wow use?
Thanks.
Then instead of saying 'This object is moving at this velocity' which introduces a slight lag.. The server instead says 'this object will arrive at this location at that time'.. That way all objects on the clients arrive at the same time.. but to archive this they might move at very slightly different velocities..
Which is best for 100's of mmorpg users? what does Everquest 2 and wow use?
Thanks.
Quote:is there any way get around this?
If you want an authoritative server, you need the server to simulate.
If it's OK if different people see different things, then you can just forward states from the client, and only do basic consistency checking on the server.
Your choice.
I just thought of this so who knows how much merit it has. What I am thinking is what about having the client calculate all the pathing information and then have it send the movement to the server. So the client would determine where the player moves and the server would validate it.
So for example lets say we have 8 unique directions that the player can move. The client calculates where to move the player and begins moving him there. He then sends that movement to the server in the form of <direction><Speed>. Both of which are set to server defined values (So speed could be 1, 2, 3 for walk, run, sprint). That way the client can't just define his own movement and jump around. At the same time the client is the only one calculating path. Add in the waypoint thing then all clients could calculate the same movement based on where the player is going and time. The server would only need to send 2 peices of information to the client then. 1. The waypoint (when it changes) and 2. the current location (every time).
I have not thought through all the hacking implecations so feel free to point them out.
So for example lets say we have 8 unique directions that the player can move. The client calculates where to move the player and begins moving him there. He then sends that movement to the server in the form of <direction><Speed>. Both of which are set to server defined values (So speed could be 1, 2, 3 for walk, run, sprint). That way the client can't just define his own movement and jump around. At the same time the client is the only one calculating path. Add in the waypoint thing then all clients could calculate the same movement based on where the player is going and time. The server would only need to send 2 peices of information to the client then. 1. The waypoint (when it changes) and 2. the current location (every time).
I have not thought through all the hacking implecations so feel free to point them out.
I'm not a networking guru, certainly not with MMO programming or the "anti-hacker" side - However, I was considering something similar to what Andruil mentioned for a small personal project of mine where the client does all the work and sends the server enough information to validate if the proposed location is valid to prevent position/speed hacks through :
1.)limit the rate of movement proposed with simple prev/curr and time lapse checks to prevent speed hacks
2.)validate larger scale world location with simple volume checks to prevent ghosting through walls into other rooms or "cells" not mapped/connected to your current room/cell.
Are these kinds of approaches valid, ever used?
Security is not necessarily an issue for me at the moment, maybe for ziplock, however would like to develop with a basic level of security in mind and the ability to transfer to a more robust "hacker-proof" system later.
Sorry for leeching on your thread Ziplock, just had similar questions / ideas that may if answered help you with your own :)
[Edited by - DCM on May 29, 2008 11:53:20 AM]
1.)limit the rate of movement proposed with simple prev/curr and time lapse checks to prevent speed hacks
2.)validate larger scale world location with simple volume checks to prevent ghosting through walls into other rooms or "cells" not mapped/connected to your current room/cell.
Are these kinds of approaches valid, ever used?
Security is not necessarily an issue for me at the moment, maybe for ziplock, however would like to develop with a basic level of security in mind and the ability to transfer to a more robust "hacker-proof" system later.
Sorry for leeching on your thread Ziplock, just had similar questions / ideas that may if answered help you with your own :)
[Edited by - DCM on May 29, 2008 11:53:20 AM]
What I do at the moment uses an authoritative server, with the client being optimistic (which I think all large MMORPG's USE)
* Out of the several type of client movement I have 'Click on map location to move there), rather than 'press W for forward'
* The server is event driven, not an internal heartbeat/tick
EXAMPLE 1
CLIENT A - Player Clicks on map at 200,500
CLIENT A - client does internal pathfinding/validation
CLIENT A - Path is valid, sends message to server ME_MOVE,200,500
CLIENT A - Start animating character to 200,500
CLIENT A - *game loop*
SERVER - Receives ME_MOVE,200,500 from client A
SERVER - server does pathfinding, and finds that it is ok
SERVER - server tells all other clients in the same 'bubble' as A, to move character A to 200,500
SERVER - internally animates client A (COMMMENT 1 BELOW)
SERVER - *server loop*
CLIENT A - animation gets to 200,500 and stopps
CLIENT A - client sends server ME_STOPPED,200,500 (COMMENT 2 BELOW)
CLIENT A - *game loop*
SERVER - Receives ME_STOPPED,200,500 from client A
SERVER - server stops internal animation of client A
SERVER - server tells all other clients in the same 'bubble' as A, that character A has stopped at 200,500
SERVER - *server loop*
COMMENT 1
---------
Although the server sets up an internal animation of a character, it does not update this information on each tick or at a regular interval. Rather, based on time since the start of the animation, it calculates the current expected position. This means the position calculations are done JIT and when needed (distance=speed/time)
COMMENT 2
---------
You may think this is redundant, since the server has already been told the end point in ME_MOVE.. so why send it again with ME_STOPPED?. Originally I did have that to stop hacking and reduce packet size. I had to include it because of network lag. If I introduce client/server time sync and timestamp actions this may not be needed.
* Out of the several type of client movement I have 'Click on map location to move there), rather than 'press W for forward'
* The server is event driven, not an internal heartbeat/tick
EXAMPLE 1
CLIENT A - Player Clicks on map at 200,500
CLIENT A - client does internal pathfinding/validation
CLIENT A - Path is valid, sends message to server ME_MOVE,200,500
CLIENT A - Start animating character to 200,500
CLIENT A - *game loop*
SERVER - Receives ME_MOVE,200,500 from client A
SERVER - server does pathfinding, and finds that it is ok
SERVER - server tells all other clients in the same 'bubble' as A, to move character A to 200,500
SERVER - internally animates client A (COMMMENT 1 BELOW)
SERVER - *server loop*
CLIENT A - animation gets to 200,500 and stopps
CLIENT A - client sends server ME_STOPPED,200,500 (COMMENT 2 BELOW)
CLIENT A - *game loop*
SERVER - Receives ME_STOPPED,200,500 from client A
SERVER - server stops internal animation of client A
SERVER - server tells all other clients in the same 'bubble' as A, that character A has stopped at 200,500
SERVER - *server loop*
COMMENT 1
---------
Although the server sets up an internal animation of a character, it does not update this information on each tick or at a regular interval. Rather, based on time since the start of the animation, it calculates the current expected position. This means the position calculations are done JIT and when needed (distance=speed/time)
COMMENT 2
---------
You may think this is redundant, since the server has already been told the end point in ME_MOVE.. so why send it again with ME_STOPPED?. Originally I did have that to stop hacking and reduce packet size. I had to include it because of network lag. If I introduce client/server time sync and timestamp actions this may not be needed.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement