questions about MORPG

[rogerborg]

For a typical ORPG, you'd more likely send state changes. So instead of sending "monster A at X,Y,Z" ... "monster A at X+dx,Y,Z"... send "monster A at position X, Y, Z is moving to attack player B". Then your clients can perform dead reckoning to guesstimate where the monster should be and update its local position in their copy of the world state.

Just be sure that its position is sent every few seconds in order to keep it reasonably synchronised. By that, I mean have each monster remember the last time a packet was sent to nearby players, and if goes too long without sending one, then send out a state packet for it containing its position and other vital information, even if it's not actually changing state.

[B@z]

ohh.. sorry, but i don't get it

so, i'll when the monster see the target, that it's going to attack.
then, the client moves it. (and the server too, but isn't sending the info)

and it's sending the monster's position in every few seconds, to synchronise it?

[rogerborg]

Yes, that's it, exactly.

For a multiplayer FPS, it's important to keep the game states on the server and all clients tightly synchronised, which means sending very frequent updates.

For an ORPG, it's generally not so important, as long as players can select sensible targets for their actions.

[B@z]

it makes sense!
thank you, i'll try it

[B@z]

hi
i could do that!
the monsters movement are good, but what should i do about players?
i don't know when will they suddenly turn, or stop or anything...

i can't do dead reckoning i think, but i don't want to send position at every frame...
what should i do about it?
i tried to send infos a little lesser, but it doesn't smooth enough (at it will be worse if there will be a lag.)

how can i make it smooth?

[rogerborg]

You're letting players do their movement locally? Well, OK, that's a perfectly valid way of doing it, and gives a good responsive experience. However, it has a couple of drawbacks:

1) It allows speed/teleport hacks. If you don't care about that, fair enough, but be aware of the issue.

2) It results in mobiles sharing the same physical space. Even if you stop the local player from moving on top of another mobile, how do you stop the mobile from moving on top of them?

You'll never have a completely synchronised world across all clients, so how often to send state information and what to do with it is a compromise depends on three related things:

1) How much bandwidth you want to use.
2) How far you're prepared to allow the state on each client to get out of sync.
3) Whether you want the appearance of other players on each player's client to be accurate (but jittery) or smooth (but out of sync).

A typical FPS would go for: lots / as little as possible / accurate at the expense of smoothness. So client A would send updates very frequently, the server would distribute them immediately, and the receiving clients would immediately change player A's local state.

An ORP can be different.

You could, for example, send an update every (e.g.) 0.25 or even 0.5 seconds, and only if player A's state has changed. The server would update its local state immediately, but would make an independent decision about distributing state change for each player (in case a rogue client is sending updates too frequently).

Then it would send goals, just as it would for a NPC, i.e. instead of sending "PlayerA has moved to X,Y,Z", send "PlayerA is moving to X,Y,Z", as it would with a monster, then let the clients perform a smooth local animation to reach that state. This will introduce a good deal of lag and inconsistency, but will use much less bandwidth, and may actually look better because of the local interpolation on each client.

[B@z]

thank you for your reply.

can i do in other way? i think if i let the server move the player, it would be a huge transmission, it isn't too good i think.

and yeah, speed hack... well, if somebody does that, i'll bann him xD
and maybe i can write some security thingy for that (like checking the time and the positions or something)
it isn't problem i think

i don't get that mobiles part.

i see!
so i move the players like the monsters, but with different time.
but for that, i think i should send the current position sometimes, right?
if there is a bug or something, so the client thinks that the player B is on -500,-500,-500, and coming to 100 200 300, then it would be a little problem xD

thank you, i'll try it!

edit: ohh, and it doesn't matter if not synchronised well. only when PVP... maybe i should send more freqently, when there is a fight between players?

[ultramedia]

ouch, I'm starting to not regret my moving away from mmorpg as much, all this is making my head spin... (and I'm a PHP MySQL dev).

Having said that, awesome work B@z, and awesome advice and experience rogerborg...

[B@z]

yeah, programming orpg is really hard xD but fun

and, yeah, thank you rogerborg for helping me that much!

[Dark_Kilauea]

Here's an idea...

