Java4K Competition 2015

Contests
#1

Having seen the fact that the Java 4K has been ended, seemingly due to the Java security model changes at Java 7 and the very specific settings required to get unsigned applets running, I was really disappointed. I only took part in the 2014 competition, making the game “Mostly Newtonian”. It was a buggy mess but it was such good fun to make and it was a great lesson about managing the scope of the project, and I was really looking forward to participating in future Java 4K competitions.

This is the reason that I would like to suggest I organise a less formalised Java 4K competition; really a bit of fun to aim your extreme code footprint reduction skills at. If you have any interest in taking part in this or helping with its organisation, please let me know. If you think this is a good idea, also, please let me know :). I am posting this thread in order to figure out if there’s any interest in this as well as for tips/advice and suggestions on how a future competition could be run (for example, in the interests of fairness should the 4K just be the class file size footprint or should it be the full JAR file size like it was for the Java 4K, or if there should be different areas that people could win in, e.g. gameplay, technical complexity, sound, etc.).

I know this is a really wordy post, and I apologise, I suppose I just want to ask, what do you think to this idea?

#2

I never participated in Java4K, although I was seeing it for the last three years, because I think that the rules for the original Java4K are no longer possible to follow in newer versions of Java. The first thing that come to my mind is the death of applets.

Applets were once a very cool feature of Java, when they’re released at first, several people used them, I made a lot too, but now with the weird “security” aspects, Oracle has killed applets. I don’t know what had happened, but if Oracle had cared, they can make Applets still stand-out just like Adobe is still maintaining Flash.

With that in mind, we can no longer use applets or keep the 4K game size rule, I don’t think that is still valid. So now, people must use either Swing or libraries and engines like LibGDX, Slick2D, Mercury, etc., to make their games, and the libraries itself aren’t less than 4KB size, the size limitation is impossible now. We need some other rules, that are flexible to the current scenario of late 2014.

Alternatives? I can only think of restrictions like do from scratch without libs, or do it in a specific time span… But there are already competitions being conducted with those rules, what should we have as rules to make Java4K be unique?

My only suggestion to you is that if you are really willing to having a competition like this, it is better to drop the idea of Java4K now, and take part in LudumDare. That’s what I think, is the best option for us in the current scenario.

What do you think?

#3

I suppose what always made me fascinated by the Java 4K and why I participated in it this last year was the deadline; it was almost non-existent as it was from December to February and you could write games outside of those time periods and submit them next time. My main gripe with a lot of other competitions is their fascination with extremely small time-scales, and prototyping a whole area of gameplay within 48 hours generally. I mean, with the Java 4K I was able to make my game during lunch breaks at work, when I got home from work, even when I was working away I was able to do a little coding on it. And all this was really fun. I don’t want to devote a weekend to developing games based on a theme suggested by anyone else, I just want something to do as a little side project which can be worked on whenever really.

In terms of the technical considerations, if the worst comes to the worst, we could always develop a small library for the games which would not be counted against the 4K game size and would handle things like window creation, graphics rasterisation, etc. Or we could make it really interesting and use something like jMonkeyEngine (and then make the rules more around 4K class file size of the class file which you have all your game logic code within, though this would be less feasible due to its high reliance on high level object oriented features which can be rather bloaty).

I think there are options which we could follow to make this competition still work, I think we just have to think outside the box a little. And if the worst comes to the worst, and it doesn’t work very well the first time, the rules can be changed and tweaked to make it more feasible. What do you think?

#4

J44K Contest: you submit 1 Java source file no larger than 16K.

#5

That sounds like an interesting idea; another idea I had earlier was maybe allowing a certain quota of file space for graphics and sounds, as before in the Java 4K I think it was really rather difficult to get imagery or sounds into the games. I suppose it’s all about us choosing a single file size to go for and then to try it out, and then tweak it; it will get progressively better as a compo as time goes on, if the interest proves to be there :).

#6

This totally defeats the purpose of it being called “Java4k”, but maybe you should raise the size limit to something like 8k or even 16k.

#7

I know that J4K sources often weigh in at > 35Kb, but then again they weren’t golfed, so…

Code golf at that scale is evil. And Java isn’t that great at it, considering the boilerplate. Wound be interesting to see though.

#8

My Thoughts :slight_smile:

  1. I am a proponent of the current rules. But I enjoy the compression aspect… hunting for those extra bytes! No matter what is decided, there is a delivery problem: will have to be run outside of a browser… so why don’t we leave the rules the same and use the Java4kLauncher ?

  2. larger than 4k JARs start to remove the equalizer effect. That is, the difference between a 2 year java programmer and a 10+ year java programmer’s entry is smaller when the allowed bytes are smaller. This means that more entries are able to compete effectively. 4096 bytes seems to be the sweet spot.

  3. Accessibility. Moving from non-standard java libraries restricts the number of potential entrants as they will be required to learn a new library. see underwhelming response to the LWJGL16k competition.

  4. One large source file means that you have to embed graphics into the source file meaning that you cannot lever off of standard and byte-cheap image reading methods. Not a big issue I guess. Out of all the options presented thus far this is one i would most likely support. It does have an added benefit of being somewhat future proof.

#9

It would definitely have to be limited to just source files, because otherwise I could just embed a .class file (of any size really) in the png or whatever and dynamically load it via ClassLoader.defineClass()…

Unless the sources are reviewed for unfair tricks. :slight_smile:

#10

