views:

4403

answers:

19

So I was just wondering, why aren't many video games (commercial 3D games, not random open source 2D ones) written in Java? In theory, it makes a lot of sense; you get a productivity boost and a cross-platform application for free (among other things, such as the vast amount of Java libraries, and built-in garbage collection -- although I admit I'm not sure if that's a good thing). So why is it never used? I can't think of a single semi-popular commercial game written for the Java platform.

Is it because of performance? Well, I've seen games written for the .NET platform, so why not Java? Also, most of the heavy lifting would be done by the GPU anyway, through OpenGL.

Any insight would be great, thanks.

+11  A: 

I think .NET had (has) a lot of the same perceived issues that Java has. Microsoft has just done a better job at marketing to developers with XNA :-)

Joel Martinez
XNA also makes it possible to deploy your .NET application to XBox. I haven't seen anything quite that smooth for Java.
StriplingWarrior
You can also deploy to the Zune as well.
cbeuker
+23  A: 

For one thing, Java's lack of operator overloading makes all of the math you have to deal with to get a working graphics pipeline very, very annoying and hard to read.

All of the matrix multiplication and affine vectors you need to deal with are a lot easier to follow if they're in well-formed mathematical expressions rather than object-oriented expressions like

product = vector.multiply(projectionMatrix).dotProduct(otherVector);

That's just terrible. Math shouldn't look like that.

Welbog
I remember back in '96 I think it was, some of the designers from Sun were giving a presentation on Java at Berkeley. William Kahan (http://en.wikipedia.org/wiki/William_Kahan) was giving them sh*t over this very issue. :)
JP Alioto
i think there is a good reason not to allow operator overloading in a language: to prevent people from using it. it is a powerful tool and very cool for maths, but is dangerous for everything else. lazy as coders are, they tend to missuse it for shortening down code, and the moment people start performing a map multiplying an iterable with a function, or even when all arithmetic ops are defined for functions, code readability is about to reach 0. and yes, i've spent considerable amounts of time porting code like that. :-Sit's a design choice. and design choices always tend to be disputable.
back2dos
Punish everyone else for a few bad apples? This is one reason I prefer C#. If I really need operator overloading it is there.
ChaosPandion
+3  A: 

.NET definitely has some of the same issues that Java has when it comes to intense 3D performance. Microsoft has also invested a lot more time and money in the development of the libraries when it comes to working with 3D heavy operations.

(...personally, I also think they had a leg up when it comes to the magic between DirectX and .NET)

Justin Niessner
+8  A: 
  • Are there any good ports of gaming engines/libraries?
  • Many C/C++ developers, particularly the ones on Windows (where most commercial games are written) are familiar with Visual Studio. There is no comparison in IDEs.
  • In general, Java has been sold to businesses because of it's solid typing and it has a perception of not having memory management issues.
  • And yes, Java still suffers from a perception that it is slow, and it's memory management is poor, and for games, it probably is ill-suited to the task. As stated in some of the other answers, garbage collection just isn't going to cut it when you are dealing with real-time high-performance requirements. Video games push CPUs and GPUs to their limits.
altCognito
+1 for the bold text. People don't seem to realize that when your game is running at 20 fps, it's often hardware bound at 20 fps. It really want to get to 30+ fps.. but it can't.
GuiSim
+1  A: 

I'd guess that speed is still the issue. Cross platform is going to be an issue isn't it since you don't know what 3d card is available when you write the code? Does java have anything to support auto discovery of 3d capabilities? And I'd guess that there are tools to ease porting a game between the wii, xbox, and ps3, but expensive I'll bet.

The ps3 has java, via the blue ray support. Check the bd-j site.

lumpynose
+5  A: 

A large reason is that video games require direct knowledge of the hardware underneath, often times, and there really is no great implementation for many architectures. It's the knowledge of the underlying hardware architecture that allows developers to squeeze every ounce of performance out of a gaming system. Why would you take the time to port Java to a gaming platform, and then write a game on top of that port when you could just write the game?

edit: this is to say that it's more than a "speed" or "don't have the right libraries" issue. Those two things go hand-in-hand with this, but it's more a matter of "how do I make a system like the cell b.e. run my java code? there aren't really any good java compilers that can manage the pipelines and vectors like i need.."

San Jacinto
+5  A: 

