... can be found in three parts in the Java Developer's Journal, where a bunch of high-flyin' industry big wigs talk about Java and games development with, er, me. Not sure why I was involved now, it was months ago we did it, but there we are.

Java has a very, very bright future as a game development language, we believe. You C++ and Blitz programmers would do well to at least have a think about it.

Anyway: if you're interested in dabbling in Java you might want to grab the 1.4.2 JDK (http://java.sun.com), a free IDE (http://www.eclipse.org), and have a look at the open sourced library (http://www.lwjgl.org) I used. There's a ton of experimental and useful code (http://www.sourceforge.net/projects/spgl) to look at to help get your thoughts together. And plenty of people to ask (http://www.javagaming.org) questions (http://www.puppygames.net/forums) of.

At least have a quick go at making a mongy sprite wiz across the screen and see what you think.

Cas :)

Java has a very, very bright future as a game development language, we believe. You C++ and Blitz programmers would do well to at least have a think about it.
OK.

Done. No, thanks.

:D

:D That was really funny Gabriel.:D

"Java Developer's Journal" hm... I think there is no way I could get that mag (here).

Can you scan the article Cas? I really would like to read it.

I can get hold of a PDF file I think but mostly it's me waffling on about stuff like I always do, and Jeff Kesselman being quoted horribly out of context :D

Cas :)

I was looking at Java to learn next but didn't you experience a lot of compatibility problems when you first released your game? Did you ever find out what was causing them?

Mainly me. There are some broken OpenGL drivers out there too which we can't do anything for. And we've got a problem still with Matrox cards. However, all the problems now occuring are in C code, not in Java code.

Now we've figured out a lot of stuff we won't be making the same mistakes again of course.

Cas :)

When I worked on this (http://www.adventurearchiv.de/r/rosemondreviewe.htm) game, we used Java as our scripting language, implementing basically the whole game in script, with the C++ engine providing all the graphics, sound and other performance critical functionality.

It worked reasonably well most of the time, and it gave us the benefit of being able to hire anyone with Java skills to help out with the scripting. But unfortunately, some weird bugs occured a little now and then (and I don't know if it was directly related to Java or to the way we had hooked in our C++ code into the Java VM). Also, we found that some (not all) of the Java programmers we hired had an almost fanatic attitude about how Java code should be written. For example, we used a capital letter at the start of every method that was implemented in C++ and exposed to Java... but one of the Java programmers was very adamant about "in Java, method names ALWAYS starts with lower case", so he spent a good few weeks writing wrappers for all the methods.

All in all, I think it worked quite well using Java, and that the problems we had was more related to 1) how we connected C++ and Java and 2) personality traits of the people involved.

However, the damage had already been done, and for the next project, we dropped Java and made everything in C++.

Originally posted by Mattias
However, the damage had already been done, and for the next project, we dropped Java and made everything in C++.
Ahhh, I love when histories have a happy ending :D

Ok Cas, let's have a go at this. What would you say are the top 10 reasons why a developer should look at Java for games? Java is obviously a good choice for someone who likes Java, but for someone just starting out who doesn't know what language to use, why Java?

Or for someone that's already loving the C++ lifestyle. I've used Java in the past (admittedly when it was still 1.4), and it was a pain in the butt. Made a cool word materialization applet thing that froze the browser half the time because of the stupid Microsoft Java VM, but yeah. I couldn't imagine making a game with Java, especially if I didn't use Java2D - I always used AWT, since Java 1.2 wasn't supported on all browsers (and I only really did applets, not applications).

Just my $0.02.

My top ten reasons to use Java in no particular order:

1) There are in fact no arguments about coding style allowed! There is only one style, and Sun invented it. Before a project begins you all agree to use the official style, end of argument :) Anyone says different, you tell them to **** off!

2) It's considerably faster to develop large and complex projects (or even small and simple ones) in Java.

3) The development tools are excellent, interoperable, and varied. No programmer needs to be made to use a tool he doesn't want to use - they all produce the same result, and they all interface with the same code repository. As you start getting into the realms of GUI builders and such this is less true but for games you have all you need.

4) Build times are more or less instant as Java is very, very modular and dynamically linked.

5) No more stupid pointer errors. I hear a lot of C++ programmers bemoaning the lack of pointers, but, see, I'm also a C++ programmer and pointers account for nearly all the problems I ever had in C++. No more buffer overruns either.

