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

Security in multiplayer games

Security

We have touched on security a few times already but there is still much more depth that is left to be explored.

The importance of security in games is often understated and it is often over-looked compared to a developer's other priorities such as game polish or adding features. But even a single bad event can destroy a game's credibility for the player. How robust and impenetrable a game appears is more important then one might think. Would you buy micro-transaction items for a game that has hackers running around everywhere? It instantly de-values those items in the eyes of the users!

Thus, we must lock-down our game and ensure that hackers cannot get in and make a complete farce of our hard work, driving our players away in process.

The first step you should take to ensure that a player doesn't encounter any "hacker" scenarios is, ironically, actually not related to security at all.

More often then not, reports of hacking are greatly exaggerated because they are not actually hack attempts at all! Rather, it's often just a case of someone misinterpreting what they see as hacking.

This normally occurs when the player does not understand the game properly and thinks the other player is cheating when he in fact is making a legal move. This can be combated simply by clearly showing the player how to play and on every action that would not immediately be clear, informing the player of what just happened.

In this particular game of checkers, one person has gotten a double jump. Make sure their opponent knows that and doesn't suspect them of taking two turns instead!

Keeping the player informed will instantly "protect" you from these "hackers".

Real security is important too... what do you have to look out for?

Flash is vulnerable to somebody trying to get in. It takes all of five minutes for someone to rip your flash game off the web and decompile it to see what's inside. So, unless you have taken precautions to ensure that your game has been protected against de-compiling then you must assume that anyone can take a look at your source. If this happens, then they are in a very strong position to break into your game because they know how it works. (and it's possible to even re-compile code and play with that, if they know what they're doing.)

There are a variety of SWF encryption products out there. Some of the more notable ones are Kindisoft, Amayeta, Amberia and SWFprotect.

Of course, these all cost a good deal of money. It is up to you to decide if they are worthwhile.

But even with a fully protected SWF, we are still vulnerable. If there are holes that can be exploited, it is fully likely that someone will find them and exploit them. Then, if they care at all about their reputation as a hacker, they will then try to inform the whole world of this vulnerability for e-cred.

Security through obscurity is not real security.

Of course, depending on the game you are creating, you might have to settle for just "obscure enough". The best example of this is a peer-to-peer type setup. If you are going to use this setup due to unwillingness to learn C# or similar considerations then you will never be able to build an impenetrable shield around your game. If they are persistent enough, a hacker will likely be able to get through. The trick is to make it difficult enough that 99% of the hopeful hackers give up and leave you with a population of hackers small enough to be almost negligible.

The methods used to make a hacker miserable are situational dependant and varied but there are a few recurring themes..

First, if we wish to beat the hackers we must think from the perspective of a hacker. As a hacker we have two places where we can attack:

  1. The messages being sent out from or arriving at our computer. It is fairly easy to detect, replicate or reproduce messages with the proper programs and knowledge.
  2. The flash application itself. Possible attack types include a hex edit, decompiling the application or (a stick arena favorite) speed gear.

It is important to note again that with the server-client setup the hacker essentially gets his hands chopped off. Assaulting the client itself is fruitless because it holds no weight (being only a fancy input-output device) and the messages it sends out hold little direct power over the game state. Simple server dependence is the sledgehammer alternative to all the options we are about to present.

Looking at protecting our flash application first: If you have secured the game and are assured that it will not be decompiled, you can put preventative measures into the client itself. Strategies such as ensuring that the frame rate does not exceed what it is supposed to be [can be done by comparing against Date.getTime()] and ensuring that important values such as score or ammo behave the way they are generally supposed to (a ward against hex edits) are very effective at warding off script kiddies.

In the case that you think you have caught a person cheating, do not take severe action. A disconnect is all that is required. The cheater will get the message and once they see your game is secure and their tools do not work, most will be forced to give up (because most do not know how to circumvent these measures). Plus, a wrongful accusation is a very bad situation.

If you wish to make sure your games are safe from the common tools, you should test them out and see how your game responds. You can easily get the most common hacking tools from the internet.

Preventing a cheater from interfering with your messages is a much harder problem to tackle. It is very easy, with the proper programs, to catch packets as they leave your computer or intercept packets as they arrive at your computer. This allows one of two things:

First, the hacker can modify outgoing messages to suit his desires. Instead of the packet saying "10 damage" he'll make it say "1000 damage".

Second, he can block packets he doesn't like. For example, he could block packets that say that he was damaged, making him invulnerable.

When dealing with problems of this nature, we cannot stop the cheater from accessing the data or modifying it. The best we can really do is make it really hard for him to do so. Even just scrambling message names every so often and adding various values to all data (then removing them on the other end) is enough to dissuade most hackers. They will be able to modify your data, but they won't know what to change!

A more secure form of encryption would work even better, such as RSA.

Overall, you can still get a fairly secure game without relying on the server for security. The best solution, however, is still a server-based setup.

You should still be mindful of the various attacks a hacker can perform, even if you have all critical information on the server, however. Take a look at what would happen if a player were to send extra copies of a message when they were not supposed to, or block a packet that they were supposed to receive.

Often cheating can be as simple as being able to click on something that should be out of reach. Imagine there is an item on the ground in an area that the player should not be able to reach. Even though they do not change their actual position on the server, if the player can get next to that item on their screen and send the message that says they picked it up, the server would give it to them! (unless you were smart enough to sanitize against this)

So, we must program defensively and trust nobody and nothing. Every time an event occurs, we should make sure that it actually can occur.

Every time a player makes a move, we check it is his turn and the move is valid.

Every time a player picks an object up or interacts with the environment, we make sure they are close enough to do so.

Be paranoid
(But to a reasonable degree)



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).