Deployment reliability

I’ve recently deployed my game Zatikon to facebook. Previously, the game used a downloaded installer bundled with a jre, but the world of facebook has forced me into the scary world of applets and webstart.

My first attempt was using deployJava.js with createWebStartLaunchButton. Only ~10% of users who visited were able to successfully launch my game.

Next, I used deployJava.js to only check the java version and prompt a new JRE installation, and used a regular html anchor to launch my jnlp file. This improved the success rate to about 40%.

Frustrated with webstart, I abandoned it and created an applet version, again using deployJava.js’s java detection and a traditional html tag. Now my success rate has reached ~65%.

Anyone know any tricks or techniques I can use to bump this higher?

maybe :

  • always use APPLET tag
  • do not use “code base” attribute on applet tag (if possible)
  • use an Applet Booter compatible with java 1.1 and check for your minimum requierment inside (I ve posted one in the shared section) : the compatibility with java 1.1 is juste there to ensure you that the booter will start anywhere java is.
  • add a message inside you applet tag to propose the user to download java :
<APPLET ....>
<A href="http://java.com/"> you need java to run this game ... blabla...</a>
</APPLET>

EDIT :
as a side note here are the results I got last week for an applet according to my logs : Applets rocks !

SIMCA1000/index.html 238 1% => 238 reach the html containing the applet
SIMCA1000/ROAD/ROAD.3DS 200 0.8% => 200 succesfully load 3d model 1
SIMCA1000/ROAD/CAR.3DS 200 0.8% => 200 succesfully load 3d model 2

this make a ratio of 200/238 = 84% of succes (it is a little more in reallity as it also include robots/bots that dont even try to run the applet and then dont load the 3d models and also do not include people that dont launch applet)

EDIT: :slight_smile:

DzzD: for the sake of debugging i run my explorer using java 1.4 and currently your applets flicker on Interenet Explorer resize.

I was wondering if you think that using jnlp files in the applet tag are a good idea (is there any reason not to)?
using the key word “MAYSCRIPT”
and: param name=“jnlp_href” value=“http://www.blah.blah/blah.jnlp

I found its the only way to fix the problem in Windows java 1.4/1.5 applet flicker.
by checking the OS and using the vm arguement:


<resources>
 <j2se version="1.4 1.5" locale="" os="Windows" java-vm-args="-Dsun.awt.noerasebackground=true"/>
</resources>

Is there any downside to doing this for Java 1.4 and onward?

thanks for the tips, I seen the flickering and try to fastly fix it (recursivly attacking applet parent container…) but without any success… and finally think it was just another plugins bug…

[quote] I was wondering if you think that using jnlp files in the applet tag are a good idea (is there any reason not to)?
[/quote]
it is inded up of your target visitors, It is probably safe in some case (intranet /big game & know audience but not for “standard website”) but I would be carefull, it is an emerging new plugin stuff and as all new plugin stuff it is not supported by a lot of internet visitors that do not have the necessary plugin ( still only 50/60% got java 1.6 and some features where added in subversion of 1.6… 1.6-1 1.6-2 etc… until 1.6-10 where most new features were added so assume that less than 50% got 1.6-10 against the 80/90% that got java )

MAYSCRIPT is an old keyword enabling liveconnect you may get a javascript/java security/access exception if you try java<=>javascript communication without this keyword on some configuration/browser, it cost nothing to add it.

you can pass argument to jvm with new plugin without the need of jnlp, now you point a possible solution I will try to think to update applets that flicker :

//to get more memory you can do :
<applet	etc...>	
<PARAM name="java_arguments" value="-Xmx256m">
</applet>
// so probably you can also do ?
<applet	etc...>	
<PARAM name="java_arguments" value="-Dsun.awt.noerasebackground=true">
</applet>

ok this seems to work fine with it doe not change anything for people having old plugin but it does not flicker anymore for people having new plugin

here is a patched applet, when resizing the browser applet is now resized without flickering : http://superdev.fr/3d.html (EDIT: seems that I forgot to compil this one with compatibility … may not run anywhere… :-\ )

thanks !

EDIT: [quote]Is there any downside to doing this for Java 1.4 and onward?
[/quote]
for version under 1.6 you cannot pass any argument to the jvm (really/absolutly/definitly no way), IMHO you should dont really mind/care about flickering on resize with old jvm as long as the applet start & run fine people with old jvm wont go away they will just get a little worst experience but as long as the applet dont crash and they can play they wont be deceived.

EDIT 2 : just because it is very funny I have to say that it doesn’t flicker with the 1.1 microsoft JVM and it does with the lastest java plugin (without passing argument to the JVM) pff…

Cool thanx for the info. Then I guess I have no need for the jnlp file for the moment.

Is this true even in the case of arguements passed with a"jnlp" script?

EDIT:
I uninstalled 1.6 and tested 1.5 with applet+jnlp script, and flicker problem remained.

yes in some ways it is true, jnlp will work but… first it is jnlp you will got other problem and it may not run as expected :
1 - not using standard applet tag and can have server issue (jnlp mime type) as client plugin issue
2 - the jvm argument must be set before the vm is started, prior to java 1.6 there was only one instance of the jvm, It maybe possible that parameter is only working if no “applet” have been run before your applet .

about the applet tag, even if it is a little outdated (my side I believe it is still more robust than any other object tag):

[quote]Note: The HTML specification states that the applet tag is deprecated, and that you should use the object tag instead. However, the specification is vague about how browsers should implement the object tag to support Java applets, and browser support is currently inconsistent. Sun therefore recommends that you continue to use the applet tag as a consistent way to deploy Java applets across browsers on all platforms.
[/quote]
source : http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/using_tags.html#applet

sory this one is more recent…

source : http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guide/using_tags.html#applet

and this is completly true…

What about IzPack?

Personally I have problems with Web Start only when there is a firewall or a file quota, the user has to retry and it works.

Those are caused by bugs in URLConnection, nobody seems to care. Avoid it like the plague.

Is there any drop-in replacement? That works automatically with proxies (obtained from system setting).

[quote]What about IzPack?
[/quote]
if you can fit in an applet it is far more user friendly than any desktop installer : webstart / izpack / executable jar … and the interresting thing in facebook is that application run inside browser… this is web world…

[quote]Personally I have problems with Web Start only when there is a firewall or a file quota, the user has to retry and it works.
[/quote]
are you sure you only got problem with firewall, did you log how many user succed and how many fail ? also lot of people have a firewall… proxy … file quota… exotic java plugin…

dont look for an alternative when something have proved to work well …

not sure if it is still true but with unsigned applet you cannot get browser proxy settings

Of course, I meant it for normal standalone apps.

in this case that’s pretty easy, you may use socket or any other net libraries ( for http it is pretty easy and only requiere to add two headers, but there are existing libraires too : probably HTTPProxy or such )

EDIT: forget, I realized that I ve probably missunderstood your point now…