Discuss the future of 4k contest

But I’m not telling to carry on with applets. I wrote just the opposite.

I do think applets are dead. I hear my girlfriend saying all the time when she tries to access her online banking “What ? another java update ? Screw it, I’m going to an ATM”

I even stopped updating java because it is so damn annoying. I can’t play my own 4k entries.

But I am willing to give the launcher a try. Like I said, I can’t see why should an exe, which in this case is generated by java code, should be more dangerous than any of the exe games I donwnload from tigsource.

They absolutely won’t be. The launcher is a great idea. The size of the launcher vs. the 4k of the games is a red herring - nobody cares about the size of the launcher (hello broadband), and the 4k aspect of it is to appeal to geeks as an arbitrary restriction. If one was concerned that the relative ratio of the size of launcher:game was a problem we’d be making 4k games in assembler instead. It misses the point.

That said, a security sandbox in the launcher is a nice touch. With the right security in place 4k games won’t need signing.

Cas :slight_smile:

Any extra component that does not come with an out of the box JRE breaks the spirit of the Java 4K Contest. I’m all for downloading a binary and running it locally, but it must be executable through some command-line option. If that is not possible with pack200, then I’d rather drop the pack200 compression than introduce some extra, special 4K lib that must be downloaded also. Such a “loader” would contain bootstrap code necessary to get the binary to run. That’s cheating.

At this point, the launcher is a self-contained jar. So a single file that you download, which on Windows systems will run automatically if you double-click it (assuming you have Java installed. ;)) On *nix I guess you need to still do “java -jar launcher.jar”, not sure about Macs. By keeping it pure Java it should work on all OSs that have full standard JVMs. (Probably not on Blackberry or Andriod systems, due to differences in the JVMs and libraries.)

Well, the launcher is more like infrastructure, it’s not part of the contest. It’s like a helper for the java4k.com website (which is PHP by the way), not a 4K entry. And it doesn’t supply any extra libraries or anything like that to the contest entries. Think of it like a custom web browser, that only points to the Java4K.com games. So you can turn off applets in your browsers, but if you want to browse and run the Java4K games, you still can.

The challenge is to code to an existing infrastructure. A loader really is pointless for the following reason: Anyone can prove that they wrote a 4K entry by generating a pack200 jar no bigger than 4096 bytes. Once that proof is submitted, you can run it directly from an uncompressed jar. No loader is needed to play the game.

If we move to a deployment model where the player launches the game from the command-line, then we probably have to drop pack200 unless someone discovers a way through existing options to get it to run.

Well, the problems loader solves are:

  • People disabling applets in browsers.
  • Unsigned applets not running in web browsers due to upcoming security updates.
  • A simple method of discovering and playing the games.

I’m not 100% clear on what you’re suggesting regarding compressed and uncompressed jars, and running from the command line. If you’re suggesting that people playing the games should download an uncompressed version of the jar and run it from the command line, I think you’ll find that is too cumbersome for most people.

I might be misinterpreting your post, in which case please clarify, but it seemed like you thought the launcher is a command line tool to run games individually, or some sort of wrapper around each game? It isn’t - instead, it’s a listing of all the games (pulled real-time from the java4k.com website), and selecting a game from the list pulls the jar (in uncompressed, Pack200, gz, or pack200+gz), and loads the game into the frame. I’m trying a few different UI styles, here’s what I was looking at Sunday night (I haven’t pulled the game icons yet, so I’ve set the JList to render the title and description.) Selecting a game loads it into the right side of the split pane.

http://s24.postimg.org/47x887ohh/4k_launcher.png

Another screenshot below, at another size, with a game running.

Also, it takes ages to load all the game screenshots into ImageIcon objects, even if I do them all in parallel. I’m thinking of just showing the title, putting the description in a tooltip, and showing a progress bar as the icons load (popping them up in the list as the Futures return.) Any other ideas for the icons?

http://s21.postimg.org/4vq1l163r/4k_launcher_02.png

Looks very nice!

I like the idea with the showing only the title and the decription in a tooltip.

My wish would be a sorting option (by year, by title and by author).

Launcher looks neat. I’d like to try it out.

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

A Service for the game-list informaion yould be great.
especially the information about the main class and target screen dimensions, as was defined in the applet definition:

definitely a great start :slight_smile:

Hmm… i wonder whether we would be allowed fullscreen entries again now that it is affectively a java application… It would make my entry much better (a hybrid RTS)

Perfect! This launcher will go a long way into making java4k more viable. I especially like the fact it can run pack200 games. The contest is saved. :slight_smile:

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:


	public static List<AppletConfig> getContestAppletConfigs(URL contestUrl) throws IOException {
		String regexGameUrl = "<tr>\\s*<td>\\s*<a\\s+href=\"(.*?gid=(\\d+))";
		String regexScreenshotUtl = "<img src=\"(.*?)\"";
		String regexGameTitle = "<td class=\"gametitle\"><a.*?>(.*?)</a>";
		String regexGameAuthor = "<td class=\"gameauthor\"><a.*?>(.*?)</a>";
		String regexGameDownloads = "<td class=\"gamedownloads\">(.*?)</td>";
		//String regexGameSubmitted = "<td class=\"gamedownloads\">(.*?)</td>";
		String regexGameDescription = "<td class=\"gamedescription\">(.*?)</td>";
		
		ArrayList<AppletConfig> applets = new ArrayList<>();
		
		String html = getHTML(contestUrl);
		
		if (html != null) {
			Matcher matcher = Pattern.compile(regexGameUrl + ".*?" + regexScreenshotUtl + ".*?" + regexGameTitle + ".*?" + regexGameAuthor + ".*?" + regexGameDownloads + ".*?" + regexGameDescription).matcher(html);
			while (matcher.find()) {
				AppletConfig config = new AppletConfig();
				config.setGameUrl(JAVA4K_URL + "/" + matcher.group(1));
				config.setJarPath(JAVA4K_URL + "/applet.php?gid=" + matcher.group(2));
				config.setScreenshotUrl(JAVA4K_URL + "/" + matcher.group(3));
				config.setName(matcher.group(4));
				config.setAuthor(matcher.group(5));
				config.setDownloads(Integer.parseInt(matcher.group(6)));
				config.setDescription(matcher.group(7));
				applets.add(config);
			}
		}
		
		return applets;
	}

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.

I started working on making it work with WebStart apps, so it can potentially be used to run all the previous entries as well as the new ones. I’m holding off new changes until you merge in.

Should we look into adding Mac compatibility to fix the issue it has with key release?

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 :frowning:
  • 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.

Again, thanks for any and all help.

I just downloaded your code, and I’m looking into pulling it into the PikaCode codebase now.

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.

As to the other questions:

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.

Yes, and the nice part is, yours works! Hopefully the code I pulled in for this can be easily swapped out with a feed reader if we get to that point.

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.

Here’s a screenshot from the current build:

Here’s my current list of to-dos:

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

Not bashing, maybe more design is on the agenda.

if design isnt on the agenda, at least do something minimalistic and not bulky looking. eg mame game select: http://cdn.toucharcade.com/wp-content/uploads/2013/01/IMG_0140-525x393.png

Looking great!

I wouldn’t worry about prettifying it until it’s functionally complete; you can waste loads of time dicking around with L&F.