Standards functions one would have in an mmo

Xer0botXer0

Senpai
Hi guys,

So while reading up on networking I came across the thought that there are some standard functions required in an mmo(i say mmo because perhaps there's fewer requirements inacoop game)

As an example,

If you get stuck in a wall in a singleplayer game you can open up the console and enable noclip.

1)
In an mmo you may ask a moderator to teleport you out of that position, which means you need the ability to fix issues like that real time instead of bringing the game down for debugging as to why it happened.

2)
But then there's a 'keep alive' thing, perhaps it's the same with your forum session here, if you don't say 'keep me signed in' and your cookies clear you lose your session id ?

So what if a player disconnects, the pc crashes, power goes off, he closes the game with the 'close window' button..

What sort of functionality is required in such a case to inform the server that the player has left (I mean a button that says disconnect always works) but I feel like there should be perhaps a ping sent to the server from the layer side to say they're still connected, if the server doesn't receive a ping from a player in say five minutes then disconnect them ?

3)
Profanity filter

4)
Someone mentioned this:
"- There is a delay when the server sends data to the client too. The server must send his time-stamp too. In the client you calculate the difference time between server stamp and client stamp and move the data a bit forward" what does that mean ?
- More on this:
https://docs.yoyogames.com/source/dadiospice/002_reference/networking/network_set_config.html
Is this how I timeout a socket ?

5)
Someone else mentioned this: I found it interesting that you show the enemies in the past or rather slow down time until your latency goes away ?
"And also, I think you're kind of confused regarding the "200ms in the past thing". If you try to implement such a real-time game, you will notice that it's very hard to deal with latency. A common strategy (used by Valve for CS, and most likely by any other competitive game) is for the client to display *other* players in the past, so that it can interpolate between their past positions rather than trying to guess what they'll do next. Of course, "the past" is like 200 or 100ms in the past, so the human player behind the keyboard will never notice the difference."

6)
Interesting stuff here regarding mmo size:
https://www.gamasutra.com/blogs/Dan..._about_designing_multiplayer_games_so_far.php

So I'm not the expert which is why I'm asking, what sort of functionality should I consider networking wise ?
Less obvious stuff.
 
Last edited:

TsukaYuriko

ā˜„ļø
Forum Staff
Moderator
If you get stuck in a wall in a singleplayer game you can open up the console and enable noclip.

1)
In an mmo you may ask a moderator to teleport you out of that position, which means you need the ability to fix issues like that real time instead of bringing the game down for debugging as to why it happened.
There's no need for this if you give players a skill or chat command to teleport to some sort of bind point. Ideally with a long cooldown and cast time so that it can't be abused in the middle of PvP, sieges or other activities where time and getting the hell outta there ASAP sometimes are of the essence.

2)
But then there's a 'keep alive' thing, perhaps it's the same with your forum session here, if you don't say 'keep me signed in' and your cookies clear you lose your session id ?

So what if a player disconnects, the pc crashes, power goes off, he closes the game with the 'close window' button..

What sort of functionality is required in such a case to inform the server that the player has left (I mean a button that says disconnect always works) but I feel like there should be perhaps a ping sent to the server from the layer side to say they're still connected, if the server doesn't receive a ping from a player in say five minutes then disconnect them ?
This is less about "how to inform the server that the player disconnected", which is impossible if the reason they are no longer connected is that the client can't reach the server (crash, internet drop, freeze), and more about "how does the server notice that the player disconnected".

A solution for this can be a simple timer that ticks down and gets reset when any sort of information from a player's client is received. If the timer reaches 0, disconnect the player. Due to the client-server environment, it is not necessary to keep the connection alive for the player to continue existing on the server, as they do so without the need for the player's client to be active or even open - it is only when the player performs an action when that connection needs to be active.

A logout button should of course still signal that the player logged out and immediately reflect this on the server (or with a delay to prevent abuse by logging off in the middle of PvP).

3)
Profanity filter
No. There's absolutely no need for this. It doesn't prevent people from swearing, either because they don't care about the filter or insert zero width spaces in between characters, and only causes confusion when something accidentally trips it. I'm tired of having to tell newbies that join my legion to turn off the swear filter when they get confused when other people tell them they should "invite an ******in to the group" for instance XYZ or that loot rules are "one e**h".

