Die, Webstart!

Networking & Multiplayer
#1

Well, y’all probably know that I’m a secret fan of Webstart, and generally I reckon it’s great. Well, the 1.5 version anyway.

So it breaks my heart to say that I will be downplaying its role in Super Elvis once again, and generally deploying the game as a Win32 executable.

Whaaaat? I hear you cry.

Look, see, it’s all about the bottom line for me, and the end user experience. The bottom line for me is influenced chiefly by the number of downloads I get, and then by the number of successful installs I get, and then by how cool the game is.

So, I was very disappointed when I released Super Elvis into the wild to a bunch of non-Java heads, and received a ton of bad feeling and disgruntlement about Webstart.

I could just about manage to live with this.

Except that when I created the Win32 executable version of Super Elvis, complete with my, ahem, secret embedded JVM, it was only 8.1 MB - smaller than the Webstart version. No, I can’t use Pack200, because 1.5 is as rare as hen’s teeth. The .exe installs easily, quickly, instantly, painlessly, familiarly, flawlessly, says nothing scary to the end user… it Just Worked.

That clinched it. Webstart for MacOS and Linux, but the Windows folk are going to be encouraged to use the exe instead.

Any thoughts?

Cas :slight_smile:

#2

Would you mind going into some detail of the process you used to create a self installing windows exe with an embedded jvm? I have never developed with webstart either, as I don’t do much client side programming, but I have found the experience to be less than intuitive as a user. Just want to understand my options. Thanks,

Chris

#3

Of course, you shouldn’t have to fight your users and force them to do what’s good for them (but unpopular); that’s what JGF is there for - to take the hard stance and take the flak ;).

I think that nullifies 1/3 of webstarts major advantage (the other 2/3 being: fast, efficient, automatic libraries, bugfixes, and upgrades, …and… 100% cross-platform)

You seem to be saying that JAR compression is now lightyears behind the state of the art? I’m assuming that:

a. You’re distributing an up-to-date JVM, i.e. not sacrificing performance for download size (by including a very small but slower JVM)
b. You’re not actually using most of the JRE classes, instead you’re heavily using secondary libs (LWJGL etc) so that you largely have to distribute a similar amount whether or not the user has a JVM installed?

And…how much difference is there if the user already has all your webstart libs installed (LWJGL installed base growing continously…especially amongst those who play JGF games :))?

PS I did include a bitch about Sun’s pathetic claims of how great and stable java 5 is, and how many people are being turned off by the “buggy” java turning out to be just as buggy as ever and getting even more suspicious of Sun marketing. It’s starting to get REALLY hard to persuade the slightly-technically-literate people to install java AT ALL - amongst my (non-IT) social groups, Sun has a reputation considerably below Microsoft for stability, reliabilty, and “not f***ing up my computer”. I find this deeply ironic considering these same people get MS-caused crashes and headaches weekly yet still have lots of faith in MS; but that’s just the way it is :(.

#4

Here is a link to the feedback on Indiegamer forum: http://forums.indiegamer.com/showthread.php?t=987&page=1.

I think it is the right decision to go with the native installer. But I’ve never been a fan of using webstart in a commersial game.

[quote]And…how much difference is there if the user already has all your webstart libs installed (LWJGL installed base growing continously…especially amongst those who play JGF games )?
[/quote]
LWJGL only takes about 350k compressed, so there is not much to gain.

Great game btw. Hope you make some money out of this one :wink:

#5

The LWJGL is more like 210KB when it’s LZMA’d. The miniature JVM itself is 2.5MB. It’s just a bog-standard Sun 1.4.2 client VM with all the crap, er, um… whoops, my installer must have some fault in it however could that have happened etc.

So there we go, a fully-featured gaming runtime weighing in at 2.7MB. It’s got RMI, security, and fully internationalized, but precious little else. It could get considerably smaller yet I think, if I chucked out RMI and some of the internationalization and a few other odds and sods.

I’ve been round this loop before :slight_smile:

a ) The VM is just 1.4.2 minus crap. It’s fast as hell. I could make it faster by using the server VM but I pay too dearly in startup time and it’d cost me another half meg. I haven’t fiddled with 1.5 yet and probably won’t, as I’ve noticed some odd behaviour (jerking, juddering etc.) that I can’t tune out.
b) S’rite, I use very little of the VM. In reality, if I had some kind of “linker” stage I’d throw out every bytecode that wasn’t going to be executed. Probably save myself another meg on download size, and that’d be almost competitive with Blitz Basic.

