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.