I am creating a series of web games for a web site and I decided I'd rather learn Java then Flash (for now anyway). My first attempt at writing anything (other than HelloWorld) is a break-out game (original, I know). It's not finished (mainly I'm just waiting on some artwork and some new level designs), but it's playable. I think it's turning out ok. What do you think?

I tried to play, but he told me i have to download the JRE1.4.1, which i have already, and a don't like to download tons of data i already have, because i'm with 56k.... Is this part of your code, or is it my probably wrong configuration ?

This is not in the code, I suppose, but the reaction of the runtime plugin used on the page (instead of an APPLET-tag).Something with your local JRE installation seems to be wrong.

Now, you can start digging into your registry starting with a search for CAFEEFAC-0014-0001-0000-ABCDEFFEDCBA under HKEY_CLASSES_ROOT\CLSID.Should be there. If found, check wether it points to an existing dll (npjpi141.dll) and so on and so on....

It was too fast, IMO, on my windows box.It doesn't run on my linux box even thought I have the 1.4.1_01 sun jdk installed. (Plugin problem)I'd like some vertical indicator about where the mouse is. When the mouse is moved outside the applet the paddle stops tracking the mouse. This is frustrating when I move the mouse a little to low and cannot get to the otherside of the screen in time.

Can you elaborate? It has frame-rate limiting in it, so it shouldn't run any faster on your system than on mine or anyone else's. If anything it might get a slower frame rate on a slow machine.

Or do you mean the balls start out too fast to be playable? (the balls will speed up over time as well).

Quote

I'd like some vertical indicator about where the mouse is. When the mouse is moved outside the applet the paddle stops tracking the mouse. This is frustrating when I move the mouse a little to low and cannot get to the otherside of the screen in time.

This is a problem with Java applets in general, as far as I can see. Once the mouse leaves the panel events are no longer sent to the applet.

I eliminated the mouse cursor because other testers found it annoying and it left "mouse droppings" on a couple of platforms with buggy mouse drivers.

So I'm thinking of using a "robot" to force the mouse's Y position to remain constant as long as the mouse is within the panel. This should help somewhat (if it works).

As for horizontal movement, I could also use the robot technique to move the mouse pointer back if it gets too close to the edges. The only time the mouse should then leave the panel is if you move it quickly and move it far.

I tried to play, but he told me i have to download the JRE1.4.1, which i have already, and a don't like to download tons of data i already have, because i'm with 56k.... Is this part of your code, or is it my probably wrong configuration ?

If anyone can help me,.... PLEASE ! mbw :-/

This is nothing to do with the applet itself, but it could be something in my plugin code in the HTML (I'm a complete Java newbie and copied the HTML plugin code from someone else's example).

Can you elaborate? It has frame-rate limiting in it, so it shouldn't run any faster on your system than on mine or anyone else's. If anything it might get a slower frame rate on a slow machine.

Or do you mean the balls start out too fast to be playable? (the balls will speed up over time as well).

It may have been the lack of visual indicator of the mouse Y position combined with my lack of corridination that I found the game play too fast, or maybe I'm slow. I initially thought you didn't have a FPS limiter.

Quote

This is a problem with Java applets in general, as far as I can see. Once the mouse leaves the panel events are no longer sent to the applet.[...snip...]So I'm thinking of using a "robot" to force the mouse's Y position to remain constant as long as the mouse is within the panel. This should help somewhat (if it works).

I don't know about the robot technique. My first thought was a tick mark that moved up/down one side following the position of the mouse.

How did you solve the collision detection (i mean how did you solve to find out from which side exactly the ball hits the brick ?)

Each ball has an X, Y, DX, and DY value (all floats). To move a ball I:

First add DX to X.

Check to see if the new X/old Y falls within a brick, which is as simple as dividing X by 32 (the width of the bricks) and Y by 16 (the height of the bricks) to get indexes into my 2D array of bricks.

If the brick at that location has any hits left, then there is a brick present, so I reverse the sign of DX and add it to X again immediately. Because I've only moved it horizontally at this point, I know it had to have hit the left or right side of a brick, and I can use the sign of DX to tell which side.

Then I do the same thing for Y and DY, which tells me if it hit anything from the top or bottom.

Knowing which side got hit is important in my game since bricks can have optional armour plating on one or more sides, which means you can only break them if you hit them from a particular side (should make for some interesting levels later on).

well that's not complete:At any givent moment, the ball is able to hit 3 bricks.1 to the left, 1 to top (if moving upwards), and one in the direct position moving in. The one in the diagonal position can be removed since this would imply that either the one to the left, or the at the top was hit before that brick. You would therefore need to check for more than 1 brick - and wait there's even more! ...

If the ball is moving faster than 2.0 px/frame then the ball can hit multiple bricks in one frame. In a corner case the ball could first hit a brick to the left (which causes x *= -1) and in the next px movement hit a brick above it.You would therefore potentially need to map the movement of the ball, especially if the ball can somehow move faster than brickheight/width + ball height/width. In which case the ball could move over a brick.

You are over-complicating things. This is just a breakout game, not a physics demo afterall :-) I dare say the collision works as well or better than any other breakout game I've tried lately (and I've tried dozens of them).