6) The syntax is pure and simple easier than C++. No macros to do unexpected things, no operators overloaded in daft ways so the code becomes unreadable. Source code does what it says on the tin.

7) It's finally fast enough to use for games. Speed is no longer a valid C++ argument. Anyone still unconvinced can compile it into native executables on Windows anyway (and soon on Linux).

8) It runs on Mac and Linux - unmodified. Literally. Although the wee Mac bit we're still working on.

9) Webstart deployment rocks. It's such a neato way of delivering software.

10) Comes with a bunch of exceedingly useful APIs to do loads of stuff for you that is otherwise something of a black art. No more Winsock worries, no more trouble saving and restoring game state, trivial encryption, writing servers is a piece of cake, etc. etc. etc.

I could go on but it might be more instructive to come up with 10 reasons why not to use Java.


Cas :)

1) This has little to do with the language/platform. I prefer freedom over dictatorship, anyway. If you want to impose a coding style (I agree that it can be good), go ahead - impose your own or use one of the suggested styles.

2) Proof?

3) Again, little to do with Java itself. It's a matter of picking the set of tools you feel comfortable with. Use the Official Prepackaged Set of the Truth or your own mix.

4) C++ too

5) Don't use pointers if you don't like them. Use references. Use smart pointers. Use pointers and a garbage collector. Get as low level or as high level as you want. Can I do that with Java?

6) Use a subset of the language you feel comfortable with. Nobody forces you to use pointers, templates or macros. With C++ you have the choice. With Java you don't because somebody decided they were "bad". Let me choose, I know what I'm doing.

7) Exactly what isn't fast enough to write an OpenGL wrapper running in a 2 GHz processor?

8) My C++ code runs on Linux, Win and Mac with a recompile. A recompile within Linux, of course. No VM required.

9) Not much to do with the language, again.

10) STL? Boost? Roll your own?

In the end, it's a matter of choice. If you want extra safety sacrificing flexibility and control, go ahead, use Java. I prefer extra flexibility and control. I don't want every array bounds checked because somebody decided I couldn't get my indexes right.

I don't want this to degenerate into a flame war, so I won't post more comments here.

Now, now - I know we all love our language choices but it's not a religion.

Then again, I have yet to see a shareware game that couldn't have been developed in half the time and at the same quality using Blitz or any of the other BASIC alternatives ;)

I think Blitz is the dog's bollocks but I can't get on with non-OO programming any more. It's not nearly as fast either and I expect that when something gets as complex as AF it's going to take rather longer to write.

There's a lot of other subtleties to the choice of using Java, none of which have any bearing on anyone who prefers to use C++. There are things like code signing and built-in content delivery mechanisms which are actually a consumer benefit rather than a developer benefit.

But mainly it all comes down to the 80/20 rule. When Java gets 80% of the work done for 20% of the effort you need to have a good think about why you're putting in all the extra effort for what appears to be no tangible gains using C++. Indeed for smaller games Blitz has got an edge here because it's even easier to begin with.

Cas :)

Is there a size penalty for Java games? I seem to recall there's a reason why your AlienFlux demo is 10megs but I'm not sure if it's related to Java.

Also, since you posted 10 reasons why Java is superior, can you post 10 reasons why Java might not be superior?

Thanks.

I downloaded Java from Sun's website. Now..is this everything I need to make java games or do I need something else?

Nooooooooo! Another one sucked in by the gilded surface of Java! I beg of you, repent! No, wait...not that one. But yeah, C++ :p

I'm still writing everything in C++. I've tinkered with Java, but (IMO) it's Not Quite Ready Yet™.

Java's language features are hard to argue with (although the addition of a "smart" pointer would be nice) but it's the platform(s) support, built in API(s), and VM that are holding it back.

A few (3) reasons Java is Not Quite Ready Yet™:

1) A constantly depreciating API. Every time Sun releases a new SDK, a large set of packages (or parts of X package) become depreciated. It's hard enough getting used to a new API. It's harder still when it's constantly changing.

2) Multimedia performance is inconsistent from one VM implementation to the next. Sun's windows VM (until recently) was considerably slower then Microsoft’s broken VM. Why? I don't know.

3) Missing flexibility. I want my pointers. Sure, pointers can be difficult to use, test, and debug - so why not just give me a built-in smart one? Don't just take the feature away and have me "deal with it".

I like Java as a language, and it doesn’t have any inherent flaws that can't be fixed. I've been waiting for years for Sun to get it's act together. But until then, Java is Not Quite Ready Yet™.

