IWhen it's about making money, you have to please your customers, not the techies.

I thought we were talking about the contest? What you do for your business is, well, your business. But as far as the contest is concerned, I'm thinking it won't be a good thing to bundle the JRE. The judges probably wouldn't be too happy if every Java entry had a JRE bundled with it when they already have a perfectly good one installed. I know I wouldn't. My advice to you is to post in the contest discussion forum and get the opinion of a GDNet staff member.

Of the over 250 client license of my software installed in the last 3 months, a grand total of... 2 ..I say again... 2 had Java installed, and both of those were 1.3.1, which couldn't run the software.

Statistically, that's 1 in 100 had Java and 0 out of 250 could run a Java 1.4.2 webstart application My client is a Java 1.4.2 webstart application.

I was a bit torn one way or the other before on this topic - no more. I was being naive and forgot that the biggest problem with software is not bugs - it's 12 inches from the keyboard.

Of the over 250 client license of my software installed in the last 3 months, a grand total of... 2 ..I say again... 2 had Java installed, and both of those were 1.3.1, which couldn't run the software.

Statistically, that's 1 in 100 had Java and 0 out of 250 could run a Java 1.4.2 webstart application My client is a Java 1.4.2 webstart application.

That's a little biased - everyone with java 1.2 or above "can run" a 1.4.2 webstart app, even if it's going to force them to upgrade to the current JVM *that you need for almost all games anyway*.

Seriously, java 1.3.1 is bloody awful, and you need some pretty exceptional reasons to still run it .

Maybe the people with it installed just don't use Java and have no idea that it is even there or that, being there, it could be improved...

Exactly what I think I believe you pretty much have to distribute the JRE with your app. I think it's even more important then Windows games developers distributing DirectX xxx with their game, and 90% of them do for pretty much the same reason - counting on the users to get it on their own is just going to leave you with a boat load of support calls, or worse...them giving up and just playing someone elses game.

When they include direct x, they include the installation on the cd. They don't embed it into the game.

EDIT: agreeing with MP, in case it werent obvious

And they wouldn't make much money if they did - DirectX detection infamously is frequently broken, failing to recognise that a newer version is already installed, or that the OS has an embedded version and that the on-CD version *cannot physically be installed* (the win9x directx could not install on winNT, for instance).

So, you leave it up to the user to run DirectX if needed. Generally, they won't [need it], but often, they will.

