A few weeks have passed since the changing of the horses in Java Gaming community, and if I’d like to comment on the situation. This post originally started out as a response to a thread about Java Performance and how people perceive the language. After typing a few extraneous paragraphs, I’ve decided to move them here, in a vague attempt to be on topic.
Why are the flames from a group of misinformed prepubescent SlashDot users about performance relevant to the recent developments at Sun and JavaGaming org? In a world where games are give the development go-ahead based on how successful and accountable a team’s previous effort was, perception of those very angry young men is the reality in which Java must prove itself.
As a Java developer, I myself have shouted “Beware the Microbench!” along side my fellow developers. Like so many Shakespearen soothsayers, words are given little heed, and the slaying of Caesar plays out time and time again. We say Java is fast enough to do all but the most demanding of gaming tasks, but with little more than “macro benchmarks” to back our claims, we sound desperate with hollow words. Without a title to prove the point, yelling at the mountain of disbelief serves little purpose.
There is a paradox in producing Java based games. There was a joke in this month’s Gamasutra, there were so many sequels at E3 this year, the editor expected the show to be called E4. If only named development teams with established histories, using established titles are getting the publisher dollars, how is a new technology supposed to make inroads? This is a difficult question indeed. And so to offer constructive thoughts, I’ve made a few suggestions below. These are not directed solely at Sun’s newly formed Java Games Division, but also the community at large. It is a not a call to action but merely the ramblings of one man. Doubtless Jeff and Chris have heard these (from me) before, but I feel I’ve come up with a few possible suggestions to solve what I see are the major issues facing Java today.
Before I do this however, allow me to introduce myself. My name is John Carney, and I’m a Java developer (I certainly was at one point, current situation not withstanding). I worked for awhile at a company called Tower Technology, we produced our own JVM via a Java to C complier. Also for sometime, I ran a community event, in id Software’s Quake universe, called QuakeCon. I’m also a co-owner of the Online Gaming League, a challenge/league/tournament service, dedicated to serving a few hundred thousand gamers and a few dozen games. While none of this makes me an expert as to why an OpenGL method should be called gl.vertex() or glVertex(…), it does give me an excellent sense of why gamers pick the games they do, and why developers make the choices they do to appease those very hot headed slashdotters everyone seems so upset about. It also gives me an excellent view of how communities are built, and why some succeed were others fail.
To start, allow me to congratulate who ever came up with the idea that Dell installing Sun’s Java on their PC line was due to the success in the wireless market. If anyone starts playing any of the games available a Nokia cell phone on their PC, I’ll eat my Redhat issued Redhat.
Recapturing the Java advocates
Recapturing the Java advocates in existing development houses MUST be step number one. After the JSR-134 fiasco, I’m surprised the developers who stuck with things survived as long as they did. I suspect without the LWJGL, things would have been in a far worse shape, and Sun’s task would now be exponentially harder.
As quickly as possible, release all the work that was done on the JSR to the development community. However, don’t get caught up on the details, if a company is dragging their feet granting you a license to do so, bypass them. Drop their contribution from the new division. Make it clear you’re working forward from this point on, and if they want in, now is the time. Nobody cares what Gamespy does anyway. It is CRITICAL Sun lay all it’s cards on the table as soon as possible to keep the momentum of Java One going as along as possible. Reserverations that Sun will release a technology developed for the JSR is retarding Open Source projects from starting to help fill in the holes in the current technology.
Learn from failure of the JSR.
Leaders in the industry aren’t always the leaders forever. No more grandiose initiatives, no more sweeping promises of epic technology. The games division at Sun must be nimble, able to incorporate new technology, such as shaders, into the Java gaming libraries at rapid pace. Do not try to out Microsoft the DirectX team. Follow the Linux example of agile, on target need fulfillment. Use modular packaging, and class loading to your advantage.
Don’t try to eat the whole steak at once.
Convincing a development house to write a rendering engine in Java is a difficult proposition at best. While I applaud the effort to move away from Java3d , people who write rendering engines will be the last to think about a Java solution. Direct your efforts to where redundant effort is most obvious, at the game programmers and level designers. Writing a robust scripting engine is a tedious, difficult process. Typically they exist outside the game engine proper, providing a clear cut border for data transfer and coding duties. To this end, I would suggest integrating the JVM into either a licensed copy of the Quake3 engine or the GPL version of the Quake 2 engine, replacing the DLL invocation of game logic with game code written in Java. Using NIO, I bet this could achieve some very impressive results, while providing a real world example you could show to interested development houses.
Work to your strengths.
Java is best known as a networking, backend language right now. With nearly 70 MMOGs in active development or planning, Java would seem to be the answer to a great many of their issues. Pursing the MMOG might seem to be backwards, bypassing smaller scale server applications like Quake and Unreal network engines, but in actuality, it is not. Smaller scale applications like first person shooters with less than 64 players are tied heavily to the native client side code for things like PVS and collision detection. MMOGs do not do this, as it is computational cost prohibitive. This is one place where it will pay to look before you leap.
Build a class framework suitable of handling a few thousand connections from an existing native client application. Connecting a demo Ogre application to a scalable backend would be a remarkable demonstration. An application like Warbirds would be an ideal target, as the distinction between client side duties and server side tasks is very clear.
Throw away what doesn’t work.
Give up on Java3d completely as a game technology. This might have unofficially happened, but it needs to be said, loudly. It doesn’t work for game developers. Scene management is needlessly complex, while the collision model is nearly useless. While Java3d does an excellent job getting novice developers running quickly, it handcuffs them from standard development techniques. It is clear, however the lowered barrier to entry of Java3d struck chord. So, for my next point…
Keep what does work.
Java has allowed people to produce very complex applications with basic knowledge and nearly free tools. Java needs to continue this tradition by making standard functions of game development, such as scene rendering, network communcation, and input management approachable. Create as much example code as possible. Java.net is a great start, but take a look at the documentation section of the Unreal Technology engine. Write a reasonably complex 3d engine in Java new users can use as a replacement for Java3d. Not as a paradigm, but in practice. This has the added benefit of showing experienced developers how Java accomplishes standard development tasks. Not only does Java have to compete with C++, but it must compete with existing license technology. Publishers would rather pay for a licensed engine they know will work, and does what they need.
Find New Space to ROAM.
The latest rage in games is physics. At present, Havok and MathEngine are leading this add-on market place. They’re expensive, but add a huge advantage to companies that license the middlewar. Offering a built in, 100% Java physics engine would be a compelling feature indeed. As games grow more to a free-form polygon soup environment, Java versions of technologies like physics, dPVS or Jon Blow’s unified rendering LOD code would be a great thing to have as a downloadable resource.
I feel doing some of these things would greatly benefit the Java Game Development Community.
Respectfully,
John “EvilJohn” Carney
