I could provide for a JSON service to retrieve list of games and any information to make it easier to display and run games.

Thanks appel, that would help make it more robust. Right now I'm doing a simple regex parse of the HTML from the contest listing, but getting the values from a service or even an RSS feed would future-proof against changes to the HTML. Here's the method, you can see how it relies on the page structure and CSS classes, so any significant changes to those would break it:

That would definitely help, as right now I need to hit the game page to get the name of the Main class, the width and the height. It costs an extra few seconds, on top of pulling and loading the jar.

I'm having a few issues merging what I had already done with Groboclown's project, so it will be a bit until I can commit it there. For the time being, you're welcome to run a bleeding edge build from my dropbox. Once we get grobo's to the same point, I'll start committing a built jar to that project for anyone to download.

Grobo and Apo have both offered to help merge the work I've done with the project on pikacode; thank you to both of you. For now I've simply zipped the source from my old project and put it in my public dropbox. Grobo's got a lot of good security set up in his project that would be great to keep, as well as user-friendly error messages and things like that. I've spent some time this lunch-hour cleaning up some bugs in my old project before posting the zip, and as far as I've tested the code I've posted correctly plays all apps from last year's competition (uncompressed, pack200 and pack200+gzip.) I haven't pushed any further changes to the pikacode project since my changes are only partly complete, and also for some reasons listed below.

The problems I ran into when trying to put some of my work into what Groboclown has already done:

The use of launcher.dir in the policy file caused me some grief initially, and specifying the jar in the codebase means it can't be run directly from the Run menu in Eclipse (you have to build the jar first.) Maybe we can just grant the higher permissions to all code on the classpath instead?

I can't actually see the running applets when running the code I pulled from pikacode - I get messages stating the applet started fine, but nothing is visible. I've run in debug, and it looks like the applet is added, then pack and validate are called. I don't know what's going wrong, unless there's a missing call to setVisible somewhere?

My code takes 5 or 6 seconds to download and start a game, and I expect Grobo's does as well (similar loading strategy), so if we stick with this strategy then a progress bar or message should be added. An alternative is to pull all jars down right away on startup, but then we'd have to be careful of conflicts, e.g. two games with the same jar name. (I'm sure A.jar is probably quite popular!) Renaming the jars when downloading would probably solve that.

In my code I'm using the system property java.io.tmpdir for temp files, I recommend we do that instead of storing them anywhere else (such as the launcher's directory.) However when I changed the code in Grobo's PrivilegedActions.createTempJarFile(), the app gave me permission denied errors. No idea why

My code to get the list of games and the game details is quite a bit simpler than what's currently in the pikacode repository. Groboclown may have made changes in the meantime, but if not might I suggest plugging in my code or something that reads a feed (if appel can get one set up.) The code that's in the pikacode repository is certainly more robust than what I wrote, since it fully parses the HTML and then navigates the elements, so I understand if you decide to stick with it. It just seemed a lot harder to understand than what I did with a few regex (though that might be because I wrote it - easier for an author to understand his own code?)

It looks like Groboclown's code runs the applets in a separate thread. Is that necessary? Is it for some security concerns, or something else?

My code in Java4KLauncher.java includes event handlers to stop, start and unload the current applet on minimizing, restoring and closing the application. I didn't see anything similar in the pikacode, though I may have missed it (sorry if I did.) I see it now, it's in GamePanel.

Grobo and Apo have both offered to help merge the work I've done with the project on pikacode.

