I disagree! There have been some abysmal entries it's true, but overall I'd say the quality was remarkably high, especially given the constraints.I was watching a vlogger who set out to find the 10 best LD entries (out of 2700!) and he had trouble actually finding 10 which (in his opinion) had any playability value at all. That's 0.3% 'good' games. I'd give 4K a figure of 10-20% 'good' games, and rarely a contest goes by without at least 1 really top quality game being produced.

I was wondering if it would be possible to make/use a tool which would 'html5-ise' the games...?

I dunno, but I'm spoiled for choice with the instant accessibility of Flash games these days, so getting something that simply looks and sounds awful (when it makes any sound at all) just because it's 4k isn't all that much interesting to me as a player. The 4k competition appears to exist mostly for the benefits of developers and this is basically what limits its appeal to such a tiny audience - it's by programmers for programmers to show off to each other.

I like java 4k, as the size limits the amount of time I spend on the game (Usually a couple of weekends). The gradual demise of Applets does however make this more of a by-developers-for-developers format, although I think it was always pretty much that anyway. More annoying for me this year is the totally broken Key_Release functionality, at least on OSX, which looks like staying broken until Java 8. So much for run everywhere. More like run away everywhere.

The LWJGL16k was a nice idea too, although it never really got off the ground. Twice. Of course, if it ever happens, I have one finished game and one almost finished game on the blocks. They both use legacy direct mode though.

In terms of compression, Java 5 + Proguard + kzip work pretty well, although you need a utility to convert zip to gzip (strip off the zip header). Edit: Actually I used Java 6 last year, or at least pack/unpack from Java 6. I might have still been using version 5 javac, since the files were smaller. Yes I did - Java 5 compiler + Java 6 tools.

So where do we go from here. I don't rightly know. I've gone right off Applets though. Even webstart would be better.

Running applets c.a. 8-10 years ago wasn't such a hassle, in comparison to other similar technologies, realplayer, vr plugin, and even flash.

The grace period is over, users are not forgiving anymore, they want stuff to work and it should work. My 9 yearold nephew can't be bothered with going to java.com and download and install a JRE. He uses youtube all the time, and it works, he plays flash games all the time, and it works, and he uses an ipad and everything works.. no security warning dialogs or missing plugin errors.

But that debate is pretty much settled, Java simply lost the race for the web browser, despite having like a 10 year head start on flash.