Performance issue is the first reason. When you see the kind of hyper optimized C++ code that are in the Quake engines ( http://www.codemaestro.com/reviews/9 ), you know they're not gonna waste their time with a virtual machine.

Sure there may be some .NET games (which ones ? I'm interested. Are there some really CPU/GPU-intensive ones ?), but I guess it's more because lot of people are experts in MS technologies and followed Microsoft when they launched their new technology.

Oh and cross-platform just isn't in the mind of video games companies. Linux is just around 1% of market, Mac OS a few % more. They definitely think it's not worth dumping Windows-only technologies and librairies such as DirectX.

Ksempac
"cross-platform just isn't in the mind of video games companies" -- That's why I fully respect the companies that do. :)
musicfreak
I'm definitely grateful to Carmack for being so committed to both cross-platform and open-source. I simply stated what most companies think.
Ksempac
That's true. You don't see a lot of popular video games ported to Linux. :(
musicfreak
Cross-platform is not just cross OS. Think of PS3, Xbox 360, Wii.
JulianR
"they're not gonna waste their time with a virtual machine." http://en.wikipedia.org/wiki/Quake_III_Arena#Virtual_machine, Carmack built his own for the game logic.
James McMahon
+5  A: 

One of the biggest reasons Java and other Virtual Machine languages are not used for games is due to Garbage Collection. The same thing goes for .NET. Garbage collection has come a long ways and works great in most types of applications. In order to do garbage collection though, you do need to pause and interrupt the application to collect the trash. This can cause periodic lag when collection happens.

Java has the same problem for realtime applications. When tasks must run at a specific time, it is hard to have an automated task such as garbage collection respect that.

It is not that Java is slow. It is that Java is not good at handling realtime tasks.

Chris Dail
You can, however, write your own scheduler for the garbage collector if you're going to go so far as to port Java to a new environment. The memory has to be reclaimed either way, and in a real-time environment, you could have the option of when to schedule your gc... best of both worlds.I have to go back to the point that there isn't much reason to port Java over to an architecture to do the things you want it to do when C/C++ already do those things for you. Java shines in other places.
San Jacinto
This is not the 1990s. Garbage collectors are pretty good now when tuned for low pause.
Tom Hawtin - tackline
+5  A: 

I'm playing the Sims 3, and I did some poking around. The graphics engine is C++, while the scripting and behavior engine is C#/Mono. So while C++ is there for time critical bits, other stuff like .interaction, game logic, AI is in an object oriented managed language.

John Simon
+1, interesting find.
musicfreak
and then for the Mac version, they shove the entire thing inside a modified Wine virtual machine. Still faster than it would be in straight Java I think :-)
Ben Gotow
Wine is not a virtual machine, it is a runtime library that mimics the behavior of the Windows runtime libraries. Hence the name (Wine Is Not an Emulator).
Nate C-K
This is very common in games, quite often logic that isn't time-critical is written in some sort of scripting language, commonly lua or python.
KSchmidt
It's not vanilla Mono, though. EA needed a special team working on their own custom CLR full-time to make it work.
Crashworks
+2  A: 

You can ask why web applications aren't written in C or C++, too. The power of Java lies in its network stack and object oriented design. Of course C and C++ have that, too. But on a lower abstraction. Thats nothing negative, but you don't want to reinvent the wheel every time, do you?

Java also has no direct hardware access, which means you are stuck with the API of any frameworks.

Markus Lux
Java can call native code through "JNI"
Bart van Heukelom
... and lose portability while you're at it!
LiraNuna
+50  A: 

I think John Carmack said it best with:

The biggest problem is that Java is really slow. On a pure cpu / memory / display / communications level, most modern cell phones should be considerably better gaming platforms than a Game Boy Advanced. With Java, on most phones you are left with about the CPU power of an original 4.77 mhz IBM PC, and lousy control over everything. [...snip...] Write-once-run-anywhere. Ha. Hahahahaha. We are only testing on four platforms right now, and not a single pair has the exact same quirks. All the commercial games are tweaked and compiled individually for each (often 100+) platform. Portability is not a justification for the awful performance.

(source)

Granted, he was talking about mobile platforms, but I've found similar problems with Java as a whole coming from a C++ background. I miss being able to allocate memory on the Stack/Heap on my own terms.

Marc
a source for your quote might be a good thing
matt b
+1 for the John Carmac reference. :)
musicfreak
Added the source.
musicfreak
Thanks for adding the source for me - I'll be more considerate in the future =)
Marc
That quote was from 2005. Both Java technology and Cellphone power has considerably improved since then. Comparing cellphone gaming vs PC gaming is comparing apples to oranges.
Chris Dail
John Carmack said it. Case closed.
GuiSim
I suppose I could have also added the quote from one of his QuakeCon speeches where he said that Java is a good way to make your game 10x slower, but I couldn't find a transcript to quote.
Marc
I concede to the fact that you can run graphics intensive code faster in C than you can in Java. However, 9 times out of 10, when people say Java is slow compared to C/C++, the project they're currently coding in C/C++ would have performed just fine had it been written in Java
Ross
That may be true for some applications, but we are talking about full 3d games here and aren't starting a flame war.
Marc
I just get uneasy when I read "Java is really slow". It's like saying a $50k sports car is slow compared to a $100k sports car. Sure, it's slower, but 90% of the time, the job it does is still great and at half the cost ;) No flame war intended. I agree that the above reasons are why Crysis and like-games are not written in Java.
Ross
It's all good. On the flip side, I can get just as (if not more) defensive when people start quoting those flawed/skewed java vs C benchmarks and claiming that the era of C/C++ is dead. Glad we could meet half-way =P
Marc
I'd say there's a rather large difference between an interpreted (presumably, the article seems to hint at it) J2ME and the JIT or statically compiled Java running on the Sun VM..
JulianR
@Chris Dail, this underscores the whole issue with Java performance. Has Java performance improved? No, cell phones just got faster. Games are supposed to push the limits of realism, and therefore push the limits of hardware, and throwing away %30-%40 of your performance before you've even written a line of code is unacceptable.
altCognito
+49  A: 

