Important: NO PACK200

note: before replying to this thread, please read Sun’s tutorial for pack200 to ensure you know exactly how pack200 works

pack200 has been disallowed from this year’s compeition. I have talked to several other game developers (even some who compete in the 4K) and they are as torn about the issue as I am, but they agree with the decision.

I’m not sure how many of the pack200 advocates out there truly understand the nature of the beast. Pack200 is NOT just another button you can press in your eclipse configuration and ta-da your JAR is smaller. Pack200 relies on server-side configurations. While there are many of you who are willing to jump through all of the hoops it takes to get pack200 working correctly, most people won’t. If we allowed pack200, there would be a severe advantage to people who have the benefit of having a server customized enough to handle pack200. There are still people who can barely get their webhost to launch JNLPs with the correct MIME type, good luck having those hosts deliver pack200 compression! Also, there are still several regular competitors that rely on geocities for hosting - most people don’t bother with paying for highly customizable webspace. We simply cannot introduce pack200 in a fair way.

With this in mind, we do not have a minimum java version this year! we instead have a maximum. This year you can use any Java you want up to (not including) Java 1.6 aka “Java 6.” So for those who are still set on developing your 4K entries with lower SDKs, feel free to do so. I would, however, recommend you use Java 5 for its more precise timing code.

I can understand this is going to cause some controversy, but with your support on this issue we can continue to keep this contest 100% fair and available to everybody who wants to participate! Now let’s get ready for the biggest 4K yet!

Just out of curiosity, why was the target JRE for J4K 2006 version 1.4.2 as opposed to an earlier version? Unlike 1.4.1 and before, JRE 1.4.2 includes the high-performance timer sun.misc.Perf. Was 1.4.2 chosen to support that class? For J4K 2006, was that (somewhat hidden) class allowed in the competition? For J4K 2007, if we choose to compile for JRE 1.4.2 instead of 1.5.0 (which supports a high-performance timer method in the System class), can we use sun.misc.Perf?

1.4.2 was chosen because at the time I figured it’d be best to give 1.5 one more year to populate itself on more computers (as we get visitors from slashdot)

I didn’t even think about the Perf timer… anyway, it wouldn’t have been disallowed I don’t think, but I’m not sure if any game used it. should absolutely not be allowed. There’s no guarantee they’re available in any implementation of java, even counting official sun implementations.
Using classes is as bad as using jni.

hmm that’s true.

it shall henceforth be enscribed in ye ol’ account of rules and regulations

Ok. So, sun.misc.Perf will not be permitted in J4K 2007, but System.nanoTime() will be allowed.

What about accessing system properties?

Are they all allowed, regardless of their symbolic name space?

for instance, the system property “sun.boot.class.path” as far as I am aware exists in all 3 main stream VMs; however because of its “sun” prefix I am unsure whether it is considered a “standard” property, or not. (it contains all library classes & jars that are present on the classpath)

Is someone going to write a simple constants pool examiner to ensure such rules are adhered to?

zeroone: yes nanoTime() is part of the library, thus permitted.

as far as abuse’s properties question goes, I honeslty have no idea. I didn’t even know about that property, though I’m 99% sure it wouldnt help any 4K game o_O

and, Abuse, nobody’s going write a constants pool examiner ;). By disallowing Perf, we help the participant steer away from a class that would break their game in different JREs.

there are some checks on the 4K games. for example I run all of the entries on a networkless computer to verify that no outside resources are being used. there are a few other simple validations I use, but definitely not a constant pool examiner :stuck_out_tongue:

It was a little idea I had, for a way to obtain a huge word dictionary for very little size cost.

Iterating through all the classes on the classpath, using reflection to grab the method names, and splitting them using the standard java naming convention (and disposing of the garbage names - you’d be suprised how much of the Java API doesn’t follow standard naming practices!), can get you a dictionary of about 4000 English words - at a cost of about 500bytes of code.
With an average word length of 5.5 characters, this gives about 20000 bytes of data - this equates to an extremely impressive loss-less compression ratio of about 40:1.

All that you need to do then, is devise a game that can make practical use of 4000 english words! =)

TextTwist4K :wink:

as impressive as it sounds, I’m still unsure if it should be allowed. I’m kinda in the middle (and somewhat drunk atm)

imo it should. stuff like that makes 4k fun.


I’m kind of leaning towards “no,” - I can see we’ll need to amend the "standard java library " rule to only include documented features.

if sun.misc.Perf is disallowed, there’s no reason to allow a non-documented System property (it is not one of the guaranteed properties as specified by the doc)

Well not to worry, the standard set appear to include java.home, so grabbing all the jars in %java.home%/lib is no more complex :wink:

Either way, the idea above was simply a way I thought of that could give me 1 up on everyone else in terms of effective jar space - I don’t think I want to use it, as it restricts the scope of the actual game to something I’m not particularly interested in making.
Implementing it was actually an interesting technical exercise into things I rarely use (java properties, zip manipulation, and regex).

It actually got me thinking how much game logic you could actually express through applying regular expressions to a know data set, and analysing the result.
Regex’s are certainly very compact and contain a great deal of advanced logic - though not all of it appears to be applicable to game logic.

Surely requiring that the game works on all 3 major platforms will ensure that no-one uses sun.misc.Perf? (it isn’t present in the Apple VM is it?)

I’m not going to lie, I really don’t know, I suck at technicalities =)

it feels more “logical” to allow only documented libraries. especially since the soundbank isn’t even allowed just because Sun decided not to distribute it with the public jre. (if that makes sense. maybe not. still drunk)

That is similar to what i was thinking of doing for my game (space trading sim) for generating the names of planets, ships, NPCs and the like. but I do not know if I will have enough byte space to do this and instead may just hard code and hope for the best :confused:

I ran a test on OS X yesterday. Apparently, sun.misc.Perf is in JRE 1.4.2 for OS X. Though, there is still no sense in using it if we can use System.nanoTime().

there are other java implmentations than the sun java jre. :slight_smile: