Conclusion

This chapter has covered the basics of how to make Java games play nicely together on a local area network (LAN) using today’s Java. In this next and final section some of the other issues in Java network games are briefly addressed.

Future APIs

JDK 1.5 is right around the corner. It is going to add some key functionality that you had to build yourself in JDK 1.4 or earlier. One key networking addition to JDK 1.5 will be a standard UUID class. This UUID, being part of the environment, will be able to look for MAC addresses and produce the best possible uniqueness. When it is available, it will be preferable to the UUID class presented in this chapter.

In addition, there is ongoing work in Sun’s Game Technology Group on a variety of game topics, including networking. Anyone seriously interested in this topic should bookmark the Java Games Community Web pages and visit them reasonably frequently. (You can use either of these URLs: http://community.java.net/games or http://www.javagaming.org.)

WAN Play

As briefly mentioned earlier, more and more games are dealing with wide area networking (WAN), the most common type being the Internet. The issues and tradeoffs for these kinds of game are very different. Bandwidth can be limited, particularly if you are trying to support analog modem play. Latency can be bad—as high as six-second spikes on analog modems.

If you are designing for broadband users only, these issues become less of a problem but still do exist to some degree. (The Internet itself can cause latency spikes of up to about half a second.)

For LAN games you can get away with lock-step games using controller communication, but a modified lock-step game that isn’t tied directly to frame rate is preferable to allow each machine to render at its own pace. For WAN games, you really have no choice but to use some form of open-loop asynchronous synchronization.

Server-Based Games

This chapter addressed only peer-to-peer games. It used a communications architecture where there is one thread per socket that needs to be read. This technique is perfectly fine for games that have up to one or two dozen players. Game servers, however, often need to handle at least hundreds and maybe thousands of sockets at a time. This architecture is not suited to such large-scale problems that you would end up with hundreds or thousands of threads competing for CPU time.

Since JDK 1.4, Java has provided a solution for this with the alternate socket facilities in the javax.nio (new IO) packages. Such server coding is beyond the scope of this book, but more information on using NIO can be found at http://java.sun.com/j2se/1.4.1/docs/guide/nio/. (This same guide also appears in the guides section of the Sun JDK 1.4 download.)