Time to plan for '08

[woogley]

I wasn't going to sign on for another year because I thought the contest was kinda dying, but I just looked at July’s hit-count for java unlimited and it has 4,000+ unique visitors in the off-season! Wow! (on-season months vary between 10,000-15,000 unique visitors)

Also, as every year seems to go, we get more "mainstream" attention. For example, check out this great article at Java World that came out this past February: http://www.javaworld.com/javaworld/jw-02-2007/jw-02-games.html

So with that kind of visitor count, and reasonably good attention flying around, I'm definitely on board for another year. So it's August, and time to plan for the contest that's coming up in only 4 months.

The Plan
Launch: December 1st, 2007
Deadline: March 1st, 2007 2008 ^[/edit]
Results: instant (see below for details)

Not much of a plan, but it's in big letters, so it must be official, right?

so judging last year wasn't the best, but it definitely wasn't the worst, and I think it was a step towards a fairer system - the major flaw I think was not enough participation (which is partially my fault)

The voting system is going to remain public this year; there will be no judges unless there is a critically low public response. The problem that I’ve been having so far is keeping it all legit: i.e. not allowing for multiple votes (hence why last year's system linked to jgo's user base up to a certain join-date). While the jgo-linking did a fantastic job at keeping everything legit, it also created an insane amount of isolation (not many people trust sending their jgo password to a third-party site).

rant warning: the next few paragraphs blab about the javaunlimited site

On top of the above problems, the site is OLD. Like, really old. The site was coded in the early months of 2005, while this page was providing a very basic listing of the games. It was then launched in January 2006 for that 4K contest.

While the site is fully functional, the layout and code is very dated (it was coded before I made a living with php/mysql programming), so I’m sure it is absolutely polluted with security holes. In summary, the site not only needs an overhaul, it needs to evolve with the needs of the contest.

In the past, the site has purposefully strayed away from becoming "another javagamesfactory.org," because JGF was just getting started, and I didn't want to be an ass. But now that time is over, and the javaunlimited site needs to step into those boundaries, for these reasons:

• with 50+ game entries per year, popular vote is a must - but popular voting needs registration to help with keeping the vote as legit as possible
  
• nobody is going to register just for voting, and apparently not many will throw their JGO login across the web to a 3rd party site, either
  
• 9 out of 10 suggestions I get via e-mail ask for peer review, commenting, and other social features
• javagamesfactory is more or less defunct, and though Adam will flame me for this: that site is still fuck ugly
  
  

NORMALLY, the problem with creating a social website as suggested would take more than 4 months - but luckily, the code already exists! Does anyone remember the Playground project? It was a small experiment me and Kevin Glass were toying around with, which was eventually abandoned. However, I had written much of the "social" coding, and of course, I rarely throw away any code! The Playground-website-to-be had a pretty decent Web 2.0-ish layout (IMO). Well, here, take a look for yourself. While that screenshot doesn't really give you a good idea of how much code has been done, check out this API I made that was linking the Playground client to the website. So, by a little luck, a "new website" is already half done, all I really need to do is swap out the logo.

So, the idea is to revamp the javaunlimited site into a completely new java games site (not just contest-games)
end site rant

Alright, so the next paragraph involves the javaunlimited site as well, but also involves the contest a bit

Based on emails and forum post suggestions, here's the proposed features list for the site. This is where you can add your suggestion so it can be added in before the code concretes

Site Features List
+ public game submission
+ game tagging (vs. boring strict categorization)
+ peer review/commenting system
+ Digg-like weighted voting system
+ uploadable games (vs. public FTP) - this is mainly to avoid the horrendous "archiving" process
+ webstart generator (to keep it all consistent)
+ applet support (current site forces you to ZIP it all up)

Add yours here...

[moogie]

well if the games are all going to be hosted by your webserver then the whole debate about PACK200 is pretty void in that all competitors will be using the same webserver which i assume will be PACK200 enabled?