Michael Sikora
Guardian Games (http://www.guardiangames.com)

Well, ever since I started using C/C++, I've disliked the language a lot. And it doesn't matter how much I learn about it or have much I use it, I still find it to be an uncomfortable, aged and very non-modern language.

However, have never find a real alternative. C/C++ is the only language that I can use for all my programming needs, and I definitely don't want to be using different languages for different projects, because that would make code reuse between projects very difficult.

Cas: you say that speed is not an issue any more. Is that really true? I would like it to be, because if it was, I would consider switching to Java... I'm going to ask a question about Javas performance, and I'm not asking this to be awkward, or as a hypothetical question... It is something I am working on right now, and something I would want to be able to do if using Java as well: Could you, in Java, write a software renderer that could compete, speedwise, with one written in C++?

Java games are smaller than their C++ counterparts when they're in JAR format. However when you compile them into executables they're generally larger as the compilation process incurs a 1-2MB overhead depending on how many features you use. Alien Flux is so big because about 7MB of it is graphics and sound. I'm going to shrink it quite a bit in the next version.

Speed really, truly, isn't an issue. It is true that Java is not as fast as C++. In some places it's half the speed; in other places it's about the same. When you actually put a whole game together instead of measuring microbenchmarks you will find that you need roughly 10% more processing power to run a Java game. You also incur a memory overhead; reckon on 8MB of memory overhead.

The speed of modern games is largely governed by the bus bandwidth and fillrate on a graphics card now rather than the speed of the CPU anyway. If you're the sort that insists on blitting in software you are probably better off writing the rasterizer in optimized assembly language, or, more wisely, using someone else's blitting code. Having said that some people are pretty happy writing software renderers in Java (http://www.jpct.net - I can't find the link but he actually wrote a Quake3 level renderer which he's still working on which runs at 20fps (320x200 1.2GHz), and that's quite amazing really). I don't think that's competitive with a C renderer really; I'd imagine a C renderer could double that. But much like we accept Moores law, now might just be the time to accept that Java is probably better off relying on a graphics processor as well as a CPU. It gets faster every incarnation anyway. Floating point performance doubled in 1.4.2 just now which was quite a shock.

A quick response to Guardian_Light's points:

1. This is a FUD. It's not constantly deprecating. Very few parts of the API are ever deprecated, ever. When they do, they are not removed, you are simply advised not to use them because there is a better or faster way available.

2. There are in reality only two proper Windows implementations of the JVM - Sun's and IBMs. Both are blazing fast compared to the MSVM. Sun's multimedia performance is poor out-of-the-box; that's why we created the LWJGL, which brings it in line with C++.

3. This is not actually an argument. Instead of pointers you get references. There's your smart pointer.

And now 10 reasons not to use Java

It relies on an 8MB runtime. But it's a one time overhead.
It imposes an 8MB memory overhead
The syntax is still way more complex than BASIC
It's not as fast as C++ at memory IO; generally it's around 50% of the speed. This is highly unlikely to be a problem for anything other than AAA titles though.
Several critical Sun APIs are buggy. In particular, getting a fullscreen display (!) and transparent blitting (!) are a bit broken on anything but the very latest 1.4.2_01 VM (!)
To get the 3D performance, I currently rely on OpenGL. Typically that's another one time 6-8MB download.
If you don't understand what you're doing it's possible to write bug-free but amazingly slow and jerky games. There are several pitfalls for the unwary. It's taken me 2 years to figure them all out.
The APIs are way more complex than BASIC too. They are, however, considerably easier to use than STL.
You think you can manage memory better than a machine. Unlikely, but some people still think that it's a man's work.
You're so scared of decompilation that you think your honest customers will decompile your code and hack out the regcode. Although it's been debunked many times on this forum as a myth, some people are still paranoid that because Java is easier to decompile than C++ you'll sell less copies due to piracy.

Any more?


Cas :)

Ok, very informative, thanks for that!

That certainly clears things up for me... looks like I have to stick with C++ for a bit longer :-(

What do you think the reason is for Java having 50% slower memory IO? I mean, if you compile it to a native Win32 executable, why couldn't it be just as fast as C++? Is it because of the lack of pointers or because of some range checking or what?

I have no doubt that Java will one day be just as fast as C++. I just wish that was NOW :-)

It's to do with pointers, yes. Actually pointers won't solve the problem, they'll just make the language unstable and dangerous again. What's needed is a way to map the fields of a Java object directly into the memory of a ByteBuffer. ByteBuffers are how Java accesses memory safely. Unfortunately they're not very well integrated with Objects yet. You can write a lot of glue code but it'll never be as efficient as direct access C style.

It's not really a very valid reason against using Java of course. Unless you're writing a AAA 3D title with all sorts of stunning shadows and volumetric effects etc. you're very unlikely to get anywhere near a performance bottleneck in this area. And even then it's hugely likely the bottleneck will be the graphics card.

<edit> I just had a look at your site and there's nothing you're doing that couldn't be done in Java, very effectively indeed. Have you got an Nvidia Geforce card? I wrote a tiny demo (http://www.puppygames.net/downloads/shaven_puppy_demo.zip)(1mb) a couple of years ago to show off Java performance to C++ disbelievers. The demo only shows a few things in the architecture as well. The whole thing was a pluggable terrain renderer where you can just drop in different materials and have it render them like lava, glass, metal, etc.

Cas :)

