Slashdot Mirror
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."
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
In my mind, there's really no question about whether Java itself is useful, or whether it could clean up the development process. It is, and it could. I don't doubt that in the near future, we'll see a game system for which most games are written in Java.
The current limitations are these...
First, using a language like Java, despite all that you hear and believe, demands additional processor time and additional space. Only one or two current game systems are up to the task at present. You won't see a change until all current-production systems are up to the task, because virtually every game development house is leaving the option of a universal port open, if they're not already targeting all three major systems. Nobody likes closing their options.
Second, because game systems have typically been very restrictive in terms of RAM size and CPU power, most game developers are accustomed to working at a very low level. They're used to cycle-tuning. They want complete control over the system. Getting most to even consider C++, let alone something as far removed as Java, is an uphill battle. There's a lot of cultural baggage ("this is the way we've always done things") to shed, as well as a lot of relearning to be done. Eventually, it will probably be imperative that Java or some universal event-driven scripting toolkit is adopted. But for as long as possible, the majority of the individual established game developers - the ones who are usually in charge of complete production teams - will avoid making any fundamental changes to their tools.
Next - we work with the tools we're given. Not a one of Microsoft, Sony nor Nintendo have been pushing Java. Accordingly - most of us haven't even evaluated the possibility. The concept is far enough removed that we still joke about whether being a Java programmer is an oxymoron.
Lastly - who wants to be first? Somebody's going to have to take the plunge. Until someone who's - due to personal preference or financial incentive - just gonzo java-crazy jumps in and makes a well-performing Java-based hit, where's the guarantee that going Java is even safe? It's good in theory... but so was WinCE-based Saturn development, and you saw how many hits came from that approach. (Hint: They all have WinCE startup screens, so you'd know if you ever even saw one.)
I have several criticisms of the report.
- For each language, the report conflates the standard library with the language itself. Languages are grammar and semantics. Many specifications also describe aspects of the language run-time environment, but this is not part of the language proper.
- The paper makes little distinction among lanaguage/library implementations. This means that comparisons between Java and C++, especially when comparing performance, are not necessarily comparing apples to apples. Hand-waving implementational differences, especially between two different programming languages, is sloppy at best, especially when one may see vast differences in "performance" within a family of language implementations, e.g. in the Common Lisp world, the CLISP implementation (which compiles Lisp to byte codes running on a C-based VM) is said to have good bignum performance, but the CMUCL implementation (which compiles Lisp to assembly codes) is said to have superior fixnum and floating point performance.
Ok, so with all this talk of performance, there is this really neat paper called "Optimization: Your Worst Enemy". It has an eye-catching title but it's really worth a read.I'm proud of my Northern Tibetian Heritage
>> Now, if these numbers are right, then the C++ program is up to TWICE as fast as the Java one... I
No this is not right. Page 33 says:
>> That Java is a factor of x slower that C++, means that Java uses x times more time
than C++ to perform the same computation.
So a slowdown of 50% means that is is 1.5 times slower.
Jacob Marner
When asking a question: "Can I do X in Java?" and X is something that requires access to some piece of hardware the answer is always that it is possible via JNI if not via the Java standard library. You should not feel limited by the Java standard libraries - if there is something you miss it is easily wrapped an accessed via JNI in a few minutes. If you can access it from C++, you can access it from Java. So for the specific questions: >> How easy is it in java to control the floating point settings of the FPU such as rounding and accuracy? 3D physics simulation is very sensitive to these settings. I don't know. >> How can I write a game which is compatible with 3D glasses standards? Already part of Java3D. Can be done via JNI. >> Can I access 3D hardware functionality? Hardware lighting or multipass texturing? Yes. >> How much control do I have over the garbage collector? I don't want weird pauses happening at the wrong times. Read the report page 37-38. >> Can a java program change the screen resolution and color depth? Yes - possibly only via JNI. My own game at www.rolemaker.dk does this. >> How much control do I have over sound mixing? Can I use 3D sound? All you want. Also via JNI. Wrapping a C++ for use in Java can be done in a few minutes so it is not something that should be considered a limitation.