Evaluating Java for Game Development

Jacob Marner writes: "A large independent university report has just been published that examines whether Java is useful for professional game development."

Comments

Hasn't Lisp already proven this?

[Jayson]

Since there have been games written mostly in Lisp already, doesn't this empirical proof extend to Java or other higher-level languages? I have seen comments such as "nobody wants to be first" and that there is "cultural baggage," but wouldn't Lisp's trail blazing really have been these new firsts and unloaded some of the cultural baggage?

Re:Hasn't Lisp already proven this?

[DGolden]

Well, Lisp has a reputation for use in AI programming, so games programmers often think of it when considering scripting languages for enemy control - e.g. Abuse. (though, of course, there's nothing magic about Lisp that will make your enemies behave more intelligently, a dumb loop in lisp is still a dumb loop.)

Java has a reputation as a rather pedestrian C++ variant (though due to its dynamic features, javais actually more like a cut down smalltalk with C++-like syntax), and really is a pretty boring and ordinary language. "21st Century COBOL" is how it's been treated in the corporate environment.

mobile phones

[jilles]

Java gaming is going to happen, just not on the PC for the moment. Right now, mobile phones are being shipped that have a JVM on board. It will be a matter of time before someone figures out how to use that for games. The same applies to PDAs.

These kind of platforms require the kind of safety and security Java offers. Particularly being unable to corrupt manually is a very nice feature since you typically don't reboot your phone.

As for 3D gaming on the PC there's some stuff to consider. You have game engines, game code that uses these engines, standalone games and low level APIs such as directX or opengl. If you look at the quake and unreal engines (responsible for most of the succesful 3d games of the past four years) you will find that they include their own scripting languages in which most of the game functionality is implemented.

In addition both John Carmack (quake) and Tim Sweeny (unreal) have considered using Java for that job in the past (way before stuff like hotspot compilers was around). For various reasons they chose not to. I recall Tim Sweeny saying in an interview he needed a more domain specific language than Java to script the objects in the game. Performance was not so much a concern (after all they ended up using a scriptlanguage).

I don't believe we're going to see much Java games in the next few years. The existing game engines are simply to good and to mature to compete with. However do foresee a shift from the low level details of rendering 3D stuff, doing 3D sound, etc. to game functionality. Already many games just use third party engines for their games. Developing your own engine only makes sense nowadays if you're able to sell it to others. One engine for one game just isn't economically feasible anymore. Likely the game engines will continue to be written in C/C++. However its just a matter of time before there will be gameengines that can also expose their API to Java or .Net. Thus allowing gamedevelopers to use a higher level, less error prone language than C for the game functionality.

Embedded game languages (e.g. Unreal engine)

[smcv]

Scripting languages embedded in C or C++ game engines, like Unrealscript in Epic's Unreal series, seem to provide a good compromise - many of the advantages of Java, but without the performance problems. (but then, I make Unreal Tournament mods, so perhaps I'm biased...)

Epic Games' Unrealscript reference has some background on this. Some of the interesting bits:

Why they didn't use Java:

During the early development of UnrealScript, several major different programming paradigms were explored and discarded before arriving at the current incarnation. First, I researched using the Sun and Microsoft Java VM's for Windows as the basis of Unreal's scripting language. It turned out that Java offered no programming benefits over C/C++ in the Unreal context, added frustraging restrictions due to the lack of needed language features (such as operator overloading), and turned out to be unfathomably slow due to both the overhead of the VM task switch and the inefficiencies of the Java garbage collector in the case of a large object graph. Second, I based an early implementation of UnrealScript on a Visual Basic variant, which worked fine, but was less friendly to programmers accustomed to C/C++. The final decision to base UnrealScript on a C++/Java variant was based on the desire to map game-specific concepts onto the language definition itself, and the need for speed and familiarity. This turned out to be a good decision, as it has greatly simplified many aspects of the Unreal codebase.

Game content and even third-party mods designed for Windows work perfectly on the Linux and MacOS ports of UT:

UnrealScript is bytecode based: UnrealScript code is compiled into a series of bytecodes similar to p-code or the Java bytecodes. This makes UnrealScript platform-neutral; this porting the client and server components of Unreal to other platforms, i.e. the Macintosh or Unix, is straightforward, and all versions can interoperate easily by executing the same scripts.

Why performance isn't always vital (my emphasis):

UnrealScript is a slow language compared to C/C++. A typical C++ program runs at about 50 million base language instructions per second, while UnrealScript runs at about 2.5 million - a 20X performance hit. The programming philosophy behind all of our own script writing is this: Write scripts that are almost always idle. In other words, use UnrealScript only to handle the "interesting" events that you want to customize, not the rote tasks, like basic movement, which Unreal's physics code can handle for you. For example, when writing a projectile script, you typically write a HitWall(), Bounce(), and Touch() function describing what to do when key events happen. Thus 95% of the time, your projectile script isn't executing any code, and is just waiting for the physics code to notify it of an event. This is inherently very efficient. In our typical level, even though UnrealScript is comparably much slower than C++, UnrealScript execution time averages 5-10% of CPU time.

Re:Conclusions...

[mvw]

Java3D is actually based on OpenGL.

No, for Windows you can either choose a version using Direct X or one using OpenGL for rendering.

Yes, that means that there is C code running at a low level (i.e., the OpenGL implementation provided by each graphics card provider), but that is no different that *any* language other than C that uses the OpenGL standard, including C++.

My complaint is that there is no Java3D version that is portable and free at the same time. But that is my general problem with Sun's Java licensing.

I agree that Java may have missed the mark, as far as performance-intensive applications like games are concerned, but given that people are seriously interested in Python-based game development (as evidenced by pygame, PyOpenGL, etc.), I think it's hardly reasonable to attack it on the basis of performance.

The present Java games are not bad. But they are the same league, like games written in Flash are. Hard to imagine a Java title would show up in the games top 10, and this mainly due to the fact, that most top titles try to really use the hardware at its limits, thus performance is an issue.

Personally, I'd rather hear the opinion of someone who had actually worked on commercial- scale gaming projects.

Java gaming is a good resource. Several of my colleagues are former game professionals. They watch the Java game development community with great interest. As far as I can tell, their opinion on Java for gaming seems to range from promising to not suitable (at least not for Quake III like games, where state of the art 3d engines are needed that squeeze out every cycle).

The crucial question for them is if you can make money with such a title, which seems to be not easy in the games industry. Perhaps it will be in the mobile phone market?

Re:I'm very curious

[mvw]

I've never done official tests, but Java always seems to take an order of magnitude more memory, and runs much slower.

Memory waste seems to be a bigger problem in Java, then it is in C++. (Which in turn has a much worse performance impact than the usual suspect VM interpretation).

I am not exactly sure why this is.

• Is it because people have a garbage collector and thus they get more careless about memory cleanup?
• Or is it because Java programs are on a higher abstraction level than C++ programs (which means more complex object hierarchies with much unfortunate temporary object creation/destruction)?

Maybe someone can explain to me, how Java could be faster than C++.

One argument is that a JVM like Hot Spot does dynamic compilation. The typical C/C++ code gets one once compiled. The resulting exe is hardly optimized after, even if you might take it to quite different execution environments.

Code generation involves making assumptions about the execution environement and will result in certain influential decisions.

A JVM like Hotspot however probes the present environment and will profile how the compiled code behaves, and will probably try improving matters during interpretation.

This might lead to better and thus faster code than the static one, we are used too.

I believe Intel's C/C++ compiler does a dynamic optimization at runtime too.

Might be interesting to compare that one to Hotspot Java code. :)