Next 4K contest should be Applet only?

As someone stated, I think some people feel more comfortable launching an applet in their browser rather than actually downloading something then uninstalling it.

Personally, I prefer applets.

Actually after 6u10 I have to manually disable the next generation plugin in the java control panel to see applets at all…

Don’t forget to file that bug report :-X

Posting this here too:

Whilst I think that there’s some drawbacks to JNLP as others have mentioned, adding the requirement to be applet does seem to increase the size of the application for no good reason.

Isn’t this competition about the games that can be written in 4k and not how we should show them to the user?

To make an application via JNLP, all you need to do is override the paint(), processKeyEvent() and call setVisible(true) in your application somewhere. Sure, you can override or call a lot more system functions, but for the most basic game this is all you need to do. (Ok, so you probably want to call getGraphics() and drawXXXX also)

I’ve never written a game as an applet, so please correct me if I’m wrong, but don’t you also need to:

  • override init()
  • use the interface java.lang.Runnable
  • override run()
  • call JApplet.enableEvents(AWTEvent.KEY_EVENT_MASK)

plus probably some other stuff that I’m not aware of, like cleaning up the applet?

These appear to be an unnecessary overhead on the game and for those of us who have fought tooth and nail to squeeze every byte into our 4k, may mean the difference between a good game and a great game.

And isn’t this competition all about making great games, like many of the entries are this year, in 4k, and not making good games as applets in 4k? :slight_smile:

I agree with your sentiment about too many unnecessary rules or restraints could make it less fun to develop.

It seems to be something like a 50/50 split between those who definitely want Applets, and those who still want to include Webstart. We definitely don’t want to alienate some portion of the developers, that will only do harm to us.

I suggest for next year:

  1. Webstart still allowed
  2. Applets encouraged (on forums, on java4k.com)
  3. Applets can be embedded on the game page and played directly
    3b. Webstarts can also be uploaded directly in the game submission page.

In fact no change, other than adding better capabilities to the Java4k site to handle, host and view games.

I was skeptical about applets at first (because of how poorly they worked a couple of versions ago), but I’ve changed my mind.

My experience is exactly the opposite of this. Every time I’ve converted a game from my 4k template (which is available in one of the threads, uses a JFrame, and gives a reasonably small size) to an applet, the program has gotten considerably smaller. Which means that I ended up converting most of my games to applets this year.

Also, somebody discussed caching problems with applets. While it is true that you can sort of avoid them with webstart versioning, this takes a bit of work. And if you don’t use the versioning, I believe webstart has equally bad caching problems. “Works on second try”, yay!

