Design Article
Mobile Game Networking Essentials--Part II
Michael Morrison
6/9/2008 12:24 PM EDT
Network Game Problems and Solutions
Now that you know which type of network games you are dealing with, let's look at some of the common problems you will encounter in a mobile network game design. The overriding concern to be dealt with in designing network games is maintaining synchronization. Synchronization refers to how multiple game instances running on different phones maintain the same game state information. Remember that each player is running a separate instance of the game, but the overall goal is to make each of these different instances function logically as one game. All the internal data structures modeling the game's state should match exactly on each player's system.
You can best understand this concept by looking at an example of what can happen when synchronization is lost. Suppose that two players are playing a network adventure game similar to one of the games in the popular Diablo series. As they are walking along together, they run across a demon. Player 1 is a little more assertive and starts fighting the demon. Player 2 is low on energy and decides to just sit in the shade and watch. When Player 1 finishes off the demon, Player 2 somehow must be notified, and not just as a matter of convenience; any change in the game that potentially can affect other players must be communicated to them.
Another common problem in regard to synchronization involves using random values in games. It is fairly common for games to place some objects randomly when a game starts, such as treasure or even monsters. Sometimes games use random events just to make things vary a little from game to game. In network games this creates big problems unless each game instance uses the exact same random values as all the other instances. It would totally blow the synchronization for each game to have things going on randomly with respect to each instance. The point here is that many seemingly insignificant things, such as generating random numbers, can cause major headaches in a network game environment.
Now that you understand the problems, let's move on to some solutions. There are many different approaches to designing network game communications, and they all must somehow address the problem of keeping each player's instance of the game synchronized with all others. You're going to focus on two basic types of network game synchronization strategies: state synchronization and input synchronization.
State Synchronization
State synchronization is a communication method by which each game instance communicates its current state to the other instances. The state synchronization method is very robust because there is no chance for information loss; everything regarding the current state of the game is sent to the other instances. In a two-player space battle game, for example, the position and speed of all the planets, asteroids, ships, and bullets would be sent as the current state of the game.
Gamer's Garage: Because of limited bandwidth on mobile phones, state synchronization represents the biggest challenge to developing networked mobile action games.
Sounds good so far. But what about a more complex game, such as a role-playing adventure game with entire virtual worlds with which the players constantly are interacting? Sending the state of the entire game starts looking a little more difficult because of the vast amounts of information required to model the game state. And don't forget about the bandwidth limitation you learned about earlier, which keeps you from being able to send loads of information between mobile phones. Knowing this, it's easy to see that state synchronization is a fairly messy network communication solution. Although state synchronization is functionally a very solid network solution, technically it's not always feasible.
Input Synchronization
Input synchronization is a communication method in which each game communicates the input events of its player to the other game instances. Using input synchronization, each time a player generates input events, such as pressing keys, the game broadcasts these events to the other games. If you think about the space battle game example from before, rather than send the state of all the objects, the game just sends the key input events generated by the player. Each game then handles each remote (virtual) input from the other games in a similar manner as it handles its own local player's input.
There has to be a catch, right? Of course there's a catch! Input synchronization works fine as long as all the changes in the game are dictated solely by the players' inputs. Practically speaking, this rarely is the case except in very simple games. There are usually random effects in a game, such as placement of background objects. These random effects wreak havoc on games relying on input synchronization because they aren't affected by player input and therefore are never communicated between games.
If you happen to have a game in which the entire play flow is dictated by player input, input synchronization is for you. Otherwise, you'll have to come up with another solution. Can you think of any games that are dictated entirely by user input? Give up? It ends up that most turn-based games are driven completely by user input. So you usually can implement network support for turn-based games by using input synchronization.
Gamer's Garage: The Connect 4 game that you design and develop in the next chapter is a good example of a turn-based game that relies solely on input synchronization.


