PlayerIO

The fastest way to build online games without breaking a sweat.

Building Flash Multiplayer Games

This tutorial is also available in a pure flash version..

Table of contents
1 - Introduction 8 - Synchronization
2 - Game Basics 9 - Interpolation
3 - Turn Based Games 10 - Latency
4 - Network Architectures 11 - Tips & Tricks
5 - Security 12 - Game: Turn Based
6 - Example Game 13 - Game: Realtime uninterpolated
7 - Real Time Games 14 - Game: Realtime interpolated

Real-time Games

Real-time games

A combination of wits and reflexes, speed and smarts. With a real time game, you can offer challenges much more intense then in it's turn-based counterparts. The simple addition of a time-based factor makes any game more pressing and can garner you quite a few fans.

If it's done right.

Real-time networked systems are inherently problematic and not for the weak of heart. You will spend good lengths of time just trying to get simplistic things to work the way they are supposed to.

You may very well be surprised how much the simple addition of a time-based system can wreck havoc with what we are trying to create.

From here on out, you will see very little code. We will instead be focusing on the theory behind how to make real-time games. Again, it is hard to overstate how difficult and complex a real-time game can be. Simply making a character move around properly using proper lag-defeating techniques may take you days to properly understand and implement.

For this entire section, we will be using the server-client type setup as well. If you thought that a client-based peer-to-peer type setup was bad news when making turn based games, it gets even worse when you transition to real-time.

Every single problem that is inherent in a real-time system (we will be discussing these shortly) is multiplied in magnitude when you don't have one central entity controlling everything and making something of what often turns into a contradictory, disgusting mess. Although, it is still quite possible.

You will want to learn C#, if you haven't already.

The fact that you're still reading this despite the warnings I have given might just mean you have what it takes to make a real-time game; Guts, determination and a desire to learn. The next few chapters will tickle your brain in new and innovative ways and introduce you to advanced concepts.

With the right game design and proper implementation, you can sweep all the problems that plague this type of game under the metaphorical carpet and come out with a solid game.

Before we can do any of that, however, we must see what we are up against..

Chapter 08

The Fundamental Problem of Latency

Let us begin with an example. We have two players playing a top-down first person shooter.

Player 2 is waiting around the corner to try and ambush player 1. Let's take a look at what would happen if player 1 began to move forward.

First, however, we must make an important distinction.

It is possible for player 1 and player 2 to see different things on their screens due to the transfer time between computers on a network. This transfer time is called latency and it is your biggest nightmare when making a real-time game

Here, we see Player 1 press up and begin to move forward on his screen, as shown by the moving blue circle.

Player 1 also sends a message to player 2, to inform player 2 that he has begun to move upwards, as shown on the right by the network diagram.

Recall that a message sent across the network does not reach the other player immediately. This is latency. As we can see in the network diagram, player 2 still has not received the information that player 1 is moving. Thus, on player 2's screen, player 1 remains where he is. At this point in time, THERE IS NO WAY FOR PLAYER 2 TO KNOW THAT PLAYER 1 IS MOVING.

Once player 2 receives the network message, he will see player 1 begin to move. On Player 2's screen however, player 1 will not be at his true position.  Player 1 will be lagging behind his true position by the amount of time it took the message to arrive (for the average flash game, this can easily be between 50ms and 500ms [milliseconds]

At this point, player 2 sees player 1 and wishes to shoot him. This even further compounds the problem, as we shall see.

Here we see player 2 shoot, then send a message that informs player 1 of this event. Throughout this, player 1 is still moving.

Note two things:

- Player 2's screen showed a hit
- Player 1 does not even know that player 2 has shot yet.

Here we see player 1 receive the network message that player 2 has shot.

Player 1 will see player 2 miss considerably.

The real question here is: did player 2 actually hit player 1?

Did Player 2 hit player 1?

Here are your options:

Welcome to the wonderful world of latency.

In the next few chapters we will take a look at possible solutions for this problem.

Table of contents
1 - Introduction 8 - Synchronization
2 - Game Basics 9 - Interpolation
3 - Turn Based Games 10 - Latency
4 - Network Architectures 11 - Tips & Tricks
5 - Security 12 - Game: Turn Based
6 - Example Game 13 - Game: Realtime uninterpolated
7 - Real Time Games 14 - Game: Realtime interpolated


About the author

Ryan Brady is a Canadian developer who is currently going to the university of Waterloo. When he isn't fooling around with friends or dealing with an ungodly amount of course work, he likes to design and build games.

Two of the things Ryan likes most above all else are sarcasm and irony. Thus, he likes other people when they have a sense of humor and don't take offence at playful stabs and teasing. Otherwise, people tend to think Ryan hates them and/or the entire universe.

Subscribing to the "Work hard, Play hard" mindset, Ryan is always on the move. There are not enough hours in the day to do everything he wants to do (which is quite a bit). As a habit, Ryan designs more things then he has time to make. Alphas and proofs of concepts are his bread and butter though he always wishes he could make them into full games.

Every so often, you will see Ryan with a full beard on his chin. This commonly refereed to as Schrodinger's beard as you never know if Ryan will have it when you see him next. He re-grows it in under a week.

Every 4 months, Ryan has a co-op term so he moves around quite a bit. He might be living in Canada one month then be living in San Fran the next. You will never know when Ryan will be at large in your area next (until it is too late).