Whammo! It’s the 21^st century. "But, I’m not ready!" Well, get ready, because computer technology continues to race along, out of control, and so computer game design must move with it (marginally in control). 

In my ever present spirit of giving, I now give you a heads up on the issues and problems you’ll have to deal with as we venture forth into the wild new yonder. Don’t thank me yet though, you may not like me after you finish reading.

In a nutshell, expect to find a mix of both new and (unexpectedly) old challenges with the single most important difference being, of course, the Internet.

Many Internet games are written in Java or Shockwave/Flash. Because of the way these languages work, they will run slower than the same game written in C/C++. That’s just the way it is. These languages aren’t completely compiled down to machine language, so they simply can’t achieve the same raw execution speed. Therefore, if we want to get the most out of our games, we need to know how to code things efficiently in order to squeeze the maximum performance from every ounce of available CPU.

Space limitations are back and they’re steaming mad. Okay, they’re not really mad, they’re just back. That’s right, we’re dealing with strict limits on how big our total code, graphics and sound can be. In the old days, this problem cropped up because of a lack of RAM or disk space. But these days, memory and especially disk space, are cheap. Bandwidth is the problem. The game still has to be delivered over modem connections to most people. So we don’t have 600M of space available anymore. Even 1/10 that size is fairly hefty and most people won’t sit around for a long time for a Java or Flash game to load. So in general, start thinking "small".

In a restricted environment like this, game play has to be really good. You can’t expect a raging blizzard of polygons and an aneurysm-inducing soundtrack to send your player’s into a hypnotic trance. You actually have to have a game, and it actually has to be fun to play. Why are we seeing all these old arcade games returning? It’s because those games were carefully crafted works of art. The graphics were primitive, and the sounds were simple, but they were well thought out and really fun to play.

Multiplayer games are now the wild, untamed frontier. In some ways, multiplayer games are simpler than traditional single player, stand alone games. Mainly because you don’t have to create a worthy AI competitor, which, depending on the game, can be a massive undertaking. On the much weightier negative side, it’s much more difficult because the designer now has to deal with networking, cheating, lag, (networking, cheating and lag, oh my!) sockets programming, asynchronous events like players coming and going unpredictably, and more stuff you’ll learn about later.

Also, because you are dealing with real people playing against each other, those players will feel a need to communicate with each other. So the dreaded "chat system" invariably raises its slimy head. And speaking of chat, what about censorship? What do we do about all those nasty little f-words that our cheery little net pals like to use because our arms aren’t long enough to reach through the wires and kick their little asses? Do we try to filter out dirty words and objectionable stuff? Should we? Can we? Think about it. It’s not as cut and dry as you’d think.

One of the first technical issues that comes up with multiplayer games is the actual procedure for getting people gathered together into one place so they can play against each other. Let’s say you get a bunch of players gathered together into a lobby. Once there, how do you get 2 or more of them separated from the herd and grouped together as players in a single game? It’s not as easy as it might seem if you’ve never done it before. Lobbies like this often represent large projects by themselves.

The biggest crimper of styles is probably "net lag". The inherent travel time for data across the Internet from client to server, or client to server and back to client. In general, any given client can expect a message to take from 20 to 200 milliseconds to travel to another computer over the Internet. If a message has to travel from a client to its server, and then that message requires a response, the total round trip from message sent, to answer received can take from 40 to 400 milliseconds average. For some types of games this can be an offensive and unacceptable eternity.

In addition to net lag, which is always there, ya got yer "net weather". This refers to the unfortunate fact that lag can vary dramatically from moment to moment. In fact, sometimes data can disappear entirely. Depending on the protocol you are using, this could result in the hopeless loss of the data, to a protracted time-out and re-sending of the data. So in fact, any given message could take from 5 to infinity milliseconds to arrive at its destination. Your game absolutely must be written to handle these conditions gracefully, because they will happen. Trust me.

Net lag really sucks if you’re trying to make a real-time action game. Whenever any game play element depends on split second timing, like dodging a missile, or a missile being in just the right spot at just the right time to register as a collision, then lag is going to make your life hell. You’ll find yourself spending enormous amounts of time dealing with cheating, and synchronization problems that will never really be solvable. My advice is don’t bother trying to make real time action games right now unless they are single-player games. Wait 3 years and then we’ll see what the state of the art is.