If normal users can't use applets, there's no point with the "applets only" rule. We can go back to webstart and see how that shakes things up in terms of window sizes (fullscreen) and such. (I'm inclined to do a "webstart only" contest next just to make it a bit different).

If normal users can't use applets, there's no point with the "applets only" rule. We can go back to webstart and see how that shakes things up in terms of window sizes (fullscreen) and such. (I'm inclined to do a "webstart only" contest next just to make it a bit different).

Please, no! Webstart is an even more evil experience than applets, you still get scary pop-ups and then you have to 'uninstall' every single game you play through the control panel? WTF?!One thing we all agree on: immediate gameplay gratification through java is no-go. To my mind, either we play it as a by-devs-for-devs thing or do something completely different.Anyway, with the Minecraft and Runescape (is that still going?) phenomena, maybe applets aren't quite the total turn-off we think they are.Can anyone name a successful game that used webstart?

In terms of compression, Java 5 + Proguard + kzip work pretty well, although you need a utility to convert zip to gzip (strip off the zip header). Edit: Actually I used Java 6 last year, or at least pack/unpack from Java 6. I might have still been using version 5 javac, since the files were smaller. Yes I did - Java 5 compiler + Java 6 tools.

javac 6 targeting jsr14 puts the least junk into the class file. Unfortunately javac 7 no longer supports jsr14 as a target, so you need an old compiler.

I don't have good memories of the year we used webstart. If we're not doing applets, I'd rather take a big jump into Android (although I confess that as I don't have experience with it, I don't know how realistic 4k is - does anyone know how big an Android hello world is?)

javac 6 targeting jsr14 puts the least junk into the class file. Unfortunately javac 7 no longer supports jsr14 as a target, so you need an old compiler.

I don't have good memories of the year we used webstart. If we're not doing applets, I'd rather take a big jump into Android (although I confess that as I don't have experience with it, I don't know how realistic 4k is - does anyone know how big an Android hello world is?)

Thanks for the tip on javac 6 targeting jsr14, which I assume is 1.4. My main compliant about applets is that currently nearly all of the ones on Java4k.com are not working on OSX, which makes it a PC only contest. I have a PC, so no problem developing, but at the moment I think applets are even more broken than webstart. If both are off the table, then it's back to executable jars, which are fine when you know and trust people, but not so good for entries from unknown folks. I have an Android tablet and could develop for that, but then there's the problem of guessing how much processing power people have available and catering for all the different screen sizes. Still, it's an option.

Edit: It's just Key_Release that's borked, so I could do an Applet that just relies on the mouse. For instance ApoHockey still works perfectly well on OSX as it only uses mouse input.

Ok, it actually wants you to add stuff to the manifest. That means we will have to have a manifest and it will bulk out the jar considerably. We'll probably have to submit two jars, one with and one without the manifest.

Quote

Note to the Publisher: Security features to prevent unauthorized redistribution of your Java application will cause this application to be blocked in the future. See current Java documentation about Jar Manifest entries for the changes that need to be made. Note to Users: For any questions, please contact the Publisher who provided you with this application.

Edit: I added them, but then got a slightly different warning message, when running from local disk (i.e. no webserver). Looks like running java applets direct from the file system is on its way out too.

Edit: So far I haven't been able to remove the warning even using a webserver. I'm coming to the opinion that you can't remove the warning, but if you don't add the extra manifest entries, you java will refuse to run the applet outright on some future release. Edit: Actually I'm coming to the opinion that unsigned and self-signed won't work at all next release whatever you do.

Edit: Oh and there is a warning on self-signed applications too. Looks like self-signing won't work soon. I wonder whether installing my own self created root cert would fix that. I'm not sure whether that would work either, since java now phones home to check revocation lists. It *might* work provided security is not set to the highest setting.

Overall: If you buy a traceable code-signing certificate, you still get a warning the first time you run an applet, but I believe there is still a tick box to suppress it on future use. Unsigned and Self-signed applets work in this release, but display a warning every time and won't work at all in a future release. I think this could be the last Java4k competition, as it will just about work this year, but won't work at all next year, unless we go to traceable code signing, or have a custom downloader.

I never took part in the Java 4K stuff.The reason is I would really obsess over technical details and trying to cram code in there.Also audio was almost impossible.Also sprites very much.

I do understand that limitations yield good products, it has been shown again and again.I just think that the arbitrary limitation of the game having to be 4kb of size max is kinda... well its a simple rule that IMPLIES a lot of restrictions but has downsides.

If you rather have like... a time limit to develop in, and then maybe like 8-bit colors and sound for example... the game can only only be x minutes long in average to play - I dunno, I'm not going to make up any reasonable rules here. I just think, in general, a completely different kind of set of limitations would be much better.

From the technical standpoint the idea of having a launcher that includes even a private jre, where you can download kinda like DLC new games that are submitted for the competition would be the very best thing.

I also imply that we ditch Java2D completely. I simply believe one should not code games in Java2D, its atrocious. LWJGL, Libgdx and others should be allowed.

I wanna make a game within limitations, but I dont wanna fiddle around with crappy Java2D and stuff, wasting time that doesnt improve gameplay.

Looks like self-signing won't work soon. I wonder whether installing my own self created root cert would fix that. I'm not sure whether that would work either, since java now phones home to check revocation lists.

Installing your own root cert should fix that problem. Revocation lists aren't an issue (they're a good thing); at worst, if Java insists on having a CRL you need to ensure that all the non-root certificates in the chain include a "CRL Distribution Point" value which is a valid URL to an empty CRL.

How about someone make a downloadable game-loader, wich dynamically loads and executes the Java4K applets.

From a users view looking like this:

-download the Loader (conveniently with an exe starter version for windows)-GUI starts, and loads a list of Java4K jars from the website (Jar, Thumpnail, Descriptive test)-select a game from the list, and hit run-the game could be executed in a seperate window, or on the side inside the Loaders window.

Dynamic updates:each start, the Loader can (automatically) look for new or updated entries, and downloads the jars / descriptions

like a little "steam" client for Java4k

BTW: this distribution method could be used for all kinds of other (smaller) games herePlus developing it is a nice (and more 'serious') programming challange.

Why not simply have a javascript4K compo? Plenty of compression tools about, instant gratification, runs everywhere... I'd be up for that!I think depending on libs or a custom JVM might be asking too much of casual players.

Looks like self-signing won't work soon. I wonder whether installing my own self created root cert would fix that. I'm not sure whether that would work either, since java now phones home to check revocation lists.

Installing your own root cert should fix that problem. Revocation lists aren't an issue (they're a good thing); at worst, if Java insists on having a CRL you need to ensure that all the non-root certificates in the chain include a "CRL Distribution Point" value which is a valid URL to an empty CRL.

