Doug Twilleager's Blog

February 2005 Archives

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.

Back to Blogging

I must appologize for not blogging over here more often. I have been posting fairly regularly now over at blogs.sun.com, but I need to get into the habit of going back and forth. A lot has been going on around here, and I will get to that later today. I will start by reposting something I posted over thare last week. As usual, the community is amazing, so thanks for being so patient.

This week Sony, IBM, and Toshiba released more details about the cell technology that they have been working on for the last 3 years. One of the first devices to utilize this new technology will be the Playstation 3. The rumbling started last year when developers started to get the specs on the next generation game consoles. They would be CMT, or Chip Multi Threading, machines.

So, why is this such a big thing? Multiple CPU machines have been around for many many years. Visualization systems have been using multiple thread systems to power their visualizations ever since the technology was available. But when the specs for next generation consoles were given to game developers, they hated it. The industry is very change adverse. They know how to make single threaded games that squeeze out every ounce of performance, and they would be perfectly happy if physics would allow clock rates to climb to infinity. Unfortunately, that is not the case, so things are changing.

It is not as though the industry doesn't have experience with multithreaded environments. The Playstation 2 has multiple processing units. The difference is that each processing unit on the PS2 has a very specific function. Although, there are some threading quirks that have made many a PS2 developer bang their head against the wall. Most of the problem of harnessing the power of the next generation machines will revolve around rearchitecting their simulations.

If you look at the general flow of a common game engine, it follows roughly the same path - gather input, process each world entity (responding to physics and collision), decide what is visible, sort it, and then render. By doing this in a single threaded environment, you have a closed set finite state machine where ambiguities can be resolved with simple tie breaking rules. Once you make multiple processing units available, things get trickier. In big visualizations systems, there are usually many screens to render to, and therefore, some processing can be divided among screens. That doesn't work in single screen environments. Trying to have multiple processing units feeding a single graphics device can cause graphics context thrashing. Although it is worth noting that many graphics cards do divide up the single screen and parallelize the work for performance. Other techniques are needed to utilize the processors.

If mutiple rendering processors is not the answer, then we need to look at the other systems. I don't want this to turn into a debate on engine design, so I will simple give a few examples to illustrate the possibilities. Input systems have a possibility for multiplayer input, but often these functions are handled by the hardware anyways. Processing each world entity in parallel has a lot of possibility, but it does require the finite state machine to become not quite a closed set. Imagine one entity making a decision based upon another entity which is about to change state in parallel. It definitely causes the equation to go from finite to becoming valid within a given range. Deciding what is visible is another massively parallel activity. The complexity of worlds could become much greater if we started to utilize some parallel occlusion culling methods. Sorting could be parallelized to a certain extent as well. As we can see, there are many ways to divide the simulation into many parallel components. If you look at what we did with Java 3D, you can see some of these methods implemented.

No matter what the PS3 turns out to be - because there still seems to be lots of missing data - it will be a machine that has more than just a few processing cores. This will be the case of all client machines in the not too distant future, so the industry will have to adapt. Most likely there will be three responses. Some people will not adapt, giving us games that only look incrementally better than the current generation. Some people will retire. And some people will step up to the challenge, harness the true power of these machines, and blow us away with the games that they create. I can't wait.

P.S. Did I mention that Java would be the perfect platform to harness the power of these machines. Oh well, that is a different topic.

This work is licensed under a Creative Commons License.