Java might sound familiar if you're a fan of video games. Back in 2011, Minecraft was created using Java. Minecraft is one of the one of the best-selling video games of all time and one of the most popular games that run on Java.
Despite its fantastic use cases and widespread general use, Java remains somewhat obscure in game development today.
1. Robocode. It would be just rude not to start this list with Robocode, as this is probably the most famous Java-based coding game of all times. Initially launched back in 2000, Robocode is an open source game where the player has to develop a robot battle tank to battle against other tanks, while coding in Java or .
Java is more versatile and supports more advanced functionality for mobile games, without adding much difficulty. It's still a very beginner-friendly language, and the learning curve is much smaller than the C-based languages (C# and C++). It's worth trying out Java to see if it's a good fit.
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.
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.
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.
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 :-)
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:
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.)
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With