The Rules

  1. The game must be 40x30 or 30x40 pixels in size or a nearest neighbour integer scaled up version.
  2. The game can only use a maximum of 16 colours for any single frame chosen from the 64 colours of the EGA palette.
  3. The game must be deployed as an applet.
  4. The game must run in the standard Java applet sandbox without triggering any security exceptions.
  5. Must be a playable game not just a demo/video.
  6. Target JRE is 1.5+

Not strictly required but in the interest of trying to get all the entries on a single screen it would be nice if:

  1. Display a title screen with click to begin followed by requestFocusInWindow().
  2. Be able to handle any applet container size with integer pixel scaling to fill the required space.
  3. Monitor focus and pause the game and any audio when focus is lost.
  4. Have all resources bundled into a single jar file.
  5. Instructions if needed should be provided in game.

Contest ends at midnight (GMT) 31 August 2010, no formal judging at this stage but we may have a forum poll or possibly get some judges before the end.

Anything I’ve left out?

Instructions (if needed) should be in-game.

Attached is a Photoshop Swatches file for the EGA palette; handy for those of us drawing any of our graphics. It’s an .ACO file in a .JAR archive due to the upload restrictions.

So a resizable applet is not required? In my game I’m thinking of using png-images, created in a painting program, so the sprites got a fixed size.

[quote]Instructions (if needed) should be in-game.
[/quote]
Good idea I’ll add that one.

[quote]So a resizable applet is not required? In my game I’m thinking of using png-images, created in a painting program, so the sprites got a fixed size.
[/quote]
You can assume the applet will be a fixed size and a multiple of 40x30 and you can use getWidth()/40 as your fixed pixel scaling. I will post an example Applet template this weekend, and I’m sure many other examples will also be posted. Given the progress some people are making already we will probably have a substantial resources/templates thread before long.

I hate to be the one that opens a potential can of worms, but what exactly does this mean? I assume you mean “no native libraries” (dll etc.) and not “no JRuby, Jython etc.”? Perhaps something along the lines of “Entries must consist solely of bytecode that runs on a 1.5+ JRE”? (although that may have other implications I’ve not yet figured out).

[quote]I hate to be the one that opens a potential can of worms, but what exactly does this mean? I assume you mean “no native libraries” (dll etc.) and not “no JRuby, Jython etc.”? Perhaps something along the lines of “Entries must consist solely of bytecode that runs on a 1.5+ JRE”? (although that may have other implications I’ve not yet figured out).
[/quote]
I did intend it to mean no native libraries, but it is really trumped by this requirement anyway:
5) The game must run in the standard Java applet sandbox without triggering any security exceptions.

I have removed the rule. Your free to use anything that works without security exceptions in the 1.5 JRE applet sandbox.

The rules are simply to clarify the theme limitations and provide the best play experience for users. If anything is not 100% clear then common sense and adhering to the spirit of the contest should point you to the right answer.

What about any in-game mouse cursor? Limiting the colors is easy, but what about the position when up-scaled?

You ask a good question, my gut feeling is that if you are going to use mouse input the OS cursor should be disabled (set blank) and you are responsible for drawing your own cursor on the 40x30 pixels available. Anyone got any other suggestions on the best way to handle this?

Oh. Software rendering! A novel idea…(I’m off to kick myself now).

Would sub-pixel mouse input be acceptable, or does that need to be on even pixels only?

My gut feeling would say the latter.

It’s hard to imagine a game where the mouse resolution being higher than the display resolution would make any difference, plus it would be very difficult to enforce. Perhaps I should add a rule that the game must be playable with no upscaling.

Something like miniature golf, pool, etc. Anything that the input depended on mouse motion and/or precise movement.

For what I’m think of doing, requiring it to be playable unscaled could be tricky. I’ll have some hit-boxes that are as small as single pixel.

Would JavaFX be allowed?

[quote]The game must be 40x30 or 30x40 pixels in size or a nearest neighbour integer scaled up version.
[/quote]
Could you clear this up. Am I allowed to have a larger applet size but still have the game 40x30 pixels? E.g have the applet window of size 800x600 but have the game centred in the middle of 40x30 (then I could have a scale option in game).

Bump.
I wouldn’t mind trying making one in JavaFX so I would like to know if this is allowed.

Sorry, have been offline for the last few days.

JavaFX would be ok, as long as it doesn’t trigger any popup dialogs. You can do any integer scaling nearest neighbour up-scaling in the applet container provided, so you could do a black-bordered 40x30 in a 800x600 container if you like. I’m not going to be super strict on the rules as long as you stick to the intent of the contest.

The end result we want to head for is a single page with all the entries that should just work for the vast majority of internet users without any popups or exceptions assuming they have the Java plugin installed. I think we will also use a bit of Javascript to display some text instructions for the currently selected game and users should be able to switch back and forth between any of the games without any adverse effects. It may require several iterations to get it right but I think it will be super cool if we get it done.