Why are only a few video games written in Java? [closed]

Answer 1

• 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.

Answer 2

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.

Answer 3

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.

Answer 4

It was talked about it a lot already, u can find even on Wiki the reasons...

• C/C++ for the game engine and all intensive stuff.
• Lua or Python for scripting in the game.
• Java - very-very bad performance, big memory usage + it's not available on Game Consoles(It is used for some very simple games(Yes, Runescape counts in here, it's not Battlefield or Crysis or what else is there) just because there are a lot of programmers that know this programming language).
• C# - big memory usage(It is used for some very simple games just because there are pretty much programmers that know this programming language).

And I hear more and more Java programmers that try to convince people that Java is not slow, it is not slow for drawing a widget on the screen and drawing some ASCII characters on the widget, to receive and send data through network(And it is recommended to use it in this cases(network data manipulation) instead of C/C++)... But it is damn slow when it comes to serious stuff like math calculations, memory allocation/manipulation and a lot of this good stuff.

I remember an article on MIT site where they show what C/C++ can do if u use the language and compiler features: A matrix multiplier(2 matrices), 1 implementation in Java and 1 implementation in C/C++, with C/C++ features and appropriate compiler optimisations activated, the C/C++ implementation was ~296 260 times faster than the Java implementation.

I hope you understand now why people use C/C++ instead of Java in games, imagine Crysis in Java, there would not be any computer in this world which could handle that... + Garbage collection works ok for Widgets which just destroyed an image but it's still cached in there and needs to be cleaned but not for games, for sure, u will have even more lags on every garbage collection activation.

Edit: Because somebody asked for the article, here, I searched in the web archive to get that, I hope you are satisfied...MIT Case Study

And to add, no, Java for gaming is still an awful idea. Just a few days ago a big company that I will not name started rewriting their game client from Java to C++ because a very simple game(In terms of Graphics) was lagging and heating i7 Laptops with powerful nVidia GT 5xx and 6xx generation video cards(not only nVidia, the point here is that this powerful cards that can handle on Max settings most of the new games and can't handle this game) and the memory consumption was ~2.5 - 2.6 GB Ram. For such simple graphics it needs a beast of a machine.

Answer 5

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.)

Answer 6

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.