New j4k contest anytime soon?

Amen. Pre-planning is way more important than pre-optimizing. I’ve got my (first of many? crosses fingers) entry nearly ready, and I’ve still got >500 bytes available. And I haven’t even run it through a class optimizer yet! :slight_smile:

As nice as Pack200 is, I’m not sure if the tradeoffs (e.g. no full screen mode, etc.) are worth the file savings.

I havent kept up with this entire thread, just been skimming over the last few days.

to summarize, the official thread will be posted in a few days with set rules based on the previous years. Im not going to get into details… but I will tell you that applets, jars, and webstart are all acceptable entries.

more details to follow

[quote=“jbanes,post:54,topic:25185”]

Actually the WebStart version was preferred over all others. At least that’s what I did, and I thought Blah^3 did the same.

This time around I would make it a requirement that Web Start be the ONLY way that the games are to be run. It was a pain to fiddle with the command line to try to run a few of the games last time, special when there were .bat files for Windows only or something silly like that.

Downloading a JAR even if it is executable is still more of a pain than Web Start. But a non-executable JAR just plain stinks.

this is an excellent point. no offense to previous entries that relied on command lines, but… I think it would be a more enjoyable contest for everyone if all entries from now on are “run and play.” do not rely on command lines. if a tiny 4K game needs to increase max heap size, I suggest you optimize in other ways…

[quote=“woogley,post:64,topic:25185”]
Web Start can deal with that bit anyway :slight_smile:

Personally, I think this is a knee jerk reaction. Executable JARs work just fine, and I believe should be a requirement for a downloadable version.

Let me ask you this: Have you ever tried your own hand at a 4K Java game? (If memory serves, you’ve never had an official entry.) It’s @$%#@ difficult! I know we all make it look easy, but you’re talking about forcing many developers to sacrifice precious space for a signature! Heck, the lack of requirement for an executable manifest was an intentional decision so that programmers could have that little extra space! While we’ve shown over the last three years that the manifest is a very tiny and acceptable compromise (especially if you want to “keep up with the Jonses” as it were), it simply hasn’t been proven yet that Pack200 can effectively make up for the cost of a signature!

If judging executable JARs is too much trouble for you and your peers, then I will happily withdraw myself from the competition and offer my services as a judge. I care that much about not stifiling the creativity of the developers.

I ran every game last year, no matter how much time and effort I had to put into making it work. While I would like to see all developers take a professional approach to deployment (it should Just Work™), I’m not going to put any sort of unreasonable barrier in front of them. The 4K contest is a very special thing to me, not just because I’ve always been a strong contender. It’s special to me because it encourages myself and many others to write games that they would have never found the time to write. Why it appeals to developers so much when similar contests like the 16K competition didn’t, may forever be a mystery. But what I do know is that new restrictions should be considered carefully and not made on whimsical statements like “Webstart is much easier for me”.

Agree with the “It should just work concept”. Some of last years games were much easier to get going then others. If I had 50 entries to judge, a consistent way of starting programs would be top of my list.

Not signing entries would also be high on the list, as otherwise it’s not immediately obvious that the games are under 4k, which comes to the pack200 question. One could include signing in the 4k limit, but that would use up the 800 or so bytes saved, which would lose any advantage of pack200. In that case, only applications which don’t need signing would be worthwhile with pack200. Actually I’ve been trying for that anyway, to allow exactly the same jar to be webstarted… but that’s a personal idiosyncracy.

Providing webstarted apps as competition entries also makes judging more tricky, as the jnlp needs editing to reflect the new codebase, before the thing will run offline. A possible solution is to mandate a codebase (e.g. C:\j4k2006\yourgame), but this is already getting PC specific, which is daft, as I’m hoping that some OSX & Linux testing will be done.

So that really leaves Applets as the only “just works” approach to pack200. My test gave about 20% more code in the same space. In my view Applets have slightly more overhead than Apps, since a new Thread needs to be started; however there should be change from the circa 800 extra packed bytes. Unless networking for head-head play, there is less reason to sign the jar. Networked games didn’t do well last year. Maybe the room would be best used for some in-game sound.

I will work with whatever the rules will be :slight_smile: If an executable jar is a requirement, then I won’t be pack200ing and will be producing standalone apps (using a JFrame). If executable jars aren’t required, I will probably pack200 the code (without signing) and produce applets. For the Applet, I’m thinking the downloadable zip file will contain the HTML file and the .gz archive & maybe a text file with instructions.

Alan :smiley:

Because the point of the competition is the 4k limit? :wink:

I agree, the point is not make something that ‘just works’ on anything. Lack of cross platform compatibility and difficult deployment have always been java’s dirty little secrets. (Granted the situation is much better today.)

Why shouldn’t the judges goto the cmd line to run a jar? "oh, last year we had 50 entries, it was to hard… ’ :’( Wah. Then you shouldn’t have been a judge.

