Become a fan of Slashdot on Facebook


Forgot your password?
Games Entertainment

Platform Independent Gaming? 505

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.
This discussion has been archived. No new comments can be posted.

Platform Independent Gaming?

Comments Filter:
  • by ImaLamer ( 260199 ) <john,lamar&gmail,com> on Sunday March 24, 2002 @08:50PM (#3217967) Homepage Journal
    I've seen this story of before []

  • by Dr. Bent ( 533421 ) <> on Sunday March 24, 2002 @08:56PM (#3218012) Homepage
    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).
    • 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?

      • 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
        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).
        • 1) FPS - runs slow on my 1.2G Thunderbird - no
          2) FPS - no other information
          3) Simulation - could be
          4) It's like #3 but without all the features - could be
          5) Business Sim - *wets pants in anticipation*
          6) Movie franchise - shit, if they can make a movie franchise game on 2600, they can do it in Java
          7) Simulation - probably
          8) Kiddie Simulation - probably
          9) Multiple games - dunno
    • 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). They were getting 60fps running 1024x768@32. The PCs were pretty beefy and of course they were using Nvidia's latest cards, but pretty cool never the less (They were also using the 1.4 JDK for MMIO). It can be done, just wait for a couple more iterations of Moore's Law.
      • by Stormie ( 708 ) on Sunday March 24, 2002 @11:01PM (#3218594) Homepage

        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.

        • 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.
          • 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.

            Dude, I know, I program PS2's for a living. That was my part of my point - Java is a replacement for "C++ code used to called gfx library functions", not a replacement for what you need on a console (on a PS2 anyway).

            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.

            Well, yes, if you value programmer ease over maximum performance. This generation of console wars will probably decide which way the console makers go in the future.

            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.

            Oh, of course, I wasn't suggesting that what you could do with the VU1 code you couldn't do any other way. Just that you couldn't get PS2 _and_ Gamecube _and_ Xbox _and_ PC all running nicely with one codebase, whatever the talking heads at Sun might think..

    • Check This Out (Score:5, Informative)

      by Enonu ( 129798 ) on Sunday March 24, 2002 @10:47PM (#3218526)
      This API absolutely rules: GL4Java []

      It works on Linux, Sun, and Win32, and it hauls ass to boot! Quake3 in Java? It's definitely possible!.

    • I agree with most of your post, but I think there is a way for Quake X to be written in java. Using NMI and OpenGL, I think anyone could get acceptable results considering that my computer spends more time waiting on the video card than the code to execute. However, Sun will probably fix their shoddy, broken implementation to actually work right just for this purpose. Don't let anyone convince you that Java is slow at math! I forsee much better 3D support in Java's very near future. This is the second story in the past week or so about this kind of thing.
      Anyone serious about doing OpenGL (which is anyone serious about cross-platform 3D graphics) should visit NeHe Productions []. They have examples for C, ASM, Java, C++, and even Python. They use a cross-platform NMI mapping that works on Unix, Windows, and Mac. You'll have to play with them to get them working though (classpath and security settings). Would be cool to set up a Java Webstart for them :)
    • by smallpaul ( 65919 ) <paul.prescod@net> on Sunday March 24, 2002 @10:51PM (#3218546)

      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?

    • Take a look at They have some screen shots there that might change your mind. Keep in mind, this stuff is pretty new. It's only getting better.

      As a professional Java developer, I've learned not to give up on Sun. Java's potential has jumped leaps and bounds in the last few years.
    • In fact, it DOES make sense that things like turn based and realtime strategy games could benefit from being written in Java, if you've got the right JIT behind the JVM running the code. The same could be said of several other genres of game. Now, a FPS or something in that same class would be a very hard sell- not impossible, but currently very improbable.
    • by mikec ( 7785 ) on Monday March 25, 2002 @02:38AM (#3219547)
      Think about this for a minute. Five years ago, I was running Quake on a machine about 1/40 the speed of the machine I'm using now, and Quake ran pretty well. Now assume that Java detractors are right and Java is only 1/2 as fast as C/C++. Why should it have trouble with Quake? Java runs many times faster on my current machine than carefully written C/C++ did on my machine five years ago.
  • I bet pong looks great on each.

    Really thou, how can you bang the hardware using java? Normally 3-4 years after the hardware is out, people start pushing the hardware to its extreme. Thats when the games truely shine. Will java be able to take in account all the extra features and use them? Then doesnt it break the "run anywhere" model?

    Cool idea, I'd sure like to be playing Halo on my PC right about now. :)
  • 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.
    • I don't see how any of the game system manufacturers would approve of this.

      From the original article...

      My inbox is constantly full of e-mail from the participants in the experts groups just banging away on the specification because they understand its importance. So along with Sun, we have companies participating like Sony Computer Entertainment...

      It sounds like Sony (developer of the PS2) is interested after all. Perhaps it's for their games consoles [], perhaps it's for their cell phones [], perhaps it's all hype, but they do seem interested.

  • I work in Java tooling.

    However, I don't think that Java makes sense for any *serious* (e.g. console/PC) gaming, you still need a healthy amount of native code to get anything done, right? So the idea of write once, run everywhere, of course requires that a set of gfx libs are implemented on every platform.

    So fine, even if you do that, suddenly there's no real competitive advantage for the consoles. There are features you wouldn't be able to exploit on some consoles, you would have to cut corners. Ultimately you are limited, you can't push the envelope without writing native code for a specific platform. The gaming industry has progressed SO much because pushing the technology can produce better games. I want quality games. Portability of gaming code, in this industry, has to take a back seat.
    • by banky ( 9941 )
      >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?
  • What are the odds that hardware vendors for traditional game consoles would back this? They all want you to own their box and their box alone... If you consider that MS published most of its good games from this season from smaller studios... They're probably not going to backa studio that says they want to produce a killer game that works on the PS2. PC compatibility is a different thing... maybe a game that is X-Box and PC compatible would fly... but expect it not to touch Java... I think this could be a Sony/Sun/Linux relationship or cooperation that could be quite interesting. Odds are slim... but I'd like to be surprised.
  • Read the article... (Score:4, Interesting)

    by SaturnTim ( 445813 ) on Sunday March 24, 2002 @09:15PM (#3218110) Homepage
    Let's thing about this for a moment... excluding fps titles... what games actually use 100% of the hardware they are running on?
    Certainly not all. Games like Escape Velocy Nova [] that are Very popular (and only available on the Mac) would work great even with the elegid java performance hit.
    Sure, Sun has a lot of work to do before this is a working solution... but you are fooling yourself if you think it can't be done.
  • 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.

  • As an example of a Java application (though it's not a game) that's pretty common, and runs well, take a look at Limewire. Obviously a virtual machine can't be as fast as native code, but they're definitely getting close. Macromedia Flash also uses Java (at least the Linux version does, anyway). At any rate, I'd like to be able to take a disc from one system and use it in another just as much as the next man, but then that would defeat the point of having multiple systems. Each game console, for example, has its own unique strengths, quirks, and so on. I like the dreamcast because it was fun getting Linux cross-compiled for SH4 and burnt to a CD. I like the PS2 because it uses a 297MHz R5900 (ohhhh, MIIIPPS), and has official commercial support for Linux. Running everything in a virtual machine would take those strengths away, since it wouldn't be possible to take advantage of them without breaking compatibility.

    • a virtual machine can't be as fast as native code, but they're definitely getting close

      Bzzzzt....incorrect. Read up on Hotspot. A VM can certainly be faster than native code, particularly in long running iteration-intensive situations. Can anyone say game engine?

      All in all an interesting idea, the problem Java will have is getting the stuff to the screen - but there are decent gfx libs coming along. Can't wait :)
  • Really......

    Do you honestly think that for really interesting games any virtual machine layer will not add so much overhead as to make the game unplayable? Sorta like Java Swing adds overhead to simple Windows you can get to see various Windows being repainted?

    Most people do not like watching Windows repaint.

    No offense to Sun...but the folks who are cutting edge on gaming will always write down to as specific as they can get to get as much performance as they can.

    Besides....doesn't it seem odd that Id Software
    has ALREDAY made it possible to play their games on any number of platforms...all by strictly coding in C.

    But Id Software doen't make java, or workstations. They just make great games.

    • Re:Get Real! (Score:3, Informative)

      by LadyLucky ( 546115 )
      Swing is a bad example. It runs slow even when compiled to native code (in fact, a bit slower). The problem isnt the java, the problem is the inherent design of swing in which you are very deep in inheritance trees, much abstraction going on.

      An example of why java guis dont need to be slow is eclipse. You can't tell its written in java (except maybe the slow load time :-)), but this uses a a different windowing toolkit.

      In summary, the VM adds overhead, yes. But the VM is not the cause of a lousy GUI toolkit.

  • As I see it, this is missing 2 things, neither of which Sun can really control.

    The first is performance. Sun can take some steps to make this better, but games are about raw power. In order to do so, they'd have to really get their asses in gear. It might be easy to make the back-end deal with distributed processing and RMI and all that stuff, but the front end needs to haul ass.

    The second problerm is MINDSHARE. In my experience, the vast majority of programmers (and probably games guys even more so) don't care about cross-platform, because THERE IS ONLY ONE DESKTOP PLATFORM. Some of them expressed interest in OSX (with Java, OpenGL, and all that) but really, they only see Windows + DirectX.

    (Most of them don't even care about portables, phones, or Playstations for that matter)

    Sun needs to overcome the midnshare thing, and get to work on the speed thing, before it even has a chance on the front end.
  • As long as people are willing to code to the bare metal to squeeze as much performance out of their hardware as possible (and then achieve a few miracles beyond that) this won't catch on. Sure, the development costs will be lessened, but at a substantial hit to performance. This will kill any company's hope in an industry where everyone's convinced that graphics is more important than gameplay. It isn't, but that's still the marketing angle that everyone uses.
  • Java is a sweet programming language. I can't stand C++. Hopefully if they can get this going (or at least produce a usefull API for lin/win/mac games) java will be a viable option for dong 'real' game programming.
  • by Spencerian ( 465343 ) on Sunday March 24, 2002 @10:04PM (#3218352) Homepage Journal
    In 1977, many people were astounded by the first console video games and arcade games--devices unimaginable by the scientists, much less entertainment industry because the technology at the time was rudimentary for such devices.

    But the popularity helped to fund the technology improvements and the gaming industry took legs.

    Now, we play games with millons of colors in 3D spaces with near-virtual reality situations. It only took the maturity of the technology to make it possible.

    Would Java game playing require a new technological paradigm to work? Sure--it can't work under the current model. When games first appeared in the 70s on TV, there was NO significant competiton. Today, the competition is too fierce for a new idea to compete directly and the performance of current games easily exceed what platform-agnostic programming might offer right now.

    But then, Atari's games started with a handful of very large pixels and simple game premise. Nobody thought a video game would point the way to what has become.

    For Java to work, it would need to take on a new competitive edge. I would suggest taking the open-source approach to the commercial side. Make a MAME-like, open source game player (this may take care of the hooks needed for platform performance) that's freely distributable and extensible.

    Next, sell games. Some may be free, others not. But ALL could be placed on any OS and platform desired that supports Java. You would think that we have the ability to improve Java through hardware (such as a PCI Java "processor" expansion, also available for all platforms) or even let processor evolution handle it.

    I'm not a pro programmer, but Java's general specs could be made to work, if companies like Microsoft (who are so profit driven to stifle competition) don't intervene. It would have to take baby steps.

    QuickTime, Apple's movie/multimedia technology, started with movies the size of a postage stamp and was the first viable movie technology for computers. Today, it allows you to watch "Star Wars" trailers (don't start with the "Pro" version stuff--that's just Apple being a business). What could the future hold tomorrow if the playing field stays fair, although not necessarily even?
    • Actually people like Capcom and Konami have been doing this for a while. Their arcade boxes ran pretty select hardware for specific games which is one of the reasons arcade machines are so fucking expensive and the console versions of the games don't look quite the same. The games are almost always run inside of an emulator on the console which makes it cheaper to port games to consoles. Rather than rewiritng all games to specific console hardware they only have to write a snappy emulator for the console to run the game inside of. The SNES didn't have half the components that the SF2 arcade boxes had in them but Capcom made a really badass emulator that took advantage of what the SNES DID have. What Sun wants to do with Java and game consoles is extend that concept to a more general virtual machine than an emulator.
  • 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.
  • by The Cat ( 19816 ) on Sunday March 24, 2002 @10:26PM (#3218439)
    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.
    • The retail box model is horribly broken and will likely never be fixed.
      I agree. That's why this story [] about Valve's [] new "content delivery system" got me excited. New ideas like this that embrace the internet and cut out the middle-man are the future.

      The movie, music, and most of the gaming industries don't get it. They're just dinosaurs waiting for extinction. The only thread they have left to hang on to is the law. If they can't beat you, they'll sue you. If we don't speak up to our legislators, more draconian laws will be passed that will limit our freedoms and supply them a lifeline.

      The Sonny Bono Copyright Term Extension Act [] & DMCA [] need to be repealed; and the SSSCA [] (now CBDTPA [], or whatever it's called this week) needs to be killed before it makes it out of comittee.
  • The GameCube uses "Mini-DVDs" instead of the larger ones used by the other consoles. If they want to create something that is cross-compatible with all of the current consoles, they'll either need to make all of the Java-coded DVDs small, or insist that people purchase a Q console if they want the best of both worlds.

    (Q is a GameCube clone by Panasonic that can play DVDs. It is unlikely, however, that it will ever be sold outside of Japan.)
  • Anybody remember Ultra HLE? It's a N64 emulator. I never got the chance to muck with it because I never had a Voodoo 2 card, but what I read about it was very interesting. It didn't emulate the processor of the N64, instead it was a translator so that commands in the ROM went to native commands on the Voodoo card. A 'draw triangle' command on the N64 would be sent to the Voodoo card and translated to 'draw triangle' in the native hardware. This is different from trying to get the PC's main processor to emulate what the N64 processor would do.

    In other words, it was more of a translator than an emulator. Now that I think about it, isn't Wine like that?

    Would this approach work with games? It seems like if this technique were ported to the PS2, GameCube, and XBOX, it would be possible to make portable games. Each one would have to be tweaked a bit on a per-platform basis, as each system has their strengths, but they probably could go a similar route that Ultra HLE did.

    I have concerns about using Java for it. The problem is that the game hardware is a little too different. One technique that'd work on the XBOX would have a different effect on the GameCube, just because of how the graphics co-processors work. I think it'd be possible to make one game engine work on all machines to run the same code, but I don't think Java would be the solution. I think a cross-platform engine would be more suitable.
    • HLE in this case stands for High Level Emulator. It's emulating the API (like Wine, which emulates the Windows API) rather than being a machine emulator.

      I imagine UltraHLE had to do some machine emulation, though, but maybe less than even an average SNES emulator would have to. Just enough to cover some of the games hitting the metal at times.

  • Though it may be good for the consumers, and the developers, this will not happen. Nintendo, Microsoft, and Sony make their money from games that come out on their platform. They have no incentive to support a technology that will aid their competetors.

    Also, part of the reason that Java and C# have caught on as well as they have is because the PC is really quite stable in terms of basic functionality. Aiding this is the dominance of Windows. But the products that have really benefited from Java are not games. They are internet applications and productivity applications. Games are very dependent on exploiting the target hardware to the fullest. Also, that hardware is anything but uniform in its functionality. A Game Cube has no real resemblance to an XBox. A PS2 has no relation to any sort of other existing hardwrare. If a game was truly platform independent, it would look like a barely average game on the weakest of all of the platforms.

    The only way this would succeed is if either Nintendo, Sony, or Microsoft become the ONLY player on the console business. And if that happens, there is then no longer any need for a platform independed game development language for Consoles.
  • Part of the problem with the game industry is that there are too many games in it. For now, it's okay because there are still lots of people not playing games yet, but eventually it'll turn into a market where there's 10 new games for every game player. Uh oh. I don't have $500 a month to spend on maintaining a game library.

    What effect will this have on the game industry? Well, that's a little hard to predict. Here's a problem I face today. I bought a GameCube, I love it, but occasionally there's a game on the XBOX that I'd like to get. The problem is that the $300 I'd spend just to get the system is at least 6 games I could by on my GC or GBA. It would definitely be in my best interest for these games to be portable across the various systems.

    Here's the problem, though. The dividing line that's preventing me from having too many games is the fact that I only have the GC and GBA. The different games coming out on the XBOX are so seperate for me that I'll continue to be a Nintendo customer. That is great for the companies that are focusing on Nintendo. But if I can suddenly play XBOX games on my GameCube, then it's just a flip of the coin which platform I want, and I'll be able to play all the games. Well, this leaves Microsoft or Sony with very little left to do except try to make new platforms for me to play on. The console market will suddenly turn into the PC Market.

    The unfortunate problem here is that the PC Game Market isn't as lucrative as the Console market in some respects. The average shelf life of a game goes way down. A successful game is rated at like 500,000 copies sold, versus 2 million on the console platform.

    Is there hope? Oh yeah. Eventually PC game makers will realize that a price drop would be in their best interests. If the average PC game were $35 instead of $50, people could splurge a little more. More copies would get sold. If the majority of the people who would have spent $50 on one game decided to spend $70 on two games, then the industry's audience widens, allowing more games to get made.

    Personally, I think it is in everybody's best interests if the line between each console stays thick. Stick with a platform, cater to that platform, and then watch the money roll in. There's nothing more frustrating than having a game's quality diluted because it was transported to other different consoles.
  • While we're still waiting for the Java OS, Sun comes with an even wilder idea. There ideas continue to impress, there accomplishments however, well that's another story.
    • "While we're still waiting for the Java OS"

      There has been a JavaOS. I remember downloading it years ago for the x86 platform. You had to boot into it from DOS. I can't remember whether it ran on top of dos or not, but the OS itself was very basic- think of a crappy desktop with a few token things like a calculator.

      Basically it was just a shell for graphically launching java programs, which I thought was cool at the time because it meant you could run java progs without windows.

      But then I tried to run java progs with it and changed my mind...


  • I'm not going to say that any particular JVM I've used has been amazingly fast (i.e., coming anywhere close to a C app), but the potential is there.

    Garbage Collection can actually improve locality, and thus cache hit rate... which leads to faster performance. Years ago, in 6.001 (a introductory programming class), we all had to read about how generational GCs can result in a net speedup due to improved cache performance, *including* the cost of the GC itself. I'm not saying this is common, but it's possible.

    Also, a dynamically recompiled machine can perform runtime optimizations that you just can't do at compile time.... finding hot traces and inlining them, for example. The Dynamo project dynamically recompiled PA-RISC into PA-RISC (yes, kind of strange) and got net speedups over -O4 executables in several cases. The same technology can be applied to Java.

    Again, I'm not saying we're there yet, or that we'll ever get there with Java, but the nay-sayers should realize that a VM language system allows for all kinds of "magic" optimizations that CAN more than make up for the overhead of the VM itself.

  • Ok. Games now have a few gigs of data. Why not just load a whole OS off the disc? Developers could get as fancy and cross platform as they want as long as they can port Linux or whatever to that console's archetecture. This would royaly piss of console makers, but who cares. Maybe consoles will become more like PCs where you can get the latest console every six months instead of every two years.
  • Check this out (Score:3, Informative)

    by AKAImBatman ( 238306 ) <{akaimbatman} {at} {}> on Sunday March 24, 2002 @11:35PM (#3218733) Homepage Journal
    Duke Nukes Stuff []. Before the code was VSync locked (and timing locked) it ran 400 FPS! Say what you will, but Sun has come through this time. See Java Gaming [] for more info.
  • This sounds familiar (Score:3, Interesting)

    by Entropy_ah ( 19070 ) on Sunday March 24, 2002 @11:41PM (#3218763) Homepage Journal
    Do you guys remember when windows 95 was first released? Well, game developers shuned it despite microsoft's promise of some library called DirectX. Game developers and end-users had trouble coping with the percieved performance hit that games would take when written on top of windows (who needs another layre of abstraction when you are writing for performance). Well, DirectX and OpenGL on the windows platformhave since matured and almost all games are developed exclusively for windows. And i'm sure you all can see the parallels to todays talk of java gaming.
  • 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.
  • by Trepidity ( 597 ) <delirium-slashdo ... g ['kis' in gap]> on Monday March 25, 2002 @02:18AM (#3219449)
    Two consecutive Slashdot stories:

    -- Platform Independent Gaming?

    -- Ask Slashdot: Most Outrageous Vendor Lie Ever Told?
  • In order to have seamless cross-platform, you have to have a very significant abstraction layer between the application and hardware. You have to have a layer that adapts to the specific querks and architecture of the underlying machine and presents a uniform interface to the application.

    Well, in order for this to be done there will be significant overhead -- almost to the level of emulator overhead. It will need to be sufficently smart also, for example you can't use any of the standard libraries like OpenGL or DirectX because some hardware may not support them and thus the application will break. This implies the creation of your own libraries which scale to specific hardware to use its features and capabilities.

    Well, Java currently does not offer this. What it does offer is a good way to get really good simple apps running on a wide variety of hardware. However, games will always need 100% of what hardware can do to stay competitive, and by nature need hardware-level access. This means stuck to a specific platform, which is unfortunate.

    If Java can provide really good hardware abstraction, with really good 3D graphics and sound libaries which are not dependant on 3rd parties, then there will still be a speed hit. Game developers need to attract people based on the latest technology. Being able to have products play in already niche markets doesn't interest too many.

    I am sure such platforms as Linux don't even enter a game developer's mind -- they're too worried about what the competitor is doing on the graphics/game end.
  • Illwinter [] have accomplished something very much in spirit of what this discussion is about with their Dominions game. This game works on Windows, Linux, Solaris, IRIX, and HP-UX.

    Wasn't too difficult either, mind you.

    All you have to do is have different executables for each platform that all work off the same graphics, sound, level, etc. files. Given the current state of the gaming scene, it's most likely that the bulk of development is done on the accompanying graphics and audio files, complex game engines notwithstanding.

    There ya go, no need for portability of code :)

  • I find the /ignorance almsot amusing.

    Would anyone else who actually WENT to the GDC like to comment? Here's what I saw at the Sun booth...

    A Granbd Prix racer that looks as good as EA's latest , was cross paltform compatable with Win32, Linux and Solaris, and ran at better then 60fps on 1.4gig AMD witha GF3 GTS.

    An FPS, equally portable, that ran at 145 FPS on the same kind of box.

    A poster sized copy of the PC Gamer reveiw of Roboforge, a commerical game from Liquid Edge. PC Gamer gave it an "Excellent" rating (87%, which is very high in their scale.)

    A 3D fighting game with real interactive shadows that ran at 60 fps on the 1.4Gig/GF3GTS box.

    A MMOLRPG that looked terrific (better then EQ or DAOC, at least that's what pothers around me looking at it said) that apparently also runs on Win32, Linux and Soalris./ theyd eveloerps told us it took them a total of 2 hours fro mwhen theyw ere first handed a Soa\laris box til they had it running.
    (See their GDC report at

    An internet "Smash breothers" type game in 3D that looked and palyed terrific on both Win32 and a OSX Mac.


    >>> flame on

    Ya gotta love the internet. Its the only medoum I know of which so freely allwos thsoe who knwo nothing to inform those who knwo less. And slash tends to be the internet in microcosm.

    Open your minds to new ideas and its amazing what "impossible" thinga you will discover are already happening.

    flame off

  • by mikeee ( 137160 ) on Monday March 25, 2002 @11:53AM (#3221327)

"In matrimony, to hesitate is sometimes to be saved." -- Butler