Rules

I mailed appel, but I figured others might be able to answer my questions and the answers might help others too.

Hi there! I’m new to this community.

I’d like to enter the competition. I have read the rules (and the forum), but I have some questions:

First question:
I’ve read that pack200 is allowed. What does this mean? What does the 4k limit applies to?
The jar file? Or the repacked jar file created by the “pack200 --repack Some.jar” command?
Or even the pack.gz can be 4k? (which might be the output of “pack200 Some.jar.pack.gz Some.jar”).

Another quesiton:
If I submit my game now, will I be able to re-upload an improved version before the deadline?

Last question.
All that required is that the jar can be run as Applet?
For example to run it as an applet, it does not have to have a MANIFEST.MF (it will not be a valid jar, but can be run as applet).
Ideally the jar should contain only one file: for example G.class (if it does not use resources).

Is this so?

Thanks in advance.

First: “java pack200” can be googled. And the resulting pack200 file is what is counted towards the 4096 bytes.

Another Yes. It is possible for you to update all the details of your game, including uploading new files.

Last: No manifest is required.

I don’t think his question was “What is pack200?”.

The file you upload (whether a straightforward .jar or a .pack.gz) has to come in at 4096 bytes or less.

Ok, I misunderstood the question. But I did answer it. The .pack.gz file has to be equal or less than 4096 bytes.

Yup, my question got answered.

But then here’s another one:
What do the jugdes look when scoring an application?
Just how fun/good it is? Or do they look into the source code as how readable, understandable it is and how well it is documented?

No one cares about the source code in this case. Fun game and impressive for 4k.

Kev

ha, the code for most Java4k games is super evil :), even obfuscated code isn’t as bad and in some cases, no one but the author can make any sense out of it.

Ok, I will try to focus on the game instead of writing docs. But I claim that any medicore Java coder could understand the sources of my Java4k game (which is yet to be submitted).

Then you must have tonnes of room left to squash it and fit in more featres :smiley:

Kev

Yes, I still have tons of room, but I used lots of local variable constants to make the code more readable and easier to manage, and lots of comments.

And if the judging is like last year there’s a nostalgia bonus for writing a clone of a GameBoy game.

That is what most do. Just make sure you use ProGuard to shrink the class file down. ProGuard is a code optimizer/obfuscator. It will remove a lot of bloat from the class file.

What does the 6th rule mean?

[quote]6. No soundbanks may be used because they are not a default part of the “public” JRE. You will have to create your sounds at runtime rather than use MIDIs.
[/quote]
That I can’t use wav files for sound effects?
What about Applet.play() method? It is part of the public JRE. And it can play wav files. Of course I know I’m not allowed to play a wav from the internet, but am I allowed to play a wav stored in the jar file?

Sure you are; if you can fit a meaningful wav into a 4kb jar!

I think there are some wav files embedded in the JDK, that can be used directly. That’s not part of the “public JRE”, so it cannot be used.

I assumed you were talking about Sun’s MIDI stuff, which isn’t in the JRE already.

I am considering doing a sim game, which really could do with persistant storage, so you can come back to it. Rather than sign the applet, I was thinking of using cookies, since these work fine in the sandbox. However this is a bit broken on Firefox 3.5 on the Mac at the moment, although it works Ok with Safari on the Mac & both IE and Firefox on the PC. The Mac problem appears to be due to the old java plugin using LiveConnect, which Firefox doesn’t support anymore. It’s a problem that should go away eventually when Apple has caught up. In the mean time safari works.

Writing cookies, needs to be done carefully, since I could trample on top of any used by Java4k.com (You have some starting __utm). I thought that setting the cookie name as the applet name + year would work, and unlikely to clash with someone elses. Since Java4k.com already has several cookies, I am assuming that the PHP code isn’t going to throw a wobbly if it get’s one from me on page fetches.

The documentation says that you need to add MAYSCRIPT to the applet tag, to get access to the DOM. Curiously this is true for Safari and Firefox, but IE just plain ignores it and grants access anyway. Still MAYSCRIPT needs to be allowed if this is to be cross-browser. I haven’t experimented to see if Java4k.com will allow this tag.

Anyway, I’m not sure whether this is a good idea; if everybody did this, there would be a pile of cookies, clogging the place up - so I’m looking for opinions.