I agree with every single statement in that post, jbanes.
Especially about the 4k limit. 2k is too small for anything sensible. 8k is starting to approach āreal gameā size instead of āfun challengeā size.
I agree with every single statement in that post, jbanes.
Especially about the 4k limit. 2k is too small for anything sensible. 8k is starting to approach āreal gameā size instead of āfun challengeā size.
I agree with jbanes too.
[quote]Nobody gets within the limits because they found some secret switch on 7zip as opposed to doing something brilliant in their code.
[/quote]
To me finding that secret switch is part of the 4k fun.
To me finding that secret switch is part of the 4k fun.
[/quote]
Thatās my secret switch. Hands off
Mucking about with obfusticators and various zip programs is all part of the fun. Iām pretty happy with my java 1.4.2 jar crushing script. However I probably need to figure out a new solution for java 1.5
@swpalmer - I run my compression script after every build, so putting it in the online submission system wouldnāt really help me fine tune my jar size. Nice idea though
I didnāt realize people put much value on the packaging phase. I just donāt see that as a āfunā part of these sorts of contests. Its the algorithms and neat-o hacks that I like.
Just for the recordā¦ I have done hardware design (itās been a while now) and worked with constrained devices. For example I have built and programmed devices like 68HC11 microcontroller based ārobotā kits (http://www.mcmanis.com/chuck/robotics/controllers/miniboard.htm) and had all sorts of fun with those things. In fact, I have a modified RC car with one of those boards sitting on the shelf in front of me :). I also have a Lego RCX robotics kit, that I program in Java even :).
Anyway, I was just throwing out some ideas, I think the main thing is to have a bit of consitency in terms of the format of the submissions and how they are executed, and it seems people are generally in agreement with that. I wonder if I will be able to enter this time aroundā¦ work is as busy as everā¦ but surely I have time to write 4k of code
Thereās a bit of a hitch with the pack200. The only way (I can find) to make it work, with either applets or webstart, is to write a pile of stuff into .htaccess (assuming you have Apache), so that the server provides myapplet.jar.pack.gz with appropriate header, when the plug-in/webstart asks for myapplet.jar. Of course this totally fails to work, when accessing the applet direct from disc, rather than via a suitable configured server.
Soā¦ I can deploy my 4k app on my own server, but canāt provide a downloadable executable if using pack200. Woogley mentioned a jnlp āsnifferā program as a possible solution. I guess we host our own entries, & woogley runs his sniffer over them to check that they are no more than 4k. However, since this has to be done online, itās a bit tricky to confirm Iā not a dirty rotten cheat & surrupticiously (canāt even spell the word) loading other resources.
Maybe thereās a way to make this work directly from disc & iām too thick (or too tired) to see it. Maybe there isnāt a way to do it (but I could still be too thick or too tired). Maybe I should stop writing tripe & get some sleep.
Alan (ZZZzzzzzzzā¦)
To run a pack200 applet from my harddrive, I just double click on the html page. I have jre 1.5.05 as my errrrr, jre.
I tried executing a pack200 applet from my geocities site and it didnāt work, not a surprise. Like the Alan indicates, there are setup issues with apache.
I have some space on myjavaserver.com (ie javalobby) I havenāt used, Iāll try it on there if I can find my passwordā¦ ie Iām thinking if anyone would allow you to host pack200 applets, they would.
Edit; myjavaserver.com didnāt work either. They seem to have stopped responding to messages on the āsuggestionā forum too. Hmmmmmā¦ :-\
How about supplying a download that includes the html run it?
two thingsā¦ I am able to tell if you use online resources at runtime by running it locally with my modem turned off and watching for IOExceptions in the command window
the other thing is donāt even worry about using pack200ā¦ you will see why when I post the official thread
I think the mechanism is to specify myappletorapp.jar as the archive (or webstart resource). Webstart then queries the server, stating that it can accept jars & pack.gz in the MIME type. The server looks for the pack.gz MIME type and if present, returns myappletorapp.jar.pack.gz instead of myappletorapp.jar.
Now if I happen to have an unpacked jar in the same directory on my harddisc, then the applet/app runs, because the unpacked jar is picked up in preference. Possibly Applets also run if I have the un-jared classes in the same directory, which is pretty likely. (I tried to run Nonnusās Combat4k jar from last year, which failed because of a lack of a manifest. It ran fine when I un-jared the classes into the same directory).
However, it seems that Woogley is unflustered, so Iāll park the whole pack200 thing for now & get back to thinking about content.
Alan
I think Iām going to try to enter this time around.
This was the recommendation of 2 judges from last year, IIRC :).
Easy to deal with, Woogley may have already done so. I could do that on JGF now, but Iām a lot more concerned with fixing the meory leak these days.
Actually, I tihkn you have that the wrong way around. Webstart: run once, and quit. Now cached. Applet: run once, and quit, try and reload and you find the secondary-files form the webserver have NOT been cached. Youāre screwed. Applet fails to run.
[quote=āswpalmer,post:63,topic:25185ā]
Yep. c.f. previous comment about webstart and caching. But, in my case, it was judged in phases (on airplane, at conference centre (with internet), in hotel (without internet) :)) so different things preferred at different times.
This time around I would make it a requirement that Web Start be the ONLY way that the games are to be run.
This was my very strong recommendation from last time too. Frankly, I find it sad that this is even being debated, given that we, as judges, made such a huge point of this last year. There were arguments back then, and we replied, and I got the impression some people still werenāt convinced, but ā¦ you know, we actually did try and work through every game, weāre developers ourselves, we can fix a lot of crap, and we still found it extremely difficult in more than a few cases.
There were also several other major recommendations we made. No-oneās thought to email me to ask for input this time around, so Iām hoping Woogley got all those comments and has taken them into account. If not, TBH I canāt be bothered to go through it all all over again. Weāre not exactly hard to find or contact, if people canāt even be bothered to ask, Iām fed up trying to tell them.
Great attitude!
People who canāt be bothered to try to get things to run shouldnāt be judges.
I enter the competition to try to squeeze a fun game into 4k, not to worry about how some moody judge will like my packaging.
last year there was about a month of wasted time debating the rules - not this year. the contest is running almost the exact same way as last year with only a few minor changes such as no command lines. gamers should be able to click a game link in java unlimited and then immediately be playing a game. itās fine if you zip your files and the user has to unzip it, but it should never get to the point of using the command line. the only games that really need to be zipped are applet-based games because they need an HTML file and a JAR file to run. Most application-based games can get away with just living inside one JAR file.
This isnāt about the judges, itās about the players. Look at the download numbers for games in Java Unlimited - and thatās AFTER the contest. Itās not just judges and java devs playing these games, you have some gamers googling around for games who know nothing about the command line and barely anything about unzipping
no command lines.
Fine
gamers should be able to click a game link in java unlimited and then immediately be playing a game.
Does this include executable zips, or is webstart compulsary. Are you supporting pack.gz archives serverside or do we need to use regular zip archives only? Are the judges going to judge the entries directly from java unlimited, or do I need to provide a downloadable version that runs offline. Offline running from harddisc with no server means no pack200.
itās fine if you zip your files and the user has to unzip it,
Are you directly supporting applets, or only indirectly via downloading a zip with the relevant files. It wonāt be possible to use pack200 on the latter, as you need server support to send the archive with the correct MIME type. Running directly from disc doesnāt cut it with pack.gz archives.
I donāt really care whether pack200 is in or out, but will need to know when the rules are published, whether it is indirectly prohibited by the rules regarding how the game is to be executed.
Thanks
Alan
youāll be getting the full set of rules on launch day. but like I said earlier, do not worry about pack200 at all. Also, the only person that will be running the entries offline is me, and thatās just to validate that no online resources are used. everybody else including the judges will be running them through Java Unlimited the exact same way as normal players.
the reason that pack200 is out for at least this year is because java 1.4.2 is the minimum compatibility requirement. Next year the minimum will most likely be java 5, in which case pack200 will be allowed. This also means next year could be the most impressive year to date since pack200 reduces JARs almost 50% more. The reason for this is that I log on Java Unlimited what java version a user is running (provided the browser provides the information), and Iāve also been looking at Webstartās signature when it downloads the resourcesā¦ after rounding it off it comes to this:
[] 75% of users are running Java 1.4
[] 15% are running Java 5
[] 5% are running Java 1.3
[] 5% are running MSJVM (Java 1.1) or Java 1.2
Iām not sure what the official percentages are over the entire web, but this is how it is on my site. Most likely next year will yield more Java 5 users. Until then, no pack200.
edit: for those who are randomly curious of how these stats are found, this is what webstartās signature looks like:
User-Agent: JNLP/1.5 javaws/1.5.0_01 (b08) J2SE/1.5.0_01
UA-Java-Version: 1.5.0_01
[quote]but like I said earlier, do not worry about pack200 at all.
ā¦
the reason that pack200 is out for at least this year is because java 1.4.2 is the minimum compatibility requirement.
[/quote]
Iām glad you clarified this, because ādonāt worry about itā could mean anything, either affirmative or negative.
Iām not happy about excluding pack200, but if thatās the rules then so be it. I wouldāve liked to see more discussion about it though, as several of us have clearly stated we favor it. I thought last year jre 1.5 was required, but hardly anyone required it. Why the change?
edit;
[quote]This isnāt about the judges, itās about the players. Look at the download numbers for games in Java Unlimited - and thatās AFTER the contest.
[/quote]
I disagree with this too. This contest is about the challenge. Thatās all. If no one participated then there wouldnāt be any games to 1) judge or 2) download.
Thanks for the clarification. Iām quite happy to stay with 1.4.2. I was planning to anyway, before the extra available compression of pack200 tempted me to the dark side ;D
Alan
Great attitude!
People who canāt be bothered to try to get things to run shouldnāt be judges.
As Blah wrote āā¦you know, we actually did try and work through every game, weāre developers ourselves, we can fix a lot of crap, and we still found it extremely difficult in more than a few cases.ā
It is absolutely ridiculous to put the responsibility of making things work on the judges! Itās not THEIR entry! Thatās the crappy attitude. People that canāt be bothered to make things work properly, shouldnāt be contestants. That seems to make a lot more sense.
Amoung the suggestions from last year: Have a warm up phase where people (including judges) can provide feedback, explaining what happens when they try to run it on their system. This gives contestants the opportunity to work out glitches that they did not encounter with their own system. I think it is particularly important because of the cross-platform nature of the contest. If the entry still doesnāt work after that, then it will be reflected in the score.
[quote]This isnāt about the judges, itās about the players. Look at the download numbers for games in Java Unlimited - and thatās AFTER the contest.
I disagree with this too. This contest is about the challenge. Thatās all. If no one participated then there wouldnāt be any games to 1) judge or 2) download.
[/quote]
The This
I was referring to in that quote was about the reason the command lines were excluded, it wasnāt defining the meaning of the contest.
Amoung the suggestions from last year: Have a warm up phase where people (including judges) can provide feedback, explaining what happens when they try to run it on their system.
this is a good idea, although last year most entries were posted here at JGO and received quite a bit of feedback before the judging. either way itās a good idea to have people test your games out - āproofread,ā if I may
By the way, whoever was asking why the minimum java requirement was changed: I want devs to have equal opportunity in the contest. Some devs either have 1.4 compilers or they may have 1.5 but donāt want to lose compatibility with earlier versionsā¦ or whatever. The point is, when java 4K sets the minimum requirement to Java 5 - everyone will HAVE to use Java 5 because of the pack200 advantage. If we have a mixed version development, most 1.4 based games will be DOA due to the tighter size constraints of not having pack200. Itās a matter of which java platform is currently more available - this year itās java 1.4.