(Equally tired of Tsuka becoming T****, or even worse, TsukaYuriko becoming T***a****ko and people dubbing me "taco" as a result. >__>)

4)
Someone mentioned this:
"- There is a delay when the server sends data to the client too. The server must send his time-stamp too. In the client you calculate the difference time between server stamp and client stamp and move the data a bit forward" what does that mean ?
It means that there's a delay between a player doing something, the server realizing that they did that thing, and it being displayed for everyone else (and possibly the original player too), due to network latency (often referred to as "ping" by MMO players).

In a single player game, if a boss uses an AoE attack, walking out of its range is sufficient to avoid it.
In an MMO, depending on implementation, this may not be the case - for example, you may need to be outside of the AoE's range for a split second or you still take the hit.
That would be because it takes a while for the server to register that the player moved - until then, the player is still inside of the AoE's range on the server, and this is the position that's used to check whether they took the hit or not.

The opposite implementation of this is to use the player's perspective over the server's perspective (often referred to as "favor the shooter"), whether that's by factoring latency into account when performing hit checks or performing checks on the client side to a certain extent to eliminate a part of said latency.

The end result is that, in a non-zero latency environment, whatever route you take will sometimes feel unfair to either the one attacking, or the one being attacked - either because you swear you dodged an attack but the server said no or you swear that you hit the enemy but the server said no. While this isn't as big of a deal in PvE content, it tends to cause flame wars with PvP content.

Then there's the third and fourth factors - server tick rates (how often per second the server receives data and performs necessary checks) and client tick rates (how often per second the client updates and checks for key presses), the latter of which is also present in local single player games. All of this creates additional latency on top of network latency that further causes delays between players pressing a key and the effects of this action manifesting within the game.

5)
Someone else mentioned this: I found it interesting that you show the enemies in the past or rather slow down time until your latency goes away ?
"And also, I think you're kind of confused regarding the "200ms in the past thing". If you try to implement such a real-time game, you will notice that it's very hard to deal with latency. A common strategy (used by Valve for CS, and most likely by any other competitive game) is for the client to display *other* players in the past, so that it can interpolate between their past positions rather than trying to guess what they'll do next. Of course, "the past" is like 200 or 100ms in the past, so the human player behind the keyboard will never notice the difference."
You don't slow down things (especially not time, for the fourth dimension's sake), it's just a natural consequence of latency.

Imagine you sit in front of a button and have to press it as soon as someone over a voice line gives you the command to do so. This person is looking at a control LED that turns from red to green at a random point in time.

There's a delay between the LED turning green and the person telling you to press the button.
There's a delay between the person telling you to press the button and it being transmitted over the voice line.
There's a delay between you hearing the command and realizing that you have to press the button.
There's a delay between you realizing that you have to press the button and starting to move your finger.
There's a delay between you moving your finger to press the button and the button actually being pressed down.

That's the client-server communication process backwards.

Now imagine doing this for every player connected and spreading it selectively to only the players that are in close enough proximity to each other, except you don't transmit a single bit of data as in the example, but rather multiple bytes (player's X/Y/Z position, HP, MP, buffs/debuffs/status effects, skills they're casting, animation states...
Now imagine doing that a few dozen times per second.
That's enough to bring low end servers to their knees depending on the player count.
In order to make the "massive" part of MMO possible, the amount of data, or at least the frequency thereof, needs to be minimized.

This is usually done through something referred to as "dead reckoning". Given an entity's position and velocity, it is possible to estimate where this entity will be after a specified amount of time has elapsed, provided that its velocity does not change.
This means that it's possible to estimate roughly where a player is moving by only sending its position and velocity once in a while, for example every second. Should the player have changed their velocity during this time frame, their position can be adjusted accordingly.
To avoid people "teleporting" all over the place whenever such a position re-adjustment occurs, their position is usually smoothly adjusted over the next such period via tweening (interpolating values from one value to another over a specified time frame).
The end result is that you approximately see where other players are, but not exactly, and a bit later than they see it themselves.
 
Last edited:
  • Like
Reactions: Yal
Top