Platform Independent Gaming?

klocwerk writes "At the game developers conference, Sun is releasing a white paper on their new "Java Games Profile." Their ultimate goal? To have one CD you could pop into an Xbox, a PS2, a Windows machine, or a Linux machine, and play the same game on them all. If they get full support for it I can finally get rid of that windows gaming partition!" Sun's got an article on their site describing what they hope to accomplish.

Comments

This can only work for some games

[Dr. Bent]

As a professional Java developer, an avid gamer, and a hobbyist game developer, I can tell you that there is no way this is going to work for certian types of games. Quake [X] will never be written in Java.

However, many types of games (RTS, for example) almost beg to be written in Java for two reasons:

1) They need good game logic (and design) and not high framerates in order to be sucessful. Java fosters good design and is less prone to errors (buffer overflow anyone?) while still allowing for acceptable graphics performance.

2) Because of a Java app's inherient portability, games can be written for smaller segments of the market that couldn't be written before because the limited market, limited even further by a specific platform, did not warrant the cost of development (and porting to other platforms).

Re:This can only work for some games

[bentini]

Exactly. This is why UNIX never caught on. There were certain parts (device drivers/platform dependent code) that couldn't be written in non-specific C. So even though a lot of the system code and applications were completely portable, the system never caught on and died a horrible death.
This historical retrospective was brought to you by sarcasm.

Re:This can only work for some games

[smallpaul]

Quake [X] will never be written in Java.

Never is a long time. You must have some special insight into the future to argue with such authority against Moore's law. Don't you think there was a day when they said that Quake could never be written in C?

Re:This can only work for some games

[Stormie]

I thought the same thing until I went to JavaOne last year. There were 2 guys, that worked for some game company, on the pavillion floor that inplemented a pretty cool FPS using the Java 3D APIs (These APIs use OpenGL for hardware accelerated rendering).

Oh yeah, all very well if you're talking PCs. I'll wager that most 3D PC games could be written in Java and, although they'd suffer a bit of a hit in speed and memory requirements, at least the rendering would run fast, and they'd still be playable.

But this idiot is shooting his mouth off about consoles. Let me tell you, it's one thing to have a layer like OpenGL when all the video cards it needs to handle are basically the same. GeForce, Radeon, whatever, there's some differences when you look at the very newest features (e.g. pixel shaders) but for 99% of their functionality, it's the same.

Now compare this to the PS2, where instead of having some crappy "vertex shader" to do transformation & lighting, you effectively have a full featured CPU. How wasted is this going to be when your Java gaming platform can't ever call upon it to do more than the basic stuff supported by PC cards? It won't be rendering too many bézier patches with dynamic level of detail with this Java platform, will it? Now take into account what whilst all the PC cards are competing over who can have the most texture stages handled in hardware, the PS2 resolutely sticks to one, and if you want more, you do multiple passes. Thus totally changing the approach you need for texture tricks like lightmaps, reflections, shadows, etc.

Nope, if you want a replacement for C++ as your language to call OpenGL or DirectX with, Java could fit the bill, but if you want to program a PS2 - forget it.

Re:Why bother?

[bakes]

Why bother? Because things change. Years after the 'most stable Windows ever' (Win 3.1) was introduced, gamers knew that the best gaming environment, without question, was DOS.

Now, it's Windows.

Next, why could it not be Java? They have as good a chance as anyone else. And, if the entire effort required to port it to a new system is to carry the CD over to the other box, game developers will be able to get access to a much bigger market with ZERO extra effort.

That is why they would bother.

Re:This is not worth it

[banky]

>So the idea of write once, run everywhere, of course requires that a set of gfx libs are implemented on every platform.

Once upon a time, there was such a lib - OpenGL (and its free version, Mesa). However to counter this, a company (whose name you know) introduced a proprietary, platform-specfic graphics lib. It started off lame, and is now supposedly pretty decent. (This is how this company generally performs).

Anyway, such options exist, but mindshare has gone away from them, in favor of convenience - who needs cross-platform apps on the desktop, when there is only one desktop of consequence, anyway?

Re:Why bother?

[TheAJofOZ]

But do to the lack of universal Media APIs for your Java games to use

You mean like Java3D? Most of the time Java3D is a thin wrapper around OpenGL, but on systems with no OpenGL it can be implemented differently.

Admittedly, sound has a very poor record on Java, but there has been a recent addition of javax.sound to the standard API that I haven't looked into yet. Basically, with excellent 2D graphics support, 3D graphics support and sound support - what other media does a game use?

Disclaimer: I write business style apps and so I haven't looked into Java3D or Java's sound support much, but I also haven't heard massive criticisms from Java programmers about them either.

Can hear it already

[The Cat]

Wahhh it won't run Quake 47!

Wahhh it won't go 950 frames/sec!

Wahhh it'll only work for puzzle games!

Wahhh too slow!

Wahhh graphics!

Wahhh budgets!

Wahhh what's the point?

Guess what, folks: games must break out of the upgrades per second rut or they will never be economically viable. There are perhaps 10 projects per year that are good investments. The rest are "throw all the money in the air and hope we can catch most of it before it blows away." Those are the facts.

The retail box model is horribly broken and will likely never be fixed. Game budgets must be reduced, or the game industry *will* become Hollywood, and in 10 years, choice will have been crushed and there will be three companies at most making clones and sequels that everyone must gladly line up and pay $199 each for. (heh, for that matter, what's the game industry doing these days?)

These kinds of technologies are a step in a better direction where *gasp* we might actually make games for someone other than the couple million people who play fps games all day. That's why it is important. A Java game platform does not seek to solve the problem of faster frame rates, or more polygons, because THAT HAS NOTHING TO DO WITH MAKING A BETTER GAME. The sooner the game industry gets past this myopic "cram another vertex" mindset, the better.

Re:Why bother?

[TheAJofOZ]

Since Java3D is a wrapper for "OpenGL" (which strictly speaking is a standard, not a program or library), you clearly have a library for OpenGL hardware access.

Java3D is not a wrapper for "OpenGL". It is often implemented as a thin wrapper for OpenGL calls, but is itself a standard which does differ from OpenGL (most importantly that it is Java based, not C based).

This library is probably written in C.

Correct, most java implementations are written in C or C++, the question is not that Java should always be used in place of C/C++, but rather whether you should take advantage of the C/C++ code already written by using Java and thus gain the cross-platform benefits of Java.

Just as OpenGL is a standard, so is Java (proprietary/non-proprietary is not the issue here). The Java standard includes not only 3D graphics abilities, but also sound, 2D graphics and in fact everything you need to implement a game and provides cross-platform compatibility.

As far as speed is concerned there have been and continue to be great progresses made in JITC compilation which is making Java quite comparable to C/C++. You should note however that speed critical sections of code are written in assembly, not C/C++ and this capability is still avaialable in Java (obviously limiting cross-platform abilities, but at least only the speed critical sections need to be ported).

It is easy to give the kneejerk reaction that Java is slower or that you can do it in C anyway, but the fact remains that Java is fast enough for a very significant percentage of games produced and provides cross-platform deployment much easier than C/C++. The advantages of Java are numerous, so the question shouldn't be why bother, but why not?

no.

[autopr0n]

Java will never EVER be faster than assembly.

Thats probably because people don't have time to implement a lot of features when coding asm, not because ASM is faster. If you don't really know what you're doing, ASM code will be a lot slower then stuff spit out by a modern C++ compiler or JVM.