2 replies to this topic

[TheNut]

Nicely done. For other Java game developer enthusiasts (which are quite far and few), perhaps you can write a postmortem describing your experiences with Java and any helpful insight others may benefit from. The editor is pretty intuitive to use too. I have my suggestions outlined below.

1) The paddle should influence the direction and speed of the ball. At least that's how it was done in Arkanoid.

2) The game uses full CPU resources. I know Java isn't that bad, so I'll ask if you have an efficient renderer? Do you sleep between drawing to limit the frames per second and take a load off the CPU?

I'm curious as to how you will handle the widescreen format (I've often gave this thought, but never committed). Professional GUI systems I've used in the past offer automatic scaling and adjustment by use of percentages and stacking panels. Not easy to implement, but very intuitive to use. Some games where I looked into their SDK use floating point numbers between 0.0 and 1.0 to denote the location on the screen with automatic scaling to compensate for larger or smaller screen resolutions. This is easy to implement yet not as intuitive to use and requires mouse coordinate conversion. Just a thought I brought up and wouldn't mind hearing your side of it.

[mrgibson]

About post-mortem, I think I can say the hardest part is to make everything run synchronized in only one thread. In the game itself I am using jBox2D (physics engine) to handle balls movement and brick collision. This engine does not handle variable time steps, you have to guarantee the same amount per second. All the other stuff is easy in comparison I actually ported my engine from C++ to JAVA in 2 weeks.

BTW: I plan to release the source code for both the game and the engine behind it very soon. (With a good javadoc)

The paddle actually influence the direction and speed of the ball but I think its not perfect, from borders to center the angle modification is from 0 to 30 DEG. If you have a ball going down at 270 DEG and you hit it with a pad border, the bouncing angle will not be that much changed.

About CPU resources, this is true, you can fix this by using Crazynoid_custom executable and enable VSYNC or check CPU-FRIENDLY option. CPU-FRIENDLY option reduce the CPU usage alot but accelerate the gameplay, I am currently working on a better solution.

My game engine handle multiple resolutions based on one resolution, when you start your game project you specify a resolution you will use, for Crazynoid it was 1024x768. Since all coordinates are stored as float, resizing will not break the overall design. The default behavior is to rescale the position and the size of a graphic element but I can also only rescale the position and let the size unchanged. Calculating widescreen aspect ratio is just a question of multiplying a additional value to horizontal coordinate and size. I saw about 0..1 approach from other engines and like you I dont like to have convert mouse coordinates, in my engine this part is handled automatically

Yanick Bourbeau