Sigh. Given the amount of technical knowledge players need to pick up to get games working - becoming adapt at manipulating graphics card settings etc - it's faintly ridiculous that we're having this conversation . Specific cases - "web games" where you're specifically targetting the "non games-playing" audience - have specific needs, but even so there's a collective ignorance about how many hurdles the player has already overcome with stuff like "getting my grapihcs card to even fricking work (thanks, nVidia and Dell, for supplying a broken install out of the box)" [insert ATi and (any vendor) in that sentence as appropritiate: they're all as bad as each other].

...not that I'm trying to squash the conversation, but ...sometimes I feel people are lacking a certain perspective of the *context* within which individual players are operating.

When they include direct x, they include the installation on the cd. They don't embed it into the game.

True (mostly), but if the games are downloadable, they typically develop for ancient versions of DirectX that came with the operating system or were most likely installed by some other game within the last 3 years. Check out the web downloadable games developer sites, like Indie Gamers, there are endless dicussions about this topic.

We are at a much bigger disadvantage then the DirectX guys - there are very few Java games, so it's unlikely they users have installed one that installed the JRE and on Windows (the main platform), the operating system doesn't even come with an outdated version that we could develop for.

We are at a much bigger disadvantage then the DirectX guys - there are very few Java games, so it's unlikely they users have installed one that installed the JRE and on Windows (the main platform), the operating system doesn't even come with an outdated version that we could develop for.

Those games that do include the JRE usually include a private JRE that is not for gernal use in the system. The idea being that they can't then depend on it getting upgraded/changed in a manner that makes tech support difficult and could break the game.

That's the advantage of Web Start - that it will manage a set of public JRE's for you.

Personally I think it's great to have a choice between embedded and webstart. "If you don't know the java version of the jre or if you don't know if you have a jre installed or if you simply don't know what I'm talking about pick the embedded one bla bla"... easy enough, isn't it?

When they include direct x, they include the installation on the cd. They don't embed it into the game.

True (mostly), but if the games are downloadable, they typically develop for ancient versions of DirectX that came with the operating system or were most likely installed by some other game within the last 3 years. Check out the web downloadable games developer sites, like Indie Gamers, there are endless dicussions about this topic.

So what you're saying is that if you're going to make a small game, you should develop for a technology that the users already have instead rather than to bundle it with your app or forcing the user to download it? [1]Which is kinda my point. If you're going to make a tiny "casual" game, don't develop it in Java or C# using opengl 1.4 for the rendering.. develop it in flash.I realize a lot of the people here[2] love java and want to use it in everything they do, and that's fine. But that doesn't mean it's the right thing to do.

How about this is as a compromise - build an embedded and non-embedded - Then leave it up to the users:

Full Install - 8.4MB - If you don't have Java 1.4.2 installed or your unsure, use this linkGame only - 5.1MB - If you have Java 1.4.2 installed

Either way, I still don't see what the big deal is. If you run games (and even other types of software), your hard drive is full of duplicated code. Many C++ games are developed using standard engines, libraries and API's, should they all start using common external .dlls for those? Do you think they actually would? Why should the C/C++ guys get it easy while we invent new ways to complicate the users experience all to save a bit of disk space?

Hard drive space is cheap - most people are oblivious to the amout of duplicated code they get from C/C++ games. Why would they care any more about duplicated runtime code from Java? This is an issue the Java community created, not the users.

Full Install - 8.4MB - If you don't have Java 1.4.2 installed or your unsure, use this linkGame only - 5.1MB - If you have Java 1.4.2 installed

But when you use webstart (on windows only) you can semi-automatically installs the JVM if needed by redirecting you to the Sun java download page - so ... why isn't the java 1.4.2 link the "if you're unsure" ?

(find a machine without java and try and play any game on JGF...)

Quote

Either way, I still don't see what the big deal is. If you run games (and even other types of software), your hard drive is full of duplicated code.

Two massive problems:

1. Huge waste of bandwidth; downloading the whole of JOGL is bad enough for each game. Doing JOGL + Xith3D is worse. Doing BOTH of those AND an entire JVM is "enough time to go and make a big lunch and eat it". All for a game that *would* have only taken 1 minute *if* it had been packaged properly...

2. DLL-hell. On windows, your duplicated code causes half your games to crash, and sooner or later breaks your OS, so sooner or later you have to re-install windows.

Quote

Why should the C/C++ guys get it easy while we invent new ways to complicate the users experience all to save a bit of disk space?

You've got it the wrong way around: C++ guys f**k peoples computers up, and if we only explain this to users and get them to understand that java *cannot* and *will not* do this, then you'll see the C++ guys scurrying to make up for their crapness - or find *their* games not being trusted.

Quote

This is an issue the Java community created, not the users.

In several areas, Java does right what C++ has been doing wrong for decades. But Sun's completely incompetent marketing dept have woefully failed to explain any of this to the world .

2. DLL-hell. On windows, your duplicated code causes half your games to crash, and sooner or later breaks your OS, so sooner or later you have to re-install windows.

I don't think you got it. The jre will not be "installed", but be a part of the game, stored in the same directory as the game. It will not mess with the registry and there will be no conflict. The game will only use this one jre, so you don't have to worry about bugs in old jre or any potential regression bugs in future runtimes. You don't have to worry about the user uninstalling, downgrading or upgrading the runtime. All of witch can brake your game. The only problem is the size, and cas have found away around that problem. So, no worries.

2. DLL-hell. On windows, your duplicated code causes half your games to crash, and sooner or later breaks your OS, so sooner or later you have to re-install windows.

I don't think you got it.

Nah, you just missed the context in which I was replying (I was replying to someone asking why we java people were making up problems here - why not just let everyone download N copies of everything?).

Of course there's no problem with duplicating JRE's, just like there's no problem with duplicating libs in java downloaded via webstart - but lots of people encounter nasty problems even with java if they decide to ignore webstart and force people to install java3d for instance (which is generally neither forwards nor backwards compatible - so installing a new version breaks apps that were otherwise working).

The whole thing is such a non-issue brought about by anachronism and a daft license.

The anachronism: memory is expensive, disk space is expensive, bandwidth is expensive. This is absolutely not the case. It's cheap shit now, all of it. It's such cheap shit that we can afford to waste rather a lot of it on a VM in the first place.

The daft license is the bit that has hitherto prevented anyone from actually addressing the problem that while bandwidth is cheap, patience is not.

Let Sun work out the evangelism on Webstart, that's their bloody job. We'll just show how good Java is at games and carry on distributing our fully encapsulated software, happy in the knowledge it's small and reliable. But I'm not doing their work for them and evangelising Webstart to the unwashed gaming public. That's an uphill battle that not a single one of us has any chance of making the slightest bit of headway with. Christ knows I've been trying for years now.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org