Network Game Programming - Issue 01 - Things that make you go "hmm..."
by Dan Royer (16 June 1999)
|Return to The Archives|
Ok, I'm feeling really pressured right now so you'll have to forgive me if I don't come up with a really cool intro paragraph on multiplayer networked online game programming (he he, a few keywords for the search engines...). Over the course of the next few weeks I'm going to show you how to build a realtime game for as many players as you would like, ala defender/asteroids/etc... I read Winsock 2.0 by Lewis Napper (ISBN 0-7645-8049-3), pretty much everything after that was self-taught so if I screw up the terminology, I appologize ahead of time.|
The next few weeks are going to cover a lot, so here's the game plan:
Now let's get the show on the road!
Things that make you go "hmm..."
There are a number of things to consider before you start writing your game. That's right, before. Some of you may have tried to convert single player games to multiplayer only to find yourself buying new keyboards because you cried so hard the old ones short circuitted. I feel your pain.|
The first consideration is: how realtime does your game have to be? I can think of three basic "speeds" of game:
Play by mail doesn't concern us since it doesn't require a server. Ok, ok, you could write one, but why?
Turn based games are really a fast version of play by mail. I say this because if players were known to take a really long time between turn you could disconnect from the network during the iterim. I've never heard of anyone doing this, so it's a moot point. One nice thing about turn based games is you don't have to worry about a little delay in response time so the ammount of data being sent back and forth isn't a major concern.
Real time games are the bread and butter of the game industry today. They're the fast-paced space racing kung-fu eye gouging adventure we've all come to love. If you've just started coding and you want to bite off more than you can chew while you skip to the last chapter, this is the thing to start with. Seriously, you need an ingenuity that only comes with real understanding of your programming language (in our case, C++) because you're going to want to do EVERYTHING possible to reduce the ammount of data passing between client and server.
The next consideration is the complexity of the game or (as I like to think of it) the size. The more different things people can do in the game, the bigger it gets. The bigger it gets, the more data has to be transmitted. The more data has to be transmitted, the more bandwidth is needed. The more bandwidth is needed, the fewer the players and the greater the lag. It's a little like dominoes, knock over one and they all come tumbling after. This doesn't mean that you have to scale back your design and start simplifying, it just means you've got to be clever about it. More on that later.
Based on each of these considerations you have to choose a client server model. There are two types:
Now let's take a look at our space shooter game and see what it will entail.
... should connect to a server and request information like game name, number of players (and their names), max players, password protection and time the game has been running.
... should make a login attempt by sending a name and password.
Client Round Menu
... is where the client should choose the arena to fight in (if there's more than one).
... is where the client should choose the team or clan they belong to.
... should wait for selection approval from the server.
... should wait for chat messages and echo them to the screen.
... is a good place to put a chat and message system.
Client in game
... is where the client can move about. We'll accept movement forward, back, left, right, strafe, fire and maybe a "use" action.
... is where the client sprite can be spawned, teleported, healed, hurt and killed.
... is where the client sprite can collide with things.
... should await game status, sysadmin messages and echo them to the screen.
... should cope nicely with sudden server disconnect.
... The server should always be ready to accept new login. It should reject new clients if
... The server should only accept login commands from players it recognizes as being in login state.
Server Round Menu
... should only accept menu commands from players it recognizes as being in menu state.
... should approve requests to join a team or arena based on how many people are currently in that team/arena.
... should echo chat messages back to all clients in menu state except the one who sent it.
... should echo sysadmin and game status message to all clients.
Server in game
... should only accept menu commands from players it recognizes as being in game state.
... should await the following commands: move forward and back, strafe left and right, turn left and right, fire, use, quit to menu and quit game.
... should echo the effects of all commands from a player to every other player that would be affected.
... should keep track over every sprite, bullet, bomb, nunchuck, broken arrow head, nuclear weapon, roving derelict space ship, planet, black hole, bonus item and hot dog stand moving in the game and deal with what should happen when they collide.
... should track the idle time of online players and disconnect those that lag too long.
... should cope nicely with sudden client disconnect.
Phew! That's a lot of stuff to do, but we'll get there. Next week I'll detail the base network communication class that everything else will be built upon and show you how to get it working in a Win32 application.