Java SE 6
Java Games Development - Part 1
Java Games Development - Part 1
By: Jason R Briggs
Aug. 1, 2003 12:00 AM
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 development.
The players are:
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 games (www.imilabs.com).
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 programmable shading.
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% Java-based MMORPG).
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 Java?
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 and code-correctness.
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 solves.
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 map.
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 for J2SE.
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.
Reader Feedback: Page 1 of 1
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week