You want to go full circle, eh? (The first contest started with everyone - except me - doing Applets.)

I personally think that it's not such a good idea. Here's my thinking on that:

1. An applet requires a minimal commitment in size to implement the Applet class. This leaves far less space for actual game code.2. Applets are dead. Long live Applets. I'd much rather code Java games as serious applications than attempt to target a painfully out-of-date technology. 3. Furthering Applets furthers the old idea that "Java is slow", the exact opposite of what this competition proves.4. Full screen is much more immersive than a box inside a webpage.

Lauching issues can be solved by simply demanding the use of executable JARs. If the JAR isn't executable, give it the boot. Previous years have allowed contestants to save a bit of room by not including a manifest. Given the number of entrants last year, I think that's a requirement that should go the way of the Dodo.

Quote

and it could add some extra sexiness to the competition.

That is, if you consider Pintos "sexy".

Quote

Additionally, it provides a nice sandbox so we can trust that the games don't mess stuff up.

I wasn't aware that this was an issue? Have we had someone try to trick others by using 4K JARs?

Yes, they're dead. If I could personally drive the last stake in them, I would. Applets today aren't slow, but they do have poor startup times and they are associated with the "slowness" of old-fashioned Java. Too many people still think that Java == Applets when nothing could be farther from the truth.

Webstart. Now THAT is sexy. Applets, no. Of course, everyone is entitled to their own opinions, but mine is that Applets should not be pushed.

Quote

Requiring an executable jar file is silly as you need to put a lot of extra non-code stuff in the jar just because the judges happen to be lazy.

Forget the judges. Any players who want to download the game should be able to simply double-click and run it. Simplifying it for the judges is a nice side effect. Webstart is an even better technology, but it offers several complications when trying to cram the code into 4K..