Send state changes from the player, do the movement on the server. There is no chance for speed hacks (which fits with rule #1, never trust the client). However, you will still need to transmit the new positions to everyone from the server often enough to make things look smooth. Between the transmittions, interpolate between the old and new positions to achieve smooth movement.

For instance, your player wants to walk forward. Send a walk forward event to the server once at the start of the player pushing the button. Now the server will send the new position data for the players that the specific client can see every so often. Once the player lets off the button, send a "stop movement" event to the server.

For a FPS, this wouldn't work very well, but for a MORPG, it should be fine

[B@z]

yeah, but what about lagging?
lags, and the client "forget" to send the "stop" command?
and it wont stop.... xD

and there will be a delay between pressing forward and moving, won't it?

[rogerborg]

and yeah, speed hack... well, if somebody does that, i'll bann him xD

You may find that once you start down that path that it becomes pretty much all that you do. Do you really want to ban enthusiastic or paying customers because they used a mechanism - possibly just out of curiosity - that you chose to provide?

Reactive security is rarely a good idea. Speed/teleport hacks are actually the least of your problems. If you carry that attitude over into issues like item cloning or XP hacking, then sooner or later you're going to wake up and find that a sizable minority of your playerbase have reached this level overnight:



Then what do you do? Ban them all, because you couldn't be bothered to lock the door?

[lecture]
My attitude to multiplayer is that "hack" and "exploit" are unhelpful terms. Better to call them "unanticipated actions". The game is really the server and the network protocol, not the official client.

Try to let go of the client. Consider it exploited and hostile from day 1, and design your server on that basis. Blizzard can force their customer base to install spyware; you can not, and nor can you afford to get on the eternal catchup treadmill that that decision entails. Netrek has been trying to secure their client for 18 years or so with cryptographic authentication; it took me four hours to bypass that with a man-in-the-middle attack, including subverting a system DLL. That's not a boast, just an example of why Security Theatre is a waste of valuable time and resources.

Anything that the server lets players do is part of the game whether you intended it to be or not, and if the game isn't playing the way that you intended, then it's entirely your responsibility to change the server. You may even consider thanking your "hackers" for helping you to make the game more robust for everyone by exposing security flaws.
[/lecture]

and maybe i can write some security thingy for that (like checking the time and the positions or something)
it isn't problem i think

You may want to ask Blizzard if they think it's a problem.

It's a perfectly valid solution, but you'll always be playing catch-up with hacked clients, and you'll have to make very nuanced judgments about where to draw the line. Too lax, and you might as well not bother. Too harsh, and you'll be accusing innocent players of cheating, which is unlikely to generate much goodwill.

so i move the players like the monsters, but with different time. but for that, i think i should send the current position sometimes, right?

Sure. Actually, I'd imagine that the messages would be "PlayerA at position X1,Y1,Z1 is [moving to X2,Y2,Z2 | moving to attack objectB]"

edit: ohh, and it doesn't matter if not synchronised well. only when PVP... maybe i should send more freqently, when there is a fight between players?

That sounds sensible.

yeah, but what about lagging?

You'll always have lag; what you'll need is a realistic strategy to deal with it.

lags, and the client "forget" to send the "stop" command? and it wont stop.... xD

If the client doesn't send the stop command, then that's a bug. If it sends it and it doesn't get through (I assume that you're using reliable messaging?) then that indicates a catastrophic network failure; the client connection is toast anyway.

and there will be a delay between pressing forward and moving, won't it?

Yes, and that's the big problem with a request method, especially if you are using a key-driven movement system or repeated click-to-hit (like Diablo) rather than a click-to-move or click-to-start killing system.

What I'd suggest is:

1) Have the client perform movement of the local player immediately.

2) Send the new player position/direction to the server occasionally.

3) Have the server validate that such a move should be possible based on its definitive record of the player's state. This isn't just a defence against hacking; the player may have been hit with a crip that limits their movement, without their client being aware of it yet. Get your validation code in early, and make it as robust as possible.

4a) If the move appears valid, send the new data (either as a "has moved to" or "is moving to") to all clients except the acting client (because it can assume that the movement is valid until told otherwise).

4b) If the move appears invalid, then don't break out the banstick just yet. Instead, have the server correct it to a possible position, then send that position out to all the clients, including the client for that player. If you really must, then you can start logging it as a potential ZOMG HAXXX at that point, but honestly, why bother? Even if it was, you've already fixed it. No harm, no foul.

5) On player's client, when it receives a position update for its own player, have it examine the corrected position. If it's very far from its own position, take the hit and jump straight to there. If it's very close, simply ignore the difference. If it's a "moderate" way off (with a meaning dependent on your app) then start interpolating the player's position towards it in order to correct it in as non-intrusive a way as possible.


If that sounds complicated, well, you've got a complicated problem, with no perfect solution. It will be easier if you set out your requirements clearly, decide how robust your solution needs to be, and then get it right the first time.

[B@z]

thank you for the lecture
you're totally right. i'm sorry.

the inventory and xp and others are fully contolled by the server, so i think it would be hard to hack it. maybe xD

yeah i'm using key-driven movement system... the click-to-move thing would be good to me, but not the other teammates xD

i don't get that validate part. where can't the player go?
the server can't do collision... so what's the invalid path?

and what about that?
when the player press the forward key, the client sends it to the server, and the server computes the pos. (with current pos, and current rot + speed).
so i don't have to send the next pos from the client.
the server calculates not the next point but a little far point (for example, the next step would be 0,5 far from the current, but the server sends 2), and send that to every clients (except the moving client.)
but the local player is move immediatly, when the UP key has been pressed.
and when it's rotating, or stop or something, it sends to the server, and the server changes the calculations.

[B@z]

hi

i have questions again xD

when i started this project, i was told to use arras' tiled terrain for maps.
but i don't know it know..

for my project, i need medium terrains (i mean, not too big, not too small.. xD)
but i wanna make it various.

so, grasses, sands, rotten apples, everything.

i cant imagine a game with just grass everywhere...

so what should i use? how should i do that?
for an rpg, what terrain type should i use?
terrain? tiled terrain? 3d model?

i'm really stuck here.
pls help