Is Java a good choice for cross-platform games?

Question

I'm looking to create a game in Java and would like it to work on Windows, Linux, and Mac. I'm pretty sure C# is a bad choice for this, and I don't have enough experience in C or C++. I want to stay away from Flash. Therefore, is Java a good choice for me? Mostly, I use C#, and think that Java is similar, so I assume it won't be that hard to learn. But is it fast enough? Is there a language more suited for my needs than Java?

Answer 1

Java is extremely suitable for writing cross-platform games. Main advantages:

• Portability - In general, you can write a Java game and expect it to run unchanged on most platforms. It's probably the most portable option of any language - C/C++ is the other highly portable option but needs to be recompiled for each platform and in many cases libraries have platform specific features that limit portability.
• Performance - Java code, if written well, will perform pretty much as well as any other language, including C/C++. The JVM JIT compiler is extremely good. You can write a top quality, successful game in Java (Minecraft, for example).
• Libraries - there are a huge range of libraries available for Java that cover almost every feature you could want in games, from networking to graphics to sound to AI. Most Java libraries are open source.

The main decision you will have to take is what GUI framework you are going to use. There are quite a few different options but the most prominent ones are:

• jMonkeyEngine - fully fledged 3D engine. If you want to make a 3D game this is probably your best choice - contains lots of game engine features such as scene graphs, terrain generation etc.
• LWJGL - a more low-level library with direct access to OpenGL. Likely to appeal to you if you want maximum performance and don't mind writing a lot of your engine from scratch.
• Swing - has the advantage of being extremely portable and is included in the Java runtime so doesn't need an extra dependency. It's good for non-graphically-intensive 2D games (strategy games, card games etc.)
• Slick - a 2D game library based on LWJGL. Probably good if you want to write a 2D game but still need good graphics performance (shoot-em-ups, scrolling platform games etc.)
• JavaFX - designed for rich internet applications, roughly like Flash. Has a lot of neat features that would be good for games although I haven't seen it used much yet. JavaFX 2.0 in particular is looking quite promising.

The main disadvantages for Java for gaming are really around the "edge cases" that probably won't affect you but are relevant for some classes of game:

• 3D engine availability - although the tools and engines listed above are good, they still aren't quite up to the level of C/C++ engines like the Unreal Engine used by professional game companies. So Java is possibly not goingto be your first choice if you are are trying to develop a major FPS with a multi-million budget - C/C++ still wins out here.
• GC latency Java garbage collection is overall a huge benefit, but it can cause slight pauses when GC cycles happen. This is getting much better with new low-latency JVMs, but still can be an issue for games with very low latency requirements (first person shooters perhaps). A workaround is to use low latency libraries like http://javolution.org/, however these seem to be targetted more at high frequency trading or realtime systems rather than games.
• Lack of ability to exploit low level optimisations - while the Java JIT compiler is incredibly good, it still enforces some constraints that you can't avoid (bounds checking on arrays, for example). If you really need to get native machine-code level access to optimise this kind of thing away, then again you will probably prefer C/C++ over Java.

Note that there are also a few deployment options to consider:

• Applet - runs in a browser, very convenient for users, however applets are rather restricted in what they can do for security reasons. Note that you can sign applets to get extra security privileges, although this will cause a slightly scary prompt for most users.
• Java Web Start - better for more sophisticated games that need a full local download and also need to access local system resources. It also works in a pretty platform-independent way. Probably the best route for a medium-sized game or something that needs to escape applet security restrictions.
• Installer download - You can write an installer for a Java game just as you could for any other language. It's a bit more work to configure and test of course, since installers tend to have some platform-specific features.
• Web - you could write a HTML5 web application and make use of the strength of Java purely on the server side. Worth considering for a multiplayer web game.

Finally, it's also worth considering some of the other JVM languages - these have all the benefits of the Java platform listed above, but some consider them to be better languages than Java itself. Scala, Clojure and Groovy would be the most prominent ones, and they can all make use of the Java tools and libraries listed above.

Answer 2

Minecraft and Blocks that Matter are both built in Java, so yes it's plenty good for making games. The main issue you're going to run into while using Java is porting to mobile platforms if you choose to go that route and write a native app. Android is a kind of frankensteined Java SE with a separate library. RIM's Blackberry uses Java ME. iOS can in theory be programmed with Java though Objective-C would likely be a better choice for that platform.

Java is quite similar to C#. I often find C# code understandable despite only knowing Java. They do have a different design philosophy but as far as being widely deployable with minimal hassle both fit the bill. C# isn't a terrible choice for games by any stretch either though your mobile deployment will be harder and deploying to non-windows platforms will be more time consuming or difficult depending on what specific external libraries and so forth you wind up using.

Answer 3

The most obvious and least resistant way is to use HTML5+javascript combo. Any application or game made using this will run on almost every device and browser.

Advantage :- You will need zero configuration for making your game run on various platforms and devices.

NOTE:- I have seen few games that are build using the above said technologies but they were smaller in stature. But, I suppose if one can make butter out of milk then cheese is not impossible

Answer 4

You can use Scala and Scheme Bigloo on Eclipse to use JVM for stressed code or parrallel action inside your Java game.

With Pattern Design and UML2, you can also secure code with OCL, all is in Topcased.org .

Mastering those tools take time, but they are the Java's background, the base which will push you at the top.

Answer 5

Short answer: no.

Java do not generates a binary executable but only bytecode as C# does ( CLI ), and this is not a good thing for serious business in "opened environments" for two main reasons:

• the probability to get trapped in reverse engeneering are very high, especially with old and really well knowed languages like Java
• you are not in full control over the machine performances, in the case of Java the JVM plays a big role taking the full control.

Of course every language has its own libraries but due to the great amount of them for each and every language this is not a real problem and i don't think is the purpose of this topic.

Maybe at a professional level you can find something that can break the rule like a dev-Kit that can translate all C# statements into assembly code for a real world machine, but if this kind of approach it's not in the cards you are pratically forced to consider only the C and the C++ for your development when you aim to sell your product in an open environment.

The things are a little bit different for the mobile devices because they are "closed environment" even Android is pratically closed considering the fact that the source of the real world ROMs are not usually available to the public, Android may be considered opensource but the 99% of the ROMs on actuals devices aren't. In this cases you can't argue too much, everything is already set for you and every platform has its own language like everybody knows.

In the end if you are going to sell this products in an opened environments i can only suggest languages that can produce compiled and binary/assembly code, in closed environments the decision is tipically more easy to do for different reasons.