86

I'm not a game developer or anything, but I know that Java is not very widely used for game development. Java should be fast enough for most games, so where's the catch? I can think of some reasons:

  • Lack of game developers with expertice in Java
  • Lack of good game development frameworks
  • Programmers don't want to accept Java as a games programming language. Most only accept C++ as that?
  • No support for game consoles (though the PC market still exists)

It could of course be something else. Could someone who knows the business better than me explain why Java isn't getting momentum when it comes to game development?

Anto
  • 11,157
  • 13
  • 67
  • 103
  • 42
    And now wait for all of the "Java is slow, C++ is fast" answers that really only touch the surface of the issue in an overly broad and completely correct way. Be aware that people answering this way are almost certainly not professional game developers. – Ed S. Mar 05 '11 at 19:53
  • 24
    In fact, Java _is_ used for game development; i.e. in the mobile market. Java ME, Android. – user281377 Mar 05 '11 at 20:14
  • Meant to say "*not* completely correct way" above =D – Ed S. Mar 05 '11 at 20:32
  • 23
    Why should it be used? What does Java offer a game developer, that the more widely used languages don't have? Java provides an enourmously rich ecosystems to business application developers, that outweighs its shortcomings as a language, but when it comes to game development, the Java platform offers little tools compared to a number of alternatives. – back2dos Mar 05 '11 at 22:56
  • http://gamedev.stackexchange.com/questions/3789/famous-games-written-in-java , http://www.java-gaming.org/index.php/topic,3123.msg192440.html – Peter Taylor Mar 05 '11 at 23:01
  • 14
    Interestingly, Minecraft is Java based. – Uri Mar 05 '11 at 23:03
  • As I noted below in comments, its more a matter of runtime access across platforms that inhibits managed/jvm based games from becoming more mainstream. Three completely seperate codebases makes little sense even if in isolation the managed/jvm code accomplishes as much, nearly as efficiently, and with far less hand crafted code. – JustinC Mar 06 '11 at 00:25
  • 3
    Java is HIGH LEVEL, c is LOW LEVEL. How can anyone possibly make this question more complicated?? It's just that simple. – Fattie Mar 06 '11 at 00:44
  • Ed S - I'm guessing you are **not** a "professional game developer"?! – Fattie Mar 06 '11 at 00:45
  • 1
    @Peter Taylor: I think even the fact, that there is a list of all successful Java games shows, how few there are. @Uri: What exactly is interesting about that? – back2dos Mar 06 '11 at 06:33
  • @back2dos, where did anyone say that it was an exhaustive list? – Peter Taylor Mar 06 '11 at 08:50
  • 2
    To whoever has down voted all of the posts that say that Java doesn't have the same performance as C/C++, last time I checked; Java uses a Stop-The-World garbage collector. This is fine for Business applications, but gamers *will* get annoyed if their game stops temporarily. – dan_waterworth Mar 06 '11 at 13:30
  • 3
    @Joe Blow: I think he guesses you're not that either – Anto Mar 06 '11 at 14:05
  • 1
    @dan_waterworth Garbage collection can be tuned for the application profile and collection pauses can be reduced (although, I am guessing few develops opt for or are even aware of tuning the GC). By default it is tuned for throughput and smallish allocations. Eg small server apps. – JustinC Mar 06 '11 at 16:54
  • 1
    [Magicka](http://www.magickagame.com/) is also written in C#. – Rei Miyasaka Nov 16 '11 at 18:02
  • To me Java adds very little value to game development. For performance code you want to be in control and not battling with garbage collector :o) C or C++ (if used sanely) just rule in this domain. For higher level game code you are usually better off with other offerings because of better C/C++ binding: UnrealScript, Lua, Python, etc. Otherwise Java would be quite usable in this domain (UnrealScript is actually quite Java-ish). – MaR Nov 28 '11 at 17:54
  • @JoeBlow: Why is it better to use a low-level language for game programming? Is that still true today? Maybe that's necessary if you are making NES cartridges, but not if you're targeting, say, and iPhone. (I don't know, but all discussion I see takes it as *clearly true*, without ever explaining why.) – Sean McMillan Nov 28 '11 at 21:38
  • 1
    Java is SLOW - http://www.computing.co.uk/ctg/news/2076322/-winner-google-language-tests Can we move on please? – Coder Apr 24 '12 at 07:48
  • 5
    @Coder Looks like the C++ code was heavily optimized, but the Java code was not. So it's an invalid comparison. – Izkata Apr 24 '12 at 15:39
  • One must distinguish between the language (Java) and the way (JVM) a program written in this language is executed by a computer. On the one hand programs written in Java can be compiled (by AOT compilers like Excelsior JET) and executed without the JVM. On the other hand the JVM can be used to execute programs written in languages other than Java, e.g. Groovy (which provides advanced features like operator overloading). – Eddie G. Dec 27 '12 at 21:45
  • 3
    People that say "Java is slow" are just co-signing an old blog while java was in its infancy. I'm already writing a 3D game in Java/JOGL and the performance is wonderful. To end the debate this is the ultimate decider today: "If you write crappy code, you get crappy performance." – SpicyWeenie Jan 16 '13 at 11:22
  • Bastion is partially implemented using MonoGame (that is, C#). That's how it runs on Linux, and it runs pretty well. If it can be done with C#/Mono, it probably can be done with Java, especially delegating low-level graphics stuff to the appropriate libraries. – Andres F. Feb 20 '13 at 23:45
  • @JoeBlow LOW-LEVEL actually works against the development of interesting and complex game logic. Low-level graphics do benefit from raw low-level performance, yes; that's why you delegate that to libraries (or implement that parts in C or C++). But game logic? Give me a high-level language, please! – Andres F. Feb 20 '13 at 23:46
  • Okay, I know the business **extremely* well, having been in it for 25 years. I also know Java in games *extremely* all having been Sun's Java Game technical evangelist. And you are dead, spot on. Most of the people "correcting" you are horribly misinformed. I'll post more on that in a full post. – user430788 Mar 24 '14 at 00:48
  • @Uri: So was the new Sim City and look how that turned out. – AndrewJacksonZA Apr 02 '14 at 12:24

13 Answers13

100

Several reasons:

  • In the old days, you needed "direct access" for performance and UI. This predates VM languages like Java and C#.
  • Most consoles (e.g., 360, PS3) do not have a JVM, so you cannot reuse code from the PC version. It is much easier to compile C++ code to support various devices.
  • Most mainstream game engines (e.g., Unreal) have C++ bindings. There are some Java connectors (e.g., for OpenGL) but nothing like it.
  • For PC gaming, DirectX doesn't really have strong Java support (if at all).
  • Web based games run in JavaScript or Flash. You could write them in Java though using things like GWT.
  • The iPhone runs an Objective-C variant.

Java is primarily used in Android games these days, simply because it's the primary language for that platform.

Aviv Cohn
  • 21,190
  • 31
  • 118
  • 178
Uri
  • 4,836
  • 1
  • 18
  • 23
  • 14
    +1 "Most consoles (e.g., 360, PS3) do not have a JVM, so you cannot reuse code from the PC version. It is much easier to compile C++ code to support various devices" If the device doesn't have the runtime, you won't see games developed based on that unavailable runtime. Xbox 360 and Windows phone have managed .Net runtimes, so game development using them is possible, and likely a growing trend. However, because the runtime isn't on the other major platforms (PS3, and to a much lesser extent, Wii), its hard to justify a completely seperate codebase. It really is not a performance issue at all. – JustinC Mar 06 '11 at 00:09
  • @JustinC: That's a good point. I haven't realized that the 360 had a .NET runtime, I thought that it predates the popularity of that platform. – Uri Mar 06 '11 at 03:25
  • 2
    It's called XNA, which is currently subset of the .Net 2.0 framework. There are some other interesting frameworks in the wild: MonoXNA, MonoTouch, and XnaTouch among others. – JustinC Mar 06 '11 at 04:46
  • 1
    A JVM for consoles can be included on the game disc. I don't see the problem there. –  Nov 28 '11 at 16:22
  • 7
    Predictability of performance is not possible with a JVM. – Klaim Nov 28 '11 at 21:52
  • 5
    Very good points. However, I'd add the fact that the GC can cause unpredictable pauses/load . If this isn't a problem for server apps, it is for a real time game. This is for instance visible in minecraft. – deadalnix Oct 11 '12 at 14:04
  • 1
    Best answer IMHO. One thing I'd like to add is that it's much harder to keep memory footprint low in Java than it is in C++. When there's a lot of data invovled, JVM just bloats. Coding your way out of that can be very hard. – MrFox Oct 11 '12 at 15:22
  • @WTP Technically: Yes, one could. Practically you'd have to port it to the platform, optimize it for the platform and and pay license fees (or deal with GPL) for being worth it Java would have to provide notable benefits. – johannes Oct 11 '12 at 16:54
  • Also, programming OpenGL in Java is a big pain. Java 3D is still full of errors and too complicated. M3G available on J2ME devices is a joke. Even on Android people go for C when implementing OpenGL games. – Sulthan Feb 21 '13 at 10:37
  • 2
    @Klaim It's also not possible with `malloc` or `new`, so if that's a concern you're going to implement pooling no matter what. Unrelated to that point, a big issue with Java is that it doesn't support value types, unlike C#. – Doval Oct 25 '16 at 21:24
  • 'Java is primarily used in Android games these days, simply because it's the primary language for that platform.' Well, this is not true. The most popular mobile game engines - Unity and Unreal are compiling down to C++. Most proprietary internal engines are also C++. There is no place for Java slowness in the gamedev it is just as plain simple as that. – GuardianX Mar 03 '21 at 13:31
85

Technical reasons:

  • Most of the best 3D game engines are written in C/C++. This is a big deal, since most game developers don't want to compromise on their 3D engine, but nor do they want to write one from scratch. Java has jMonkeyEngine which is open source and actually really good but it still can't yet compete with the Unreal Engine.
  • For some very rare situation, there are advantages in getting "close to the metal" in C or assembly language, specifically for access to special hardware features. This is not so important nowadays, but professional game developers still like to have the option.....
  • Java has a garbage collected, managed runtime. 99% of the time this is a huge advantage, it certainly makes coding easier and less error-prone and is one of the big reasons why Java is so popular. However it does cause an occasional latency issue for games as garbage collection cycles can cause noticeable pauses. This is getting to be less of an issue with the newer low-latency JVMs, but is still an issue for graphically intensive games where maintaining high FPS is critical.

Non-technical reasons:

  • Professional game development houses are heaviliy invested in C/C++ skills and technologies. This creates a huge amount of inertia.
  • The largely irrational perception that Java is slow. Possibly true in the 90s, definitely not true now - you can certainly write a profitable, commercial 3D game with Java (Runescape anyone? Or how about Minecraft? )
  • A pretty fair perception that Java is more focused on business applications and the web rather than gaming. This might change with the growth of Mobile and the need for more cross-platform development, but is certainly true at present.

Interestingly there are also some good reasons why game developers should consider Java:

  • Portability - as the number of target platforms proliferate, Java becomes more and more attractive with it's pretty much unparalleled ability to create genuinely cross-platform binaries
  • Library ecosystem - with the very important exception of 3D game engines, Java has the best range of libraries overall of any platform. Networking, sound, AI, image processing, key/value data stores, you name the topic and there's probably an open-source Java library for it.
  • Server side development - Java is a great langauge/platform for the server, and as more games incorporate massively multi-player elements the server side will become more and more important. Java on Linux looks pretty compelling here as a platform.
  • The JVM - is probably the best engineered VM execution environment in the World, with fantastic garbage collection, JIT compiler, concurrency support etc. It's only going to get better, and as game developers increaingly start to use dynamic languages within their games they will want the best possible runtime environment.
  • Other JVM languages - Java is a solid old workhorse, but the real innovation is happening with the new JVM langauges (Kotlin in particular). These languages get all the advantages of the Java/JVM platform, plus they are extremely powerful modern languages.
steventrouble
  • 111
  • 4
mikera
  • 20,617
  • 5
  • 75
  • 80
  • 19
    No, protability isn't better in Java in the video game world. Most console don't have a JVM. For portability reasons, C++ is prefered to java in video game world. – deadalnix Oct 11 '12 at 14:07
  • 5
    Why is library ecosystem a bonus for Java? Networking, sound, key-value pairs - that's not a thing; that's avilable everywhere nowadays. I would actually argue that AI and image processing is much easier done with C/C++ libraries (fann, OpenCV). – MrFox Mar 11 '13 at 18:50
  • 4
    More important than FPS, I would perhaps emphasize *consistent* frame rates. I can have my game running at 100FPS, but if some of those frames take half a second, that's just not going to do. Even if GC is fast, if it causes noticeable irregularities it's still a problem. (This speaks nothing to Java's performance in particular, just a general problem to keep in mind) – Gankro Mar 24 '14 at 04:12
  • RE: your points about the JVM & other languages - LuaJIT is arguably a much more portable and potentially faster jit VM. It even out performs both Java and C++ [in some cases](http://lambda-the-ultimate.org/node/3851). – Jess Telford May 16 '14 at 18:57
  • 2
    I wrote a first person shooter in Java and I have never had any trouble with the garbage collector even when I didn't use one with low latency. Anyway, when the memory isn't allocated on the Java heap, it's up to me to deal with it without the garbage collector and most of my memory footprint comes from the VBOs. In other terms, the garbage collection isn't a problem because it works when it's used for what it's designed for and it's not up to it to handle large objects on the GPU or on the native heap (!= Java heap). Don't blame an anvil for not being an efficient mean of brushing your teeth. – gouessej Aug 04 '17 at 11:22
  • 2
    @deadalnix The video game world isn't only composed of the consoles. – gouessej Aug 04 '17 at 11:26
37

Okay, theres a lot of misinformation in this thread.

I know the game business extremely well, having been in it for 25 years. I also know Java in games extremely well having been Sun's Java Game technical evangelist and lecturing Java performance programming expert.

In terms of computational speed, Java beats C++ in many scientific computing benchmarks today. You can write pathological code in either language that performs badly if you want to, but over-all, they are at par and have been for a long time.

In terms of memory usage, Java does have some over-head. HelloWorld is a 4K program in java. But that overhead is pretty meaningless in todays multi GB systems. Finally, Java does have more of a startup time. I would not recommend using Java for short run-time utilities like Unix command line commands. In those cases startup will dominate your performance. In a game however, its fairly insiginficant.

Properly written Java game code does not suffer GC pauses. Just like C/C++ code, it does require some active memory management but not to the level C/C++ does. As long as you keep your memory usage to either long lived objects (persist for an entire level or game) and very short lived objects (vectors and such, passed around and quickly destroyed after calculation) gc should not be a visible issue.

In terms of direct memory access, Java has had that for a LONG time; since Java 1.4 in the form of Native Direct Byte Buffers. Bit twiddling in Java can be slightly annoying due to the lack of unsigned integer types but the work rounds are all well known and not terribly onerous.

While its true Java has never had a Direct3D binding, thats because Java technologies strive for portability. It has TWO OpenGL bindings (JOGL and LWJGL) and OpenAL binding (JOAL) and a portable input binding (JInput) that binds under the hood to DirectInput on Windows, HID Manager on OSX, and a Linux binding (I forget which).

Its true that no complete game engines have featured Java the way, say Unity, has featured C# and that is a weakness in the independent space. On the other hand, there were two good Scenegraph level APIS that were totally platform portable across Windows, OSX and Linux. Both written by Josh Slack, the first was called JMonkey engine and the second Ardor3D.

The top poster is correct that the two biggest things that held Java back in game development were prejudice and portability. The latter was the biggest issue. Although you could write a Java game and ship it on Windows, OSX and Linux, there was never a console VM. This was due to total ineptitude in Sun middle management. The few of us working on Java in games actually had deals with Sony no less then 3 times to get a VM on a Playstation and all 3 times Sun middle management killed it.

While Sun flirted with client technologies, the fact of the matter is that Sun management never got consumer products. Thats why Java as a client language from Sun never succeeded in any form, and why it took Google and Dalvik (the Android java-like VM) to make Java a platform success anywhere.

And thats why I code games in C# today. Because Mono went where Sun management refused to.

user430788
  • 101
  • 2
  • 3
9

Java is great for business logic, servers, and platform independent code that has to run reliably. There are several factors why Java isn't often used in games:

  • bounds checking & other safety mechanisms (marginal performance difference these days)
  • having to convert between C++ data structures and Java data structures (can't just copy memory between buffers)
  • many of the books and tutorials follow the crowd so it is hard to find non-C++ game dev information
  • the core graphics libraries (DirectX and OpenGL) and many off-the-shelf engines are C/C++ based
  • many games try to run as fast as possible so they can add more visually appealing features

It is not easy to work with C++ libraries from bytecode languages like Java (writing a JNI layer) and .net (lots of marshalling/unmarshalling, api/structure attributes). So it adds quite a bit of work for little benefit.

A side note: some game servers use Java.

Similar post here: https://stackoverflow.com/questions/1034458/why-arent-video-games-written-in-java

Community
  • 1
Graeme Wicksted
  • 609
  • 4
  • 6
  • You don't have to write JNI yourself, just use JogAmp or any similar library. – gouessej Aug 04 '17 at 11:31
  • Good point. I have used JOGL and JMonkeyEngine in Java. More recenlty in I have used XNA/MonoGame to DirectX and OpenTK to OpenGL with nvorbis/naudio/openal in C#. And they work great for small to mid-size games especially when working with shaders. Big improvement to productivity over C++. Then your only *real* problem is the same as any GC-based language: preventing/mitigating the GC. It will stall your framerate periodically so you'll want fixed-size arrays, static allocations, or long-living buffers that can be tossed when gameplay is stalled (menus, loading, cinematics). – Graeme Wicksted Aug 04 '17 at 13:55
  • I've used JOGL since 2006 and I haven't had this kind of problem even on very low end hardware in desktop environment. The garbage collector isn't to blame because the biggest objects are often either in the GPU RAM or in the native heap (typically the direct NIO buffers), the former isn't managed by the "normal" garbage collection and the latter aren't directly managed by the "normal" garbage collection as it takes care of Java objects on the Java heap. It's up to the developer to release the memory allocated on the native heap efficiently. – gouessej Aug 05 '17 at 16:32
  • In my humble opinion, the problem rather comes from some "optimizations" imagined by programmers not in a Java mindset that prevent the garbage collector from doing its job. If you keep some strong references on some useless Java objects linked to some native resources, the garbage collector will never consider them reclaimable. Off-heap allocation can be useful in some cases but if you abuse of it, your long-living resources will stay in memory and you won't be able to create new objects. – gouessej Aug 05 '17 at 16:43
  • Some game programmers prefer allocating huge buffers at the beginning, slicing them at runtime and managing this memory by themselves but they'll probably do it worse that the operating system and then, Java will spend much time to free some space to create new objects. Avoiding memory leak isn't harder in Java and a more viable solution consists in tracking only the objects whose memory isn't allocated on the Java heap to release them at an appropriate time (during a pause, when switching from a level to another one, ...), it has nothing to do with the garbage collector. – gouessej Aug 05 '17 at 16:52
  • There are some libraries supporting stack allocation in Java as far as I know and I wrote a deallocation helper to "free" the direct NIO buffers: https://svn.code.sf.net/p/tuer/code/pre_beta/src/main/java/engine/misc/DeallocationHelper.java – gouessej Aug 05 '17 at 16:55
  • @gouessej you are correct that it is less optimal than the GC but the point of doing this was to disable common GC mark-and-sweep passes (even the newer concurrent ones) mainly because it is a processor intensive operation and that causes your pre-rasterization duration to change in such a way that the framerate dips. This wouldn't be so bad but it _tends_ to be somewhat predictable so you get "micro stuttering" which is most noticeable in FPS games and 3rd person 3D action games. Even world objects can cause these if you're allocating and freeing often enough. Just something to be aware of – Graeme Wicksted Aug 07 '17 at 15:27
  • When you don't use a garbage collector, you have to track all dynamically allocated objects which leads to much more opportunities of memory leak. Your tricks make sense with some other garbage collectors and maybe with Android Runtime / Dalvik but neither with the parallel GC nor with G1 which was designed to replace the Concurrent Mark Sweep Collector. G1 can respect stronger guarantees on the maximum duration of pauses, it's ready for production since Java 1.8 update 40. Java treats short-lived objects a lot better since its version 1.4, that's why even object pooling has become useless. – gouessej Aug 08 '17 at 13:48
  • Don't disable the GC entirely... just prevent collection impacting framerate. G1 >= CMS > 1.4 GC but G1 wasn't built for gaming scenarios. See their typical use-case: `6GB or larger, and stable and predictable pause time below 0.5 seconds` Neither of which your game should be allowing. Plus G1 uses more memory. As always, try it first and optimize if something goes wrong. GC might not impact your game. Simply run with `-verbosegc` and look for pauses >= a % of your frame rate (60fps = 16ms, 144fps = 7ms) so not much room for a pause (or even a CPU spike if the core count is low). – Graeme Wicksted Aug 09 '17 at 16:29
  • G1 doesn't need to make a stop-the-world pause in all cases other garbage collectors do and G1 is able to respect a specified maximum pause time a lot smaller than 0.5 seconds, that's why I find it suitable for gaming. Undead Arena and Jake 2 don't suffer of stuttering even on low end machines but I'll use -verbosegc, I'm curious to see the results. – gouessej Aug 11 '17 at 10:55
  • @gouessej it's still primarily a poorly written pipeline if pauses are occurring so it's very possible G1 is sufficient. GCs are just better at "hiding" the problem. Deterministic finalization of large buffers of objects in C++ would kill _every_ frame's performance but a GC can 'save up' some of that time -- expecting the program will flatten out to idle. GCs are also better at allocating and freeing large blocks of memory as well as memory defragmentation -- both being big problems in the C/C++ world. Funny that the two very different sides of the coin are solved in similar ways! – Graeme Wicksted Aug 11 '17 at 13:42
  • They are solved in similar ways because the GC helps to take care of objects whose "usefulness" is hard to determine but it's not a magic solution against memory leak. If a Java programmer keeps strong references on some objects, the GC won't help at all. It's almost the same if a C++ programmer not using a GC forgets to destroy some objects. The garbage collector is a small part of the solution. Using long-living buffers is an excellent solution when you're able to manage the memory very efficiently by yourself whereas using short-lived ones is better when your runtime manages it well enough. – gouessej Aug 13 '17 at 23:06
6

Java isn't fast enough for most game development. It's far slower than using C++/Assembly, which is the standard. It's the same reason more game development isn't done using C# or VB. Game developers need and plan every last clock cycle that they can get their hands on for things like physics calculations, AI logic, and environment interactions.

For simpler games, Java could be used quite effectively. If you want to create a Tetris clone or Bejeweled, or something else of that level of detail, then Java would work fine. But Java can't possibly create games like Halo, Medal of Honor, Command & Conquer, and so forth and make it playable. At least as it exists nowadays.

And the reasons you list in your question are valid as well. Except, I think, for the lack of game developers with Java expertise. Many games on phones and other portable devices are written in Java (including most Android games), and some of the games are quite excellent. So I think there is a decent, and growing, base of game developers with Java knowledge.

The thought is changing on the ability to use these higher level languages for some of the more advanced games. For instance, one of my favorite games, Auran's Train Simulator, is written with large portions in C#, and it works quite well. So the base is growing and will continue to evolve.

BBlake
  • 563
  • 2
  • 11
  • You are aware that Java bindings to OpenGL exists? –  Mar 05 '11 at 19:26
  • 17
    You leave out one of the most important points; the vast majority of the tools and API's one would use are written in C++ and rewriting them to work with Java or any other language would be a ton of work. Also, your generalization that *"[Java is] far slower than using C++/Assembly*" is too broad to be accurate. Assembly isn't used as often as you may think in PC games because a good compiler will likely generate more efficient code than you will writing assembler. Deterministic resource use and the ability to get right at the hardware is required however. – Ed S. Mar 05 '11 at 19:27
  • 1
    It is possible to write games with Java. [Jogl](http://java.net/projects/jogl/) bindings and [JMonkeyEngine](http://jmonkeyengine.com/) game engine do exist (I'm sure there are others). Don't forget the ever popular Java-based game Minecraft. – Graeme Wicksted Mar 05 '11 at 19:52
  • 1
    It's certainly possible to write a game in just about any language, the question is really one of practicality. – Ed S. Mar 05 '11 at 19:55
  • 1
    @Ed S. That is a good point. The majority of advanced games nowadays are built on existing toolsets and code, most of which are C++ based. So much of the problem is based in legacy as well. However, on speed, I have yet to see any app written in Java which ran faster with less CPU horsepower than an equivalent app written in C/C++. If you can point me to an example where this is not the case, I would certainly rethink that, but I have not found one. – BBlake Mar 05 '11 at 20:05
  • 15
    Someone really needs to create a better example of Java's capabilities than Minecraft. Until someone can create the equivalent of WoW or C&C or MOH or Starcraft in Java or C#, I will continue to hold to what I've said. – BBlake Mar 05 '11 at 20:10
  • 12
    "Assembly isn't used as often as you may think in PC games because a good compiler will likely generate more efficient code than you will writing assembler." That's another generalization. I have yet to see a compiler than can generate better IA32 machine language than an experienced IA32 assembly language programmer. Compilers generate code for an abstract machine that is mapped onto a target machine. An assembly language programmer takes full advantage of the underlying processor, including machine idioms. – bit-twiddler Mar 05 '11 at 22:21
  • 10
    Don't forget memory usage. Memory use is probably more important than speed. Java's not designed for direct memory control like C++ and the garbage collector means memory use is always significantly higher than C++ for the same task. – Matthew Read Mar 05 '11 at 22:25
  • 1
    @bit-twiddler: When you develop PC games you are not necessarily targeting one specific processor or architecture. In console games it is probably more common because you only have to target one platform and you can hand optimize your code, but if your game has to run across multiple platforms this becomes much more difficult. I'm not saying it doesn't happen, and you can certainly hand optimize bits of code to be more efficient on a given architecture, I am just saying that it's not as common as most people seem to think. – Ed S. Mar 05 '11 at 23:29
  • 4
    @Ed S., I have written a ton of assembly language in the thirty-plus years that I have been in this industry. If one examines any large piece of code that has hard real-time constraints, one will find substantial chunks of assembly language. With all hard real-time applications, one reaches a point where one has to resort to cycle counting in order to ensure that events are not lost. – bit-twiddler Mar 06 '11 at 00:31
  • Then I bow to you sir because you have more experience in the area than I do. I am basically repeating what I have heard in regards to this from a few devs that I know, but I don't have a lot of first hand experience. – Ed S. Mar 06 '11 at 00:41
  • 9
    This is not 1985. We have more than 640k of memory, better than 50 mghz processors, and more than 1.44 mbs of removable storage. Game developers challenge today isn't the same as it was 25 years ago. Go ahead and find an example of hand crafted x86/or ia64 code for a modern game. Certain myths are just plain wrong. The challenge is portability, and down level clients using relatively ancient operating environments. Least common denominator vs compelling imersion. – JustinC Mar 06 '11 at 01:49
  • 2
    I used to hear the "Java not fast enough" argument from the algorithmic trading industry, which used to prepare C++, and now you see more and more Java there. Something tells me that speed is no longer the issue. – Uri Mar 06 '11 at 03:26
  • What? Uri said: "and now you see more and more Java there [bot traders]" ... state where? Where do you "see that"? What company? – Fattie Mar 06 '11 at 15:38
  • 2
    I think it was very admirable that EdS said **"Then I bow to you sir because you have more experience in the area than I do"**. If only more people could show that sort of courtesy in internet discussions. Hat tip to EdS. – Fattie Mar 06 '11 at 15:38
  • 1
    @BBlake There's a MMO written in java, it's named Wurm Online. I think its a nice example of the potential. – Jorge M Mar 07 '11 at 10:38
  • Never heard of it. I will have to check it out. – BBlake Mar 07 '11 at 13:37
  • Some of the statements are not 100% accurate.**"But Java can't possibly create games like Halo, Medal of Honor, Command & Conquer, and so forth and make it playable."** for instance is certainly not true. – Ramhound Oct 11 '12 at 17:26
  • 1
    C++ is used because it's a middle ground. Java is too slow and assembly dev is too slow. Compilers are not better than humans... games in assembly are just too much effort. And java is slow. There would be faster programs if it was faster. Or maybe the eclipse devs just hate me and my cpu. – Millie Smith Mar 24 '14 at 02:51
  • @MillieSmith You can't measure the performance of Java just by judging Eclipse. – gouessej Aug 08 '17 at 13:34
5

Modern games are all about 3D graphics happening in special purpose hardware.

Even back in 2002, Jacob Marner found in his report "Evaluating Java for Game Development" that Java was quite usable for games, except for the most performance dependent parts, and due to the robustness of the language and the underlying JVM that it was cheaper to do it this way.

http://java.coe.psu.ac.th/FreeOnline/Evaluating%20Java%20for%20Game%20Development.pdf

It is my personal opinion that with the progress that has happened since, especially in 3D-graphics, and with the excellent bindings to OpenGL et al, that this disadvantage is much less pronounced these days.

Hence the problem must be elsewhere. A likely reason is the size of the Java runtime (which is much less an issue these days with multi-DVD games), and another the inertia of existing code. It is notoriously brittle to start working with native code in Java. A third reason is what the star developers doing the games are familiar with. A fourth is whether Java is at all available on the platform.

One thing is certain though - most games are moving into being scriptable instead of having it all burned in C code from the start, and you want the best runtime underneath your scripting language. These days this essentially means either the CLR or the JVM.

  • 1
    http://oddlabs.com/technology.php - "We have based our development on the combination of LWJGL and Java, which allows the game to run on any LWJGL supported platform without modifications and at a speed comparable to platform-dependent native code." –  Nov 28 '11 at 23:01
  • Jake2 outperformed Quake2 more than 10 years ago. We're no longer in 2002. – gouessej Aug 08 '17 at 13:33
4

Game developers like to be close to the metal and often will write their tight inner loops in assembly. Java doesn't offer the same level of possible performance, both in terms of consistent speed or memory use (running a JIT takes its toll).

dan_waterworth
  • 7,287
  • 2
  • 34
  • 45
4

I think the limiting factor for most people is the (lack of) availability of good game engines. To get very far, we need to look at why those aren't available.

I would look at that from the other direction for a moment. Developing a game engine (for example) is a lot of work. Who would benefit enough from developing one to invest the time and effort to do so?

Most of the obvious candidates for framework-like development in/for Java (e.g., IBM, Oracle) seem to have zero interest in games. The obvious candidates for game development (e.g., Id, EA) seem to have almost equally little interest in Java.

Nearly the only candidate I can think of that seems at all reasonable would be Google. The primary development language for the Android is Java, and encouraging game development for Android could provide a real advantage for the platform.

As far as I know, they haven't done so (yet?) though, which leaves some pretty severe limits for almost anybody else. Without little in the way of modern, high-performance game engines to use development on Java means quite a bit of extra work, with (what looks to me like) little prospect for producing a lot of benefit in return for that extra work.

Jerry Coffin
  • 44,385
  • 5
  • 89
  • 162
  • I think you've hit an important issue with the game engines - I think this is the biggest reason why Java hasn't caught up with C/C++. It's possible that open source may level the playing field a bit however - I've been very impressed with jMonkeyEngine (http://jmonkeyengine.com/). – mikera Nov 28 '11 at 00:50
  • and don't forget that game developers are extremely conservative overall (technically), and most of the large (influential) shops have existed for decades and are C(++)/ASM centric so aren't going to invest in Java development as it'd mean extensive investment of time, money, and other resources up-front when they've an entire C(++)/ASM architecture ready to roll. – jwenting Nov 28 '11 at 07:36
1

The question is on par to asking something in the lines of:

What is better to power your car, a boat engine or jet engine.

It comes down to scalability, bug avoidance, speed, memory signature, modularity and a whole host of things. The question should not be be about what is better as an industry standard, the question should be "what is better for me" as in what you know or how well you know it. If it does the job then it does the job, if you can actually sell the idea then it works and who knows you might even bend a few spoons.

Meh
  • 19
  • 1
0

Java wasn't made with game development in mind, Java was made to be a language "for the web".

As for game development, Sun didn't really support Java as a game development language as Microsoft backed C#.

I think the lack of compelling game development frameworks is what really killed Java in this aspect.

Mahmoud Hossam
  • 3,817
  • 2
  • 29
  • 41
  • 3
    But C++ wasn't made as a games language either, but as a systems programming language just like C. And Sun actually did make some effort on Java as a games language, I think they were cooperating with Sony to bring Java to the PS2 or something, but it never happened... – Anto Mar 05 '11 at 21:10
  • @Anto well, "it never happened", that's what matters in the end, C++ got a lot of support by people in the industry, that's what made it successful, Java is supposedly backed by a company, which should have made better support for graphics in the language, something that also never happened. – Mahmoud Hossam Mar 05 '11 at 23:28
  • The only correct answer here - and it was voted down! – Fattie Mar 06 '11 at 00:45
  • Anto, c/c++ was not a "systems programming" language. C is "the" low-level computer language. Only assembler is lower-level. This is why C is used for programming ... everything. Higher-level languages (perl, Java etc.) are fantastic, and they have their place too. – Fattie Mar 06 '11 at 00:47
  • @Anto C++ has been used for applications more than it has been used for systems programming – Mahmoud Hossam Mar 06 '11 at 13:51
  • 1
    @Phobia: But it was *designed* for systems programming. – Anto Mar 06 '11 at 13:55
  • @Anto According to wikipedia, it's a general-purpose programming language, and the article specifically states the following: **C++ continues to be used and is one of the preferred programming languages to develop professional applications.** – Mahmoud Hossam Mar 06 '11 at 14:07
  • @Phobia: The Wikipedia page on Java also has about the same kind of statements, about Java – Anto Mar 06 '11 at 14:13
  • @Anto Are you suggesting that Java isn't a general-purpose programming language? or that it isn't used for application development? – Mahmoud Hossam Mar 06 '11 at 14:30
  • 1
    @Phobia: I'm saying **that it *is* a general-purpose programming language**, just like C++. In your answer you say that Java wasn't designed as a game programming language, but you forget that C++ is not either designed as that. – Anto Mar 06 '11 at 14:41
  • it's a general-purpose programming language in the sense that you can write anything from scratch, but this isn't practical for the game development business, I've never heard of a person who single handedly written a modern game engine all by himself, this is what I meant by support for game development support – Mahmoud Hossam Mar 06 '11 at 14:44
  • Anto -- everything you say in your comment above is nonsensical: no offence. C was not developed "as a systems programming language". It is just bizarre to say that. If you weren't there at the time, read up on the history. Sure, it is used for systems development (but perhaps there will now be another marvellous SO question "Why isn't Java used to write driver and system code?!?!") but then, **it is used FOR EVERYTHING**, it's the basic worldwide everyday low-level programming language. (Actually is there even **another low-level language** than c?) – Fattie Mar 06 '11 at 15:46
  • 2
    @Joe Blow: From the Wikipedia page about C: "Although **C was designed for implementing system software**, it is also widely used for developing portable application software." I think that is pretty clear, isn't it? – Anto Mar 06 '11 at 16:56
  • 1
    @Joe “c/c++ was not a "systems programming" language” – This is something that you should take up with the inventor of C++ who has specifically called C++ a programming language “… with a bias towards systems programming”. Look it up: http://www2.research.att.com/~bs/C++.html, first effing sentence. – Konrad Rudolph Mar 06 '11 at 17:18
  • @Konrad This is my least favorite person in the programming world, and what he says doesn't change the fact that C++ is used in application programming more than system programming – Mahmoud Hossam Mar 06 '11 at 17:22
  • 2
    @Phobia I’m sorry about your personal preferences but they are completely irrelevant to the discussion. Furthermore, I don’t want to contest that nowadays C++ is used almost exclusively in application programming. This isn’t what this discussion was about. Your claim that Java was designed with web programming in mind. Well, C++ was designed with systems programming in mind. Says its designer. End of discussion. – Konrad Rudolph Mar 06 '11 at 17:33
  • @Phobia: I think he knows what he designed his language for. You claim it wasn't designed for systems programming, which it obviously was. – Anto Mar 06 '11 at 17:36
  • @Anto @Konrad I'm merely saying it's used more in application programming more than systems programming, in fact, I never said anything about its design, I'm talking about usage all day long. – Mahmoud Hossam Mar 06 '11 at 19:32
  • Minor correction, Java was not designed to be a system for the web. It was actually designed for embedded devices and interactive television. See http://www.oracle.com/technetwork/java/javase/overview/javahistory-index-198355.html – Kevin McCormick Nov 28 '11 at 17:59
  • @KevinMcCormick Java was designed to be able to execute programs retrieved through unsafe channels in a safe way. Almost all the benefits of the Java eco system can be traced back to this. –  Nov 28 '11 at 23:05
  • Good point, @Thorn – Kevin McCormick Nov 29 '11 at 15:57
-1

It's easier to glue C more directly to brand new unconventional hardware and drivers. The sooner and closer a game programmer can get to the hardware, the better they can outspec competing games. Later game programmers just stick with the same methodology and tools as those prior proven games.

For games where optimizing to the latest hardware is less important, such as casual cell phone games, using C in this way is less important than is Java's greater portability.

hotpaw2
  • 7,938
  • 4
  • 21
  • 47
-4

For some people reason has nothing to do with speed, libraries, or availability. It is simply because of the language itself. Some people simply do not like Java the language. Other people would rather use their favorite programming language instead of using Java to make games.

Echo says Reinstate Monica
  • 115
  • 1
  • 5
-7

It could of course be something else. Could someone who knows the business better than me explain why Java isn't getting momentum when it comes to game development?

It's an interpret language, ie slow. You're dealing with graphic and graphic card which is hardware. What's a good language to deal with hardware? Well C++, it's pretty low, and you deal with pointers and whatever.

If you want to pump out crazy graphic like crysis and whatever you're not going to do Java for it.

Not only that, Oracle owns Java, the thought that a company can sue you doesn't bold well. Especially when you want to build your own interpretor for JAVA to target gaming without getting sue due to fragmentation FUD.

mythicalprogrammer
  • 505
  • 2
  • 6
  • 1
    You should seriously read about JIT compilation, and look at some benchmarks where Java is put against C++ – Anto Mar 06 '11 at 13:52
  • 1
    Who the heck voted this answer down? This whole question is becoming incredibly ridiculous! Good grief. – Fattie Mar 06 '11 at 15:48
  • 7
    @Joe The answer is wrong. Java isn’t interpreted. – Konrad Rudolph Mar 06 '11 at 17:00
  • 3
    @Anto Forget those silly benchmarks. C++ *is* orders of magnitude faster than Java where it counts, see http://programmers.stackexchange.com/questions/29109/29136#29136 and http://programmers.stackexchange.com/questions/368/13888#13888. – Konrad Rudolph Mar 06 '11 at 17:02
  • @Konrad As far as I can tell you are only offering a single conunter example based on sort - how is that better than "silly benchmarks"? – Adrian Mouat Nov 28 '11 at 15:19
  • @Adrian First off, because it’s not silly but an extremely common use-case. Virtually every non-trivial application uses sorting at some point, and it’s a common bottleneck. But it’s *not* my only example, just a very salient one. I actually know a few other concrete cases, and you can generalise this to any kind of algorithm that requires type parametrisation and some specialisation based on that type (= most algorithms) and that is performed on a lot of data. This is a common problem. – Konrad Rudolph Nov 28 '11 at 20:41
  • Any modern graphics card is programmed through an API, like OpenGL. –  Nov 28 '11 at 23:08
  • 1
    @Anto What's am I suppose to look at? Speed? C++. Memory usage? C++. Look at minecraft and try hosting a server and see how much memory the game is taking up. Java consume much more memory versus C++. Making an online game, I would imagine is pretty hard in Java. Every benchmark I've seen so far Java consume more memory, now having a mmorpg game where the central server is coded in java sounds nice only if you ignore the memory aspect or change the definition of massive in MMORPG. – mythicalprogrammer Dec 08 '11 at 21:12
  • In terms of computing performance, Java and C++ are on a par and have been for a long time. You can write pathological code in either to make it look bad if you want to. In terms of memory it is true that Java has more overhead. Hello world is a 4K program in Java. However that overhead is fairly meaningless on modern multi GB machines. Java also has a longer start-up time. Very short run benchmarks will be dominated by that. I would not recommend writing command line utilities, for instance, in java. – user430788 Mar 24 '14 at 01:01
  • @user430788 It's worth noting that up until this year, the most modern consoles weren't even *single* GB systems! Both the 360 and PS3 has 512MB of RAM. – Gankro Mar 24 '14 at 04:23