[Markus_Persson]

I still really really don't like the idea of using pack200, as it requires unpacking of the game before running it. Sure, this is done automatically by webstart, but it requires a fairly special server, and it doesn't work for downloaded .jar files.

The competition already feels a bit like an exercise in finding the best compression tool, and this is just making it worse, imo.

Games published by our own members! Go get 'em!

[woogley]

pack200 is still up in the air for me:

1) I currently don't have a server that supports it
2) I don't want to abandon pre-1.5 java versions
3) Pack200 by design is made for LARGE files, I don't think the minor compression of 4K games is worth the trouble

so, it' still up in the air, but I wouldn't count on it.

[moogie]

1) i am not sure but i thought is was as simple as modifiying .htaccess
2) i believe pack200 came in at 1.4.2? but using pack200 is not obligatory... people can choose not use it and if they want to target ancient JREs then that is their choice.
3) I have tested using pack200 in my 2007 entry and it was able to bring it down from my 4096 size to ~ 3300 bytes which is a massive saving! This saving was mostly lost with having to include pack200 launcher code to make it a viable entry as an executable JAR under the 2007 rules.
4) yes it does not work for executable JARs, however i was under the impression in that as long as one version of your game was under or at 4096 bytes the other versions could be over. i.e. have webstartable version using pack200 and a non pack200 version for download.

What makes jk4 so fun is attempting to use all your skill, tools and technology available to try and cram as much as you can in that 4k limit. To me, Pack200 is just another tool to be utilised.

But it is ultimately not my decision to make but i guess i am not convinced that the arguments against are insurmountable or particularly compelling.

I would like to hear other peoples opinions.

[Riven]

Because, as Markus said, this whole competition is turning into a compression-contest, I'd be much happier with a 8K contest, where no compression is allowed at all.

Just distributing a class-file!


I know it's not going to happen. but still...

[Jamison]

Because, as Markus said, this whole competition is turning into a compression-contest, I'd be much happier with a 8K contest, where no compression is allowed at all.

Just distributing a class-file!


I know it's not going to happen. but still...

I always thought that was the whole point of 4K in the first place...? I never knew any kind of compression was used until I read this thread.

[Markus_Persson]

Because, as Markus said, this whole competition is turning into a compression-contest, I'd be much happier with a 8K contest, where no compression is allowed at all.

Just distributing a class-file!


I know it's not going to happen. but still...

Wow, I actually kinda like that idea. =D

[Riven]

I will have nightmares of you and your custom built bytecode assembler, though.



Every once in a while, what you said back then, still echoes around in my mind:
   "... but where's the fun in that?"

[Markus_Persson]

I might be geeky, but I'm also VERY lazy. Now that I've proven I could do it in java "assembler", I'm far too lazy to actually do it. It's a lot of work!

Games published by our own members! Go get 'em!

[Riven]

You'd need a:

javasource->[javac]->bytecode->[javap]-> *finetune in notepad* ->[own-compiler]->bytecode

TOOL