Maybe I am not the best person to ask for that as I actually would applaud the use of tricks like that as long as they are made public for others to use.

#11

Cool tricks yeah, but probably not ones that directly circumvent the entire point of the compo. :point:

defineClass() would enable one to write their game normally (a full game, any size!) and then pawn it off as a (probably large) image file, with a small loader class that would easily fit in any size limit. The entire actual game executable would be inside the image, and not counted in the size restriction.

#12

Okay, so far what do you guys think to this then:

  1. we use the Java4K loader as the publishing and accessibility method, you can download sources from the site and put them into that or I suppose all the games from a year’s competition could be put together with the launcher as a single download.

  2. we measure the source file’s file size however the source code is reviewed by the judging panel to ensure no unfair tricks have been used, and it is down to a vote of the judges whether or not a trick is fair or unfair… probably needs some more clarification there I think maybe.

  3. we use the same standard libraries that we have been using so nothing changes from a coding perspective.

  4. we keep the 4K size as Moogie says, it is the sweet spot and if we use the same libraries I agree.

What does everyone think on the above points?

Also, keep the ideas coming guys, so far the suggestions and ideas have been great :).

#13

This doesn’t make any sense in conjunction with your point 4), and it is a major change in direction. It also forces people to write submit Java source. I know that might sound a bit silly in the context of a Java competition, but previously there was nothing in principle stopping people from writing in any other language which targets the JVM. In fact, I squeezed out the last few bytes from one of my entries by disassembling the class file, tweaking it, and reassembling it with Jasmin.

In order to stay true to the history of the J4k, I think that the download should be what’s explicitly limited in size and not the source.

#14

I am warming to the idea of a “code-golfed” competition where only the java source file is submitted.

my reasons:

  1. It is in same spirit of the java4k competition, but different that might give freshness to the competition.
  2. Does not require complex compression chains. However, it remains to be seen whether the effort to golf code is more than using the compression chains
  3. Easy to store entries for prosperity. Java syntax and idioms are quite unchanging. i.e. future proof
  4. If people are concerned about malicious code, they can analyse the submission before running it
#15

As an experiment, someone should take one of those large source files, remove all the white space from it, remove all the code comments and rename all the variables to single letter names to find out how small the source can potentially get.

#16

Theoretically anyone serious about it should write a script which does that, because all your time is spent figuring out how to restructure a program’s logic to reduce characters… merely minifying the code is not enough.

#17

I don’t like limiting the source size for 2 reasons;

  1. The compression-chain problem simply moves from the .class file to the .java file.
  2. The source code becomes unreadable to newcomers.

I’ve learned through long experience: give variables meaningful names and comment a lot. I would like to encourage that practice - source size limitations prevent that.
The whole reason that compression became an issue was because a 4K game file contained a lot of ‘stuff’ eg a compressed ‘empty’ applet was over 1K. I say we should allow large sized source but the compiled .class file should be <8K without any compression.

Java8K anyone?
New rules;

  1. Source code is the submission. Less than 64K and must compile on vanilla java 7. Points awarded for legibility!
  2. Class file must be <8K and run in an applet tag/appletViewer/java8KLauncher whatever.

I still weep bitter tears when I think of how the potential of applets was destroyed!

thinks wasn’t there a library called XVLM or something that converted java source to HTML5?

#18

Problems:

  • Points awarded for legibility! - Too subjective to award points to.
  • Class file must be <8K and run in an applet tag/appletViewer/java8KLauncher - I’m pretty sure 8K uncompressed gives one even less (significantly less) room to work with than J4K did. Also this whole thing ended because of applets. That said, libGDX does HTML5 export.
#19

Very interesting ideas :).

Wouldn’t it be possible to have it so that the source is submitted but the whole thing is limited by the size of the .class file. That way you get to keep the file size limit roughly similar, and everyone gets to see the source. I mean another idea maybe would be to have the source submittable as a ZIP file so that you still keep some compression in there and when it’s submitted at the end, the website could automatically run a zip on the submitted class file and sort everything out so that everyone is working to the same compression too.

I mean I think some of the issue was caused by the compression area gaining more and more influence on the overall file size, and people could use different compression methods, so why not alleviate that to start with by making it universal, the compression method utilised.

That sort of maintains the current system while improving the accessibility for newcomers and makes it fresher I think, what do you guys think?

#20

Much more. It’s possible to set up a decent compression chain from scratch in a few hours - varying according to how much you already know about what’s out there: if you know that you want Proguard, Zopfli, and the zip2gzip I uploaded to the forum a couple of years ago, you could do it in less than one hour. It takes a few hours to do a proper golf of a 2k Java source file, and then once you see how small you can get it, it’s in a format which makes it really hard to add new features which use the remaining space.

You’re quite right. To inform the discussion, here’s the breakdown of the three Java4k entries I finished:

[tr][td]Game[/td][td]Source[/td][td]Uncompressed class file[/td][td]Final file[/td][/tr]
[tr][td]Gravitational Fourks *[/td][td]29315[/td][td]13653[/td][td]4054 (jar)[/td][/tr]
[tr][td]Quadriletteral[/td][td]37178[/td][td]11768[/td][td]3899 (jar.pack.gz)[/td][/tr]
[tr][td]Stick Shift 4k[/td][td]48059[/td][td]16608[/td][td]3704 (jar.pack.gz)[/td][/tr]

  • I actually did a bit more work, so these are for v1.3 rather than the submitted version, which was 1.0.