I am more or less in favour of making applets a requirement, mostly because of their accessibility (I know several people who haven’t been able to start my webstart links without guidance (“oh, you have to run it through javaws.exe in your java/bin folder”, but when presented with an applet they’ve had no problems running it). Also, it would be great if the games could be run inside the browser window on the Java4K site. With that said, I see no reason why the developers shouldn’t also be allowed to submit a JNLP link. It is even reasonable to make JNLP generation for every applet automatic.

I do not believe it’s a good idea to have applets hosted right by the game if the rules do not require an applet version. This could lead to an unfair amount of people trying only the more accessible applet games. I’m fine with the applets being hosted on the site, but they should each be on a separate page that you reach by clicking the game’s “Play now” link. If an applet version was required, on the other hand, the game could be on the very same page as the instructions and whatnot. :slight_smile:

If we’re requiring an applet version, perhaps it would be a good idea to provide a template or guide for minimal applets?

  1. You should still call enableEvents(AWTEvent.KEY_EVENT_MASK) when using a JFrame if you override the processKeyEvent() method. There is a bug/feature in the Sun JVM that calls it automatically, however, other JVMs probably won’t have the same bug/feature.
  2. The init method replaces the constructor method.
  3. You don’t need to call setVisible(true) when using an Applet. However, you do need a call to isActive() in your game loop.
  4. Yes, you do need the Runnable stuff, which is the main downside.

When I converted my game from a JFrame to an JApplet, it did grow in size, but it really wasn’t that much (I don’t remember the amount, maybe 10 bytes?).

[quote=“Morre,post:27,topic:33217”]
Very interesting to hear these sizing opinions from people who have actually used applets, and I will definitely revise my opinions in deference to their greater experience. I am curious why the size would drop though – did you ever have a look into this?

I must admit I thought there would be more of an overhead using applets than what both Morre and Ranger are saying. However, even a few bytes can make all the difference when it comes to the crunch! (I felt really bad about commenting out my “setResizable(false);” line in my application, but I couldn’t get the last few bytes I needed any other way! :o)

I agree. It would be great to see an applet template, preferably with some comments about why methods like isActive() need to be called and when.

I’m sorry, this is untrue.

Dmitri

It does make sense to allow applets, especially with 67 games! It’s a bit of a chore to webstart them all…
How about an (optional?) ‘play now’ button for applets and a ‘play in separate window’ for webstart?
I always do both versions for my games anyway, but in my exp applets are generally bigger. :-\

I agree. This would be a good setup.

[quote=“kevglass,post:14,topic:33217”]
Er, yes, absolutely. Applets definitely make games more accessible than webstart does, no question about it.

I don’t really understand why people are so much against making java4k applet only, as applet versions of my 4k games usually are significantly smaller, have fewer weird issues (like not having to worry about the location of the frame or the size of the frame decorations), and it would make for a really awesome looking compo site where hundreds(!) of games could be immediately played without installing anything on your machine.

[quote=“Ranger,post:28,topic:33217”]
Unfortunately, this isn’t true. The constructor is mandatory. If you don’t write one yourself, the compiler will add one for you. So putting code in the constructor is pretty much free.

It’s about choice. I for instance did all my games as Applets this year, why, because I hadn’t before. It gave me a chance to try something else. Adding rules that take options away from people when it’s not part of the challenge of the contest is just limiting developers experience.

If as Riven suggested the contest is now about making the best and most accessible collection of games to show off Java to the rest of the game development world - then I can understand why having a consistant deployment approach makes sense. And yes, the site would be very pretty. However, thats not what I thought the contest was for. I’m not interested in showing the rest of the world Java, I thought it was just for fun.

Kev

Learn Jasmin. I switched to disassembly of my class file and manual tweaks in Jasmin at the very end of development because I couldn’t get the last 5 bytes any other way, and ended up saving something like 60 bytes.

[quote]I agree. It would be great to see an applet template, preferably with some comments about why methods like isActive() need to be called and when.
[/quote]
There is an applet template somewhere on this board, because I borrowed from it.

I think I might. I was optimising my symbol table and code as much as I could by hand (my walls are pi unit high because I couldn’t afford an extra double to store my desired height of 3!) and I kept bumping up against the way the various optimisers would do things.

Plus, writing games in bytecode takes me back to the first games I ever wrote… 4C 00 03 6D 89 57… Those were the days… 8)

That’s precisely the example which got me about half of my savings: an iconst/bipush/sipush followed by i2d is much better than storing a double with integer value in the constant pool. Another useful one was situations where your constant pool contains methods A.foo(args) and B.foo(args) and B extends A. Call dispose() on a reference of type Graphics2D and on another reference of type Graphics and you end up with wasted space which Proguard doesn’t recover.

I think its a good idea in theory, but in practice we all know that applets sux and webstat is a failed attempt to replace them ;)(honelsty i haven’t seen any webstat on any website not related to java developent). I really can’t understand why is so difficult to improve loading experience and stop random browser crashes. That is the real issue, not the jre download size and sun doesn’t seem to understand it, but that is a bit off topic. I’m fine with the applets only contest, the games could be embeded in java4k.com site and thats a good idea (as long as they don’t crash the browser of course).

For reference, nothing bad will happen if you don’t call Graphics.dispose() - at least in the current implementations (that I know of).

Dmitri