Prologue

...or why making multiplayer games is so hard

If you've ever made a single-player video game, you already know that regardless of the platform, genre or mechanic - developing a game is a huge undertaking. There are so many challenges to overcome including narrative, game design, graphics, sound, AI, performance and many others. Even if you get all of those right - the game might still not be fun. A well-executed game that's no fun is not even worth playing, despite all the effort put into it.

Making a multiplayer game is even harder than a single-player one. It takes all the difficulties already encountered while developing a single-player game and amplifies them by orders of magnitude.

Your major obstacle? The speed of light.

Well, not exactly, but the speed of light is THE upper bound for the fastest speed anything can physically move at, and that includes data between computers. Despite the contrary belief, the speed of data isn't instantaneous.

Let's say a game server is in Melbourne, Australia, and you, the player, is connecting from Tel Aviv, Israel. The distance between the two cities is 13,759 Kilometers, or 13,759,000 meters. The speed of light is 299,792,458 meters per second. Assume for a second that there are no computers, networks or routers in the way - and that data moves at the speed of light. An update travelling from the server in Australia to the in Israel will take 45 milliseconds to reach its destination. So if you hit a key to move your car in-game, that command gets sent to the server in Melbourne and than the result of that command is sent back to your computer in Tel Aviv. The roundtrip alone is 90ms! That is without any other delays generated by network, hardware or software.

image

What does this mean though? It means that lag, or latency, is not a "bug" or a "network condition". It is a constant, ever-present and inherent to the system. A player can never know the true current state of the game, because it always gets updates in delay. The server can't know the true state of the game, because all input from clients will arrive delayed.

Real-time multiplayer games aren't actually real-time. They only offer the illusion that everyone is playing the same game, in the same world, at the same time.

Dealing with all the issues associated from networking games is a daunting task that requires knowledge, persistence and constant vigilance.

But you're a game designer - not a network engineer and that's exactly why we built Lance. We want to free game developers to develop games, not network synchronisation code. We aim to build a thriving community around Lance and hope to see many more multiplayer games out there that truly connect people. That's what multiplayer games are all about

Opher & Gary

Next: Architecture of a Multiplayer Game