I help curate a website called Build New Games, which contains longform tutorials about making games for the open web with technologies like JavaScript and HTML5. One of our most popular articles is Sven Bergström’s Real Time Multiplayer in HTML5. I wrote something in the comments that I thought might be valuable to people setting out to make their first realtime online games, so I’m calling it out here. Note: none of this is going to be news to most professional game devs, but I’m putting this here because it’s an important thing for beginners to be aware of (it kind of blew my mind when I first learned it).
Yesterday someone named Chris posted the following comment:
This article was amazing for teaching the basic points of networking in games. That said, I tried out the demo and it was still nowhere near smooth. What’s the next step? There was pretty frequent jerkiness in your demo especially when changing direction after several seconds of holding down a key. What is this demo missing? If it’s so hard to make a rectangle move smoothly on a network connection, then I can’t even figure out how to make a networked pong game look smooth!
I wrote the following in response:
Believe it or not, you actually have MORE leeway when you’re not using rectangles. A lot of games compensate for lag (and hide lag) through careful game design. For example, in most MMOs, when you press the “action” button to do anything, there’s usually a windup animation of some kind: your character swings the sword back for about a second, or starts conjuring a spell, or whatever. The client is already sending a message to the server the moment you press the button: the animation gives the server 1s-2s (or even more) buffer in order to acknowledge that it happened, calculate the result, and return the result back to the client. Then, by the time your animation is done firing (and the sword actually “hits” the enemy”), the client says “Oh, the server already told me the enemy lost 5HP, so now I can tell you that at exactly the right moment to make it look like a zero lag transaction.”
The point is: a lot of the game design in multiplayer games exists solely to catch or hide lag and other edge cases. You’re never going to be able to guarantee a “real” lagless experience, so you design around it (and sometimes, for games like Halo, that involves a massive server infrastructure that you control, and really smart matchmaking that attempts to match people geographically close to each other, etc).
Compensating for lag in a way where you’re not “cheating” too much on the physics is a huge, huge, huge technical undertaking, which most games avoid by cheating like hell.
Comments on this entry are closed.