Webstart vs. EXE - should JGF allow both?

General Discussions
#1

One of the founding ideas behind JGF was to incentivize authors into making their games cross-platform, webstarted - and showing how well things work when you do that (if all the games share common libraries, everything gets cached, etc).

Webstart is a huge deployment advantage for java games, but is not marketed by Sun, so I constantly attempt to promote it; JGF serves as a fairly good poster-child for this, given it does autaomatic-webstarting of anyone’s games.

But…as discussed endlessly in these forums, there are still serious flaws and even some major bugs in Sun’s implementation of webstart - and some basic stuff they urgently need to do, but haven’t done yet. All in all, this leads to most of us distributing games as webstart and a compiled EXE side-by-side.

But…at the moment, JGF only allows pure x-platform JAR’s, which it converts into webstarted JAR’s.

So…should JGF host EXE’s as well, and - if so - how much prominence should they get?

#2

…bearing in mind that one of the aims of JGF is to convince people that you don’t market a java game using a Java icon, but just as a “click here to play” link - so e.g. putting a windows icon and a java icon side-by-side is self-defeating: that’s just re-inforcing the belief amongst players that they should “prefer” to play the non-java version of a game.

Furthermore, one of the aims of JGF is to educate players themselves into preferring webstarted games (we know they’re better, but they don’t … yet).

#3

Hey Blah3,

While I personally don’t see many big problems with the current WebStart (i.e. it’s always seemed to do what I expected). If you allow EXEs then why not Mac Application bundles? You could also generate them on the fly from a executable JAR submission.

What about the new features added to Web Start in Java 5 that allow you to initialize the Web Start cache so you can distribute your game on CD and have it update with Web Start? Is that broken? Can the EXEs that you propose distributing be made to work that way?

And while you are going on about the flaws in Web Start can you list the Sun Bug #'s that correspond to these complaints? That way we can possibly toss a vote their way. If you are going to promote Web Start (and I’m way on your side in doing so), I think it is important to work within the system that Sun has to report these problems and gauge their popularity. So JGF should link to the bug reports that are relevant to Web Start and encourage visitors to vote for them.

#4

Indeed, and it’s something I promised to look into doing some time ago :). Feel free to vote on the poll substituting “Mac bundle” for “EXE” - it’s the same issue: To what extent should we be promoting non-x-platform distribution, as opposed to just presenting users with a single HREF link that “Just Works” - except for the crappy bugs on their OS, which it’s up to their OS provider (apple) or JVM provider (Sun) to fix.

With no pressure on Apple and Sun to fix their crappy code, things will never get any better :frowning: …

(Could someone who’s actually tried this chime in? I’ve not even got 1.5 :frowning: )

I think the problem is that people wanting to distribute EXE’s want to dist small EXE’s - i.e. with most of the JRE taken out. In that case, making an EXE that installs java, installs the game, and puts the game into the webstart cache, is going to be much bigger than they wanted?

OTOH, you could say “if you want small downloads, tell them to just use webstart in the first place” :wink:

Sounds a great idea, but it’s a matter of finding the time to do it :frowning:

Any thoughts on where / how that page should fit in to the rest of the site? Should it be an article that explains each bug and it’s importance, or just a single page with a brief sentence on each alongside the JDC bug parade link?

#5

As far as providing native application launchers goes, I don’t think it is going against the Java philosophy. Particularily if you are automating the generation of these launcher stubs… to the game author it is still ‘write once’.

The benefits of Web Start are still apparent in that you don’t want to lose the auto-update ability. So this is certainly a compromise of sorts.

Mac users prefer application bundles - specifically NOT the kind that the Web Start launcher will make, because they can easily drag and drop such bundles to relocate them. Even to move them to other systems, which does not work 100% properly for the Web Start created bundles because the Web Start cache entries don’t move with it. It’s effectively just moving the JNLP file in that case.

Anyone likely to register with Sun so they can vote on a bug likely doesn’t need more than a simple list of bug # links and the one-line description. This should be in the developer section for sure, and maybe as a link in a troubleshooting FAQ section for general users. Just add a short encouragement on the page before the list is all you need. “Please encourage Sun to fix these distribtion issues by voting, providing feedback, or even patches for the following issues:”

#6

[quote]incentivize
[/quote]
hahaha, that can’t possibly be a word.

Oh my God!
You crazy Americans! ::slight_smile:

#7

I voted Web Start and EXE side-by-side. But under the assumption that somewhere on the page it would be made clear that the Web Start version will by auto-updating if (as I suspect) the EXE will not be. Basically letting the user know they will not have to check for updates themselves to be sure they have the latest fixes.

It’s an important part of marketing Web Start that the end users realize what it does for them, other than give them an odd non-standard launching mechanism that they aren’t used to. :wink:

#8

The end-user doesn’t want to know it’s Java, it should work. Due to it’s reputation among gamers, you might want to hide it all together. So native launchers are a very good thing if you want to distribute your games and make money with them.

I think an open-sourced version of WebStart (maybe like OpenJNLP) embedded in a native launcher would be the answer.

#9

It doesn’t work with versioned resources, so any updating is purely on the basis of timestamps. As a result you lose the benefit of jardiff updating. So not quite a chocolate teapot, more a white metal teapot!

#10

* blahblahblahh falls off chair in shock

But, but … timestamp webstart often doesn’t work! (sun never implemented it properly). If there were only one protocol that they’d support, it should surely be the version protocol. Sob.

(and I was on the verge of switching JGF over to using the version protocol exclusively, to get away from all the damn bugs in the timestamp protocol).

Sigh.

#11

The version protocol does of course work very well when delivering from a server, just not via the CD route. We decided that for anyone with broadband, just downloading everything was OK (and subsequent updates would then be efficient). For those that didn’t have broadband, then both the initial installation and any updates would have to be delivered by post on CD.
Unfortunately my bug submission failed — the reviewer couldn’t understand the problem (he didn’t appear to know what the CD installation was supposed to do). I think there is an engineer in the WebStart team who does recognise the problem, but can’t now track down a message referring to it.

Found it:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6223691

Fixed in Mustang build 36 and perhaps in 5.0 update 4.

#12

I think they should be side by side.

I think webstart is an excellent deployment tool, but it’s not the be all and end all, and people have the right to use alternatives. Certainly people may discriminate when searching for a game, some people may look for webstart-only games, BUT to be honest most non-developers probably don’t know what Webstart is and dont’ care.

I think the deploy on CD, update via Web can work, so long as your jars are small in size, so the updates are small (or you just don’t update large ones).


But under the assumption that somewhere on the page it would be made clear that the Web Start version will by auto-updating if (as I suspect) the EXE will not be.

And you can’t assume that EXE == no updates. Updates are pretty important, I would expect most non-JNLP professional games have custom update code (examples that do this are AF and TT) .

Will.

#13

Both : side by side

#14

Ditto. But I prefer to emphasise the .exe now; I only have Webstart versions for Linux users. (I distribute OSX .app.zips as well).

Cas :slight_smile:

#15

Once Update 4 is released, the versioned update will mean that the size of the jar doesn’t matter, just the size of the jardiff.

#16

No EXE, please.

Starting a Java app as an EXE is like drinking an excellent glass of wine with a drinking straw.
Well, it works, but it utterly sucks.

#17

That may be true, but supplying a Java app alone is like handing them the bottle without an opener - only alcoholics (like us) will have one on them :wink:

#18

I vote for “side by side.” However it would be a good idea to also provide other native executables for Mac and Linux (as mentioned before)