Sorry, I didn't intend to use the memory speed as a reason against using Java: I do recognize the usefulness of Java, and that my needs from the language I use is quite specific (maybe even rare?)

You are absolutely right, there's nothing on my site that indicate that what I'm working on could not be done in Java. However, not everything I work on is on my site, and a lot of things I do is based on reusing code. So, if I can't write all the code using Java, I'm not that tempted to write some of it in Java. But this is a problem specific to me, not to Java as such.

As for AAA titles, that is what my day job is, and that's where I'd REALLY would like to use something like Java, because of the big team size and very complex code. However, on an Xbox, you can't really afford the 8 MB overhead of Java, nor the lower low-level speed... So if you want cross-platform code in this case, it seems like Java is not the best choice. Again, this is a problem specific to my situation, and I'm sorry if I've taken this thread too far away from the indie perspective, but I really wanted to get more knowledge on this issue, so I thought I'd seize the opportunity :D

If I were you I'd be watching the PS3 very closely regarding Java...

I do believe Java is ready for AAA titles but not AAA titles that push the bleeding edge of performance. In the end using Java is a business decision, not a technical decision. Doom 3 and Half Life 2 will certainly not sell nearly as well as the Sims because of their unreasonable hardware requirements. Using Java wisely to target the considerably larger mass market with normal hardware is where it's at. The bang for buck ratio here most likely far outweighs the prestige of being on the bleeding edge.

FWIW, Alien Flux uses around 64MB of virtual memory at runtime - just fitting inside an Xbox. We could probably tune it to get it down quite a bit. Most of that memory is graphics and sound (about 30MB of it). There's one small snag: DirectX support. Few in the Java world can be bothered with it, as it more or less ties your code to a proprietry API, and often the reason for writing in Java is the hope of out-of-the-box crossplatform gaming. And of course, there's no JVM on the Xbox...

Cas :)

princec,

what is the 8mb one time overhead? do users have to download this before playing java games? or is it part of windows?

The current Sun Java Runtime Environment is an 8MB download (or about 11MB for the internationalized version with all the extra character sets and locales). That installs the client JRE, and Webstart, enabling you to deploy Java games to people with a single click on a link on a webpage. Try it out for yourself: Install Java from here (http://www.java.com) and then just click this link (http://www.puppygames.net/downloads/alienflux-full.jnlp) to automatically install or update and play Alien Flux. No reboot needed.

Not to be confused with the 8MB runtime overhead; a typical game, which mine more or less is, has to load up a few megs of runtime environment and then theres a few megs of housekeeping data the VM keeps hanging about. Average is around 8MB or so currently.

Cas :)

Another, well documented (http://www.dexterity.com/forums/showthread.php?s=&threadid=1367) reason not to :)

:P Actually I'm mightily pissed off with that Jet bug. I can get round it with a little utility they gave me which is unfortunately out of date and doesn't work. Gah.

I have here on my harddisk a version of Alien Flux that's 11.5mb and includes an embedded Java virtual machine but currently I'm not allowed to distribute it. I'm working on getting that fixed with Sun Microsystems to allow Puppy Games to distribute our embedded VM with all our games.

Cas :)

What do you mean by an embedded VM that you can't distribute? Is it a pared down JRE?

Yes, I've chopped away all the rubbish and got myself a handy little VM. It's embedded because it doesn't actually install as a system VM - it's hardwired to run Alien Flux only and can't be used for any other purpose. Well, not without lots of hassle.

Cas :)