I finished my merge into PikaCode (https://pikacode.com/groboclown/java4k-launcher/), and added the capability to look at the different entries over the years. I included progress bars and separated out the work for downloads into more reasonable places. It still has a large amount of work to make it look pretty, and I know my use of SwingWorker can be better done, but the basics are there.

Somewhere along the line I introduced a bad bug where the loaded applets are returning "null" from a getGraphics() call. I'm assuming I'm just not parenting it correctly. This is part of the reason the applets weren't visible - they were crashing! UPDATE: I found the source of the issue and fixed it.

I'd like to see either caching of entries, or (possibly additionally) allowing for a zip download that includes all the previous entries to limit the amount of downloads we put on the java4k web site.

The use of launcher.dir in the policy file caused me some grief initially, and specifying the jar in the codebase means it can't be run directly from the Run menu in Eclipse (you have to build the jar first.) Maybe we can just grant the higher permissions to all code on the classpath instead?

There's some options we can do here, like have a debug property that, if set and the launcher.dir isn't set, then we just don't install a security manager.

It looks like Groboclown's code runs the applets in a separate thread. Is that necessary? Is it for some security concerns, or something else?

It's for security reasons, and being able to force a badly running applet to die. Applets are supposed to not be able to create new top-level thread groups, so that the running tool can just kill all the threads running in that thread group. It's also used for ensuring that the applet is running in the right security context. I also have all the thread stuff there so that we make sure that each of those different tasks runs under that thread group.

The rest of the details needs to be loaded from the Java4k page. Right now that's not happening.

There's some general Swing layout issues. The details view of the active game needs a lot of improvement. The layout is just not done right. I'm no Swing expert, and forms have always given me trouble. The default location for the splitters needs to be set to a reasonable value - right now, you need to manually adjust them at the start. It'd be nice to add in some pretty icons.

Conversion from the HTML non-ascii characters and the Java string isn't working right - you'll notice some of the names aren't showing up right.

Add support for WebStart. It's partly there, I just need to add code to parse the JNLP, and all the life cycle management code.

The pop-up dialogs for the progress bars and error messages are showing the "applet warning" note. That needs to be fixed somehow in the security policy file, but I'm not sure which property manages that.

There's a bunch of code cleanup that needs to happen. There's some places where it's pretty messy. In particular, the management of the applet classloader needs to be tighter so that it can be property garbage collected.

Somehow naively I thought by launcher people would mean a slick looking Steam-like launcher, of course with less functionality.But yeah using swing its gonna be hard making it look good.This looks like a program from 2001.

Somewhere along the line I introduced a bad bug where the loaded applets are returning "null" from a getGraphics() call. I'm assuming I'm just not parenting it correctly. This is part of the reason the applets weren't visible - they were crashing!

Applets which actually crash on that have bigger problems, because (in at least some point releases of JRE 6) applets might get null from getGraphics() due to a bug in the standard applet container's lifecycle.

I find the 4k contest is a lot akin to the the demoscene subculture. By us - for us kind of thing. Showing off what kind of neat tricks you can pull off with only 4k.

That's been my thoughts too. The java way of demo witchery. I once considered to join the 4k contest, but had to realize that it requires very specific skills and methods to produce such compact code which still does something sensible, and I don't have those - and I wasn't willing to sacrifice my coding habits just to squeeze some function into 4k bytecode.

So for me it already was a pretty closed contest for those who are like the old assembly wizards from the demo scene who made other people just "wow - I had no idea that this can even be done".

I find the 4k contest is a lot akin to the the demoscene subculture. By us - for us kind of thing. Showing off what kind of neat tricks you can pull off with only 4k.

That's been my thoughts too. The java way of demo witchery. I once considered to join the 4k contest, but had to realize that it requires very specific skills and methods to produce such compact code which still does something sensible, and I don't have those - and I wasn't willing to sacrifice my coding habits just to squeeze some function into 4k bytecode.

So for me it already was a pretty closed contest for those who are like the old assembly wizards from the demo scene who made other people just "wow - I had no idea that this can even be done".

This is what I thought the past few years and I never joined the competition because of that. But last year I tried, and with the toolset you can use (obfuscator, proguard, shrinker) you don't need to ruin your code to fit everything. My games even had 3 or 4 classes, not just 1 like people normally do. It is perfectly doable, just give it a try.

I once considered to join the 4k contest, but had to realize that it requires very specific skills and methods to produce such compact code which still does something sensible, and I don't have those - and I wasn't willing to sacrifice my coding habits just to squeeze some function into 4k bytecode.

So for me it already was a pretty closed contest for those who are like the old assembly wizards from the demo scene who made other people just "wow - I had no idea that this can even be done".

That issue gets raised a lot, but a while back Groboclown put together a good set of ANT scripts that you can use (quoted post below.) I don't know how much it has changed in the past two years, but when I used it it all I had to do was put in the paths to some tools I downloaded like proguard and kzip, and then I just used Eclipse to run the script. Doesn't get much easier than 1-click compression!

If you look at the source for many of the games on java4k.com, the fully commented well-laid out code is what was fed in to the ANT scripts, and they spit out an obfuscated, maximum compression 4k jar at the other end. My two games had a main game loop, but separate methods for drawing the splash screen, handling menu actions, drawing sprites, and loading and playing music. There's a bit of trade-off between OO design and minimized byte code, for example my use of a method to draw sprites instead of delegating that to a separate Sprite object that decides how to draw itself. Along with that decision, I used 2d int arrays to keep track of my sprites and their attributes, rather than introduce another object definition. But you can do things like define as many constants as you want (to avoid remembering the purpose of a magic number), since proguard will replace them with the values in your code.

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.

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