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.
Posted at 08:18PM Feb 25, 2005 by dtwilleager in General | Comments[8]
Java For CMT Clients
Last week, at the end of my entry in CMT for games, I made the assertion that Java would be the perfect platform for the upcoming explosion of CMT enabled client devices - next generation game consoles being the most obvious. In this entry I will expand upon that statement and explain why I believe this to be true.
The games industry is deeply entrenched in using native environments, C and C++, to build their client technologies today. One principle that I truly believe in is inertia. For someone to change what they are doing, there needs to be sufficient inertia - or value - in the change. So, for game developers to change from native environments to Java, we need to show the value.
The benefits of Java to the game development community is not necessarily the same than that of traditional developers. Let's take, for example, the most talked about value of Java - cross platform. This is a great value in markets where the number of devices to support is great - like the cell phone market. The traditional game development market has now consolidated down to four basic platforms - Playstation 2, XBox, GameCube, and PC. Most game developers have figured out how to do cross platform development using native environments on these platforms. This makes cross platform on current devices not a huge benefit. In some cases, however, things diverge dramatically on these devices - like threading models and co-processors. Since Java is a multithreaded platform from the ground up, it naturally maps to all kinds of threaded devices, and therefore could provide a new level of cross platform consistency to these new devices. So, even though cross platform is a minor feature today, in next generation consoles, this will be a big win.
In current consoles, the support for operating systems is quite limited. Much of this is due to the limited memory available to the devices. When CMT enters the picture, a robust but compact operating environment will be required to manage all of the resources. Java has proven that it can manage massively threaded environments. There will need to be specialized thread schedulers tuned for each platform, but that should be done by the platform provider when putting Java on the device - not left as an exercise to the game developer.
I believe that not nearly enough attention is given to the ability of Java and its dynamic compilers to adapt to the workloads being presented. This is a great asset of the system and could be exploited to maximum benefit on CMT client machines. For example, some information about the cell processor for the Playstation 3 indicates that different cores will be better suited for different tasks. The combination of an optimized just in time compiler and thread scheduler could ensure that every task in the game workload could be optimally compiled and scheduled based upon the characteristics of the device.
Another area that Java could benefit these platforms in is what I call "managing complexity". Time and time again I here developers telling me that there is no way that they could have implemented their complicated simulations without using Java. Next generation games will be far more complex than the ones we have today. Input systems, physics systems, collision systems, behavior systems, effects systems, animation systems, and rendering systems all cleanly interacting with each other at 30-60 frames per second. The Java platform has proven that it can be used to build large systems that interact with each other in complex ways - like big enterprise apps. Next generation game developers will need platforms like these to get these systems done.
Another touchy-feely attribute of the Java platform that can greatly advantage game developers is gains in productivity. There have been studies that have shown that programmer productivity is much higher with the Java platform compared to native platforms. There are a few reasons for this, some of which include strong typing, automatic garbage collection, and thanks to the business enterprise world, a extremely large selection of tools for Java development.
Hopefully this starts to give you an idea of all the benefits that the Java platform can bring to these new devices and game development. There are still a few topics that I have not covered yet, and I will do that next week when I continue this thread. Those will fall under the topic of many myths about developing games with the Java platform.
Posted at 05:32PM Feb 17, 2005 by dtwilleager in General | Comments[0]
JAI Has Launched Into Community Development
I have been getting a some requests to expand upon why Java is a great platform for programming CMT machines - as I alluded to in my last entry. I promise I will get to that next week. Today I want to talk about JAI.
Today we launched the JAI and imageio community development sites. This follows exactly what we did last year with Java 3D. If you look here, you will see some of th egreat work that is being done with JAI. The API is extremely solid, but we want to do a lot more with it.
The question that is always asked when we community develop something is whether or not we will still support it. Of course we will. The purpose of community developing a project is to increase focus on the project, not decrease focus. This allows developers using the API to become more productive and have more influence over the future direction of the API. We will still lead the project and build products from the community source base. We just won't be the only ones developing the code.
There is another great artifact of launching a community like this. With API's like JAI, the power of the API is directly related to the plug-ins that are available. Our hope is that the JAI community site will become the place where developers can deposit and share all of their wonderful JAI plug-ins. When you get to the core of why communities work, it is about sharing knowledge and technology. I truly hope this grows in the JAI community.
So, I strongly encourage you to check out JAI and all the things it has been used for - you might be surprised. Hopefully, it will inspire you to join the community and work with us to make it a better API.
Posted at 08:15AM Feb 11, 2005 by dtwilleager in General | Comments[0]
CMT for Games
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.
Posted at 07:28PM Feb 08, 2005 by dtwilleager in General | Comments[1]
More Men in Tights
If you go here you will see a list of the top upcoming mmorpg games for 2005. Do you notice anything? We are once again looking at another year of men in tights. It seems like all massively multiplayer online role playing games continue to follow the same formula. We get lots of fantasy characters slaying mythical monsters. There are a few games which branch out a bit. If you look at City of Heros and the upcoming Matrix Online, they are slightly different, but at their core, they are still appealing mostly to hardcore gamers.
At just about any industry discussion on the future of online games, the question becomes when will the mass market join the online games population. The answer is that they already have. Neopets is effectively a mmorpg. There are over 70 million registered users of that site. It has many of the elements that are found in a hardcore mmorpg. It just happens to appeal to kids. Toontown Online is another game that appeals to the mass market and has the same elements of a mmorpg. Imagine how popular that world would be if Disney put all of their marketing muscle behind it. And then there is my daughters favorite online pastime - The American Girl Club. This goes back to the real appeal of mmorpg games - social interaction.
The online game that successfully combines social gameplay, community building, and a mass market vehicle will be the one that sets new membership records. World of Warcraft recently boasted 200,000 simultaneous players. As I type this, there are 500,000 people playing at pogo.com, Yahoo Games, and MSN Games alone. There are plenty of people who want to play social community based games, they just don't want to play as men in tights.
There are two main reasons we don't see more variety in online games. The first is what I call the Hollywood effect. It is so much easier to take something that is proven and simply reskin it than come up with something new. That is why we saw so many sequels last year. Once in a while there are breakouts. The most obvious is The Sims, but now that is even being cloned to death. The second reason why we don't get innovative mmorpg's is that game designers are still building games that they want to play. How many game designers would enjoy Neopets. Game designers need to figure out how to build games that the mass market would want to play, which is probably not the game that they want to play.
I do have faith in the games industry. They are an incredibly smart bunch of folks. If you listen to any mmorpg designer talk about game design, it sounds like a class in sociology - not men in tights. Once they apply all that knowledge to more accessible properties, then we will finally see the mmcorpg - massive multiplayer casual online rpg.
Posted at 08:49PM Feb 03, 2005 by dtwilleager in General | Comments[0]
The Game Console Launch Dance
There is a very interesting dance going on right now in the games industry. I call it the console launch dance. The three major game console makers (Sony, Microsoft, and Nintendo) are expected to launch their next generation consoles over the next two years. It is rumored that Microsoft will be the first one out of the gate with its follow on to the Xbox. When Bill Gates was scheduled to give a keynote at CES in January, the whispers started - will it be revealed? No, it wasn't. The next logical venue is the game developers conference in March. But today, it was announced that it would not be revealed there either. The next venue is E3 in May. All three console makers have stated that they will reveal their next generation consoles in some form at E3. This is all a very elaborate marketting dance between all three companies. They will all say that they don't care about when the others launch, but they do.
But does it really matter when they do the public reveal? It completely depends upon what they think their biggest strengths are in their new products. I know for sure that all three companies are hard at work building amazing demos for their public launch. Most of the time these launches are months before the public can buy the new console, so most of the launch demos are examples of what the machine will be capable of - not what it does today. In some cases, like the Playstation 3, details about what people believe the processor to be (the Cell chip technology) was announced years ago. If a console maker wants to be known as the greatest tech box, then the launch event can set them up for that position. All of this won't matter. The only thing that will matter is the quality of the games when the public can buy the new consoles.
If you really think about these launch events, they are aimed at us games geeks. They are not aimed at the game developers. All game developers that have signed up to build games for these machines have a really good idea of what the machines can do already. In some cases, they have probably known for over a year. It takes that long, and then some, to build the games for these machines. No, the launch dance is purely for the benefit of us consumers. Like Pavlov's dog, we are being set up to salivate from the launch event until we place that pre-order months in advance (how many of you have the PSP on pre-order) or plan to camp out in line to buy one. It's all about the hype.
Don't get me wrong, the launch dance is fun to watch, and I can't wait to see what wonderful enclosures will house these machines of gaming. But at my heart, I am a techie, and therefore I am just as interested in the announcment that Nvidia will provide the graphics power of the Playstation 3. I will check out the launch events and start to salivate, but the games will really determine who dances best.
Posted at 08:41PM Feb 02, 2005 by dtwilleager in General | Comments[0]
Utility Computing for Games
Utility computing will be a hot topic today, so I thought I would write a little about the concept as it relates to online games. In theory, it is a wonderful concept. The idea of using utility computing to provide scalable resources to online games makes perfect sense. They have loads which can vary quite a bit, both from day to day as well as from launch to peak popularity to final end of life. Although, online games end of life is pretty painful - someone always wants to keep playing. Unfortunately, the economics of keepong one of these online games running is too high to support low game memberships.
Utility computing would also solve the unexpected load problems that seem to plague online games. World of Warcraft is the latest victim of its own success. It sold out at retail - over 600,000 copies, and hit a peak of 200,000+ players wanting to play all at once. Their servers crumbled, with as many as half of then down at one point. I don't know why they failed, but if it was due to lack of compute resources, utility computing seems like a good solution.
So, with this natural fit, why don't games use this compute model? There are two core reasons that it hasn't happened. They can be summerized as latency issues and the lack of middleware for online games. First, let's look at the easy one - latency.
Most online games are very latency sensitive. Some of the massive multiplayer online role playing games can handle some latency. Games like Everquest and Star Wars Galaxies will generate around 10 messages per second per player. These messages encode things like movement, object interaction, and combat sequences. The combat is usually turn based and victory is a result of your virtual character's abilities, and not your hand/eye twitch coordination. These games can handle a certain amount of latency. Action based online games, on the other hand, cannot. If I am shooting at another player, I need to know almost immediately whether or not I hit them. These games are generating more like 30 messages per second per player. Players who play these games know exactly what the latency, or ping time, they are currently experiencing. They will select a server to play on soley based upon their ping time because it gives them an advantage. In either case, current deployments of utility computing are not optimized for latency, so this becomes an issue. Once more localized compute centers become available, then this issue will be solved.
The harder problem that games have when it comes to utility computing is the composition of their back end infrastructure. Most online games have a custom infrastructure for each game. That infrastructure goes all the way down, and sometimes even includes the operating system as well. It is not uncommon for an online game to have its own custom linux kernal - yuck. Utility computing can support infrastructures like this, but it becomes very costly for the infrastructure providers. They have to dedicate hardware to a specific application, and have to provision it in a very specific manner. Current online games often do use hosting partners for their infrastructure, but it is custom infrastructure that cannot be shared among applications. This makes this style of utility computing not very cost effective for the utility provider. Using a faviorite analogy from Sun executives, imagine if you had to get special electricity to run the washing machine that you chose to purchase. It doesn't scale. The solution is to create middleware that is appropriate for the games industry.
Online game middleware allows for multiple games to share the same infrastructure. This dramatically changes the economics and the ability to dynamically respond to fluctuating workloads. It also allows for games that have much smaller memberships. An example that Chris often uses is cable. There are 500 channels of content on your cable. You may only watch 20 of them, but there is a viewership for every single one of those channels - no matter how small. If there wasn't, then the channel wouldn't exist. Games middleware would make "game channels" possible.
Middleware for online games is starting to emerge. And, more importantly, the games industry is starting to embrace it. In the mobile space you have solutions like Terraplay, Kayak Interactive, and Nokia/SNAP-Mobile. In the desktop/console space there are technologies like Butterfly.net and the Sun Game Server. Games are getting too complex to continue to write everything from scratch, so middleware is inevitable.
Sun is a huge believer in utility computing, and I think that it can create whole new opportunities for game developers and publishers. Once we solve the latency and middleware problems, we can move on to creating those 500 channels of game content.
Posted at 11:40AM Feb 01, 2005 by dtwilleager in General | Comments[1]