Personally I wonder why we didn't do this before. Some things we need to iron out, but overall a big success.

I never got my game up (again) but that was actually because I was having trouble making the JAR work right with compression and so gave up relatively quickly. Being a judge gives much less incentive to finish, after all. Having an applet seemed to work just fine, and it's very easy to throw in a main method for testing, then remove it for distribution.

My one issue is that sometimes applets leave sound playing after being closed. My game actually is one of them, and there was only 1 this that did so. I find this really problematic and we might want to add in some kind of standard deduction if this happens.

Much better than webstart!I did pick up on some players not being able to play pack files though. It'd be a good idea to deploy the jar file alongside the pack file for maximum accessibility. Could this be done with automated pack decompression in the submission system?

Much better than webstart!I did pick up on some players not being able to play pack files though. It'd be a good idea to deploy the jar file alongside the pack file for maximum accessibility. Could this be done with automated pack decompression in the submission system?

I didn't like that opening a game's page automatically loads the applet. You can't read the description, instructions, or comments without the game starting. Since most of the games (mine included) immediately jump up to 100% CPU usage, this is painful. This could be fixed if the applet was initially hidden, so you needed to click to show it - some video websites do this with their embedded player, where there's an image until you click, then the flash is inserted.

It would also help if the initial template didn't have the CPU use problem, which can be fixed by starting with the one I posted. But I'd still like to see the applets initially hidden.

I didn't like that opening a game's page automatically loads the applet. You can't read the description, instructions, or comments without the game starting. Since most of the games (mine included) immediately jump up to 100% CPU usage, this is painful. This could be fixed if the applet was initially hidden, so you needed to click to show it - some video websites do this with their embedded player, where there's an image until you click, then the flash is inserted.

It would also help if the initial template didn't have the CPU use problem, which can be fixed by starting with the one I posted. But I'd still like to see the applets initially hidden.

Yes, good suggestion. Will try to add something like a "Play now" or "Start game" button over where the applet is.

Didn't work at all at work - Class not found exceptions loading F.class or somesuch. This sort of thing never seems to happen with Flash... even behind the irritating work proxy/firewall.

Cas

I asked a non-programmer co-worker of mine what he thought of applets being used this time, as he is familiar with playing 4k games using webstart. He said it was "fantastic, great improvement. Those webstart dialogs were daunting!". From the user side it really is a great improvement.

It's not really a big problem deploying an applet, it's just that pack200 and deploying on an alien server that is the problem for most.

agree 200% it was really nice and pleasant to test/play 4k games this years : inded for their quality but also because they was applets , I think (not sure) that's the first year I ve tested all 4k entries ( twice ! ) (I remember getting bored of webstart after trying a cupple of games other years, and always thought when launching a game that I will have to remove/unisntall it later)

very very nice !

also I was wondering if you grabbed/know some stats on successful launchs/fail ?

Didn't work at all at work - Class not found exceptions loading F.class or somesuch. This sort of thing never seems to happen with Flash... even behind the irritating work proxy/firewall.

At least it tells you there's a problem. I've had a problem with at least one Flash game which played through the intro sequence and then didn't seem to respond to button clicks on the menu. Turned out that it needed version 10 to get any further and I only had version 9, but the plugin didn't take care of telling me that.

I'd go a step further, and request a JAR for all current entries. There are so many people unable to launch the applets, that it might hurt Java's reputation even more, or well, let's just try to make sure many more people can play it. It's little work for the devs, so send that bulkmail and get eternal fame and stuff.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

...and always thought when launching a game that I will have to remove/unisntall it later)

This IMO is webstart's biggest (read massive!) flaw; it's a feature that should have never been there in the first place, and the lack of an 'opt out' (or more ideally an 'opt in') for applications that do not wish to pollute the 'installed applications' list is even more irritating.

I can concede to webstart being a little problematic... however i do not like the fact that I can no longer have a native full screen game (applet limitation)

I do not agree with pack200 being a problem in its self... I think the problem is in the delivery from java4k.com I suggested that the author submits a pack200 version to meet the 4k limit and then the server should always return a normal JAR no matter what the client asks. In this way there is no issue on the client side. This was not taken up however

however i do not like the fact that I can no longer have a native full screen game (applet limitation)

you cannot get exclusive fullscreen without signing your applet (but you can if you sign it, this is a normal browser security), also you can get "full desktop/screen" size like this Applet without signing, wich could be already "hurting" for some web visitors if you put it fullscreen without prompting the visitor.

Quote

I do not agree with pack200 being a problem in its self... I think the problem is in the delivery from java4k.com I suggested that the author submits a pack200 version to meet the 4k limit and then the server should always return a normal JAR no matter what the client asks. In this way there is no issue on the client side. This was not taken up however

IMHO, until there will be 100% success with pack200, this is a nice idea...

you cannot get exclusive fullscreen without signing your applet (but you can if you sign it, this is a normal browser security), also you can get "full desktop/screen" size like this Applet without signing, wich could be already "hurting" for some web visitors if you put it fullscreen without prompting the visitor. IMHO, until there will be 100% success with pack200, this is a nice idea...

I played around with going fullscreen myself, but had to create another window, make it undecorated and then add my game class to it as a KeyListener. Took a fair number of bytes and probably would be disallowed anyway.

Another idea I didn't use is to write several game entries that work in the same game world as a LAN game. Each game has a different character with different attributes. I got as far as making a multiplayer LAN version of Assassins4k which was only slightly larger than 4k. Ideally each game generates it's own graphics model data it's own player character and transmits it to the other games. Thus each game can display all the other games characters, but doesn't need to have the code to generate them. But again, this probably breaks the rules about data injection from outside the game. Maybe I could get a special dispensation for this though, as it looks kinda fun.

I absolutely don't want fullscreen applets. The reason I like applets is that they run in the nice safe visual confines of my browser and they're easily hideable from the boss. Flash gets away with it by completely managing the fullscreen experience; that is, Esc always quits to windowed mode, and no Flash programmer can get around that. While we're at it I absolutely don't want signed 4k games either.

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