Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (741)
Games in Android Showcase (225)
games submitted by our members
Games in WIP (823)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Java4K Competition 2015  (Read 27803 times)
0 Members and 1 Guest are viewing this topic.
Offline richard.pickering

Senior Newbie


Exp: 5 years



« Posted 2014-12-05 12:07:34 »

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 Smiley.  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?

Long Live the Java 4K!

Also, jMonkeyEngine is awesome! Smiley.
Offline SHC
« Reply #1 - Posted 2014-12-05 12:22:24 »

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?

Offline richard.pickering

Senior Newbie


Exp: 5 years



« Reply #2 - Posted 2014-12-05 12:41:56 »

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?

Long Live the Java 4K!

Also, jMonkeyEngine is awesome! Smiley.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline zeroone
« Reply #3 - Posted 2014-12-05 16:12:06 »

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

Senior Newbie


Exp: 5 years



« Reply #4 - Posted 2014-12-05 16:24:46 »

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

Long Live the Java 4K!

Also, jMonkeyEngine is awesome! Smiley.
Offline DarkCart

JGO Kernel


Medals: 121
Projects: 9
Exp: 50 years


It's all in the mind, y'know.


« Reply #5 - Posted 2014-12-05 21:46:14 »

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.

The darkest of carts.
Offline BurntPizza

« JGO Bitwise Duke »


Medals: 485
Exp: 7 years



« Reply #6 - Posted 2014-12-05 21:50:42 »

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.
Offline moogie

JGO Ninja


Medals: 16
Projects: 6
Exp: 10 years


Java games rock!


« Reply #7 - Posted 2014-12-06 02:41:13 »

My Thoughts Smiley

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 ?

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

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

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


Java4k RIP 2014
Offline BurntPizza

« JGO Bitwise Duke »


Medals: 485
Exp: 7 years



« Reply #8 - Posted 2014-12-06 02:47:08 »

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.  Smiley
Offline moogie

JGO Ninja


Medals: 16
Projects: 6
Exp: 10 years


Java games rock!


« Reply #9 - Posted 2014-12-06 02:49:31 »

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.

Java4k RIP 2014
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline BurntPizza

« JGO Bitwise Duke »


Medals: 485
Exp: 7 years



« Reply #10 - Posted 2014-12-06 02:56:54 »

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

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.
Offline richard.pickering

Senior Newbie


Exp: 5 years



« Reply #11 - Posted 2014-12-06 16:41:28 »

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

Long Live the Java 4K!

Also, jMonkeyEngine is awesome! Smiley.
Offline pjt33

« JGO Spiffy Duke »


Medals: 40
Projects: 4
Exp: 7 years



« Reply #12 - Posted 2014-12-06 21:20:39 »

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.
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.
Offline moogie

JGO Ninja


Medals: 16
Projects: 6
Exp: 10 years


Java games rock!


« Reply #13 - Posted 2014-12-06 21:21:17 »

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

Java4k RIP 2014
Offline zeroone
« Reply #14 - Posted 2014-12-07 01:06:49 »

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.

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.
Offline BurntPizza

« JGO Bitwise Duke »


Medals: 485
Exp: 7 years



« Reply #15 - Posted 2014-12-07 01:18:53 »

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.
Offline SimonH
« Reply #16 - Posted 2014-12-07 01:29:58 »

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?


People make games and games make people
Offline BurntPizza

« JGO Bitwise Duke »


Medals: 485
Exp: 7 years



« Reply #17 - Posted 2014-12-07 01:38:00 »

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.
Offline richard.pickering

Senior Newbie


Exp: 5 years



« Reply #18 - Posted 2014-12-07 13:15:04 »

Very interesting ideas Smiley.

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?

Long Live the Java 4K!

Also, jMonkeyEngine is awesome! Smiley.
Offline pjt33

« JGO Spiffy Duke »


Medals: 40
Projects: 4
Exp: 7 years



« Reply #19 - Posted 2014-12-08 11:04:39 »

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

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.

I'm pretty sure 8K uncompressed gives one even less (significantly less) room to work with than J4K did.

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

GameSourceUncompressed class fileFinal file
Gravitational Fourks *29315136534054 (jar)
Quadriletteral37178117683899 (jar.pack.gz)
Stick Shift 4k48059166083704 (jar.pack.gz)

* I actually did a bit more work, so these are for v1.3 rather than the submitted version, which was 1.0.
Offline SimonH
« Reply #20 - Posted 2014-12-08 14:17:31 »

Oops! I should have said .jar file rather than .class file!
What I meant was no proguard, pack, gz compression etc, so the entire build chain would be;
1  
2  
javac game.java
jar cfM game.jar game.class

That way anyone with vanilla java and the source code could play the game.

People make games and games make people
Offline Zarkonnen
« Reply #21 - Posted 2014-12-08 15:46:57 »

I would be up for that. How about say 12 kB of Jar created with vanilla javac and jar as suggested by SimonH?
Offline pjt33

« JGO Spiffy Duke »


Medals: 40
Projects: 4
Exp: 7 years



« Reply #22 - Posted 2014-12-08 16:44:59 »

