This is another one of my ideas posts. One of the many things I’d love to do, but simply don’t have the time to. The question is: why isn’t more large-scale games development done in Java? The answer to most is simple: speed. However, the answer is not actually that simple. Take into account that most of your graphics work (the most intensive work for any game) is taken over by the graphics card, and even physics these days can be farmed out to hardware. The question remains, and the answer stands in several places.
- Cross Platform byte-codes don’t lend themselves to game deployment
- Even though the advantages of running within a VM space can be huge
- Java is heavily multi-threaded, and that can make things difficult in a world where response-time is everything
- Garbage Collection is done beyond the developers control, many game devs feel insecure about not being able to “free()” or “delete”
- Java’s support for external C/C++ libraries in via JNI, which adds an extra layer of abstraction (if a very thin one)
All of these things are however solvable. I would choose GCJ as the start of my “Ubber Java Game Development Toolkit”, it’s an excellent compiler with many of the features you’d want to see for this sort of system. I’d develop an API layer akin to LWGL, but using CNI (GCJ’s answer to JNI; which has you writing code in C++ that directly links into your executable with no abstraction layer). Using your own API (written in CNI), you could directly bind onto the underlying platforms event model, getting rid of the Java event-queue. You can even take over most of the Garbage Collection by doing it in C++.
The idea at the end of the day is: native platform bindings, Java game code. So you API layer would actually make up a large portion of the game engine, allowing the actual game development to happen in Java, with compilation to a native executable.
Lemnik Technology Blog 
April 26, 2007 at 11:03 am
What you describe defeats the point of Java. Why not just use C# and managed DirectX – it will be both faster and neater?
April 26, 2007 at 11:03 am
I might misunderstand what you’re getting, but wouldn’t a native platform binding kinda defeat the purpose of using Java as a platform?
I do agree that it’s kinda strange that more game development isn’t done in languages like Java (or .NET, for that matter). I think with processor speeds and RAM at the levels they are, most modern computers would be able to handle any overhead the VM throws into the mix perfectly fine.
I haven’t been too impressed with a lot of standard GUI stuff that I’ve seen in a lot of Java apps, but I also know a window that takes a couple of seconds to update is a far cry from an OpenGL-based game.
Interesting thoughts though….
April 26, 2007 at 3:03 pm
I’m thinking about Java more as a language and debugging environment than the full J2SE platform. The VM avoids the chances of core-dumps, while GCJ offers the speed of a C++ application. The purpose of the Java Platform is “write-once-run-anywhere”, but Java is also an extremely clean, general-purpose programming language.
So I’m describing something akin to the Google Web Toolkit, except for game development.
April 26, 2007 at 3:40 pm
That’s understandable, but you may consider C#. You still get the “pretty language”, as well as cross-platform capabilities via Mono–you aren’t tied to MS stuff. You can also use the ngen utility (from M$’s tools; not sure what the equivalent in Mono is) to create a full executable that doesn’t have the JIT compilation overhead.
I’m not sure what ngen gets you as far as .NET dependency, but I’m also not familiar with GCJ and whether it eliminates the need for the JRE. You might have to require users to download Mono/.NET Framework to run your game; maybe not (I haven’t looked into it.)
There’s also .NET bindings for Java somewhere I believe; I’m sure there’s more than just M$’s J# too.
April 26, 2007 at 4:51 pm
GCJ can produce both Java byte-codes and true native executables. It also has CNI which is like JNI, but with no over-head. It produces a C++ header and source file with all your “native” method headers filled in, all you do is write the C++ code that goes there. The structures generated by GCJ in it’s executables conform to those produced by GCC’s C++ compiler. So in essence, your Java code is becoming C++ underneath.
GCJ also includes an API level Java VM, allowing you to still have custom ClassLoaders and you Class.forName with non-native Java byte-codes, so in essence you’re code is native, the platform API is native, but you can still load Java byte-codes. This has a really nice aspect when you’re talking about games, since you just bought yourself a scripting language for free.
April 27, 2007 at 3:41 am
I think I get what you’re saying. I could argue about it more, but I’d end up sounding like I’m on Microsoft’s payroll (which would be nice if it were true, but…)
Last time I looked at the native/Java compilation stuff it wasn’t really worth the time it took to download it; all you got was support for console programs that you could write just as easily in any other language, none of the cool stuff. I’m sure it’s come a ways since then, and it sounds like that isn’t entirely what you’re looking for anyways–you’re wanting to, as you say, use Java as a scripting language in a way, right?
Good luck with it; should be fun, regardless of what happens with it.
April 27, 2007 at 9:41 am
As both a scripting language and as a glue to tie bits of the engine together nicely. The other part of using GCJ is while you’ve lost “compile-once-run-anywhere”, GCJ can compile to most platforms, so you can simply ship one executable for each platform, so it’s technically still “write-once-run-anywhere”.