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