Oops! I should have said .jar file rather than .class file!
What I meant was no proguard, pack, gz compression etc, so the entire build chain would be;
1  
2  
javac game.java
jar cfM game.jar game.class

That way anyone with vanilla java and the source code could play the game.
I foresee disputes about size. Different versions of javac will produce different size class files: older ones include less cruft. (And you're even including debug information!)
Offline richard.pickering

Senior Newbie


Exp: 5 years



« Reply #23 - Posted 2014-12-08 20:59:37 »

We could solve the issues of different versions of javac by sticking it down to one particular release, i.e. Java 7 update 51 and then provide a download link on the site.

Another idea, in order to resolve the disputes about size that may be encountered, I'm more than happy to organise about 3 or 4 different wings of the compo to accomodate different sizes of JAR file.  They would all be judged in the same way and by the same panel maybe to ensure fairness across the board, and they would be like their own categories and therefore you'd get a winner for each category.  What do you guys think?

Let me know if you think there's any weight in that idea Smiley.

I'm just thinking that will help us try out different sizes in order to figure out what sits best within a new format.

Long Live the Java 4K!

Also, jMonkeyEngine is awesome! Smiley.
Offline tom
« Reply #24 - Posted 2014-12-08 23:38:33 »

I would be interesting to enter the competition.

How about allowing executable jars. Otherwise keep it as it was. They were allowed a couple of years ago. Not as user friendly as applets. But would not be a problem for fellow developers to try the games.

Offline moogie

JGO Ninja


Medals: 16
Projects: 6
Exp: 10 years


Java games rock!


« Reply #25 - Posted 2014-12-09 05:43:12 »

Executable JARs do not really provide any more benefit over the Java4kLauncher it terms of accessibility for non-developers.

It would, however be easier to submit entries in the absence of the java4k.com website.

Java4k RIP 2014
Offline richard.pickering

Senior Newbie


Exp: 5 years



« Reply #26 - Posted 2014-12-14 17:49:47 »

Apologies for my lack of responding to this thread for a few days.

Okay, so far we have:
Java 4K launcher used as publishing/execution method

Same rules as before in terms of code size, but possibly with a number of different categories, i.e. 8K, 16K, 32K.  These will all use a fixed compression tool chain which is to be defined.  This will cause more of a code golf effect, however the tool chain can be fairly extensive, it's just common across all entries.

We will tie the version of Java used to a particular release so that we are all building on a common tool set.

The above rules mean that the 4K competition will be exactly as it was with the addition of a common tool chain, however the different categories mean that we have a chance to check out what can be done at higher limit levels.

Any more suggestions?  Or, please let me know about what you think to the suggestions made so far, or the current plan; it's all mutable Smiley.

Long Live the Java 4K!

Also, jMonkeyEngine is awesome! Smiley.
Offline moogie

JGO Ninja


Medals: 16
Projects: 6
Exp: 10 years


Java games rock!


« Reply #27 - Posted 2014-12-15 01:04:53 »

I would suggest expanding the byte code compiler rule such that other languages that target the JVM can be used. However that, similarly for Java language, only one defined version can be used.

Note that it is not important to me as I will be using java, only that there has been a couple of entries that used different languages that run on the JVM

Java4k RIP 2014
Offline moogie

JGO Ninja


Medals: 16
Projects: 6
Exp: 10 years


Java games rock!


« Reply #28 - Posted 2014-12-15 01:07:10 »

Also, if we are using a common tool chain then the only way to enforce this is to have the submissions in source files + resources format. I would suggest that an automated submit, compile, compress, return output script be made available.

Java4k RIP 2014
Offline Corvid

Junior Devvie


Medals: 2
Projects: 2


/*do not read this code sober*/


« Reply #29 - Posted 2014-12-19 21:37:52 »

Well, having participated in the 2013 contest (B4llBasher), but having moved on to other things for a while, I was seriously disappointed to see that Java4k wasn't running this year.  I was actually looking forward to it since about July and was deliberately not visiting JGO as I felt seeing all the WIP threads come December would have been a real treat to look forward to.

What a shock to finally visit the Java 4K site and see it cancelled!

If you guys do decide to run this year, count me in.  I'm also really excited about the 8k and 16k possibilities. It's small enough to have to work hard, yet large enough to have that work really pay off in a finished product.  My only fear is there wouldn't be enough participation to spread over 4, 8 and 16k categories.

Oh, and:

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

This approach gets my vote.  I found the compression part of the contest the least interesting, as it was more about predicting/knowing what would compress well,rather than writing ingeniously efficient/tiny code. 

Pages: [1] 2
  ignore  |  Print  
 
 

 
Ecumene (107 views)
2017-09-30 02:57:34

theagentd (134 views)
2017-09-26 18:23:31

cybrmynd (244 views)
2017-08-02 12:28:51

cybrmynd (236 views)
2017-08-02 12:19:43

cybrmynd (237 views)
2017-08-02 12:18:09

Sralse (251 views)
2017-07-25 17:13:48

Archive (863 views)
2017-04-27 17:45:51

buddyBro (1006 views)
2017-04-05 03:38:00

CopyableCougar4 (1564 views)
2017-03-24 15:39:42

theagentd (1372 views)
2017-03-24 15:32:08
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!