Java - any good for game programming?

[ghoulsblade]

cant..... resist.... flamewar..... XD
* java=slow & memory hungry compared to c++, benchmark : http://shootout.alioth.debian.org/u32/java.php
* (also interesting : http://blog.gmarceau.qc.ca/2009/05/spee ... ty-of.html)
* not commonly used in gamedev industry (name 10 tripple-a titles using java?, compare lua)
* yes there are hobby-gamedev projects using java, but there are also projects using almost any imaginable language. whatever works for you i suppose.
** being technically interesting or theoretically good isn't the same as being practically useful
** how "successfull" they can be considered to be is highly subjective, one "minimum" would be "100+ players average online" for multiplayer games (not 100 per day, but rather at any given time 100 or more players online, compared to several thousands or even millions for commercial games)

[charlie]

cant..... resist.... flamewar..... XD

Evidently!

* java=slow & memory hungry compared to c++, benchmark : http://shootout.alioth.debian.org/u32/java.php

Total lack of context in these benchmarks. Of course, with Java you get the whole execution stack. These massively skew any such benchmarks where the actual program is relatively small. Of course some basic arbitrary algorithm will be tons slower and consume tons more memory for 1 time running in Java. For practical purposes, the benchmarks should take into account VM start up time and memory consumption, but never do.

Games won't be loading the VM 1000s of times each time you run it.

* (also interesting : http://blog.gmarceau.qc.ca/2009/05/spee ... ty-of.html)

These are better thought out benchmarks. Here Java outperforms Lua, C# etc. (Java steady state rather than Java -Xint)

* not commonly used in gamedev industry (name 10 tripple-a titles using java?, compare lua)
* yes there are hobby-gamedev projects using java, but there are also projects using almost any imaginable language. whatever works for you i suppose.
** being technically interesting or theoretically good isn't the same as being practically useful
** how "successfull" they can be considered to be is highly subjective, one "minimum" would be "100+ players average online" for multiplayer games (not 100 per day, but rather at any given time 100 or more players online, compared to several thousands or even millions for commercial games)

Don't have the time to do the kind of research needed to answer these since Googling 'Java games' terms brings back too many web/mobile game sites.

[Julius]

I think the main point that speaks for Java is that when it is used for 3D games usually the CPU load compared to the GPU load is rather insignificant anyways, so the Java overhead doesn't hurt so much and OpenGL calls run just as fast in a Java as in a C++ game (to my knowledge).

On the benefits side you have that Java is easier to code and bugfix and that it is extremely portable, e.g. you don't even need to port it... take the same .Jar and it will run on systems you don't even know they exists (as long as they have Java ported and a OpenGL GPU) and will probably do so even 10 or 20 years in the future.
Taken that and the probability that ARM based (most likely Android driven) devices will bite off a significant chunk of both the console and the PC market, and the extreme easyness of running a Java based game on those, I think everyone starting a new game project right now should have a look at Java.
And if FOSS games ever have a chance to reach a wider audience, then most likely it will be on this devices.

Take the Motorola phone for example, which comes with a docking station to use as a "PC"... for a lot of current PC users this would be a perfectly reasonable replacement for their PC, as Firefox and a office program runs on it (with ARM Windows8 soon even Microsoft Office). The only thing that is missing are games, even though these systems are perfectly capable of running quite nice looking ones (take the Nvidia Tegra2 chip for example). So if you release a FOSS game for those, you can be quite sure you will get an quite big audience for it.

Disclamer: That said... I am not really much of a programmer, so I might be talking out of my ass

[charlie]

Don't we all like to talk out of our ass Julius. It's what makes the world such a beautiful place.

Good points though!

Talking ass

TalkingAss.jpg (93.99 KiB) Viewed 16690 times

[StudioFortress]

I think the main point that speaks for Java is that when it is used for 3D games usually the CPU load compared to the GPU load is rather insignificant anyways, so the Java overhead doesn't hurt so much and OpenGL calls run just as fast in a Java as in a C++ game (to my knowledge).

On the benefits side you have that Java is easier to code and bugfix and that it is extremely portable, e.g. you don't even need to port it... take the same .Jar and it will run on systems you don't even know they exists (as long as they have Java ported and a OpenGL GPU) and will probably do so even 10 or 20 years in the future.
Taken that and the probability that ARM based (most likely Android driven) devices will bite off a significant chunk of both the console and the PC market, and the extreme easyness of running a Java based game on those, I think everyone starting a new game project right now should have a look at Java.
And if FOSS games ever have a chance to reach a wider audience, then most likely it will be on this devices.

Take the Motorola phone for example, which comes with a docking station to use as a "PC"... for a lot of current PC users this would be a perfectly reasonable replacement for their PC, as Firefox and a office program runs on it (with ARM Windows8 soon even Microsoft Office). The only thing that is missing are games, even though these systems are perfectly capable of running quite nice looking ones (take the Nvidia Tegra2 chip for example). So if you release a FOSS game for those, you can be quite sure you will get an quite big audience for it.

Disclamer: That said... I am not really much of a programmer, so I might be talking out of my ass

Unfortunately some of your presumptions are incorrect. Any sophisticated Java game has tonnes of work to perform on the CPU, and there is overhead using the Java Native Interface for talking to OpenGL. There is also still the issue with GC pauses, even in relatively inexpensive programs, as I highlighted in my post.

Although I'd agree that Java is excellent for cross-platform, it's very far from perfect. Most of it's issues are also around sound, anything 2D (like Swing) and OpenGL. I've had Java-OpenGL games that run flawlessly on Windows, but crash horribly on MacOS. I've had threading code that runs perfectly on Vista, run crawled on XP and Linux. This also gets worse as programs become larger and more sophisticated. You certainly can get extra platforms for less work, but not for free.

Further Android is a very different Java target then Java SE. It doesn't even run .jars, it runs it's own dvorak bytecode and only a slither of it's libraries are compatible. Android supplies it's own libraries for most code. There is also no Oracle JRE available for ARM; so you could not build for Windows and run on an ARM machine.

[oberhamsi]

I wouldn't portrait Java as totally incapable of powering a game. I must admit, I don't use it for games but extensively at work. I'd say for 99% of the FLOSS games I see here, frankly, Java would easily be fast enough. Plus it's a lot easier to code in :P

I think the bias is more that, historically, most games were done in C so there's a lot of code floating around and most gamedevs know at least a bit of C.

<flame>
I never did a lot of C and everytime I decide 'lets take a close look!' i'm underwhelmed by who little C provides. It takes 100s of LOCs do to anything so I usually decide to drop it and instead do some real programming :P
</flame>

[ghoulsblade]

C/C++ is just the programming language itself.
It doesn't come with ready-to-use libraries for graphics etc as languages like java,python,c#/.net,... that come with complete frameworks.
It is generic, and the usual software-library found on the internet comes ready to be used in C/C++ (3d, physics, gui, scripting, sound...).
It is the industry standard in gamedev so knowing the basics about using it would be good,
if only to be able to make existing software libraries usable in your favourite language (creating wrappers/bindings etc).

I'd disagree that the iphone/android/mobile games are the main gaming platform of the future.
Sure they are used by many people and are responsible for a big chunk of the cash involved in commercial games,
but i for one would still have a PC with a nice big screen, a decent 3D accellerator card, and a mouse in mind when i talk about "computer games".

In terms of cross-platform i doubt that java has as much advantage over c++ and similar as some people like to claim.
You can't just take an app written for pc and expect it to be fully usable on a mobile device with touchscreen.
Also as has been already statet, gamedev involves hardware dependend interfaces like 3d accelleration and sound that just aren't "magically working" in todays world.
C/C++ itself code and many libraries are crossplatform already, and even cross-compiling (e.g. win/mac) to generate binaries for different platforms is possible using gcc, although most hobby developers tend to not look into it in detail.

[oln]

C/C++ itself code and many libraries are crossplatform already, and even cross-compiling (e.g. win/mac) to generate binaries for different platforms is possible using gcc, although most hobby developers tend to not look into it in detail.

I would say that it's mostly hobby developers/"indie" companies that do look into compiling and coding for more platforms when it comes to C++. (When it comes to gaming at least.) Most of the big companies don't. (Though this could have reasons not related to programming language or code in any way.)

[Tuxide]

C/C++ itself code and many libraries are crossplatform already, and even cross-compiling (e.g. win/mac) to generate binaries for different platforms is possible using gcc, although most hobby developers tend to not look into it in detail.

I would say that it's mostly hobby developers/"indie" companies that do look into compiling and coding for more platforms when it comes to C++. (When it comes to gaming at least.) Most of the big companies don't. (Though this could have reasons not related to programming language or code in any way.)

He's referring to using a toolchain as part of the development process. Using a cross-compiling toolchain and writing portable code while only building for different platforms when you release are not the same thing, although you need to do the latter anyways in order to do the prior. ghoulsblade is referring to making your Mac and Windows builds on a Linux computer using something like Fedora MinGW/DarwinX.

He is right when he says most hobbyists tend to not do this. In the project I am in, we have a compile farm set up that can build Win32/Linux32/Linux64 clients automatically whenever someone commits to the source repo, and all these builds are made on a Linux64 box. In comparison, PlaneShift has no such thing; they build their clients by hand on the host platforms. (Ironically, the tool we set all this up in is written in Java.)

As far as what languages companies use, that has more to do with the tool/engine they decided on that fits their project's requirements than it has to do with which language they feel is superior. If you're using Unreal or BigWorld, that's going to determine your language, and also whether you can open-source it.

A lot of the things that we do write are actually written in Java, and our reasons have nothing to do with portability or JVM performance or the availability of JNI wrappers. None of those things are relevant to what we do.

[Julius]

Further Android is a very different Java target then Java SE. It doesn't even run .jars, it runs it's own dvorak bytecode and only a slither of it's libraries are compatible. Android supplies it's own libraries for most code. There is also no Oracle JRE available for ARM; so you could not build for Windows and run on an ARM machine.

Really? I wasn't aware of that... hmm but you can let the different JRE create the byte-code on the fly out of the java source-code, right (remembering my limited Java programming experience nearly 10 years back...)? And that Dvorak is that different is really a shame, for me that seemed to be one of the main positive points of Android...

I'd disagree that the iphone/android/mobile games are the main gaming platform of the future.
Sure they are used by many people and are responsible for a big chunk of the cash involved in commercial games,
but i for one would still have a PC with a nice big screen, a decent 3D accellerator card, and a mouse in mind when i talk about "computer games".

I never said so... what I said is that they will be a significant portion of it (cutting away both from the PC and console market) and that some of them actually will be used to dock to a big screen and keyboard/mouse and have a decent 3D accelerator (look at the demos of the new Nvidia Tegra chip) thus completely replacing the PC for many people. Sure they will not be for the hard-core gamer... but everything up to the level of things like World of Warcraft can be run on mobile chips right now already and soon everything except for the most graphic intensive FPS games will have no trouble running on them either.

[StudioFortress]

Further Android is a very different Java target then Java SE. It doesn't even run .jars, it runs it's own dvorak (edit: I meant Dalvik) bytecode and only a slither of it's libraries are compatible. Android supplies it's own libraries for most code. There is also no Oracle JRE available for ARM; so you could not build for Windows and run on an ARM machine.

Really? I wasn't aware of that... hmm but you can let the different JRE create the byte-code on the fly out of the java source-code, right (remembering my limited Java programming experience nearly 10 years back...)? And that Dvorak is that different is really a shame, for me that seemed to be one of the main positive points of Android...

The JRE does not run or compile source code. Your application must be compiled to Java bytecode ahead of time. You might be getting confused the JRE will however generate the native code on the fly (allowing your application to run 100s of times faster). This is called 'just-in-time' compilation.

However it is technically possible to compile Java source code and run it at runtime; but you would have to build an application which would do this (and that application needs to be built ahead of time). Unless you wanted to use Java as a scripting language, there also wouldn't be much point in doing this for games.

To be fair quite a lot of your application code could potentially be easily portable from Windows to Android (presuming the game works fine on a tiny screen). I've not programmed for Android, but I'd be surprised if it's OpenGL bindings had the same interface as those for Windows (and they will certainly have different imports). That, and your boiler plate code (for wrapping the application up and finding user inputs), would be the main areas where things would be very different.

One big issue with Android though is that it's garbage collector is meant to be terrible as it has very long pause times. All those GC issues I keep talking about above? It's meant to be much, much, MUCH worse on Android.

[ghoulsblade]

I never said so... what I said is that they will be a significant portion of it (cutting away both from the PC and console market) and that some of them actually will be used to dock to a big screen and keyboard/mouse and have a decent 3D accelerator (look at the demos of the new Nvidia Tegra chip) thus completely replacing the PC for many people. Sure they will not be for the hard-core gamer... but everything up to the level of things like World of Warcraft can be run on mobile chips right now already and soon everything except for the most graphic intensive FPS games will have no trouble running on them either.

"mobile gaming" affects many people and much of the cashflow, but i'd think it's not really relevant for many hobby gamedev projects.
Either you want to include (or even focus on) it, or you don't. Both are sensible choices.
Mobile platforms might be limited to java, but i'd disagree that this is an advantage of using java in a generic gamedev projects.
(compare flash games that work on every browser)
Actually as opensource enthusiast i rather feel the desire to RESIST being locked in on a specific language like that.

If "mobile" devices are to get big screens and mouse, i'd think they'd also get the ability to run programs being built for native windows.
As it currently stands i don't see mobile devices as desktop replacement for people actively working with PC or the more hardcore gamers.
Maybe they are rather headed for mainstream (as opposed to hardcore gamers) entertainment platforms, like console (ps3, nintendo, xbox etc) ?

Other possibly interesting thoughts :
compare the java-vm component to wine emulator ? (if it runs on wine it's crossplatform ?)
can java with it's use of a vm be considered a new platform rather than something that runs on existing platforms ?

[Julius]

Hmm... I guess most FOSS games do not really appeal to the hard-core gamer either

Concerning your other thoughts, I don't think it can be really compared to WINE (Wine Is Not an Emulator ), as Java is not X86 specific nor does it always lack behind a closed-source and moving target (Win32 api).

For me Java is rather scripting taken to the extreme... e.g. instead of having a C++ game engine (that you have to port to each system/platform) on which you implement the more specific thing in a separate scripting language, some one decided to made a totally stripped down general purpose engine (the Java VM) and you simply implement your entire game in script and have the work of porting the engine to the platform already done for you by others.

[charlie]

Further Android is a very different Java target then Java SE. It doesn't even run .jars, it runs it's own dvorak bytecode and only a slither of it's libraries are compatible. Android supplies it's own libraries for most code. There is also no Oracle JRE available for ARM; so you could not build for Windows and run on an ARM machine.

troll bits deleted now dvorak/davlik correction has been made

There is no such thing as dvorak bytecode. In fact, if you search for "dvorak bytecode" (with quotes), the only result in Google is this thread.

[sireus]

It's dalvik, not dvorak :P

[charlie]

Ok, now we are getting somewhere:
http://en.wikipedia.org/wiki/Dalvik_%28software%29

Yes, it does seem to complicate porting to Android if you use unsupported class libraries.

[Tuxide]

It's not uncommon for Java implementations and tools such as Dalvik to only support a subset of the Java Class Library, especially tools that are written by Google. Who wants to use Swing and AWT on an Android anyways? Even GWT only supports a subset of java.lang.* and java.util.*; things like reflection and java.io.* will never be supported.

I've never developed for Android myself, but I would imagine due to differences in class libraries alone developing for Android is not the same as developing a desktop application in Java, or developing for GWT, or developing a robot controller in Java, despite the fact you would use Java for all of these.

[StudioFortress]

Further Android is a very different Java target then Java SE. It doesn't even run .jars, it runs it's own dvorak bytecode and only a slither of it's libraries are compatible. Android supplies it's own libraries for most code. There is also no Oracle JRE available for ARM; so you could not build for Windows and run on an ARM machine.

You write so eloquently.

Then you just fabricate stuff completely as well.

My bad on getting the name wrong, I'm sorry for that. But please don't call me liar.

[oln]

It's not uncommon for Java implementations and tools such as Dalvik to only support a subset of the Java Class Library, especially tools that are written by Google. Who wants to use Swing and AWT on an Android anyways? Even GWT only supports a subset of java.lang.* and java.util.*; things like reflection and java.io.* will never be supported.

I've never developed for Android myself, but I would imagine due to differences in class libraries alone developing for Android is not the same as developing a desktop application in Java, or developing for GWT, or developing a robot controller in Java, despite the fact you would use Java for all of these.

Haven't done any OpenGL stuff on either platform, but the gui and application setup parts are very different.

[charlie]

My bad on getting the name wrong, I'm sorry for that. But please don't call me liar.

Corrected.

[StudioFortress]

My bad on getting the name wrong, I'm sorry for that. But please don't call me liar.

Corrected.

Thanks!

[Xhalite]

I might try Java, I don't know if you agree, but my favorite game growing up was a java browser game called Runescape. They did a pretty good job with only minor glitches here and there. Huge world, and a ton of stuff. Shows the capability of the language. I started with C++ and haven't tried java yet.

[FreakNigh]

Honestly when your at the beginning stages of design etc you need to choose the language which is best for you and the libraries. Does your game fit into a browser? Can it just be php or does it need flash? Is it a massive server crunching a ton of information, because that will not be ideal for java? Can the game be built out of simple gui widgets because then you can use something like visual basic?

I've had multiple examples where simple java code would work on windows and then not on linux. From my understanding the real plethora of libraries are for C / C++ so if you need the best effects and integration that's what you should use.

[charlie]

Is it a massive server crunching a ton of information, because that will not be ideal for java?

I would have thought that was the ideal situation to choose Java...

[FreakNigh]

I've never heard of something like Eve or a WoW server made with java. It should be made with something like c / c++ because this language is basically a machine language, it nearly compiles directly into assembly.

If the argument is for stability reasons I simply recommend you get a c coder with good practices such as avoiding pointers, properly object orienting, avoiding threads and avoiding dynamic memory. C / C++ is about limiting too much freedom and then your fine.

From my understanding Java is all about being an alternative for a bad OS by putting a layer between the OS and the code and babysitting a lot.