Last year I wanted to make this game using polygones. In the end I made a matching game using the technique I wanted to use.

This year the sprites and level design are using different decoding mechanisms.

At the moment it isn't extremely optimized so I think I can add some more levels to the game.

The game is inspired on the Professor Fizzwizzle games.

Click on image to start

Navigate with Arrow Keys and N key for next level if you want to skip one. (P = previous)ESCape restarts the level.

Basically the sprite decode is like:

chr(nr) = number of sprites .. so for each sprite dochr(nr) = number of polygones .. for each polygone dochr(nr) = polygone palette-color referencechr(nr) = number of points in the polygone so for each polygone-point dochr(nr) = modulus of coordinate = polygone-x or polygone-y (sprite width/height determines number of chr)

The level decode is something like this:

chr(nr) = repeat number of objectschr(nr) = objectnr

The level is still in a multi-dimensional array and I know this can be optimized further using one String technique like the sprites.So that will be my next task for optimization.

Looking good... don't quite understand what the rules for object movement are but got the general gist of the game.

Two thoughts:

1. Could you turn on antialiasing to make the look less jagged? (altho maybe you want something deliberately retro)

2. The player animation is well, jumpy I was thinking it's even possible you could get animation for cheap by blending between polygon vertex positions. Assuming the player graphic is made of n polygons and the polygons preserve their identity and approximate relationship (e.g. 1 for face, 1 for body, 1 for arm, etc.), then you could create a smooth animation quite straightforwardly.

1. Originally the game was designed for 1024x768 but then noticed the 800x600 is maximum on the java4k.com site.I should redesign the drawing mechanism, or see if the limitation on java4k.com isn't that strict (anymore)2. I was thinking of a smoother animation but I'm not sure if I can pull it off without losing the number of levels. Will look into it again when things get better optimized!

I decided to modify one rule: (not popular after contest starts, I know)

Quote

The Applet window size may not exceed 800 pixels horizontally or 600 pixels vertically. This is a guideline however, games can exceed this limit if it's deemed acceptable by java4k.com, although exceeding this is at your own risk. Some games do require more horizontal or vertical space, and it is allowed to exceed it a tiny bit. But be careful of exceeding the vertical limit, as vertical space is more limited on computer screens.

Green is the new text.

The reason for this is... well, some games actually slipped in that are slightly larger than 800x600, and I don't see any reason to reject the submissions. 800x600 is an arbitrary limit just to set some limit, going slightly larger is fine, but going somewhat larger may not be.

I guess someone is going to say "I spent a lot of time making my game to fit inside 800x600, and are you telling me now that I could have done it in 840x610??? THAT CHANGES EVERYTHING!!". Well, sorry... drama queen

I think it's better and less hassle just to modify the rule (takes me 30 seconds) rather than tell those forgetful poor souls they need to spend hours in an attempt to squeeze their game into that frame.

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