Out of curiosity, I ported Dungeon4k to an applet. Just right of the bat, it shrunk 5% to 3893 bytes, without me doing any optimisation.Loading the page in firefox (totally clean and restarted, I've killed all firefox processes) takes about three seconds before the applet shows up.

Of course we're not designing wurm to run in an applet. That's just a silly question.But that doesn't mean that people don't like small (not wurm) games that they can play at work (not wurm) in their browsers. You know, like all those million flash games that people love (and pay for) despite their horrible performance compared to java.

[edit:]

Oops, I had a small bug with static variables (the game didn't survive a refresh). It's up to 3910 bytes now.

Out of curiosity, I ported Dungeon4k to an applet. Just right of the bat, it shrunk 5% to 3893 bytes, without me doing any optimisation.Loading the page in firefox (totally clean and restarted, I've killed all firefox processes) takes about three seconds before the applet shows up.

Edit: Oops, I had a small bug with static variables (the game didn't survive a refresh). It's up to 3910 bytes now.

I'd have to see your comparitive code to actually make a judgement on what's going on. However, my guess is it's the fact that you removed the full screen code (a feature that is not required by an executable JAR but many of us like to include). Not quite apples to apples, especially when most people saw the Webstart version in an applet-sized window.

Of course we're not designing wurm to run in an applet. That's just a silly question.

As it was intended. I like writing full screen, scalable games in 4K. To me, these are real games that I can get done in a reasonable amount of time. Forcing the use of applets would take that away. Of course, we should hear from others on this (as it's just you and I arguing over details at the moment) before stating which the overall preference is.

Quote

But that doesn't mean that people don't like small (not wurm) games that they can play at work (not wurm) in their browsers. You know, like all those million flash games that people love (and pay for) despite their horrible performance compared to java.

You mentioned the key word: "Flash". Java in the webbrowser was a nice idea, back in the day. I did a couple of Applet games myself. Unfortuantely, it lost in the market. IMHO, trying to regain the marketshare is a lost cause and only serves to reinforce the logic, "Java == Applets, Last I checked Applets == Slow, thus Java == Slow."

In any case, I'd like to hear what others think on the issue rather than arguing it out. Personally, I would not enter the contest if Applets were a requirement.

So then, shall we go for middle ground and say that it must be an executable JAR, or an Applet? For judging (and archiving) purposes, I'd say that adding a simple requirement to provide a downloadable version of the applet and webpage is a reasonable requirement.

Is that an acceptable compromise? (Assuming that Mlk, or whoever is taking over the competition this year is okay with it.)

I'm really surprised to hear that your applet is smaller. For an applet you have to give it a thread to run in and all that instead of using the constructor

I'm disappointed pack200 jars won't execute, is this a fact or conjecture?

What are the complications with jws? I've never worked with it so I don't know.

Applets are the no brainer solution, but I think having an 'applet 4k' contest is much different than a 'java 4k' contest. For one you're adding a restriction that is new and for another, like it or not, applets have a bad reputation. I for one like compileing without deprecation warnings...... Note, I think I had the only applet last time.

If pack200 only works with webstart, it would be difficult for entrants with only their ISP provided webspace, since these often don't have the required mime types. In addition, unless signed, webstart entries cannot go full screen or set the 'nodraw' property. Also when running (unsigned) in a window, the 'Java Application Window' banner grabs some of the bottom of the main window. Allowing pack200, would put executable jars and applets at a size disadvantage. Overall it's a mixed blessing. I'd prefer not to allow it really, although thats the Luddite in me talking.

I'm still tempted to code for java 1.4.2, although 1.5 should be allowed. There are probably still quite a few computers out there without 1.5.

Why not just say use webstart and the JNLP is *not* included in the size?

One would then argue that you can pass entire data throught it as arguments, but just forbid arguments...

That's what we've been doing. The problem with Webstart, however, is that you need to sign the JAR to do anything useful. For example, if you want to switch to full-screen mode, your app MUST be signed. The signature itself is a rather nasty size penalty, too.

The other consideration is that Webstart makes it more difficult to obtain a permanent copy for testing. At least with Applets you can give the webpage and be happy. The codebase requirements for Webstart make that just a little trickier.

In short, reducing entrants to only executable JARs or Applet form makes judging easier, makes user's lives easier, and even makes the lives of contestants easier. (Even if they don't realize it.)

Quote

If pack200 only works with webstart, it would be difficult for entrants with only their ISP provided webspace

Just to be clear, Sun does say that you can use it as an archive format similar to ZIP. It's only technically "supported" by webstart because webstart automatically unpacks it into its cache.

Quote

I'm still tempted to code for java 1.4.2, although 1.5 should be allowed.

Setting the rules at 1.5 shouldn't preclude anyone from targetting 1.4. All it means is that your work will be judged under a 1.5 VM. Since Java is so good about backward compatibility, that shouldn't be a problem for most.

Since pack200 gives such a tremendous compression advantage and can only be used for webstart it should be excluded from the competition entirely.

Or...

Allow it and for those who really care about the extra 500+ bytes and want to go thru the trouble of signing jars, setting up jnlp, and allowing only those with jdk 1.5 to play there game then they can.

Has anyone tried out pack200 on an existing 4k game? I found this quote:

Quote

I had a chance to check out the spec. Basically, the algoithm takes into account strings pools of all classes being packed and package them as a one cental pool. Executable bytecode is not being compressed.

Since there usually is only one class in a 4k program & little text, there may not be a big advantage in using pack200.

NB. IIRC, the main drawback of the zip format is that it compresses each class separately, which is not really an issue if you only have one class.

Alan

/Edit: Found this old post by Abuse on sun forums. Kinda bears out my suspicions. I am beginning to think that pack200 is a red herring.

Has anyone tried out pack200 on an existing 4k game? I found this quote:

Quote

I had a chance to check out the spec. Basically, the algoithm takes into account strings pools of all classes being packed and package them as a one cental pool. Executable bytecode is not being compressed.

Since there usually is only one class in a 4k program & little text, there may not be a big advantage in using pack200.

NB. IIRC, the main drawback of the zip format is that it compresses each class separately, which is not really an issue if you only have one class.

Alan

/Edit: Found this old post by Abuse on sun forums. Kinda bears out my suspicions. I am beginning to think that pack200 is a red herring.

Nope, pack200 works super well, and it works for applets like C. said.

My test:

jar: 4.52kbpack: 3.03kb

and it runs as an applet with an 'archive' property in the applet tag. That's ALOT of uncompressed code!

I might be wrong, but as far as I can recall, the rules last year allowed basically anything, as long as one could start it in one way or another. This seems like both a good and a bad idea.

Last year, for webstart files, you were allowed to exceed 4k with the signed JAR, right? And the JNLP was not included in file size. That's good, I think.

I can't claim to know anything about Pack200, but if it gives that much of a size advantage, it really uppers the practical limit a lot, allowing for much bigger games. Being a 4k contest, I don't really see the point, so I think this should be disallowed.

I'd personally prefer if you could use either self-excutable JARs or Applets. Furthermore, I'd allow webstart, excluding the signature's extra size, and the JNLP file, by forcing anyone using webstart to create a self-executable JAR that does exactly the same thing (in other words, no specific rules for webstart - let anyone who wants webstart follow the normal rules, and then create another file for webstart).

If those were the rules, I'd surely post any entries as JARs and webstartable (JAR for the contest, webstart for opinions, accesibility, etc).

Nope, pack200 works super well, and it works for applets like C. said.

My test:

jar: 4.52kbpack: 3.03kb

and it runs as an applet with an 'archive' property in the applet tag. That's ALOT of uncompressed code!

Yes, I'm using applets from now on .

Interesting. Was the starting jar already obfusticated & compressed with 7zip (compression=9) or kzip? It's important for comparison, since I usually manage to shrink the stock jar by nearly 50% that way.

I can't claim to know anything about Pack200, but if it gives that much of a size advantage, it really uppers the practical limit a lot, allowing for much bigger games. Being a 4k contest, I don't really see the point, so I think this should be disallowed.

I disagree strongly. The point of the competition is to try to squeeze as much as possible into 4k. Preventing means of doing so is counter-productive and silly.If you don't mind me doing a bit of slippery-sloping, if we ban pack200, we should also ban jars with non-zero compression.

Jbanes: I think you misunderstood me, that's just what I meant... about the webstart, I mean - the signed jars aren't specifically allowed, but rather something you can do if you want to, IF you also have a normal jar that's less than 4k.

Markus_Persson: I see your point - either packed, or not packed. If packed, pack it all the way... I guess you're right, although it does alter the contest possibilities in a rather extreme way, doesn't it?

Why not get something fun and and original working before worrying about the 4k limit, Not to say that anything I've ever produced is original but the shrinking things down after the fact reallt isn't that difficult.

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