Java for a game on Pc/Consoles in 2005?

[Preston]

Good morning.

A question to the veteran Java developers, please: say a small development studio (half of the developers know Java) plans to do a professional game (singleplayer, 3d graphics, not a first-person-shooter) with planned release date 2005.
Target platform: PC and the option to port the title to consoles, too (PS2, Gamecube, Xbox).

Would you advice them to use Java (with Jogl/Xith3d) as platform?

Personally, if there wasn't this console option, I'd advice to them to use Java.
However the console option does worry me.

[Jeff]

The answer is... it's a risk.

Currently there are no announced Java VMs for current or future game machines.  I cannot speculate or comment on what we are doing about this  inside of Sun beyond what I've already said.  (That we recognize its an issue.)

Keep in mind that if you are planning on using the core game APIs (JOGL/JOAL/JInput) then those will have to be ported as well.

If you write a game in Java today you can certainly do PC, Linux and Mac.  If you want to go to a console then you have 3 options:
(1) Hope that a Java VM (or compiler) is delivered for your target platform by the time you need it.
(2) Pressure the console maker to get a VM (only likely to be effective if you have a game thats already a hit that they want.)
(3) Port a VM yourself.  (I know of one company that has actually done this for one console, but for legal reasons I can't name them, sorry.)

[Preston]

Thank you for the straight answer.
This is what I've been afraid of.

Since it's a small development studio I don't know what their chances are on the console market anyway (on the PC a small dev studios can well produce "long seller" titles; I've been involved in such one during the last years).
Still, probably they won't forget about the console market option "just" because of Java. :-(

I'd love to suggest Java to them. They'd be so much more efficient. A pity. Let's wait and see. Hope dies last.

Games published by our own members! Check 'em out!

[William]

Couldn't you also natively compile the bytecode for the console with a compiler like GCJ? Might require a bit of compiler tweaking, but at least the console philosophy means that you only have to tweak and test it for one platform.

[erikd]

I don't think a GCJ version is available to compile for consoles, or is it?

[nonnus29]

I don't think a GCJ version is available to compile for consoles, or is it?

Makes you go "Hmmm..."

[swpalmer]

What processor is used on the console?  The Gnu Compiler Collection supports cross-compiling for a lot of different processors.

/me goes Hmmmmm

[Jeff]

I suspect the primary issue is library support on those systems.  Ina ddition to the JDK, which you could limit your use of, there is also run-time support for garbage collection, etc that would need to be ported.

But hey if one of you get GCJ compiling running code on a game machine, PLEASE let me know!  

[Jacko]

a quick google for "playstation gcc" throws up a lot of sites talking about creating your own toolchain using gcc tools. Most complete I found is "Not Yaroze". This is for Playstation 1, but I did find a couple of sites talking about gcc for playstation 2. So from the angle of generating code it looks doable, as gcc and gcj use the same code generation. Like Jeff said, think the main problem would be library support.

[swpalmer]

Is one of us in a position to actually try stuff?  Who here has a console SDK?

As for libraries, LWJGL was supposed to be a candidate for porting to consoles.. but it relies on OpenGL being on the console first...even OpenAL...  Hmm.. maybe X-Box is possible, but that isn't nearly as interesting, since it is not much different from an ordinary PC as far as I know.

Games published by our own members! Check 'em out!

[Jeff]

LWJGL still relies on a core Java runtime (Garbage collection, exception handling, etc).  In GCJ thats in your run-time library and I think is going to be your big snag.

[swpalmer]

But can't you just compile IT for that platform from the GNU sources?

[kevglass]

As a side note, the GP32 supports Java doesn't it?

Kev

[erikd]

I suspect the primary issue is library support on those systems.  Ina ddition to the JDK, which you could limit your use of, there is also run-time support for garbage collection, etc that would need to be ported.

OpenGL is a problem on ps2 but as for run-time support, isn't GCJ compiling some sort of JRE with your executable?
Creating bindings to use PS2's native hardware could be an option though I suppose, *if* GCJ can compile for PS2.

[Jacko]

bit more googling and I've found gcc based compilers for the playstation 2 and the gamecube. So gcc can produce code for them. I would try this but the power supply for my linux box blew up last week, and my windows box aint set up to compile GCC from source. If someone else wants to try I'll give what advice I can, as I've compiled it all from source a few times.

[Jeff]

But can't you just compile IT for that platform from the GNU sources?

Only if that run-time was written to be totally portable.  given how close it lives to the system layer, I have my doubts that you could do so efficiently, but maybe I'm wrong.


Keep in mind that down tehre you are dealing with system things like threading which WILL be different on different platforms.

[renanse]

Not sure if this is relevant but if you google for:  OpenGL PS2   you will find some references to a OpenGL1.2 PS2 port.  

EG:
http://www.dataplus.co.jp/pdf-e/OpenGLPressRelease.pdf
and:
http://www.intercity.or.jp/middleware4ps2/OpenGL4ps2.html

Nothing real concrete, but a start anyhow...

[ryanm]

As a side note, the GP32 supports Java doesn't it?

Kev

Not as standard unfortunately. The processor ( an ARM 920T, IIRC ) is one model below that which includes the Jazelle technology.

Though I am sure that i have seen a VM for the GP32 somewhere, and you might be able to use GCJ to cross-compile onto the ARM...

[erikd]

Not sure if this is relevant but if you google for:  OpenGL PS2   you will find some references to a OpenGL1.2 PS2 port.  

EG:
http://www.dataplus.co.jp/pdf-e/OpenGLPressRelease.pdf
and:
http://www.intercity.or.jp/middleware4ps2/OpenGL4ps2.html

Nothing real concrete, but a start anyhow...

I heard performance is bad of the dataplus open GL library.

There's also linux for PS2 and openGL running it. I don't know about its performance though.

BTW, the Game Cube uses open GL as standard. A friend of mine is looking at how to write these discs as game cube dvd's are not of a compatible format. IIRC the difference is something like they're written from edge to center as opposed to center to edge and that it might require a hardware trick in your DVD burner, but he was not totally sure yet. Fortunately these small writable dvd's are available.

Erik

[Preston]

Hi again. Thanks for all your helpful responce in this thread and the "Reasons for a Java game" one (also to the guys at SUN). :-)

Let's assume your crew's programers would "just" do the desktop PC version of your game. One reason being that they have got no experiences with consoles. So basically you could use Java for this.

But... how could you meet the argument that the potential publisher could want your PC game to be as "console portable" as possible? (So that it could hinder your plan to use Java "just" for the desktop PC version?)


I've been under the impression that if you're doing a C++ game, you can't take the source code of the PC C++ version and use it for the PS2, Gamecube and Xbox version in a direct way. Even if you use a so called portable 3d-engine like Renderware. Things like IO, sound, and so on are (totally) different. Except Xbox maybe.
Furthermore the different consoles have a very different architecture.

Doesn't this mean you've to re-write, maybe even re-architecture, large (?) parts of your game?
Or put in another way: don't those development studios which port PC titles to consoles (or console titles to PC), do a kind of re-programming anyway? So that the argument "PC C++ game soure code is portable to console" is weak, too?

Any console programmer here? :-) Thanks.

