Discuss the future of 4k contest

Contests
#81

I googled around to see what other people are doing. The zebra folks do a free and a paid version of their product, with only the paid for version having proper traceable code signing.

In the end they went for providing a root certificate that users could download and install to allow the use of a self-signed applet. Since it is now possible to state that the applet must run in the sandbox with the latest version of java, it would be possible to specify that entrants must include that in their contest entry, which would reduce the risk of rogue code, as sandbox escape exploit code would need to be included. (This would also help with the previously mentioned reputation issue)

There’s quite a long thread here: http://code.google.com/p/jzebra/issues/detail?id=155

#82

Hm you must be joking if you think anyone sane is going to install a root cert.

Cas :slight_smile:

#83

You are trusting the author of the software whether the certificate is traceable or not. The only difference is that the author is verified. If we made a root cert for java4k, but did not distribute the signing key, but instead wrote an upload script that signed the code and included ‘Permissions: sandbox’ in the manifest, then used the java version parameter to ensure that users with older java installations didn’t inadvertently run code that wasn’t limited to the sandbox, then we would have a reasonable level of security. It would be possible for someone to write malware, but unless it escaped the sandbox via a bug (which is a problem already), java4k would be safe. If someone wrote malware, then uploaded it to java4k, then grabbed the jar and hosted it elsewhere, it would only pose a risk if they also tricked users running old versions of java into installing the java4k root certificate. If they were going to do that, they could make their own root cert just as easily and trick folks into installing that (with the advantage that they would not have rely on users running old java versions). Overall the size of the attack surface is quite small.

The only difficulty I see is providing an easy way to install the root cert. If we limited browsers to IE and Mozilla, it would be easy. Just click on the .cer and install it in the browser keystone, which I believe is checked for applets and webstart. However I don’t think this works for all browsers, so I suggest providing an executeable jar that installs the certificate. If we were really clever, the executable jar would check the java version and refuse to install it on old versions of java that don’t support the permissions manifest entry. That reduces the attack vector surface to miniscule levels. To mount an attack would now require finding an exploit to escape the sandbox on the latest java and remain within the 4k limit, which is harder than just finding an exploit and hosting an unsigned applet (which will still run at present).

#84

Why dont you have a set time for making the games, and then you export it with the JVM so that the casual user doesnt get the security warnings and they dont have to install a jre?

#85

Installing a root certificate is just another huge barrier in the way of anyone caring about Java4K.

And relatedly, a root certificate is a serious thing. If they’re not kept in exquisitely safe places, then if it got lifted you’d then have a neat little back door on to a bunch of people’s computers. Additionally a root certificate usually comes with some sort of guarantee from the owners that they will actually verify the identity of subcertificates that they sign with it - that is, they provide a chain of accountability and trust. If you’re just going to allow any old Tom, Dick or Harry to sign code with the root cert without verifying who they are then it’s a pretty small matter for me to make a Java4K entry anonymously which contains a remarkably small number of bytes - just enough to open an AWT window with “HAHA! L4m3r! Pwned!” in it as it goes about deleting everything it can from your C:\ drive by writing zeroes over it. And you’d never find out who did it.

I could go on.

Cas :slight_smile:

#86

Just looking over this I think my faviroute idea is using the internet only as a download host for the loader and also for storing the projects.
Using the launcher to view,download and upload the contest entrys would neaten everything up and would be a lot smooth but also a lot more manageable for the organisers as they could directly control traffic.

#87

I feel like all this talk of signing, certificates and launchers makes things a whole lot messier, and uninteresting. We’re forced to focus our efforts on deployment rather than making great small games. My brain hurts.

Signing applets won’t get people to run them. It’s not a guarantee of “there be no malware here” anyway.

Creating a non-solution is not a solution, only a waste of time, or as some geeks call it: “fun”. :slight_smile:

Not so long until December 1st… I’m gonna come up with some ideas :slight_smile:

#88

Java4K is a fun coding exercise which… most of the time, produces a game. It is probably the biggest repository for Java games and java related projects we have currently… (or in our case, ever) other than this site. Programmers exercise or not, it is a pretty fair contest and one that improves each year. As far as I know, I think the contest is fine as is.

It isn’t Java4K that is causing the problem, it is Oracle and its disregard for the safety of Applets. The only plan that I agree with is possibly having a separate launcher (.jar) for the Java4K games. The limitations would still be the same, but it’ll give the users a more secure? way of accessing the Java4K content if they don’t trust Applets. For all those that still don’t mind, then the regular Applet version is still hosted on the site.

#89

Oracle don’t have any disregard for the safety of applets - they’re patching them like crazy. The problem is that major holes still keep turning up and the very idea of having this thin membrane of security between your computer and the entire internet is of dubious wisdom. I’ve turned applets off - permanently.

Cas :slight_smile:

#90

I am told the same by anyone to whom I send the java4k.com link. Maybe I should spend the time learning about HTML 5 games.

#91

I don’t know about that argument. If I were to put money on this, I’d say that Oracle expects JavaFX to completely take over where the Java Applets left off. The reason they are pushing patch after patch is just to hold a small fragment of “backwards-compatibility”.

Maybe Oracle should just say the truth and make a whole new version of Java called Java: Future-sight. Leave the old Java as legacy software, and move ahead making the lambdas, improving on JavaFX, and overall making Java more competitive for the mobile market. Reading on what Java 8 has done, it is obvious that Java 7 and previous is just dead weight holding Java back.

