So the MWO netcode has me as frustrated as many and that led to the question: How does it work!?
I spent a few days thinking about it until I was reasonably confident I had it figured out in principle. I wrote a few posts back then that I'm too lazy to dig up. Anyway, two or three weeks ago I decided to code a simple demo which would show if any of it actually worked.
I've got the first second version done now. There is still stuff to do, but I'd like to share it.
The program simulates a networked environment consisting of one server and two clients. The "game" universe is very simple: it consists of the player (the blue square) and a target (the red circle). The circle can move and the square can fire a projectile. Shown are the view of the player's client and of the server; the target's client runs in the background. There is an actual (very simple) protocol of messages spoken between the clients and the server. Each message is delayed a controllable amount of time, 70ms by default.
Here is the slightly more technical description from the source code:
Spoiler
NB. There is talk of a laser; not implemented, yet.
#
# A little demo program to show the effects of network latency on a real-time
# multiplayer game and how to counter them.
#
# The "server" and "client" components in this demo run in fixed timesteps of
# simulated 10ms. This means the program might run at different speeds on
# different systems but produces predictable results.
#
# Network latency is simulated by scheduling every message for a set time to be
# processed. A set amount of steps plus or minus a small random jitter is added
# to this "target" time.
#
# The simulation is run deterministically, with a fixed RNG seed.
#
# There are three components in this demo:
# 1. The server runs the authoritative simulation of the game world and
# communicates state updates and events to all clients.
# 2. The player, a client moving from side to side and (automatically) trying
# to shoot a moving target.
# 3. The target, a second client that controls the target, moving in a pre-set
# pattern.
#
# The game world is a two-dimensional plane containing up to four objects with
# the following properties:
# 1. The player (blue square).
# - position, velocity, acceleration
# 2. The target (red circle).
# - position, velocity, acceleration
# 3. Possibly a projectile fired by the player.
# - position, velocity
# 4. Possibly a laser beam fired by the player.
# - firing player, current beam duration
#
# Clients can perform the following actions:
# - Set their acceleration, within limits.
# - Fire projectile.
# - Fire laser.
#
# In order for clients to show their sound and visual effects correctly, the
# following events are sent in addition to the worldstate updates:
# - Weapon fired (firing player, weapon).
# - Weapon hit (position, weapon).
#
I'll upload a video later. For now, here's a screenshot.
Spoiler
Update: Video.
You can try the program yourself. Just download and run (no malware, promise ;)).
There are three four settings that affect how the client tries to compensate for lag. I won't go into detail what they do right now, just try them out and take a guess. :)
NB: The target's client likes to get confused because it's stupid and sends the red circle off the screen. Just press "Reset" if that happens. This is more likely the more "jittery" things are.
Update 2012-12-24: Version 0.2 adds client-side interpolation, a more stable movement algo for the target, performance improvements, and some tweaks to better show how shots connect as lag compensation kicks in.
Update 2012-12-24: Version 0.2 adds client-side interpolation, a more stable movement algo for the target, performance improvements, and some tweaks to better show how shots connect as lag compensation kicks in.
1
I just learned it and, well, it is as easy as they say to throw something together.
