Advanced Java Game Development: Introduction
Three years later, it's interesting to look back and see where Java fulfilled hopes and where it disappointed.
PlayLink was ambitious, interested in many types of games: single player arcade classics, multiplayer board and card games, huge persistent world universes, first-person shooters with kick-butt graphics, and real-time strategies.
Three years later, it's interesting to look back and see where Java fulfilled hopes and where it disappointed. Not to keep you in too much suspense, it might as well be said now that the only style of game PlayLink was unable to adequately pull off were first-person shooters. However, it can be done. Check out Frag Island by Niclas Thisell and Andreas Suurkuusk.
Rapid Development Shangri-La
Did Java make game development a gentle breeze, a springtime walk through the park?
There are some really robust and easy-to-use rapid development packages out there. But PlayLink is full of picky people. We wanted our games to look exactly the way our designers envisioned them. We didn't want to plug in solutions such as Java Beans, because we really wanted control over every aspect, from client down to server.
Graphically, we wanted custom scrollbars and floating, transparent chat areas. Today, we could use Swing to achieve these effects. But back in Java 1.0 days, we had to write our own lightweight components. Many of these we based on the original Java AWT code.
We'd dug our own perfectionist hole and had to fill it. We basically wrote our own class loader, media tracker, GIF decoder, containers, and components. It was slow, frustrating work.
The big reward was that our classes were lean as could be, with only the exact capabilities we wanted. Swing and other prefabricated libraries are often too bulky, and definitely slower than our home-brewed concoctions.
All one of our programmers needs to do to create a new game is provide the artwork, an optional artificial-intelligence evaluation algorithm, and the game's general rules.
Given all that, the rate in which we were able to crank out a game lobby, communications server, game framework, and dozens of games themselves was right on schedule. All our developers really enjoyed Java itself. It was great to have garbage collection take care of no-longer-important objects. It was a breeze to piece classes together. It was a pure pleasure to no longer worry about allocating memory or double-asterisking pointers to pointers.
PlayLink grew into a complete gaming system an interface through which players were able to update the latest code changes, download the latest games, browse through rooms, chat with and meet other players, create game sessions, and, of course, play to their hearts' content.
Pretty much all our games extend from a master class we call BoardGame. This abstract class has things like the chat window, the list of players, a way to update and receive the game's state, as well as a way to keep track of who's currently playing, observing, and on the waitlist.
Specific types of games are based on subclasses that extend from BoardGame. For instance, a special CardTable class keeps tracks of card hands, card animations, sorting, dealing, trick counting, and betting.
At this point, all one of our programmers needs to do to create a new game is provide the artwork, an optional artificial-intelligence evaluation algorithm, and the game's general rules. The BoardGame class takes care of the rest.
This completely object-oriented architecture also works great for updating. Let's say we decide we want a new button in all our games to allow players to invite their friends. We simply program that button into the BoardGame class user interface, and it automatically appears in all the board games. The next time a player logs on, our updater tool will search for any new files and simply download the latest 60K BoardGame class. Voila, all players now have the new functionality, quick and painless.
Page 1 of 2