Blitz Basic is the big competitor in the Java gaming space here. It’s the 800lb gorilla and Java’s the crappy monkey throwing gay bananas at it.

I’m still looking for good reasons not to switch to BlitzMax. (Playing devil’s advocate)

Yes, BlitzMax will shortly cover all 3 major desktops. Yes, BlitzMax is OO, and yes, it has garbage collection, and yes, it produces tiny exe’s that start up in a flash, and yes, it’s really, really easy to code in.

C’mon, give me some reasons.

Cas :slight_smile:

#6

No, I can’t use Pack200, because 1.5 is as rare as hen’s teeth.

Well, you can use it anyways. 1.4 jws clients will just get a usual jar and 1.5 jws clients get a jar.pack.gz (or just a jar.gz if you want) :slight_smile:

Here is a small demo, which will show you which archive was actually send to you.
http://www.kaioa.com/src/tmp/BounceDemo.jnlp

It’s all handled serversided (totally hidden from the user), by correctly responding to the accepted encoding with a small php script.

LWJGL only takes about 350k compressed

With 1.5 jws compression stuff it’s <200kb (0.92).

#7

[quote]The LWJGL is more like 210KB when it’s LZMA’d. The miniature JVM itself is 2.5MB. It’s just a bog-standard Sun 1.4.2 client VM with all the crap, er, um… whoops, my installer must have some fault in it however could that have happened etc.
[/quote]
So, aside from the interesting mini-JVM with (some of) the latest features (there’s a lot of goodies in server), the real important question here is:

Why is your webstart dist 2.5Mb larger than the non-webstart one?

You don’t seem to have commented on the compression; is it simply down to a better compressor being used in your EXE or is there something else subtle going on here? I’m interested to see where a 30% gain over max-compressed ZIP is coming from.

#8

Of course, that’s what you get for posting on a dev board, where people penny-pinch and don’t update their machines, and don’t buy new ones (that would have come with it installed alredy)

What a great thread you’ve started for collating anti-webstart sentiments, Cas! Just what I needed, thanks - I’m hoping to eventually shame Sun into action…

#9

I’m interested to see where a 30% gain over max-compressed ZIP is coming from.

Well, it’s simple. LZMA is superior to zip. That difference is even more visible if you have hundreds or thousands of tiny little files. Zip cannot handle that case properly. You’ll see that you end up with a much smaller zip if you zip all files first into a single archive without compression and then compress that archive again with max zip compression. It will be alot smaller then.

LZMA does this kind of trickery by default (of course) and the scheme in general is also better. (Well, the cpu/ram consumption during compression is EXCESSIVE with lzma… that’s the price you pay, but it doesn’t seem to be a real problem nowadays).

#10

[quote]>I’m interested to see where a 30% gain over max-compressed ZIP is coming from.

Well, it’s simple. LZMA is superior to zip. That difference is even more visible if you have hundreds or thousands of tiny little files. Zip cannot handle that case properly.
[/quote]
Yup, I realise that. But I didn’t have Cas pegged as the kind of guy to actually have hundreds of files.

And I have visions that everything is pre-squeezed as much as feasible anyway, so that the 30% improvement is being achieved over a subset of the original input (because a lot of it can barely be compressed further anyway - e.g. music, graphics, etc).

Hence…asking. Interested to know where Cas is seeing the biggest difference (or even if it’s just a big difference across the board, irrespective of the type of resource [graphic/music/code/data/xml/etc])

#11

LZMA compression as used by NSIS installer is just amazing. It compresses my image data down incredibly (which is by far the hugest chunk). I don’t have a great number of files really.

I’ve tried shaming Sun before but it didn’t really work.

Those devs aren’t penny pinchers, they’re just brutally honest business-heads most of them. Everything they say is sadly true. I take everything they say very, very seriously - no matter how trivial it might seem. From the wrong colour on the title screen to a crash bug.

Cas :slight_smile:

#12

OOI, doesn’t your online purchase stuff use AWT/Swing? Does this mean your specialised virtual machine includes this aswell?

Or, I suppose, resorting to GL dialogs…

Kev

#13

afaik, he is going to throw a webbrowser at it…

#14

A thought comes to mind, is it about time someone (the community here) got round to writing a native replacement for webstart?

