"Fred": Java's Answer to "Doom"?
Two weeks ago, we talked a bit about Java applications that pushed the limits of the technology; this week we're going to look at another, very interesting, example. It's called Fred.We know no one's taken a survey, but we suspect that if we polled all the people interested in programming in Java, possibly even half of them would have to admit that they'd played Doom, Quake, or the like at least once. It's certainly no secret that these games have a tremendous following. They've created an entirely new genre in the computer gaming industry and significantly enriched a number of the companies that started to exploit it.
Fred is (by all appearances) the first "Doomlike" video game written entirely in Java. Surprising? It should be; first-person, 3-D video games have historically had to be written in assembly language and brutally optimized so that they could move fast enough to provide a believable experience. They had to be very efficient.
Of course, the biggest dark cloud on Java's horizon is efficiency. There are numerous extra steps taken by a CPU for an average task to be completed in Java. Bytecodes have to be converted into native machine language. Security and bounds checking have to happen. All the complexities of a very intricate object-oriented language must be worked out, and for all this, while we've seen Java move fast enough to do quite a bit, we didn't expect it could do this. Yet it's in the process of being done. Even more ambitiously, Fred allows multiple players to inhabit the game environment by virtue of Java's networking facilities and a game server that runs on the same machine as the Web server.
You can see for yourself, of course. As for our experience with it, once again we're confronted with second-guessing the final outcome of a project in mid-development (version "0.2 Beta"). We found several versions of the applet available, the simplest being one that just allows you to "walk around" and explore the map, and the most complicated being a "working," multiplayer gaming environment. When we loaded the simplest one on our Sparc, we were rewarded with a small (320x240) window in Netscape that contained a working game.
It's no quake, but it is for real. It was even relatively "fast," although not a speed demon by any standard. We could speedily walk around a very flat, mazelike map, reminiscent of Wolfenstein 3-D. We could fire the requisite shotgun provided. This, make no mistake, is a very impressive feat in itself, making the applet's authors deserving of serious accolades. Of course, beyond the basics, we did run into trouble.
Perhaps we should say instead that the applet authors ran into trouble. The little-known tradition in computing history is that, rather than scientists or the military, it is most often video game authors who push the edge of the technology envelope. Frequently, they end up being the first to confront the performance problems of their venue, and Fred is no exception. The authors have been aggressively pushing against the performance limits of Java for some time, and they know from first-hand experience exactly what they're up against. What they have to say about it is very interesting, and in some cases surprising.
Perhaps their most significant discovery was finding (some would say, confirming) a general inadequacy in the Windows 95/NT version of Netscape 3.0. Specifically, they found that the Just-In-Time Java environment included in the browser (as developed by Borland) was actually slower than the competing JVM products when running their code. They also turned up an AWT bug in it--one of which drives the colors in the game display completely askew. In our test on the PC, Netscape's browser was too slow for network play; it exhibited the color bug and also crashed a number of times. Netscape under Sparc-Solaris faired much better, but on both platforms Sun's appletviewer gave us the best performance.
Also interesting is the speed threshold it indicates, the Fred team claimed they couldn't make texture mapping work with any adequate speed. (Texture mapping, for the video-game impaired, is the process of "mapping" a "texture"--a graphic of some kind--onto the polygons in a 3-D environment.) The walls and floors of the Fred environment are, thus, unadorned solid-color slabs.
Surprisingly to us (simply because we'd never thought of trying anything like this), the authors decried the inadequacy of the Java multimedia libraries, citing difficulties synchronizing image drawing with the "quasi real-time" game environment and controlling the sound. They had efficiency complaints about Java's threads as well; again, this is interesting because their observations are undoubtedly backed up by good experience.
Of course, they're still, as we said, in mid-development. Not to mention, their project has yet to blessed by the newer, much-improved JDK 1.1, now the JDK 1.1.1. Netscape, as well, has a chance to redeem itself with the upcoming release of Netscape Communicator. Once again we've found that some of the most interesting information about the capabilities, and limitations, of a system comes from the people who write its games.
Remember that because it's likely to stay true. We'll be very interested to see what comes out of these and other efforts in the future.
See you next week.
