I recently had a hankering to play an older (not ancient) PC game that I
used to enjoy. Since I've moved my entire desktop over to Linux (for almost
a year ago now) that meant stealing my wife's Windows laptop and trying to
install the game on that. Two FDISKs and one Windows reinstall later the
laptop's HDD is still woefully short of a game, and I'm back at square one.
This isn't an isolated case there's a whole backlist of games that in
an occasional retro mood I've felt like having another go atSeven to the
point of attempting to get some of them working in various DOS/Windows
emulators on my Linux machine (with only limited success), because it's just
as much of a pain in the proverbial posterior to get them running on later
versions of Windows as on what the games were originally intended for.
I would even be tempted to dish out a few bucks to buy retro games, if I
could only be sure that they were actually going to run successfully.
How much easier would this process have been if some of these games had
been written in Java? The sad fact is a lot of them could have been
developed in our favorite language had Java 1.4 been available 35 years
ago. Assuming there wasn't a huge reliance on quirky native bindings, they
would probably be relatively easy to get running now. Alternative platforms
needn't be a huge issue either (also assuming that those native bindings
were available on your platform of choice).
All of this had us thinking at JDJ (yet again) about games development
in Java. Some might say it's flogging a dead horse; some would just wonder
why, despite the cross-platform and preservation of investment advantages
I've just mentioned. Which is the reason we've gathered together an eclectic
group of interested parties to discuss that very topic Java games
The players are:
Jason R Briggs: Java Developer's Journal contributing editor and your host; games player when he has time, games developer...on occasion.
Gerardo Dada: Metrowerks' product manager for CodeWarrior Wireless Studio.
Erik Duijs: Former musician/engineer/producer with a (games) programming
passion, now an IT consultant. Switched careers for the sake of better pay
as well as maintaining a passion for music instead of "eating it" so to
speak. Author of the Java Emulation Framework (JEF) and CottAGE.
Shawn Kendall: Developed Java and Java 3Dbased game technology demos for Full Sail, Sun Microsystems, and I.M.I., and displayed at GDC and SIGGRAPH
since 1999. He has five years of 3D technology teaching experience, and in
2002 founded Immediate Mode Interactive, LLC, a game technology company
dedicated to the development and application of Java technology in computer
Jeff Kesselman: Architect for game technologies, Advanced Software
Technologies Group at Sun. He worked on the JDK performance tuning team and
co-wrote Java Platform Performance: Strategies and Tactics.
Chris Melissinos: Sun's chief gaming officer and responsible for driving an industry-wide movement toward Java technologybased game development and
building infrastructure programs for massively connected game play.
Caspian Rychlik-Prince: An IT consultant in the UK who for the last 10 years has specialized in client/server systems with RDBMS back ends. Since the
contract market in the UK has all but dried up, he has shifted focus to
creating assets rather than doing a job, so he's writing a game now.
Doug Twilleager: Chief architect of the Java Games Initiative at Sun
Microsystems. One of the architects of Java 3D, he has also worked in the
graphics research group at Sun looking at advanced rendering techniques and
David Yazel: VP of software development of trading systems and portfolio
management systems at a leading financial investment company (by day), and
by night a games developer for (and founder of) the Magicosm project (a 100%
JDJ: C and C++ have the market (and mind) share in terms of games
development languages. Indeed, the mainstream games market has traditionally
been very reluctant to change development paradigms. What do you think needs
to happen to shift that mind share toward other languages/platforms, such as
Jeff K: It is important to remember that we were asking almost the exact
same question about C++ less than 10 years ago. And before that it was C
versus assembly code. More recently, scene-graph systems such as RenderWare
were fighting the same perception/adoption battle.
In the end, nothing succeeds like success. A hit game ships in pure Java
and it will put all the nay-saying to rest. To get there though there are
many things that can help. Outreach and education are two of them. Our
industry runs to a large degree on "common knowledge." Insofar as it's wrong
(e.g., "Java is slow"), we can educate and help change perceptions. Part of
this is explaining why these preconceptions are wrong; the other part is
proving the point with working demos. We can also explain the perceived and
less-known advantages. Portability is the one everyone usually thinks of,
but there are perhaps even stronger advantages in the areas of productivity
Finally, we need to unsell some of the oversold aspects of Java
portability being a good one, in my opinion. One-hundred percent portability
is not only unlikely but in most cases undesirable for games that should
ultimately be tuned for each platform. I personally think 85% portability is
a more sensible and reachable goal.
Doug T: One of the biggest obstacles that desktop Java faces right now is the ability to access the latest game technologies in a standard way. There
are lots of community supported solutions for things like 3D, audio, and
input device support. However, until there is a widespread standard
available across multiple platforms, developing desktop clients will be
painful. These standards don't need to come from the Java Community Process;
de facto standards work just as well. There are, of course, other game areas
where Java is gaining acceptance. An example of this is mobile device games.
Gerardo D: From my perspective there are three things that must happen to change mind shares toward Java. One is performance game developers are all
about optimization: getting one more frame per second allows them to add
more details and textures, more calculations to the physics involved, and
more realism and improve the overall game experience. Java is still
perceived as slower than compiled C/C++. Perceived is the key word here
there are AOT compilers for Java and DAC technologies that reduce the
performance hit of having a virtual machine. If you ask game developers who
develop games for wireless devices, a J2ME game usually performs faster than
a C++ version of the same game running on BREW.
Number two is access to low-level stuff. With C++ you don't have to wait
two years for a JSR and an implementation to use a low-level function.
Console manufacturers try to differentiate and add new technologies for
developers (like vectorization) that would be hard to use from Java.
Developers want to use maximum performance and all the features of a console
or a PC. An option would be JNI.
Three is industry support outreach and education like Jeff mentions,
but also things such as middleware technology. As games become more complex
and platforms have higher performance, developers rely on third-party
technologies such as Physics engines, AI, and human rendering.
I also agree with Jeff; once you have a success story a developer who
builds a great game and leverages the portability of Java to reduce the
investment and time-to-market to offer it in multiple platforms (PC, Mac,
PS2, etc.) then the industry will start paying attention.
Jeff K: Actually that is not strictly true of modern desktop VMs. About the only thing AOT compiling gives you in the desktop space is faster start-up.
AOT compilers by all tests I've seen are slower then JITs in an actual run,
or, if they manage to reach JIT speed, do so at the expense of a seriously
bloated footprint. To put it simply, this is because a JIT adjusts the code
generated at runtime according to the actual runtime environment (e.g.,
processor type) and how it's actually used (e.g., in-lining methods that are
"used" monomorphically whether they are provably defined that way or not).
I am specifically excluding J2ME here, because obviously in the tiny
memory and highly constrained environment of current cellphones you can't
effectively deploy a JIT solution, and here (and only here) I would agree
that an AOT compiler might make sense. However, this is a temporary
phenomenon as we are seeing cellphones quickly rise to PDA level and PDAs
quickly reaching the size of set-top or small desktop systems. It's
reasonable to assume this trend will continue for awhile at least.
Cas P: I have to be very careful answering these types of questions. Like a lot of engineers I have a binary world view, but I'll try to be reasonable.
The C/C++ market share is a product of many factors. The first and
foremost is inertia: all the people currently in the industry who are now
experts at what they do write in C++. The C crowd is actually dying away
because the advantages of C++ are difficult to ignore. But we all know that
once we get comfortable with something and good at using it we have a very
strong tendency to stick with what we know and that's actually very wise.
I suspect we will have to wait a long time for the veterans to gradually
leave the industry and take their own ways with them.
The second factor is higher education courses. A lot of people who
graduated from university in the past 10 years started out on something
useless like Modula-2 to learn programming and got into C++ as their courses
progressed. They left university with a working knowledge of C++ and were
very likely exposed to MSVC6. That gives you a huge pool of C++ programmers.
Nowadays, a lot (most?) of the C++ courses are being replaced with Java
and if not Java I understand Delphi is very popular (also for good reasons).
In the middle of the next decade a fresh-faced C++ programmer will be a
rarity, mark my words. However, it does mean that the vast majority of Java
programmers out there are really inexperienced and won't have very many
experienced Java programmers to learn from. This is the ascendency. As Jeff
alludes, it took 10 years for C++ to finally oust C. However, it would
probably be a true case of hype if we were to claim that Java's time is
right now it's not; it needs that 10 years. I think there may be a
correlation between 10 years and the length of time the average programmer
remains in the games industry. It's a generational thing. Right now I think
we're three years in: by 2010 the majority of games will probably be written
in Java, but only if certain things are done to Java to make it as flexible
(and indeed, as powerful) as C++.
Apart from waiting, the real disadvantages of Java would have to be
addressed before you see any significant shift in mind share occurring. I'll
stick my neck out here and say that the frequently quoted productivity
benefits of programming in Java are largely nullified when writing games
because of the horrendous amount of work involved in getting performance and
quality out of the finished product, right down to writing OpenGL wrappers
up through fooling around trying to fill structures in buffers without
direct language support, through avoiding the wrath of the garbage
collector. That's just one of the technical disadvantages. It also happens
to be a performance disadvantage in a particularly critical section of a
game loop, and that's going to be picked up on very early by anyone trying
to do something cutting edge.
Jeff K: I would classify this as "maturation" and a learning curve myself. In the maturation category is the OpenGL wrappers you mention. It's insane
that everyone currently feels a need to do this themselves. I'm convinced
standards would emerge under any condition, and the conditions are actually
looking good for this to happen fairly soon.
In terms of taming and controlling the GC, that's a matter of the
learning curve. As in any language, you develop habits in how you use it as
you come up to speed.
I actually think it's remarkable if Java's advantages in performance
even end up making the learning curve a net-zero cost. From what I know, it
would be the first time that was true for any new language or environment
and Java is both at once.
Cas P: Another disadvantage is dependency on the correct VM being installed on the target platform. If you were to find Java on the next PlayStation (so
help me, but if it has OpenGL on it too I'll be over the moon), you'll be
fine, of course, because it'll be guaranteed available. But for smaller
games, the VM overhead is too great to be a reasonable proposition. That
doesn't necessarily mean you can't use Java, but because of a curious
licensing restriction it does rather restrict what bits of Java you use.
This brings me to a remedy for that disadvantage the "J2GamingEdition"
which is almost but not quite what we have with the J2ME CDC profile. What
I'd really like to see in terms of licensing is that the Java 2 platform is
cleanly separated from the Java 2 runtime environment, with only java.lang
being necessary to run the JVM. This gives the developer the feeling of
being close to the metal, mean and lean. It's a crucial comfort factor in
programming games to know that you can solve any problems by yourself
through programming, not waiting. It's bad enough waiting for OpenGL drivers
that work and hoping there are no VM bugs without dicky implementations in
the java.* libraries causing a performance hit or bugs. It's particularly
important to stress how little of the standard Java libraries are actually
useful in games programming. One of the reasons Java is so productive in the
normal application space is that it has a rich set of easy-to-use features.
But use them in a game and you discover why they're easy to use: they're not
tuned; they're very inefficient in most unexpected ways. No doubt more on
this topic later.
Jeff K: Licenses aren't set in stone. With good enough reasons, corporations can change them (in point of fact, in one-off ways Sun already has). Still,
I agree 100% that one of the bigger barriers right now is the unfortunately
restrictive Java license terms and I'd personally like to see that change.
In terms of the standard Java libraries, here I would disagree. It's the
old 90/10 rule. Ninety percent of your work is done by 10% of your code. You
can afford to trade efficiency for speed of coding and correctness of
results in many places. (This is formalized in many games by creating a
"scripting" layer that in fact is dog-slow in raw speed terms.) Even where
you need to tune, premature optimization often creates more trouble than it
A classic example that gets worked over and over again is the Java
collection classes and the ways they create garbage. When I use collections
I never specify specific types (e.g., ArrayList). All my variables are of
Interface types (e.g., list). This allows me to easily tune on two levels.
If I find a linked list is really more appropriate by the time I'm done, I
can change it by simply changing the type after the new one. But if I find
none of the supplied implementations work the way I need, I can in fact
write my own special case implementation at that time.
I would argue that this all still results in major time savings over
guessing at the beginning of my coding what the ideal data structures would
be, and then either living with a bad guess or doing major code rework.
Finally, I personally think too much emphasis is placed on the high-level
Java features when talking about coding efficiency. There are more
fundamental ways in which Java promotes proper code and accelerates its
development. Most of these can be classified under one key Java design goal:
wrong code should fail early.
There are whole classes of C/C++ errors that just won't compile in Java
(e.g., using uninitialized variables). There are many other common ones that
will throw an exception right away in Java, whereas in C they hide till late
in development or worse get out into the field (e.g., null pointer access,
array overrun/underrun, etc.).While I agree that a lot of the Java libs
aren't useful for games, I think the problem is that they aren't designed
for what we do and thus provide functionality that isn't useful. (Anyone
writing a game client that uses SQL?) But I don't think it's as big a hit on
the Java productivity story as some folks might first assume.
Cas P: For sure, and this is its best feature. Currently though I'm finding some classes of error difficult to deal with, like bunging data in the wrong
place in a DirectByteBuffer because of a language hindrance. It's swings and
roundabouts, but more swings in general, and that's a good thing.
A side effect of this is that the IDEs in Java are of absolutely
stunning quality. By last year, every Java IDE out there had surpassed the
incumbent C++ IDEs in terms of functionality and ease-of-use. Eclipse is
taking on MSVC head on and winning by a long shot. This is a great thing;
for years the de-facto hard-core Windows development tool was MSVC, and the
other C compilers were for eccentrics and specialists. We have a situation
here in which there are at least five different major IDEs, and because they
all produce identical code, there is absolutely no reason why a team
couldn't use all of them to write a game. I've always found it rather like
giving a bunch of artists a set of paintings to create and then saying they
all have to use the same sized brush and the same three paints.
But the end result is the same it's a big, big chink in the Windows
monopoly's armor. M$ doesn't really have a chance to compete any more, and
this is quite remarkable.
Back on topic for a moment, start-up time is another issue for Java.
It's actually quite acceptable in the client VM, but performance is very
disappointing. Start-up time in the server VM is terrible, but performance
is the equal of C++ in many areas (it's currently still much worse, 50% at
best, at floating point and memory access though and that's unfortunately
really where it counts in games right now). Again, "J2GE" could do with a
hybrid VM reference implementation that perhaps did a two-phase compilation.
These ideas have been talked about for at least two years now but we come to
another stumbling block: Sun doesn't have the resources and certainly
doesn't have the will to make it happen.
Jeff K: Maybe I'm an old fogey but start-up time still seems pretty fast to this kid who grew up with a C64. I do agree, however, that it's unfortunate
that nothing can be done during the load-up. If it were my commercial game
I'd probably write a machine-specific bumper that has a splash-screen and
some animation up on screen, then starts the VM.
Also, as an aside, Apple's been doing interesting things with start-up
time in their version of Hotspot.
Erik D: I think execution speed is a very overrated argument for using C++. As game projects grow more complex, the language should keep up in order to
minimize production costs. I notice that it's getting increasingly likely
that when you buy a game, it's going to be more buggy than the previous game
you bought. This is directly related to the problems C++ has in terms of
production costs; problems that Java can help address. The few frames per
sec you might lose with Java is not really important. I think Java's speed
is acceptable and getting better. GC issues are there, but Unreal also has
GC, which is sometimes clearly visible and nobody complains. Of course, this
doesn't mean it shouldn't be addressed, but I don't feel it's a valid
argument against using Java.
Most of all, right now we need some kind of Carmack that proves this
point to a broad audience in a Wolfenstein3D/Doom kind of way. I feel that's
much more important than solving technical issues, which I believe we can
already work around.
Shawn K: Shifting mind share is simple. It is not a technology question. It is a "proof (for developers) and money (for publishers/managers)" question.
All that's needed is one big, high profile hit. That's all. Many developers
scoffed at RenderWare in the beginning, but when huge hits like Tony Hawk 3
and GTA3 (Grand Theft Auto III) were released, they really put it on the
Now, how to make a hit with Java? That's an entirely different question.
As a quick high-level answer I'll say it will take all the things that are
needed to make a game a hit regardless of language, as well as significant
(read $$$) changes to Java for consoles, in addition to some serious support
I was at the Digital Media Alliance of Florida meeting recently, here in
Orlando. The panel discussion had a lot to say about independent developers,
a place where game developers are willing to take risks on game design and
game techS Even though one of the represented companies there was an
independent, the general consensus was that indie development is going away
unless some kind of big indie festival with contract awards is created,
because publishers will not/cannot afford to back experimental games and
experimental tech. It's that simple. The industry is more hit driven than
ever due to the fact that more people than ever have multiple consoles, and
the majority of players are only buying AAA titles now.
The buying characteristics have changed from the one console days.
Players would buy an average of 56 games a year, and 12 of those would be
second-tier indie-type games. Now, you can buy all 56 as AAA titles because
you get big games but on different platforms. Publishers know this and are
shying away even more from small production, indie-type projects. Add to
that the much higher cost of developing current 3D games as compared to the
2D world of the past, and the risky indie market gets squeezed to a speck.
This discussion on Java games will continue in the next issue of JDJ.