Download the webstart native binary, run it and it goes and gets whatever version of Java needed? (Even a special VM?)

Kev

#15

[quote]LZMA compression as used by NSIS installer is just amazing. It compresses my image data down incredibly (which is by far the hugest chunk). I don’t have a great number of files really.
[/quote]
Now that’s the kind of answer I was looking for…because it suggests that it’s worth adding a mini LZMA decompressor class to your webstart and LZMA’ing your images by hand first. Have you tried this? What’s the file-size difference when you do?

I was being tongue in cheek, really :).

Although, incidentally, I did think the whinges from some were OTT. The comments / bug reports themselves should have been enough, without ranting about “no-one will ever buy your product if you use this webstart crap”[paraphrase] (especially when the ranter was wrong in at least one case in believing the problem to be webstart when instead it was their own crap graphics drivers). Surely they know you, and hence are aware they don’t need to lambast you over the issues; that pointing out the problems is enough? Shrug. Just an afterthought.

#16

Yeah, they know me all right, and many of them have watched with some amusement the trials and tribulations of “The Game That Should Not Be Mentioned”. Mostly the trials. From long experience of using those forums I have learned that you have to apply a special filter to comments that the other devs make as 95% of it is bluster and fluff or plain unhelpful, but there is usually a well-hidden kernel of truth.

So: I’m not going to do the website thing entirely, I’m working on “Spaghetti2” which will make it into the game as a skinnable, fully-featured OpenGL rendered API. This will become open source in short order. So in-game purchase will be in the game, like for Alien Flux; except this time it will have Paypal & cheque options (redirecting to the website as necessary) and it’ll use RMI over SSL instead of my fancy crypto bollocks.

I could go through all the hassle of LZMA libs etc. etc. but I really can’t be arsed. There’s such a tiny return on investment in the indie games business that every hour I waste on something I didn’t need to do just means I’ve basically totally wasted my time and money and the whole point of Java was that it was supposed to save me time and money.

Once Spaghetti2 is out in the wild I hope it will become a very useful AWT replacement. You could build a Webstart client from it, no problems. Then you could have a VM that gradually downloaded the entire JRE as needed starting from a very small 3MB footprint.

Cas :slight_smile:

#17

[quote]but there is usually a well-hidden kernel of truth.
[/quote]
As a techie friend known for being excessively blunt used to describe himself: “harsh; but fair”.

Fair enough. But in the context of this thread (revolving around file-size differences as a deal-breaker for webstart) it seems a sensible thing to try had you the time.

But no-one will. Everyone will wishfully suggest that someone else does ;D.

OTOH, if we have spare cash from the JGF fund, perhaps I could find some nice chaps in eastern europe or Bangalore to whip one up (+source) in a week for $100, and then make it free to everyone? Their quality standards are high (especially the Indian software companies whose work I’ve seen) assuming you give them a very clear and precise specification.

…and then, just as you (one) reach(es) version 0.99b, Sun will suddenly release a largely inferior thing that nevertheless does almost exactly the same but is bundled and massively promoted by their marketing dept. And you’ll feel gutted. And they’ll say “Chris did mention that something like this might be happening at some point in the future, even if he couldn’t provide any details for commercial sensitivity reasons, so you’ve only yourself to blame”.

:stuck_out_tongue: ;D.

#18

So, if someone was to perchance stick an OpenGL (LWJGL) front end on OpenJNLP then it could be compiled down to around 3MB?

I guess they’re need to be some support for downloading components of the VM added aswell?

On a purely businessy note, should we be looking at figures for conversion rate based on .exe vs .jnlp ?

Kev

#19

I sort of expect exactly that from ChrisM’s dept. but I occasionally get to talk to him and see how the land lies. I’ve mooted the idea of me producing a proper product, “Puppy Games VM”, but he seemed to suggest that there were an awful lot of curious specficiation hoops to jump through to make it happen. I couldn’t see it myself, to me it’s just a product that does XYZ, no specs, like Blitz Basic.

On a business note you will be happy to learn that Webstart conversions are virtually nonexistant. But that’s mostly because I have a bug in the Webstart version of AF that prevents ingame purchase working - because of the stupid f*cking crypto strength limitation in force on the JVM.

Cas :slight_smile:

#20

Oh no! - thinks me - disaster! Can it be that webstart is a total dead-end?

LOL