The game development world is a funny one: On one hand, they're often quick to accept new ideas, on the other hand, they're still in the stone age.

The truth is, there's rarely that much incentive in switching to .NET/Java/anything other than C/C++.

Most game companies license parts of the game engine from other companies. These parts are written in C++, and although you might have access to the source so you could port it, that takes a lot of effort (and of course, the license needs to allow it).

Also, a lot of legacy code already exists in C++. If code from previous projects can be reused (say, if you're writing a sequel), that counts even more in favor of sticking with the same language, instead of rewriting it in a new language (more so since you'll likely reintroduce a ton of bugs which you'll need to spend time ironing out.

Finally, it's rare for games to be written in 100% C++ anyway - a lot is done using scripting languages, whether they're custom or just integrating an existing languages (Lua being one of the more popular ones these days).

As far as garbage collection is concerned, that can be a bit of a problem. The problem is not so much that it exists, it's more how it works - the garbage collector MUST be non-blocking (or at least be guaranteed to only block very briefly), since it's simply unacceptable to have the game freeze for 10 seconds while it scans all the allocated memory to see what can be freed. I know Java tends to choke quite a bit in GC'ing when it's close to running out of memory (and for some games out there, it will).

You're also a bit more restricted in what you can do: you can't fully exploit the hardware due to the overhead of the runtime. Imagine Crysis being written in Java... even if that's the only visible difference, it just wouldn't be the same (I'm also pretty sure you'd need a Core i7 to run it.).

This doesn't mean these languages don't have their place in game development - and no, I'm not just referring to tool programming. For most games, you don't need that extra bit of performance you get from C++, including 3D games, and if you're writing it all from scratch, it can make perfect sense to use something like XNA - in fact, there's a good chance it will.

As far as commercial games are concerned - does RuneScape count? That may well be the most succesful Java game out there.

Michael Madsen
Well obviously you wouldn't run Crysis on the JVM; hell, if you coded that game in assembly language you'd still need a supercomputer to run it on full settings. But +1 for the excellent insight, thank you.
musicfreak
You can't compare Unreal Tournament 3 or Crysis with Runescape. If graphic quality is a concern, you need to stick with a low level language with as little overhead as possible. Of course, for Indy or games where graphics are not the main selling point, Java is an excellent alternative to C/C++.
GuiSim
@GuiSim: For most games, graphics quality is NOT a major selling point. There are only a handful of games I can think of that were created with graphics in mind (I'm thinking of Crysis, but Half-Life 2 as well, at the time). I don't think most game developers care that much about graphics, as long as they are "good enough" (aka on par with most other games).
musicfreak
Graphics really have very little to do with the language. Physics, AI, yes. Graphics, no.
JulianR
Funny you should mention Crysis... http://www.mobileshop.com/blog/mobile-phone-news/experience-the-graphical-brilliance-of-crysis-on-a-mobile-phone/
skaffman
@JulianR there can be a significant workload for preparing and maintaining a scene to be rendered efficiently, so the language and associated language overhead does matter for graphics.
KSchmidt
Michael, read about GC vs malloc runtime behaviour...
EricSchaefer
+4  A: 

Misconceptions about performance and poor JVM optimizations would be my guess. I say misconceptions about performance because there are some Java ports of C++ games that perform faster than their C++ counterparts (see Jake 2). The real problem, IMHO, is that many Java programmers aren't focused so much on bleeding edge performance as they are with ease of use and understandability/maintainability of code. On the C/C++ side of things you're essentially coding in a slightly higher level assembly language and its about as close to the hardware as you can get without writing in assembly or straight machine code.

illvm
+2  A: 
  1. Java is slow, most of the heavy lifting is not handled by the GPU. There's still animation, physics, and AI hitting the CPU, all of which are very time-consuming.

  2. Java doesn't exist on consoles, and consoles are a major target for commercial games. If you use Java on PC, you're eliminating your ability to port to consoles within reasonable time and budget.

  3. Many of the more experienced coders in the game industry have been using C and C++ long before Java became popular. The two points above may contribute to this, but I expect that many professional game coders just don't really know Java all that well.

  4. Someone else's point about middleware above was a good one, so I'm adding it to my answer. There's a lot of legacy code and middleware written specifically to link with C/C++, and last I checked Java doesn't have good interoperability. Using Java for most companies would involve throwing out a lot of code, much of which has been paid for in one way or another.

Dan Olson
+1  A: 

Runescape by Jagex is written in Java, the "video game" tag might not specifically apply it being an on-line game, but it does have a decent following.

Mark Schultheiss
Sorry, but this doesn't really answer my question at all.
musicfreak
But the blind statement of the question leads to the assumption that NO games are written in Java, just pointing out the successful case of where one is.
Mark Schultheiss
+5  A: 

Minor points first:

  • any productivity boost from Java is hypothetical. The syntax is almost identical to C++ so you're really just banking on savings from memory management and standard libraries. The libraries have little to offer games developers and memory management is a contentious issue due to garbage collection.

  • cross-platform "for free" is not as good as you think because few developers want to use OpenGL and several key platforms probably lack a good Java implementation or wrappers for their native libraries, whether for graphics, audio, networking, etc.

But mainly, the issue is backwards compatibility. Games developers moved to C++ from C and to C from assembly purely because the migration route was smooth. Each interoperates closely with the previous, and all their previous code was usable in the new language, often via a single compiler. Therefore migration was as slow or as fast as you liked. For example, some of our old headers in use today still have #ifdef WATCOMC in, and I don't think anybody has used the Watcom compiler here in a decade or more. There is a massive investment in old code and each bit is only replaced as needed. That process of replacing and upgrading bits and pieces from one game to the next is nowhere near as practical if you changed to a language that doesn't natively interoperate with your existing code. Yes, C++/Java interoperability is possible, but very impractical by comparison to simply writing "C with a bit of C++" or embedding asm blocks in C.

To properly supercede C++ as the game developers' language of choice, it must do one of two things:

  1. Be easily interoperable with existing legacy code, thus preserving investment and maintaining access to existing libraries and tools, OR
  2. Demonstrably show up-front enough of a productivity boost that the cost of rewriting all your own code (or reworking the interfaces into reusable components that can be used from that language) is more than covered.

Subjectively, I don't think Java meets either of those. A higher-level language might meet the 2nd, if someone is brave enough to be the pioneer. (EVE Online is probably the best example we have of Python being usable, but which uses a fork of the main Python language, many C++ components for performance, and even that is for a fairly undemanding game in modern terms.)

Kylotan
+1  A: 

Even games written on the .Net platform are often highly optimized for speed like direct access to memory and bus. .Net allows to use C / C++ and mix it with higher level languages such as C#.

Game development studios often work close together with hardware vendors, which do provide access to low level interfaces of their products. This is a world, where you have to use ASM and C for device communication. A virtual environment would slow down these program parts.

Anyway, modern 3D games in fact do use higher level languages. Often, you'll find the game logic written in languages like Lua or Python. But the core (I/O, threads, task scheduling) of the typical 3D game will be written in low level languages for the next 25 years or as long devices do not allow abstraction and virtualization by themself (which will come).

oeogijjowefi
+1  A: 

I agree with the other posts about leveraging elements of a preexisting/licensed codebase, performance, etc.

One thing I'd like to add is it's hard to pull nasty DRM tricks through a virtual machine.

Also I think there's a hubris component where project managers think they can make stable/reliable code with C++ with all the perks like having absolute control over their tools and resources, BUT without all the negatives that complicate and bog down their competition because "we're smarter than they are".

JP772
+1  A: 

Actually, it is very possible for managed code to do 3d games, the problem is the back engines. With .Net, for a brief period, there was a Managed DirectX wrapper to DirectX 9 by Microsoft. This was before the abstraction that is now XNA.

Being given total access to DirectX api's, .Net games work a treat. The best example I know of is www.entombed.co.uk, which is written in VB.Net.

Unfortunately, on the Java side, it is seriously lacking - mainly for the reason that DirectX isn't available for Java, and games programmers know and understand the DirectX api - why learn yet another api when you will be returning to DirectX?

Foz