Sounds promising. We could provide a root certificate on java4k.com and have everyone use a code-signing key derived from it. People would need to install the cert before playing. This used to be as easy (on PC) as clicking on a link pointing to the cert, although I haven't checked that this still works in modern browsers.

Another idea is for someone to write a java applet (or application) loader. If this is written in java, it will need signing with a real code-signing key and would have to be written defensively so as not to get 'repurposed'. The new codebase manifest attribute would help with that, but it would probably be sensible to call the downloaded applet using a sandboxed thread.

I would like to have such a contest twice a year instead of only once. Because it's fun And lwjgl should be an option too. I saw that the last lwjgl16k contest was in 2011. Maybe we could rearrange this and combine it with the rules of 4K and relieve the contest.And the execution problem isn't one, because who except us is going to play them? We know how to execute a jar file.

We could also use a wrapper like jarSplice. But in the end we have to do this contest. Either with Graphics2D or GL11

However, the 4K game contest in its present form is often more about designing a good compression chain than about creative game design. This makes it less newbie-friendly. Without a good compression chain (which can be pretty hard to do) there is no way to meaningfully compete in the contest.

Groboclown put together a great set of ANT scripts two years ago. It's what I used for the 2012 competition. It does proguard, packing, gzip, etc, even with different block sizes. I think I had to get proguard and a 7zip separately and configure the script with their locations, but having that toolkit does lower the entry bar significantly.

So I had a couple of hours free, and I wrote an app that can load applets from the web. Obviously this is only a proof of concept, it's just hard-coded to use the first app that came up when I visited Java4K (with the number of games apo submitted, it was about 50% chance to be one of his .) The next step would be to either screen-scrape all the games for a given year, or else set up a web service or rss feed to supply the info we need (jar url, class name, width, size.) Then a panel could be added to this app showing all the games along with a button to load that game in the panel. Probably would be good to have a menu bar as well, with the title of the current applet and a back button. Also to be determined is whether it can handle gzipped jars.

The code is fairly simple, so I haven't commented it. Details available on request. Also, please let me know if you get any network warnings - I half expected one when my app wanted to pull the jar from the web, but I didn't get any warnings at all. Would be good to know if that's just my firewall settings (I do client/server programming), or if a locally running Java app gets permissions for network access by default.

You'd download like a very small launcher file, (be it .jar, .exe, or however you want to bundle it)

Then, will it be able to at some point, have a listing of all of the games available, and then dynamically load the applets into the 'launcher', e.g. mini steam launcher/ingame browser/app player? )

Yep, that's the idea. Since applets are panels, we can embed an applet directly in a java application, removing the need for running the applet from a browser. Ideally the listing of all games would come directly from the java4k website, so that any new games would be listed without requiring the user to download a new client or an update.

The code I posted can be run as a stand-alone java app (just package it in a jar with the manifest indicating that class is the Main class), so it's portable to any system that runs Java. It's currently hard-coded to pull the jar for ApoShift4K down from the java4k website, just to prove that would work.

Funny, I wrote a code very similar, which can load a Java4k jar (in pack.gz format) locallyand run it.

the Stub method:

public boolean isActive() { return true; }is important, as some games wait for it to become true.

What are you using for handling gzipped jars? Could you post that code, or a suggested change? Or I could put this up on SourceForge or whatever, and you and whoever else could contribute directly.

Some technical points:

I'm not keen on screen-scraping, so if we go with a locally run app it might be worthwhile to think about what information should be shown in the listing and find a way to supply that in an easy to consume format.

Needs to handle gzipped jars. The URLClassloader I'm using just accepts urls, but I'm guessing Damocles loaded his jar through an unzipping input stream. As long as the final class is loaded with a new class loader, it should work fine. We can't use the default class loader or reuse a class loader, because games with the same class name would result in the first class with that name being loaded for all of them.

I don't think any of our applets use the other Stub methods besides isActive(), as those other methods mostly do things that are outside the Java4K rules (like load images from remote locations.) Can anyone think of a reason we would need to implement any of them?

What kind of UI should be provided for browsing the games? We could duplicate what's on Java4K.com, but that seems like a lot of work to me.

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