Also the judges should be proficient with the equipment they use to test on.

:wink:

Only a few more days to go… everyone got their 10 ideas primed then?

Personally, I think you should have to enter at least 5 games to be considered :wink:

Kev

judges are not the only people who play these games…

which brings me to my next point, anyone who wants to judge can fire off an email to me at woogley[at]gmail.com. the catch is, you can’t have a game entry. So, kevglass, if you’re not able to participate in the contest but will have internet access by the judging time … :wink:

edit: alan brought up an interesting point about how tricky webstart is when it comes to validating the 4K limit. This doesn’t have anything to do with the contest, but I figured I’d just let you know I have what I call a “JNLP sniffer” which will cache the game onto my HD and write a new JNLP for Java Unlimited to use in the contest database.

Yes, all submitted games will be archived onto my server’s HD. That’s why it’s all automated this year. :stuck_out_tongue:

Personally, I think this is a knee jerk reaction. Executable JARs work just fine, and I believe should be a requirement for a downloadable version.
[/quote]
Executable jars are little bit more limited in the sense that you can’t set heap sizes and that sort of thing. But I agree they should be required given the pains of dealing with batch files and the like. I still prefer Web Start, but the main thing is consistency. Every entry should start with a simple double click on a single JAR if you go that route.

[quote]Let me ask you this: Have you ever tried your own hand at a 4K Java game? (If memory serves, you’ve never had an official entry.) It’s @$%#@ difficult!
[/quote]
Yes I have. I’m familiar with the issues. Time permitting I would enter the contest.

[quote]I know we all make it look easy, but you’re talking about forcing many developers to sacrifice precious space for a signature! Heck, the lack of requirement for an executable manifest was an intentional decision so that programmers could have that little extra space! While we’ve shown over the last three years that the manifest is a very tiny and acceptable compromise (especially if you want to “keep up with the Jonses” as it were), it simply hasn’t been proven yet that Pack200 can effectively make up for the cost of a signature!
[/quote]
This seems like a silly argument. The 4k limit is arbitrary as it is. If you were to force signing the limit could simply be adjusted to compensate. I don’t understand why it is such a big deal.

[quote]If judging executable JARs is too much trouble for you and your peers, then I will happily withdraw myself from the competition and offer my services as a judge. I care that much about not stifiling the creativity of the developers.
[/quote]
Signing has zero to do with stifling creativity. The contest is based on an arbitrary rule. If everyone is required to sign their jar then everyone is on equal ground. If a signed 4k jar is too restrictive then make it a signed 5k jar, it doesn’t matter so long as the same restrictions apply equally to every entrant.

[quote]I ran every game last year, no matter how much time and effort I had to put into making it work.
[/quote]
While your efforts are commendable, there were a lot of entries to test and if the entrant can’t be bothered to make the game easy to run that is a big deterrent and will be reflected in the scoring. Time and effort is supposed to go into making the games, it’s supposed to be effortless to run them.

[quote]While I would like to see all developers take a professional approach to deployment (it should Just Work™), I’m not going to put any sort of unreasonable barrier in front of them. The 4K contest is a very special thing to me, not just because I’ve always been a strong contender. It’s special to me because it encourages myself and many others to write games that they would have never found the time to write. Why it appeals to developers so much when similar contests like the 16K competition didn’t, may forever be a mystery. But what I do know is that new restrictions should be considered carefully and not made on whimsical statements like “Webstart is much easier for me”.

[/quote]
+1 on the “it should just work”, I guess I just disagree that Web Start is an unreasonable barrier.

That’s an easy statement to make, but can you prove it? Gameplay is all a matter of perception. You may not even realize how your perceptions are changed when you run a windowed vs. fullscreen game. Yet your unconcious may be telling you, “this game is more immersive than that one”. Judging a game in some other form than it was intended to be judged is unfair to the competitors. Especially if they spent their time tweaking their official entry to have as much of an impact as possible.

[quote=“swpalmer,post:72,topic:25185”]
Has anyone actually needed to adjust the heap? The default heap is extremely comfortable. Any game that can’t fit within it (what is it, 128 Megs?) probably has other issues. Which is beside the point anyway. I often repackaged games that weren’t executable for my own benefit. I don’t remember any of them having problems as an executable JAR. :slight_smile:

It was never a requirement that games be effortless to run. Obviously, bad things happen if the judges can’t get them working. However, there was a reason why a +1 bonus existed for executable files. The point of that bonus was to award developers for making their software easy to run. However, if they wanted to take the risk of requiring the judges to fiddle with their JARs, they could chose to gain a little extra space in hopes that their cool game will make up for it.

Since no one in the past three years seems to have made the tradeoff successfully, I’m of the opinion that requiring manifests is now an acceptable thing to do.

Wait, what? You have to announce what games you’re going to enter on the starting date? :open_mouth:

