How to Design an Air Traffic Controller Game

Computer games have become Hollywood behemoths, with dozens of people involved, but game design itself can still be explained and completed by anyone who applies a bit of organization to their thinking. Here's how old fashioned systems analysis and design can still be used. I wrote my first Air Traffic Controller game for the original IBM PC in the early 1980s. It's since transmogrified through several generations, including a multiplayer version on CompuServe in which you could affect the planes that other sector controllers had to deal with.

When creating a game there are several thought processes you move through. First, what will the game consist of? What is the object of the game? Does it have a defined ending? [eg, working though a 15' shift, or handling 20 planes]

The 2 most likely patterns for air traffic controller games are, first, a single airport control tower which handles the details of all flights in and out. The second approach, which I used, is that of a sector ATC who works over a much larger area and hands off to the individual airports.

The next step is to decide what the player will be able to do, and whether the game is synchronous [turn based] or asynchronous [player can give orders at any time]. Early games for PCs were mostly turn based, since that is a much easier way to design. And, before object oriented design took hold, asynchronous programming was more difficult.

For ATC, we'll let the player give simple orders to planes to move up, down, left or right; to takeoff or land at an airport if that's in their flight plan. We could actually take over control of the planes themselves but that wouldn't leave much for the player to do.

Next we'll need to design the user interface. Notice we're well into the design and we haven't even considered what language to use for the program. It's much better to finish the virtual design of a game before getting bogged down in programming minutiae. On the original, mouse-free PCs the choice was easier since asynchronous function keys were available. So F1 could ask for help, F2 could give altitude orders, etc. We'd first make a complete list of the commands possible

• TURN [plane #] [RIGHT / LEFT]
• ALTITUDE [plane #] [UP/DOWN]
• LAND [plane #]
• TAKEOFF [plane #]

Another option would be to present a grid onscreen and let the player do everything with a mouse.

Once we know what the planes can do, we need to design what the player can see. In theory, the entire game could be text based, but most people would decide to show a grid, with fixed airports and exit fixes, and moving planes. The alphabet letters make distinguishing the planes easy, and we can color code them to show altitude. We can also include a table showing each plane, it's current heading, altitude, etc.

Obviously there are other design elements we could add - we could allow for different speeds of the planes, or make more complicated goals, such as doing touch & go practicing between 2 airports.

Now we're ready to start coding. The basic format of the game will be:

While ( not END of game) do

If {5 sec have passed since last update} update_all_planes

If {user gives a command} process_command

LOOP

Thus, a simple continuous loop, waiting for player input, and moving planes when they're ready. Turns out, this simple structure can define hundreds of different games. The plane update subroutine checks whether plane has covered the distance to the next cell. The player command processor decodes the command received and makes the change requested.

Additional side features should include a Hall of Fame to display best scores, most recent players, etc. This information can be kept in a simple file, or as part of a database in more complex games.