[erikd]

Of course java programs can be rewritten to C++ for a console, but I suppose it will take much more effort than porting a C++ program to a console.
A very large part of the C++ code will be game logic which can probably be quite easily ported to another platform.
With rewriting a java program to C++, you'd also have to do your own memory management where it's done automatically in java by the garbage collector, for one thing. And then there's also the extensive functionality 'built in' the JRE you'd either have to avoid to get it to port more easily, or you'd have to find C++ libraries that might behave slightly differently which might in turn introduce difficult to track down bugs.
Of course it can all be done but it will definitely take more effort. You might wonder if it's worth it to avoid C++ to program in java only to translate it to C++ again to get it to work on consoles... Maybe it is, but I doubt if there's any experience with it and you will probably have a hard time defending the idea to a development team consisting of mostly C++ developers  :-/

Erik

[Preston]

A very large part of the C++ code will be game logic which can probably be quite easily ported to another platform.

Say you'd be using some kind of scripting language inside C++ for the PC version's AI (which you'd solve in another way, also elegantly, within Java): would this "C++ plus a script language" be portable to consoles, too, in an easy way?
In similar games aprox 1/3 of the entire game can consist of the AI part.

With rewriting a java program to C++, you'd also have to do your own memory management where it's done automatically in java by the garbage collector, for one thing. And then there's also the extensive functionality 'built in' the JRE you'd either have to avoid to get it to port more easily, or you'd have to find C++ libraries that might behave slightly differently which might in turn introduce difficult to track down bugs.

All the things I love with Java and can't stand anymore with C++... Sigh.

Of course it can all be done but it will definitely take more effort. You might wonder if it's worth it to avoid C++ to program in java only to translate it to C++ again to get it to work on consoles...

As said, my mentioned crew's programmers won't do the console port anyway.
I'm evaluating this "C++ to console" porting option just for the sake of the potential publisher.

Maybe it is, but I doubt if there's any experience with it and you will probably have a hard time defending the idea to a development team consisting of mostly C++ developers  :-/

Yes, that's a huge problem.
Still one day they'll have to leave C++ anyway because it's no modern language.
(Those Visual Studio C++ fans out there will be amazed how fast Micorsoft will let C++ die for the sake of their Java clone named .NET/C#).


PS: Please don't wonder why I track the topic so persistently. It's just: the game's no first-person-shooter action game, and anything it needed I can imagine to be done in Java for the desktop PC version. It would be such a nice opportunity. Sigh...

[princec]

Having said that: if the market's there, Excelsior USA have every reason to produce a cross-compiler.

There is no reason why even today a PS2 game could not actually be coded in Java if Excelsior produced a compiler for it and someone wrapped the PS2's functions with a JNI interface.

My experiences of Jet are that it has a particularly good memory overhead compared to the standard JVM and performance at least the equal of C++. It is, truly, the best of both worlds. You get the rapid development and test cycle of Java and then you get the other advantages of C++ when you cross compile it for the console. (You listening dleskov ?)

Cas

[Jeff]

In fact Id think the market  for a Java to PS2 native compiler could potentially be larger then that on Win32.

Your all already aware that I have my personal questions and issues with pre-compilation on Win32, but on a game console almost all of them go away.'

I am concerned about memory costs on  larger game though.  For CT it may well be a win because you decrease some of the over-head.  On Shawn's Java3D based games he found that compilation almost doubled his in-memory size...

[erikd]

would this "C++ plus a script language" be portable to consoles, too, in an easy way?

I think it would help. For example the unreal engine uses a scripting language using their own VM (they call the Unreal Virtual Machine) which executes platform independent byte code. These bytecode files are compiled sources of UnrealScript, an OO scripting language with strong similarities to java. So they're basically class files for UnrealScript. UnrealScript is not fast though (C++ is around 20 times faster last time I checked), but that's not always important for what it's usually used for. Besides they have something very much like JNI so you can write UnrealScript classes with native implementations written in C++.
They also have abstracted away the low level rendering layer so it works with 3DFX, Direct3D and (though not as good) with openGL and they had a software renderer too (I think that's gone now though).
And Unreal Tournament is available on Win32, Mac, PS2 (I think XBox too, but I'm not sure) which might make it an option too maybe? I don't know how expensive the license is though, but you can already download a UT demo and UnrealEdit (amazing development environment for games!) and play with it to see if its usable for you. I've done some hobby developing on it and I really like it. Another plus is that the engine is around for quite a while so it has lots of knowledge and tools available on the internet everywhere.
You might want to include it in your case study comparing C++ development, java development etc.

Erik

[erikd]

In fact Id think the market  for a Java to PS2 native compiler could potentially be larger then that on Win32.

Your all already aware that I have my personal questions and issues with pre-compilation on Win32, but on a game console almost all of them go away.'

I'm surprised hearing that coming from you   but I fully agree.

[swpalmer]

I can see where Jeff is coming from.

On Win32 you have many different processors in use, the dynamic compiler can optimize appropriately for what it is running on.  PC's have more RAM.  They already have mature VMs.

On the consoles you have a known processor with known amount of RAM.   There is less space available for things like HotSpot which need the JIT'd version and the original bytecode to stick around.  Plus you save all the space that the JIT compiler itself would take.

For exclusive titles being compiled for one platform is an advantage because it will be harder to steal the title and have it run elsewhere... the opposite goal of run anywhere applies for an exclusive title.

I actually don't think specific processor optimizations would be that helpful.. assuming a game runs well on the minimum spec it is likely that the same machine code will run as well or better on a newer faster processor.. though that isn't always the case.

[princec]

I keep thinking in all this - where's that Majc thing, or Jazelle, or Transmeta? A tiny bit of hardware assistance and the majority of issues are gone. Just like OpenGL support.

Cas

[Preston]

Compiling the Java source code to PS2 (Gamecube? Xbox?) sounds well. This would solve the porting issue of the game logic, probably.

Still two big "buts":

1) If I understand you correctly, there's no such compiler currently. So, in case you visit publishers with a graphical/draft demo of your game, you can't seriously answer their request how simple they could port the game to consoles.
Even if your game's scheduled release date was Q4/2005: saying that "maybe then a Java to PS2 compiler would be ready" wouldn't sound well to the publisher, would it?

2) What to do with 3d, IO, sound? Jeff pointed to this earlier in this thread. Say you use an OpenGL based 3d Java engine like Xith3d: how could this ever run on a console?
Or is there some Java native binding for a PC+console 3d engine like Renderware?

[William]

1) If I understand you correctly, there's no such compiler currently.

From what I've heard, any console development is likely to require some console-specific code (which is why many game firms require knowledge of assembly programming when hiring console programmers).

For Java, that might mean to hack GCJ to compile for the PS2. How much work that would require hasn't been conclusively established in this thread yet. Jeff was sceptical of GCJ having a portable runtime, but the Kaffe VM lists a port for the PS2 (with Linux kit) on its homepage so I don't know how much trouble that really means.

I would suggest you check with the GCJ folks before completely dismissing the option, maybe someone has already done it (maybe the Kaffe VM would be satisfy your needs?).

Say you use an OpenGL based 3d Java engine like Xith3d

Is Xith3D really OpenGL based? I was under the impression that Xith3D was written in a way that would assist supporting different rendering APIs. You will probably have to write the Java bindings to the PS2s rendering API yourself though.