In other words, they could have completely avoided this mess. They easily could have expanded JavaFX and made that version stronger and a better alternative than Java. It just makes complete sense to me… look at the benefits.

  • Doesn’t break the legacy code alleviating the need for patches.
  • Leaving the Java code as legacy code would keep the old Java community happy.
  • Can expand on JavaFX and make it with the tools necessary to be competitive without backlash.

The way it is now, Java has been set backwards about 8 years. (Which in Computer Science means, we are pretty much out of the race.) We are losing trust in the communities that used to support us, we are failing to gain ground by existing on the new emerging technologies, and worst of all, we have major security holes that is making sure we can’t recover.

Oracle needs to act fast and just jettison Java 7. In order for Java to remain competitive, they have to let go of Java and the legacy and work on making it competitive now. We’ve lost soo much ground already, and we were the ones with the head start. (It is like watching SEGA and its failure all over again…) [/thread hi-jacking]

#92

Is there a way to turn this into an android game contest?

Just throwing it out there ;D

#93

I don’t have an android! :-
I still favour Javascript. It runs on android, windows and osx, has no scary security issues and there’s plenty of tools & libraries out there.
What’s not to like?

#94

I think HTML5 might be an interesting change, although browser support is a bit patchy. I’m not sure what performance to expect at the moment, although there have been some interesting demos. Not really relevant to a java gaming site though.

An android competition might be interesting and much more ‘now’ than applets. I have a tablet which I could use. There’s a big range of android versions, screen sizes and processor performance, which might prove awkward when judging. Specifying that it must run on (say) a Samsung Galaxy S4 (or whatever) would help, but would require outlay. I could do with replacing my phone though, so would consider it. I haven’t looked at distribution, would we need to put entries into the android market? Overall I think this holds the most promise for a lasting and relevant solution.

Since we don’t seem to be heading towards a common agreement, perhaps it would be best to hold java4k as normal this year and accept that the games will be obsolete whenever oracle removes support for unsigned applets. The risk is that the update that removes the functionality could come within the timeframe of the competition, which would be awkward.

#95

There’s so much setup bloat with Android apps, could you even do a hello world app in 4KB?

#96

I love the android idea but it would be a complete other contest.

At the moment I port my 4k games to simple javascript. Now the user can choose whether he will use the java applet or the javascript version.

When we will start this year on the 1 december, I think the contest should be a normal java 4kb contest with (like ctomni231 said) an alternative launcer for the games.

Next year I think a Javascript or HTML5-contest would be great.

#97

I think HTML5 is too unrelated to JGO. An android contest might prove much more interesting, but as a separate contest, and we could discuss that in another thread.

I’d happily continue with the java4k contest.

But let’s have a little reality check. Reality is that applets/webstarts have fallen heavily out of fashion. There have been 10 contests, and in these 10 years Java has gone from being widespread and available on almost any desktop PC to being nearly extinct.

So the question I keep asking myself, is it time to end the java4k contest? Would another year be like a “walking dead” zombie, dead but somehow walking?

The 4k contest has been the most fun thing here on JGO, but maybe we need to switch things up as well just to keep things interesting and not stale.

An android contest might be very interesting and relevant. It’s also easier to manage, because all you really need is to have links to the apps in the play store. But it won’t be “4k”, you can’t make an android game in 4kb. So there would need to be different restrictions to make it fun.

So in my mind there are two choices:

  1. Continue with the 4k contest as is.
  2. Put the 4k contest to a rest, switch over to an android JGO mini game contest.

I don’t know a whole lot about android game making, so I’ll leave that up to you guys, to come up with an idea how this contest could be tailored to the JGO community in the same spirit as 4k, small games, restrictions to set a ceiling on how much effort you need to put into making a game, and all that.

#98

If some one wants to create an java applet (including a limited set of swing, awt classes) to html5 converter I think that would be be best of both worlds.

It would:
-keep the competition spirit, rules and technology the same.
-allow users simple means to play the games. No need for java to be installed.

How it might be achieved:
-Create new classes to simulate the behaviour of Applet / JApplet.
-Create new classes to simulate a subset of AWT/SWING classes. e.g. Graphics2D, Shape, etc
-Use GWT to generate the java script
-Perhaps use an existing GWT extension for the heavy lifting for Grahpics2D

Rule changes that would be necessary:
-Need to upload source code as well as jar. To allow GWT to convert.
I doubt the decompilers will produce code that would be able to understood by GWT

#99

Slightly off the main thrust of this thread, but worth a quick mention as we’re close to the start date. The KeyRelease events on OSX java are broken (and have been for the last two releases), which breaks most real-time java games on the Mac. Mouse events are still fine, as is keyboard stuff that doesn’t rely on monitoring how long keys are held down. Is multi-platform still a ‘key’ consideration? This might be a major influence in my game design this year.
Edit: Applet only problem; not applicable to applications.

#100

Even if people don’t have an android device, you can still use the emulator (though last time I checked, it was pretty bad) but considering its for a 4k like game. Maybe it won’t matter.

I think the android thing would be great. It probably would need to be changed from the 4k.

I personally think having a very basic setup for Android as a ‘base’ template would be ideal, and have it call a specific .java file for your main thing, and its that single file would be the restricted element. Ignoring the ‘basic stuff’ that every android has to have.

Maybe we can have the compiled .class of a java file still be the limitation, 4k, 8k, 16k but have it be based for an android directly instead