Check out my company's latest game, Hungry Jack's Phone Footy for iPhone!
- Peer-to-peer 2 player connection
- Augmented Reality camera tracking
- Magnetrometer input for game wind direction
- Face recognition
- Accelerometer passing and catching controls
Proud to be part of such a talented team!
I know I've made several false-starts and empty promises for posting some game examples, but I swear this will change soon!
Something that I've wanted to build for a while is a multiplayer game using Flash. To understand how this will work, we will look at some fundamental concepts:
Peer-to-Peer: This form of connection creates a direct link between the players or users of your Flash application. No servers are required, lag is reduced (because data doesn't need to flow to a server). Despite these positive attributes, multiplayer games often use the alternative connection method below.
Client-Server: This setup is more often used in games because a server acts as an adjudicator in the gaming environment which is often highly competitive. Having a server also acts as a security measure against players attempting to hack the game or inject unwanted code into the application.
Flash Socket Connection Servers
Flash applications on different clients connect to each other by what are known as socket connections. When a client establishes a socket connection with a server, data can be transferred freely between the computers (without security interruptions). Some examples of Flash Servers are SmartFox, ElectroServer and Red5. I haven't decided on which server to use for my game yet, but hopefully I'll elaborate more on the different servers in another post.
We've already talked about the different connection methods, so now we will apply this in an example. Lag is unfortunately a fact of the internet. No matter how fast the client connections are, there will always be at least some latency issues. Latency is the delay in data transfer due to the physical distance that the information needs to travel on top of the quality of the clients' connection. Let's consider the following scenario:
You are dueling another player in a fighting game. Both of you hold a sword and shield. Your opponent presses the 'attack' button, causing him to swing his sword toward your character. As you see the sword approach, you wait for the very last moment before pressing the 'block' button to defend yourself. On your screen, you appear to have blocked the attack, but because of lag, your opponent doesn't receive information that you have blocked, and to him you received the hit.
In a peer-to-peer connection, this will cause both clients to disagree on the current state of the game. To solve this, the client-side code can disregard all 'hits' unless both computers agree on the outcome, but this opens up even more problems - for example your opponent can use a program to always ignore hits on himself, making it completely unfair for the other player.
For this reason, we use client-server connections. A server, who may be a third computer that contributes to even more lag, is better in a competitive game because it will decide on the current state of the game at all times. In the above example, the server will decide whether or not your opponent's hit was blocked, and broadcast the result for all the players to see.
This is not to say that servers are the only way to make games. It is plausible to create games that are purely peer-to-peer, but these are often non-competitive or just cooperative games where an adjudicator is not necessary.