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?

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)

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

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

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! =)

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

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.

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)

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

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.

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 :/

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