I guess a quick answer to this would be no, that Java is not the "current" best choice for game programming. However I would like an opinion as to the "near future". Games today push for the gazillion pixel and drive hardware to the limits, so we use c++ to squeeze every last bit of the juice out of our hardware. Java in this instance, maybe 20 - 30% slower than c++, but makes the development just that much easier. Since we are observing an approximate 2x speed gain in processors every year, and even more in graphic processors, that 30% really seem trivial. With c++, there is the speed advantage, the vast third party libraries available, and complete flexibility. Java on the other hand, shortens the development time a great deal, prevents the programmers from making many programming mistakes, albeit its compatibility issues with windows So really, I am stumped. If you were to start a new game project a few months from today, which would you choose?

C++. I agree that faster development is preferable to a slightly faster game, but I don't see that Java would shorten development time at all. As you point out, almost every third-party library is written for C++, and it's likely that you're going to need at least one of those. C++ and Renderware is probably the best way for most companies to go.

Java should never be used for such big projects anyway. Java's an interpreted language so it's going to run very slow - even with fast machines! For Java development I run "Together" a platform built entirly in java, and while it's a kick ass development suite it takes a looong time to load. Java is just too slow.

Remember vampire the masquarade: redemption? I beleive that was programmed in java. I too would stick with c++.

Java is not technically an interpreted language. It is compiled into bytecode which is then executed on a virtual machine, or on a native processor (Sun built one some time ago). Or it can be compiled into native machine code (at runtime via a JIT-compiler, or in a second compiler pass with for example gcc). Java has automatic garbage collection, which is nice from a programmer point of view although it does slow down programs from time to time when the garbage collector is running. As for big Java programs not being a good idea, I agree, but more because I believe that OOP doesn't scale well in general than because of speed concerns. I'm working on that (something that scales better in terms of large systems) btw :-).

Lourens, that sounds interesting. What exactly do you mean by saying that you're working on it? -- Jani

Slashdot mentions an interesting tidbit about native compiled Java. Things seem to be slashdotted* at the time of writing so I haven't checked out the screenshots yet. * Slashdot has about a third of a million hits per day, and if a story is posted on it all those people read it. This has reduced many a web server to smoldering ruins, rendering it unreachable, or slashdotted. Jani: I'll make it a separate thread, to avoid hijacking this one.

Yeah, deploying applications encoded in a hardware independent intermediate format sounds like the way to go to me. It can always be compiled to native code on site to take advantage of the capabilities of the underlying hardware. If no such compiler exists in the system then just run it on a virtual machine. I really like the idea and I think I like C# as well. Wrote my first pieces of C# code last night. Nice features and all. Well, templates (generics) are still missing, but we'll likely get those with the next major release. Well, I'm not sure whether I actually miss the template metaprogramming madness that has engulfed the C++ world. -- Jani

I thoght C was object orientated.

Huh? What's C got to do with this? I was talking about C# not C. C# surely is object-oriented, but it's still missing generics (=templates). -- Jani

Well you can write object oriented programs in C. It's just not designed for it, and you don't get proper encapsulation and inheritance and stuff, but in a very basic sense it's possible. Well and if not you just write a preprocessor like they did for GTK (I still don't understand why they didn't just use C++, but that's another issue altogether).

...well at my uni they have been telling us that C is an object oriented programing language, not that you "can do OOP" in it but that it IS object orientated. Oh and when talking about C# & C++ you might as well be talking about C as they were built on top of C89 so basically if C is OO so is C++ & C# ... of course a C99 prog wouldn't work in a C++ compiler but hey

C is just as object-oriented as pure assembly language. You can do OO programming in both, but that makes neither an OO language. It isn't about what you can do with the language, it's about how well a language's design supports object-oriented programming. -- Jani

Exactly. I'd love to know how to declare an object in C, proper encapsulation and all. I'd say that's the minimum requirement for an OO language. As for C++ being a derivative from C, well, the syntax is alike and the first C++ compilers were C compilers with a wrapper for C++, but with OO and template metaprogramming C++ isn't much like C anymore if you look beyond the spelling of keywords.

Originally posted by fluKe ...well at my uni they have been telling us that C is an object oriented programing language

Are you sure you didn't mishear/misinterpret what your lecturer(s) said? If they really do think C is object orientated then you should think about transferring to another university. C is function orientated, Java is object orientated, C++ is a hybrid.

C++ gets slightly confusing once you learn about metaprogramming. When writing C++ code I always get the itch to write some fancy template code and make my classes as generic as possible should I _ever_ need to reuse the code in a slightly different context. Designing good templates is time-consuming and I never get far that way. On the other hand, languages like Java and C# are quick to work with, because you don't have that option! -- Jani

Ohh.. I hate this bell tolling on this site. I have these stereo headphones on at work and that bell almost gave me a heart attack.. Can't it be disabled? -- Jani

Go directly to http://boards.lionhead.com/

Thanks. -- Jani

It's perfectly possible to program fast games in java and the online nature of most java programs encourages programmers to be a little more frugal with bandwidth and storage space (for any major new game, keep a gig or so spare on your HD) which isn't a bad thing. Also, Sun and SGI have recently announced that they're going to create a set of opengl java bindings (there are efforts to do this already but they haven't been part of the official line until recently) which raises the bar for java games much higher. I currently use my own software 3D engine in Java (see my webpage for examples, all fairly old now) which is fine for simple games and it runs on anything with java 1.1 but for more serious efforts, hardware acceleration is a must. The trouble with that is that the kind of casual gamers who play web-based games often have really rather ancient graphics cards and neither know nor care about the latest greatest cards; Gamers who buy boxed software learn pretty quickly what it means to have a decent gaming rig, the same isn't true for the majority of computer users. Finally, I don't know what current java implementations are like on Mac OS or linux boxes but last time I looked, they sucked. You need a good java interpreter with a just in time compiler. Otherwise, forget about anything running at 60fps. Tim.