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

[Dr. Bent]

If the only types of games that Java can truly implement and make platform-independent are (relatively) slow, light on graphics, or "written for smaller segments of the market", is it really worthwhile to pursue this as some sort of holy grail?
Sure, it's easy enough to write Tetris in Java and make it platform independent, but how does that help the people hanging on to their Windows platform in order to use Unreal 7, Wolfenstein 6D, and Tribes 4?
As of last week, these are the top selling PC video games (according to ArsTechnica.com):
1) Command & Conquer Renegade
2) Medal of Honor: Allied Assault
3) The Sims: Hot Date
4) The Sims
5) RollerCoaster Tycoon
6) Harry Potter and the Sorcerer's Stone
7) Civilization III - Infogrames
8) Zoo Tycoon
9) Entertainment Multi Pack
10) The Sims: Livin' Large
I would bet at least half of these games could be written in Java and still have the same level of game performance. In addition, I would bet they would cost 20% less, take 20% less time, and not require any additional costs to port to other platforms (or additional distribution or maintainence costs for different versions).

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:This can only work for some games

[Elevation]

Except that you DON'T use C++ to program to the PS2's hardware. The Vector Unit's use macro (VU0) or micro assembly instructions that are preloaded into their instruction memory before running. Similarly, programming the DMAC controller relies upon building a DMA chain structure in memory and then triggering an upload. What should happen is that the graphics library exposes a clean interface to the programmer, either C, C++ or Java and NOT assembly or hardware related. OpenGL could certainly have extensions added to facilitate any specific hardware requirements that a console might field. And the graphical effects programmer might have to reorder texture/model drawing and transfering commands for optimial performace, but this could certainly be done in either Java or C++.

Lets not forget that most major game companies use cross-platform graphics libraries such as their own OpenGL implementations or commercial offerings like Renderware. Sony's PS2 dev team themselves has their PS2GL project to expose a clean interface to the PS2. And to take your example of the Bezier subdivision used by SSX, well that game has been successfully ported to both the X-Box and the Gamecube with added graphical effects.

Finally, it is rather unlikely will again choose such a radically different architecture without providing a clean graphics API along the lines of OpenGL for their next consoles. It took a full year for games that made full advantage of the PS2 to come out, by which time the next gen consoles from Nintendo and Microsoft were coming out! Sony made the developer's jobs harder than it should have been and paid the price by having a lackluster game offering for the longest time. Luckily, truly excellent games such as GTA3 allowed them to triumph over their competitors last Christmas.

This will never fly

[DragonMagic]

Because the developers of the systems are almost always losing money, or just barely making a profit, on the game systems. They make their money by the licensees developing games for their systems, and by having people want to buy their systems to get those games.

To be clearer, if you have system A, and have company B develop games only for your system, and those games are popular sequels or highly sought after, all the people can do is buy system A to play these games. By buying system A, more developers will want to license to develop games for your system, since that will probably mean a higher yield of sales.

Now, if suddenly people can play system A games on, say, systems D, G, L and P, then exclusive contracts are pretty much useless, and as such, there's no real push to buy any single system. Most people will go with the cheapest system.

I don't see how any of the game system manufacturers would approve of this.

Fast language like C++?

[TechnoLust]

Well, actually Java is very similar to C++. If you study your Java history, the guy who thought up Java (I think his name is Gosling) was a C++ programmer that didn't like some of the things in C++, such as multiple inheritance. He rewrote some of the compiler rules that removed the things he didn't like and included some libraries of things he did like. Since then, Java has developed into it's own language. I program is C++ and I just learned Java, and I do most everything in Java now. You CAN do 3D in Java, and if you do a good job, it isn't slow. You can natively compile Java to only run on one processor, like C++, but that defeats the whole purpose. Compiling it to ByteCode and running on a JVM is the way to go. The latest JVMs are a lot faster than previous ones. If you haven't looked at Java in a while (and I don't mean the cheesy web applets) I suggest you take another look.

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.

Java's Crossplatform Shortcomings

[mgrochmal]

A cross-platform compatibility would be great. However, it would have several hurdles to overcome before it accepts widespread use.

1) Performance - As others have already stated, Java is made for compatibility, not for speed. Most mid-range applications would start to drag down the machine, while hardware-specific code will enhance the speed and execution of the application. The games mentioned in the article are not hardware-intensive (You don't Know Jack, Who Wants To Be A Millionaire, Majestic), so they can transition to Java easily enough. For specific programming projects, such as graphically intensive games, many developers will probably stick to current standards or in-house programming languages.

2) Industry Support - XP's omission of a native Java RTE shows that not all developers are willing to go with Sun's development software. Additionally, many people buy consoles for specific software applications. If the need for a proprietary standard is removed, then people will go for whichever hardware setup is easiest to acquire. The game companies can't force people to get specific consoles to play games on. Yes, most of the video game consoles sell at near-cost (if not below), but many games are identified with a certain platform. Also recall a few years back, when Nintendo sued developer companies that didn't get its Seal of Approval.

Cross-platform programs would be appealing to consumers, but it will come down to if Java programming will find acceptance among other companies.

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?

An academic argument.

[Bitsy Boffin]

All of the posters saying how this can't be done, because of Java this and Java that are arguing a purely academic argument.

Why ?

Because no matter if SUN can make Java into a good game environment or not, the fact stands that the console manufacturers would never allow it.

Think about it - if a PS2 could run the exact same stuff as an XBox and vice-versa what distinguishes the two. It would only be a matter of time before SONY and Microsoft write a clause into their developer contracts...

x.y.z No Java Clause :
You may not write your game in the Java language. Because it will eat into our marketability too much.

Consoles are a closed box system, the manufacturer of the console has complete control over what they will and will not allow with respect to what runs on thier console.

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?

Re:Whoa whoa! Stop the "portability" train!

[bolthole]

It is apparent that the only clear choice for game development is still well-written C. It's fast, clean and, if well-written, far more portable than Java could ever hope to be.

Presumably, what you MEANT to say, was

"... is well-written C, using a consistant, stable graphics API that is available on all platforms".

And even once that is satisfied, you STILL have to convince the software makers to RECOMPILE FOR YOUR PLATFORM.

You gonna go bug them all to recompile for OpenBSD? hahaha.

Whereas if it was java based, "all" you have to do is catch up to the other *BSDs, and get java working properly on your platform of choice.

it defeats the purpose

[SouperDouper]

The beauty behind consoles is that when programmers make games for them they can optimize the graphics and gameplay to get the best possible experience for the game. Using java on top of their built in functions would dramatically slow down gameplay, quality, etc. If they go this route, I will truly have a reason never to own another new console.

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.

As if Java isn't slow enough

[timecop]

Now we have this?
Cmon, let's beat it already. Java is dead. Deader than BSD. C# is the future, and (unlike some mexicans will have you believing) only on Microsoft platform.