Time to plan for '08

Contests 4K Game Competition - 2007
#1

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][size=14pt]
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…

#2

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?

#3

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.

#4

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.

#5
  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.

#6

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… :-X

#7

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.

#8

Wow, I actually kinda like that idea. =D

#9

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?”

#10

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!

#11

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.)

#12

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

#13

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.

#14

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. :wink:

#15

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? :wink:

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.

#16

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?

#17

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

#18

i am hurt :stuck_out_tongue:

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

#19

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

#20

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