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 do
chr(nr) = number of polygones … for each polygone do
chr(nr) = polygone palette-color reference
chr(nr) = number of points in the polygone so for each polygone-point do
chr(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 objects
chr(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.

updated link to java4k

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

Thanks for looking at it and commenting on the game!

  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!

Best regards from

Antialiasing is literally one line of code in your painting method, practically takes no space. iirc you have to set the rendering hints…

Nice puzzle game.

me, you should know that the rule has changed concerning the 800x600 limit.

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 :slight_smile:

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.
The link : http://www.java-gaming.org/topics/java4k-2013/27689/msg/258272/view.html#msg258272.

You should directly ask to appel if your 1024x768 screen size would be a problem for the java4k site.

Thanks all for commenting.

I have updated the game (and link at top of forum-post)

  • Scaled down to 450x400
  • Antialiassing (penalty: increased bytecode !!)
  • Added levels + implemented the optimization code for level-load
  • Added objects

Best regards from