Next 4K contest should be Applet only?

[SimonH]

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

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.

[Morre]

How about an (optional?) 'play now' button for applets and a 'play in separate window' for webstart?

I agree. This would be a good setup.

[Markus_Persson]

Does using applets do that too now? I realised it that applets are now the second comming of god but more accessible too - awesome.

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.

Games published by our own members! Go get 'em!

[Markus_Persson]

2. The init method replaces the constructor method.

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.

[kevglass]

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.

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

[pjt33]

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!  )

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.

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.

There is an applet template somewhere on this board, because I borrowed from it.

[Paladin]

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.

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

[pjt33]

(my walls are pi unit high because I couldn't afford an extra double to store my desired height of 3!)

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.

[userek]

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

[trembovetski]

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.

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

Dmitri

Games published by our own members! Go get 'em!

[pjt33]

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

I'll bear that in mind next year. Thanks.

[Abuse]

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.

The only reason I voted against Applet-only is because of the design constraints it imposes upon the type of games you can make.
Looking back at past games, if fullscreen mode/DisplayMode switching or Robot manipulation were unavailable several excellent games would not have been possible.

However, you're argument regarding presentation of the competition as a whole is a convincing one.

So, just for the record -1 for "No!" and +1 for "Yes!"

[Ranger]

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.

Damn!  ...err, with Applets you don't need a setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE) call, or a main(String[] args) method! 

[Markus_Persson]

The only reason I voted against Applet-only is because of the design constraints it imposes upon the type of games you can make.
Looking back at past games, if fullscreen mode/DisplayMode switching or Robot manipulation were unavailable several excellent games would not have been possible.

Ah, yes. Fair enough. =)

I've changed my opinion to "let people do whatever they wish, but make it easy to host and play applets and webstartable apps directly from the competition site". Perhaps even with a "make applets the officially preferred method of deployment".

[Morre]

Yeah, this seems to be the best solution right now. But I do think it's important to keep the actual applet on a separate page (as in, after clicking a "Play!" link). If one doesn't do that, they might have an unfair advantage over webstarted games.

[pjt33]

Yeah, this seems to be the best solution right now. But I do think it's important to keep the actual applet on a separate page (as in, after clicking a "Play!" link). If one doesn't do that, they might have an unfair advantage over webstarted games.

I don't really understand this stuff about unfair advantages. Surely it's only relevant if the judging is based on number of people who played the game?

[irreversible_kev]

if fullscreen mode/DisplayMode switching or Robot manipulation were unavailable several excellent games would not have been possible.

I haven't checked, but fullscreen and Robot use can be done in Applets can't it? It just pops up a security dialog like WebStart would.

One restriction though, is that each Applet would really need to be of the same dimentions. I. E. 640x480 or something, so that they embed well in the site. This really isn't that much of an issue I would bet though - especially as most of the WebStarted 4k games I have played "break" when you resize the window.

[Markus_Persson]

Yeah, this seems to be the best solution right now. But I do think it's important to keep the actual applet on a separate page (as in, after clicking a "Play!" link). If one doesn't do that, they might have an unfair advantage over webstarted games.

See, I'd consider that a good incentive for people to use the preferred deployment method.

[DzzD]

http://www.java-gaming.org/topics/applet-vs-webstart-what-do-you-prefer-as-a-end-user/20044/view.html

you should read the foolowing with a background music with bass Applet ! , Applet !, Applet ! , Applet !, Applet ! , Applet !, Appppletttt!