Go go go!
(Then it wouldn't be so darn hard.)

[Markus_Persson]

Something like inlining assembler in the .java file probably would work.. I think... Then writing my own javac.

[Abuse]

FYI proguard has come a long way since last years competition, it now performs all manner of additional crazy (and in some cases insafe =/ ) peep-hole optimisations.

[Riven]

Isn't that the same as the extreme-zip/pack200 driven entries?
You often find yourself squeezing everything out of the sourcecode, to make it compile and zip under 4096 bytes, and then average Joe and his dog come along, run their tools on your jar and tell you that you have a few 100 bytes extra to spare now.  It's just not fun, this competition should focus on dirty-hacking, nasty tricks, not POJO, OO and a fancy zipper!


I hate programs that do the hard work for you... it levels the playing field too much.

[Morre]

Riven, I tend to disagree. The compression is fairly easy to get reasonably good, especially with the multi-tool compression utiility that was kindly provided by moogie last year. On one level, though, I also agree that the competition should be about the code and the games, not the compression, but I think compression is more or less needed for 4k. Nowadays, the competition is established enough that switching to 8k might be a bad move, and to be entirely honest... when you speak with somebody who doesn't know the details, doesn't it feel just a slight bit better to say that it's only 4k?

However, pack200 seriously changes the balance here, because it's so much more efficient. Add to that the fact that it's not launchable in the same way per default. That is, not just harder to launch (which might be okay per se if that was also the case for other compressions), but a different type of compression (if I'm not mistaken?). Improving compression is a different matter than changing the compression type, in my opinion. I vote no pack200.

[Riven]

The extreme wozzie-fancy-wozzie compressors used Pack200 under the hood, then dumped out a *.jar .

So not even disallowing Pack200 would stop its usage - nobody knows how you created your zip, right?

[Riven]

Two years ago, I almost finished my fake-3D Poker4K game, and I wanted to finish it last year, but the focus on compression took the fun part out of it for me. I can do the nastiests things, shrinking the class, increasing the ZIP. That's darn demotivating!

What about having an 8K limit on the bytecode, and let some server-side zipper, ZIP (or GZ) it all up for everybody.
The GZ will very likely be under 4K*. And as we're not counting HTTP-overhead, JNLP-overhead, why would we count ZIP-overhead?
Both the JAR and the JNLP will be generated on the fly! It's darn easy to code!

Everybody happy - I guess? (I am!)

[moogie]

and then average Joe and his dog come along, run their tools on your jar and tell you that you have a few 100 bytes extra to spare now. 

i am hurt

It was fun making the 4KJO tool and i learnt a lot about low level byte code! especialy since for my 2007 entry i am injecting the graphics byte stream directly into a compiled class file. And with making a self executing embedded pack200 jar, i learnt a lot about class loaders and pack200.

Each to their own, but i dont think avg joe would be able to perform these optimisations

[moogie]

Two years ago, I almost finished my fake-3D Poker4K game, and I wanted to finish it last year, but the focus on compression took the fun part out of it for me. I can do the nastiests things, shrinking the class, increasing the ZIP. That's darn demotivating!

What about having an 8K limit on the bytecode, and let some server-side zipper, ZIP (or GZ) it all up for everybody.
The GZ will very likely be under 4K*. And as we're not counting HTTP-overhead, JNLP-overhead, why would we count ZIP-overhead?
Both the JAR and the JNLP will be generated on the fly! It's darn easy to code!

Everybody happy - I guess? (I am!)

I am not how about games which have level data and the like which compress really nicely however would be way over the 8k limit before compression?

[woogley]

And as we're not counting HTTP-overhead, JNLP-overhead, why would we count ZIP-overhead?

because a JAR *is* a ZIP.

the HTTP/JNLP is not counted because that's just the methods of content transportation. the JAR/ZIP is the actual content

[Riven]

Oh please... me != n00b.


Inside the ZIP (or JAR...) there is a little chunk of GZ for each ZipEntry. The GZ is the data/content, ZIP is the structure, JNLP is the accessor, HTTP is the transportation.
In ZIP (or JAR...), the 'zipentry-listing' is actually twice stored, one 'stream-like' at the beginning, and one 'table-like' at the end. It's such a waste of space!

Maybe J4K has gained too much momentum to steer it around a bit? It would be too bad, because I'm not really fond of where it's heading

[Markus_Persson]

I'm not really fond of where it's heading

.. I didn't even submit an entry last year.

[Morre]

I kind of like the idea of having a standardized compressor and a higher max-limit for the class itself, although it would not lead to equally sized games, which is a shame... :/

[woogley]

Riven, seriously, you're splitting hairs there. It would be ridiculous to count ONLY the "compressed byte count" of the class file without counting the ZIP overhead that is neccessary to reassemble the game to be loaded. It's hardly a waste of space, it's how your game is put back together. If you want to take out the duplicate zipentry listing without corrupting your zip file, nobody's stopping you.

And this has been the case since J4K1, so it's not a new rule or direction; if anything, there's too few changes (hence why some people want pack200).

[Riven]

Riven, seriously, you're splitting hairs there. It would be ridiculous to...

Yeah, relax. Everybody is entiteld to their own opinion, and it's not up to you to say my intent is to split hairs and to make everybodies life hard and miserable. *faking a sob*

If you want to take out the duplicate zipentry listing without corrupting your zip file, nobody's stopping you.

Can't be done. Not possible. one listing == corrupt archive



You know what the point is - and I apologize to Moogie for the "average Joe and his dog"  - IIRC he was the one that re-zipped my JAR and told me I had >100 more bytes to spare. I tried, and tried, but I simply couldn't get it to compress it to the claimed size. Even downloaded the generously released 'bruteforce tool', which kept crashing on me, and the JARs it spit out, where not that far from 4096 bytes anyway - I simply failed to replicate it! This was extremely demotivating, knowing that if I could only get that zipper to work, all my problems were over, and I'd have room for a few more features.

I kinda stopped right after that.


I just don't want to spend half of the development time on finding/building/bruteforcing the right JAR, it's a Java contest! Maybe we should create a sub-category, or I could maybe build a little site to roll my own geeky-contest.

Who's got a spare dedicated/colocated server with a fancy JRE installed? Just send me a PM, I can offer a nice contest in return

[woogley]

Yeah, relax. Everybody is entiteld to their own opinion, and it's not up to you to say my intent is to split hairs and to make everybodies life hard and miserable. *faking a sob*

what the hell are you talking about?

anyway, the whole JAR thing comes with the territory. the fact of the matter is, code is not the only thing you have to optimize.

if we were to run a contest where the server zips up everything FOR you consistently, there would be WAY too many complaints about "well, from the server, it's 4.2k, but on my local machine I've crunched it with proguard/JoGa in such a way that it's 3.82k"

the problem with compression in general is there's nothing consistent about it. each game is subject to a different compression setting that may or may not work better.

[Markus_Persson]

Who's got a spare dedicated/colocated server with a fancy JRE installed? Just send me a PM, I can offer a nice contest in return

I wish I could..

[Riven]

what the hell are you talking about?

Little aggitated?

Anyway, the slightly more or less than 4K isn't a problem as, as said earlier, it whould be a 8K bytecode contest, but heck, why am I even bothering, you're attacking it like there's not tomorrow, so I'm not really expecting to convince you.

I'm going to see where I can get a tiny server with full access and give a few of my ideas a try.

[Riven]

To lighten the mood a little, I scraped all my art-skills together



how 'bou that eh?

[Abuse]

Little aggitated?

Anyway, the slightly more or less than 4K isn't a problem as, as said earlier, it whould be a 8K bytecode contest, but heck, why am I even bothering, you're attacking it like there's not tomorrow, so I'm not really expecting to convince you.

I'm going to see where I can get a tiny server with full access and give a few of my ideas a try.

1   2   3   4   5   6   7   8

String compressedClass = <utf8encodedZlibStream>; byte[] zlibStream = getBytes(compressedClass); // decoding algorithm for whatever algorithm you used to encode into utf8 form Inflater inf = new Inflater(); inf.setInput(zlibStream); byte[] uncompressedClass = new byte[100000]; int len = inf.inflate(uncompressedClass); Class c = this.getClass().getClassLoader().defineClass("A", uncompressedClass, 0, len); c.newInstance();

10 lines of code, and i've defeated your "8kb uncompressed class" limit.
Compression is a part of 4kb development, you cannot escape it.

However, good compression does not make a good game AND your game does not need to be optimally compressed (impossible!) for it to be feature complete.
Write a good game, and write it small - then optimise; optimise; optimise *until* you reach the 4kb limit - then stop.