Doug Twilleager's Blog

Java Game Development Myths

I have been meaning to write this one for a while. And now, just over a week before the Game Developer Conference (GDC), it seems like just the right time. This entry will continue trying to answer the question "Why aren't there more commercial games written in Java". There are exceptions. Puzzle Pirates is an award winning massive multiplayer game all written in Java - client and server. This game came up from the independent circuits and just got picked up to be distributed by Ubisoft. Before Puzzle Pirates there was Law and Order and Roboforge, but for the most part Java games at retail were nowhere to be found. Why is this?

The first problem is pure reputation. If you ask 90% of game developers out there what they think of Java and they will give you one of two responses. Either they think it is a mobile only platform, or they think it is only good for "web games". Java is great on mobile devices, and it continues to be the dominant development platform. For the web games reputation, Java was actually a victim of its success. The emergence of Java created the web games market. With Java available in every web browser, game developers were quick to build games with this new platform. Unfortunately, the Java platform developed for was the Microsoft Java platform. When the trouble started with that situation, the Java platform for web development stalled. The developers had to program to the lowest common denominator, which was the Microsoft JVM. This was very early in the life of Java, so only simple games were possible. Why don't they just bundle the latest JRE? (You might ask) Well, it's not very practical to bundle a multimegabyte runtime environment with a game which is only a few hundred K in size. Therefore, Java became known for what it could do in the web games space, which was truly primitive.

So, let's pretend that we get past the web games reputation. The next myth is that Java is slow. Obviously, since it is an interpreted platform, it can't be anywhere as fast as native code. For some reason, these folks have never heard of Just In Time (JIT) compilers. I can understand that. This is an industry that prides itself on instruction counting, so relying on a JIT compiler may seem like voodoo. The fact is that JIT compilers now produce code that is just as fast as native compilers. And, in some cases the code is faster. JIT compilers can analyze runtime patterns and adjust compilations. Native compilers can't do that. We can also thank the introduction of C# to help educate game developers. They still don't seem to trust JIT's, but at least they now accept their existance.

Now that our code is as fast as native code, there is no way that the Java platform has all the game development features - graphics, audio, input drivers, .... Two years ago, I might have conceded this one, but not now. With the technologies that we put out on java.net in the games community, you can now build state of the art games on the Java platform. We have Java bindings to OpenGL. But wait, isn't OpenGL slower than DirectX? After all, aren't most games written in DirectX. Yes they are, but there are some OpenGL games out there that disprove that myth - say like Doom 3. We have Java bindings to OpenAL. OpenAL is the most used cross platform audio api for games, and it is maintained by a small hardware audio company - Creative Labs. Finally we have an input device discovery and polling api - JInput. But what good is an input api without drivers? That is correct, but the implementation of JInput on Windows uses DirectInput. That means that any device you go out and buy at Fry's or Best Buy will plug right into your desktop and be available in Java.

Next up is Java on consoles. I concede this one. Java is not on the consoles. But, we are still working on that one, so don't give up hope yet.

Finally, there is the tools issue. Many tools do not support Java out of the box. In most cases you will need to write a loader for your favorite tool to get the content into Java. Although in some cases, I don't buy this argument. How many people do you hear asking if a tool exports to C. I know the argument is weak, and I somewhat concede this one as well. There is, however, a very interesting project that is getting good adoption. Collada provides a single file format for all content creation tools. Write a Collada loader for Java, and you have all your tool problems solved.

All of this is purely debate. A picture is worth a thousand words. Show me the money. Show don't tell (yes, I am a Rush fan). There are quite a few independent game developers creating some amazing games with the Java platform. Check out MegaCorps Online or Tribal Trouble or Wurm Online or jME or the stuff our friends at Immediate Mode Interactive create. Or, if you are in San Francisco in another week, come to GDC and check out the Sun booth. Say Hi, and I will show you what Java can do.

Comments

• To expand the definition a little, there is a growing interest in what is termed "serious games" for training and and teaching purposes. Java may well fit into this niche very well.

  Posted by: duanegran on February 25, 2005 at 10:03 PM

• Creative Labs is not a 'small hardware audio company'.

  They own 3DLabs, that drove the OpenGL Shading Language from start to finish.

  Posted by: rexguo on February 26, 2005 at 05:38 AM

• I know. That was a silly attempt at humor. We have worked with Creative/3D Labs on a number of projects. My point was that the largest maker of audio HW backs OpenAL.

  Posted by: yensid on February 26, 2005 at 07:04 AM

• A big factor is probably inertia.
  Remember that until very recently the gaming industry didn't even use C++ on any large scale and even now Assembler is a vital skill for many gamges developers.
  In part this is due to old hands not wanting to (or not having time to) learn new skills, and those old hands define the technology to be used on new projects. In part it's also the same as everywhere in IT and that's management not wanting to take risks and not wanting to spend money on evaluating and introducing new technology (let alone on training staff).
  As a result change is slow. Maybe someone brings Java into the office for some internal tools, and on the next project it's used for some more internal tools. The project after that it might turn up as the driver for the game's internal scripting engine, and often there it stops because of the mistaken perception that Java is slow and Java has no support for highend graphics, sound, and networking.

  Posted by: jwenting on February 28, 2005 at 04:43 AM

• I completely agree. That is a good sysnopsis of where the industry is today.

  Posted by: yensid on February 28, 2005 at 08:30 PM

• > Java is not on the consoles
  > But, we are still working on that one, so don't give up hope yet

  sounds interesting.. what steps are being taken?
  

  Posted by: asjf on March 01, 2005 at 08:11 AM

• (oops should have previewed..)

  > Java is not on the consoles.

  > But, we are still working on that one, so don

  sounds interesting, what steps are being taken?
  

  Posted by: asjf on March 01, 2005 at 08:12 AM

• If you want to develop for TiVO you use Java. That's not a game console per se, but there's nothing stopping you from writing a game that could run on a TiVO.

  Posted by: skovatch on March 01, 2005 at 09:22 AM

• It's not 100% java but its a step in the right direction.
  Chrome the game

  Posted by: franqueli on March 01, 2005 at 10:10 AM

• I know that the lack of precise timers stumped me while trying to write game code in 1.4, maybe relatively minor improvements like better timers in 5.0 will make the difference?

  Posted by: kj12345 on March 01, 2005 at 05:37 PM

• I really look forward to see Java desktop games. Chrome seems very nice, hopefully something like Warcraft III will come up soon.

  Posted by: denywuy on March 02, 2005 at 04:08 AM

This work is licensed under a Creative Commons License.