Faster, Better, Cheaper. That's What!
In AT's interesting Blog "You Can Make Real Games In Java!!! Yeah... But So What?" he raises a lot of interesting questions. What I don't entirely agree with though are his answers:
"Problem is, as far as these guys are concerned, anything we can do in Java, they can do in C++. And they already know how to write games in C++, so proving equivelant (sic) capability is no real argument at all."
By definition, anything that can be done in any language can be done in assembler. Yet higher level languages continue to evolve and developer. Why is this?
The answer is that just getting the job done is not enough. If there is a tool that will get the job done faster, cheaper or quicker then that is often the right tool to use. Sometimes its tough to convince someone to try a new tool. It took me forever to convince my wife that using the heal of a shoe to drive a nail in was giving her inferior results for too much effort and that she should leanr to use a hammer. Needless to say today though she doesnt reach for a shoe when hanging a picture.
"Cross-Platform? Well, cross-compilers for games have been around for a while, and when game companies are thinking cross-platform they're primarily thinking PC, PS2 & Xbox not PC, Mac & Linux, so Java's not really gonna help them there. "
Tell this to Bioware, who set out to write Neverwinter Nights as a cross platform C project for Mac, Linux and Win32. In the end the Linux and Mac versions shipped highly incomplete and have not been maintained with upgrades the way Win32 has. Why was this? Because while you CAN write cross platform C, its damn hard. In the end trying to do so adds so much to your expense of development that you really can't afford to target those secondary markets. Bioware eventually gave up and used Win32 specific tools to build the ore of their product-- the Aurora toolset. As a result that is not part of the Mac or Linux releases and what could have been major breakthrough products on thsoe platforms instead became incidental curiosities.
"Why care about the Mac market. Its only 10% of the desktops", you might ask. Yes, its only 10% but its a voracious market under-supplied for game content. That market supported and built Bungee, the company responsible for Halo, through all its start-up years. Thats real money folks IF you can get there cheap enough that the expense of opening the market doesn't eat the all the profits.
Java can do that. C can't. Its that simple. And who is to say Java won't extend its reach to other important platforms like the game consoles? The game console manufacturers are driven by their developers. Thats a fact of the industry. All it would take is one developer writing a super-hot game in Java and then telling Sony, "Gee we'd like to port to your platform but we need Java" and I guarantee you Java would arrive on PS[whatever].
Athomas next comments on the memory management situation in Java.
"No offense to the truly brilliant minds who continue to catapult the JVM leagues ahead in power and capability with each release, but memory management in games, especially on constrained devices like consoles, largely consists of pre-allocating objects and disposing of them when you're done. Having a process you don't control eating CPU cycles in the middle of a tight game loop isn't really seen as a bonus."
The mistake here is equating the state of current Java memory management with the possibilities of proper game-oriented GC. Let me tell you as someone who wrote games and game portability libraries that "little process" of self memory-management that game developers follow that AT describes is a royal pain in the rear. A proper game GC, where you could tell it "this is the maximum hit I want per game loop iteration right now" would be a godsend and reduce development and debug time significantly. It would also reduce the large number of memory errors that games today typically ship with. (Ever play your favorite game for a really extended period of time and have it lock or crash out? Surprise, thats probably bad memory management at work.)
More importantly though is what garbage collection really enables, which is proper object oriented coding. Today game programmers don't write OOP. They may use C++ but by and large they use it as a C compiler with stricter type checking. Given their tools today they cannot separate their code effectively into reusable objects and modules. Global memory management means monolithic code, its really that simple. Java GC frees you from that. You can allocate temporary on-the-fly objects as needed and be assured they will get collected without other parts of the code needing to know anything about them. And thats the real reason why GC is essential.
Does today's GC meet game needs? Unfortunately not, but the developers of the Java spec in their wisdom preserved a lot of maneuvering room for new GC algorithms and I'm confident we will eventually see GCs that can handle game needs.
"What about RMI? Object Serialization? " Sorry AT, this is a straw man. Noone having to manage and count individual bytes uses these. Instead, you should have asked "what about NIO and scattered reads and writes?" These are the Java facilities for low level packet twiddling and they are a lot more convenient then their C counterparts. conveniences means faster development and less bugs.
However, I'd even argue with the assertion that serialization is not of value. Used judiciously it again can give you code modularity without a very high overhead. A great example is the UUID class that is used throughout the back-end of the Sun Sim Server (I'm told by the way we're going to change its name back to Sun Game Server so get ready to see that in the future.) UUIDs are generated in a few different factories and then passed around and used by other parts of the stack that never need to know their insides. Without serialization, the layer that transports such things must know their internals. I can see this convenience and code modularity (again read "faster development, fewer bugs, better maintainability") reaching out through the edge of the back-end and over the net as bandwidth issues become less and less. There are already game consoles that require broadband for game play. What's 10 or 12 extra bytes on a 128K connection?
Then there are some other qualities of Java AT didn't get to. Like the fact that the entire language is designed to "fail-early". Many errors that plague C programs are caught at compile-time in Java (eg uninitialized variables, dead code, memory leakage through orphaned data blocks). Others are caught as soon as they occur and exceptions are thrown (eg null pointer access, array over-run and under-run.) These are all things that plague games in release today. So not only is writing Java more convenient, its inherently more bug-proof.
Finally, and perhaps most importantly, Java is a language built to handle complexity. In C++ you pay penalties for making your code modular and reusable. In Java, thanks to the miracle of run-time compilation, the easiest and fastest ways to do things are often also the most modular and reusable. Reused code is tested code, leading again to faster development and fewer bugs escaping into the field.
Okay so maybe Java IS good for game developers. It opens markets by reducing porting costs. It allows the developer to deliver more reliable code quicker. Most importantly It allows the developer to reduce the complexity of the game programming problem down to manageable units.
But what's wrong with Java as a scripting language?
The answer is nothing is inherently wrong with it. In fact, its so easy and obvious, its already a fait accompli. Management always likes targets that are already accomplished-- they can declare victory and go on. But setting your goals on already accomplished things gets you no where.
Java has the potential to radically transform the game industry, making better and more reliable games easier to build and deploy. It would be a crying shame to set our goals at anything else.
We've seen transitions like this before in the game industry. Perhapses I'm the only one in the GTG long enough in the tooth to remember this but I lived through the transition of game coding from assembly to C. And the partial transition to C++. These transitions *are* painful there is no denying it. Some developers will absolutely refuse to move, and will eventually find themselves marginalized like the assembly coders are today. Another set will only move when its a proven thing. When the waters seem safe. Those guys will be scrambling for jobs and catching up on their skills. Some will manage the transition and some will fall by thge wayside. But the leaders, the guys who are *always* at the front of the industry, are already playing with alternate technologies like Java. They do it at home on their time so when the shift comes they will be ready for it.
The big question for the game developer is which group do you really want to be part of? The big question for us at Sun is, do we want to ride the front of the wave which means pushing Java into new uses or do we just want to sit safely on the beach content with the uses and users of today.
Myself, as John Brunner puts it in "Shockwave Rider"-- I'm a chaos surfer!
Always have been. Thats why I'm here at Sun pushing Java for game development instead of writing "web services" or whatever managements favorite easy-win is today. Why? To quote a song well known to old fogies like me, 'Cause Mama, that's where the fun is!