TCP/IP socket programming is how you will most likely be communicating over the net in your game. Sockets are similar to file handles, but not exactly. A socket is like a pipe, either end of which is held by a program. Each program is free to send messages into the pipe, read them from the pipe, or close the pipe at any time. Also, even though one computer may choose to write, say 100 bytes of data, does NOT mean, that the other end will immediately be able to read 100 bytes of data. After an indeterminate amount of time (see "you know what" above), the receiving client will be able to read some of that data. It may not all arrive at the same time. You may receive the first 32 bytes, and then 10 seconds later, the remaining bytes, or some portion of them. Or the remaining bytes, plus the first 20 of the next message. This has to be dealt with, usually in terms of a special thread that waits on the socket and collects the stream data into discrete messages.

In order to open a socket connection to another computer/program, one or the other of them must act as a server at least until the connection is established. This means that it must "listen", or wait for the other computer to attempt a connection as a client. If you are trying to make multiple machines act as peers, equal and identical in every way, you will have to find a way to deal with this.

And then, there is "scaling". How do you ensure that your game servers will be able to handle the load if your game turns out to be popular? What if marketing chooses to do something that results in a huge, sudden surge of traffic? Will your server(s) handle it? Or will they just cough up blood and fall over dead? Wouldn’t that be embarrassing?

If someone chooses to hack a single player game so they can cheat the only person directly affected is him or her. If someone does this to a multiplayer game they can ruin the game experience for all the other players. And the others may very well have PAID for that experience. It’s a law of nature that people who pay for things and then have those things busted or taken away, have a reliable tendency to become pissed. So cheating isn’t just a piracy issue, or a technical issue, it can instantly become a political and public image issue.

Cheating can be dealt with effectively in any game that does not rely on client side resolution of game issues such as which object collided with which other object. In other words, as long as no message coming from a client is trusted, cheating can be dealt with. That doesn’t mean that resolving things on the server means your game will be cheat proof, only that it can be cheat proof. Turn based games are generally the best candidates for being cheat proof.

Multiplayer games pit real people against other real people. Any time you have a collection of real people, you have a community, or social situation. This social situation will be similar to normal ones in that you may need to deal with disgruntled customers, bickering, accusations, inappropriate behavior, etc.

One particular issue that is somewhat unique to Internet communities is the problem of child protection and Internet predators. What can the game designers and publishers do to limit their responsibility if something terrible does happen? What can be done to prevent it?

So what does it all mean? Well, it means that the Internet, and in particular, multiplayer online games represent an entirely new environment as compared to traditional game design. Because of the current restrictions in processing power, data space, and media quality, we can expect to see games changing to accommodate those limitations.

For example, there will be far fewer fast paced, action games. At least until low latency, high bandwidth Internet access becomes ultra cheap and ubiquitous. We can expect to see more games focusing on game play and strategy, rather than ultra high quality sound and graphics. You won’t be stumbling over heaps of real-time, first person, 3D games. There will be many more turn based game designs springing up and games will tend to be smaller and shorter.

We will continue to see more resurrections of classic arcade games, games that were originally designed for limited environments, but were still fun.

Also, though I haven’t stated it explicitly, it should be fairly clear that game designers should expect any multiplayer game to represent a two, three or four fold increase in complexity and development time.

If you’re moving from traditional game development into Internet game development, be prepared to have to learn a whole lot of new things, and unlearn a few as well.

And lastly those of us who have been making computer games since the beginning will find that our abilities are suddenly in high demand. We were sending email, and transferring files on the Internet long before there was a web. Long before anyone in the real world was even aware that there WAS an Internet.

And of course, many client/server-based multiplayer games now rely on a UNIX based, server side component with extensive use of asynchronous sockets, multithreaded code and database interaction. These are ancient and familiar, as is the art of wringing maximum fun from minimum speed and space.

If you’re just starting out, and all you know is the Internet, seek out the wizards from the past. They possess a treasure of clever spells and incantations that can be applied directly in this new environment and a deep understanding of the dank and musty foundation stones on which the Internet rests.