well that's not complete:At any givent moment, the ball is able to hit 3 bricks.

I was just playing the game again and thinking about what you wrote... how do you figure that the ball can ever be in a position to hit 3 bricks?

The ball is round, the "corner" between two diagonal bricks is square... a ball can only ever make contact with two bricks simultaneously, and my game deals with that just fine. It's not physically possible for the ball to hit the "corner" brick, and it's not possible (or shouldn't be) in my game either.

Perhaps I misunderstand what you are trying to say?

Quote

If the ball is moving faster than 2.0 px/frame then the ball can hit multiple bricks in one frame. In a corner case the ball could first hit a brick to the left (which causes x *= -1) and in the next px movement hit a brick above it.You would therefore potentially need to map the movement of the ball, especially if the ball can somehow move faster than brickheight/width + ball height/width. In which case the ball could move over a brick.

Yes, if the ball was moving more than 15 pixels at a time (which my game does not allow) it could skip over bricks, but other than that I don't think I follow you.

Just for kicks I made the ball move 12 pixels at a time and lowered the frame rate to twice a second. I couldn't see a single instance where the ball/brick collision did not work as one would expect. When I bumped it up to 20 pixels it occasionally skipped a brick and took out the one on the other side of it, but that's not really an issue since the game doesn't allow balls to travel that fast normally.

Fantastic game! Especially like the sound - fits perfectly with the graphics, if you know what I mean. The cartooney atmosphere with the zany concept and the old occasional bleep and woop. Excellent.

You might want to take a look at xboing (available under all UNIX-like OSs, not sure about Windows). They solved the vertical-mouse-position thing by turning the mouse cursor into a small black dot, one pixel in size. It didn't interfere with the game but still let people know where the mouse was.

Also, xboing has an excellent launching system - there is a semicircle above the bat when it's holding the ball with a pointer in it that moves back and forth. When you launch the ball it goes in the direction of the pointer - that bit of extra control is very handy.

I definitely agree with more control over the direction of the ball by hitting it differently with the bat too.

I was just playing the game again and thinking about what you wrote... how do you figure that the ball can ever be in a position to hit 3 bricks?

I said that the ball could theoretically move such that it hits 3 bricks, when dx, dy have been added to x, y. However since the movement would collide with the bricks to either side BEFORE hitting the diagonal brick this case will never occur. As said this is just theretically - not something to ever account for - just food for the mind

I said that the ball could theoretically move such that it hits 3 bricks, when dx, dy have been added to x, y.

Ah, sorry, misunderstood you.

In my code I move the X first, check for a collision, then move the Y and check for a coliision again. I *think* this eliminates the problem you describe (ie: it can't skip over a brick by going over a corner of it). As long as the ball can never move more than 16 pixels in X or Y then it should always collide properly with the bricks. I think.

For those who are still following this game, I've uploaded an update. Better splash screen, vertical mouse indicators on the left and right sides of the screen, less cheesy background image, slightly dfferent sprites for the powerups, a few bug fixes.

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