My plan for this year is to make unsigned pack200 compressed applets… I hope that’s acceptable… ?

Me too, and somebody better make a good case why not if it isn’t… ;D

Knock your socks off. You’ll need to wait for the official rules from Mlk, of course, but I don’t think that will be an issue.

Of course, our applications will kick your applets’ butts… (Kidding!) ;D

I hope so! =D

Half the fun of the competition is to see the amazing stuff people make.

Is it really that important that the contest be based on the illusion that 4k is somehow special? I mean things like “4k in bits is the same as the maximum value of a 16 bit signed number” is still a completely arbitrary statement. It’s now different than saying the contest should be 64k because that is the amount of addressable memory in the Commodore 64, it is the highest value you can count to with a unsigned 16 bit number, It is one tenth of the amount off memory that should be enough for everybody :), etc.

[quote]With all the work that has been done in this contest changing the allowed size would change the dynamics. If it suddenly went to 5K, would developers be as interested? I don’t know. But I’m not really looking to find out. The whole point is to pack as much as you can into 4K. If develoeprs want to eat the cost of a signature, that’s their right. Was it worth the trade? Questions like that are part of what makes this contest so interesting.
[/quote]
Well the Web Start packaging was supposed to be completely outside of the initial 4k constraint. Considering that most of the stuff has now been automated with regards to the submission process , why not just allow users to upload a 4k jar file and specify the name off their main class, then have the submission system add the manifest and signing stuff. That way the 4k constraint is checked upon submission and the rest of it is simple distribution details that make things consistent and simple for both the submitters and players.

Note, I don’t particularly like that idea of automatically signing the jar with a common certificate on submission, since it leaves things open to potentially serious abuse, but the concept is what I’m going for.

Another option is to provide a standard script that uses standard java tools to make the JAR, so obfuscation, pack200 and whatever compression can be used the same for everyone. Users would submit an uncompressed jar that would be repackaged automatically and checked against the space constraint. That keeps all the clever stuff in the code where I think the contest intends it to be. Nobody gets within the limits because they found some secret switch on 7zip as opposed to doing something brilliant in their code.

Just an idea, I don’t actually think it makes sense to go that far though.

It’ s hardly arbitrary. It’s one of the reason why 4K was such a popular number. (Just don’t ask me why there are 8 bits in a byte, which gave us 16 bit addressing in the first place.) I realize that I probably assign more significance to this than others, but once you start mucking around with hardware design you start seeing things in a different light. Considering the hardware limitations I’ve worked with, I have to say that 4K is HUGE. Simulating memory circuits of that size is a good way to slow my machine to a crawl. :wink:

[quote]It’s now different than saying the contest should be 64k because that is the amount of addressable memory in the Commodore 64, it is the highest value you can count to with a unsigned 16 bit number, It is one tenth of the amount off memory that should be enough for everybody :), etc.
[/quote]
That would be a good statement if it worked. Sadly, 64K is just way too much to work with. I could probably fit a full-blown, modern game in 32K without breaking a sweat. :slight_smile:

[quote]Well the Web Start packaging was supposed to be completely outside of the initial 4k constraint. Considering that most of the stuff has now been automated with regards to the submission process , why not just allow users to upload a 4k jar file and specify the name off their main class, then have the submission system add the manifest and signing stuff. That way the 4k constraint is checked upon submission and the rest of it is simple distribution details that make things consistent and simple for both the submitters and players.
[/quote]
That’s certainly doable, and I’m not against it. However, it does detract a bit from the challenge of packing your own executable games.

[quote]Note, I don’t particularly like that idea of automatically signing the jar with a common certificate on submission, since it leaves things open to potentially serious abuse, but the concept is what I’m going for.
[/quote]
I’m not sure if it matters much. Most signatures wouldn’t be certified by a CA, making them useless as a security device anyway. Even signed, all the cert does is tell you that the Certificate Authority guarantees that the signer is who he says he is. Which isn’t quite the same thing as guaranteeing that he’s not manevolent. The CA would probably revoke the cert if it was misused, but it may be a little late at that point. :slight_smile:

[quote]Another option is to provide a standard script that uses standard java tools to make the JAR, so obfuscation, pack200 and whatever compression can be used the same for everyone. Users would submit an uncompressed jar that would be repackaged automatically and checked against the space constraint. That keeps all the clever stuff in the code where I think the contest intends it to be. Nobody gets within the limits because they found some secret switch on 7zip as opposed to doing something brilliant in their code.
[/quote]
Now that’s just not fun. Everyone has their own little secrets each year. Usually we share them, but not always. For example, I kept my SuperPack software and sound engine (if you can call it that) under wraps until after the 2004 competition was complete. If someone wants to mess with special compression techniques to get more out of their work, that’s their right. Remember, half the fun is having people shout, “How the hell did they do that?!?” :wink: