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?
JavaNoob
PS: “programmer art” - you’ve been warned.
Love the sound FX, what a riot! I would like more control in the direction of the “ball” via the hit location on the “paddle” though. Nice and smooth and fun.
Very smooth, addictive.
It seems to happen that a games starts w/o a ball on the paddle?
I had to restart the applet in order to get a ball.
I like it, reached 9000 pts so far…
Ah, still works smoothly even if the machine is under heavy load. This IMHO is very important for this kind of casual games!
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 :-/
I got the same error. I got 1.41 and it wants me to get another one. nothx
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…
Maybe just try to re-install 1.4.1?
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.
Hmm, can you change the HTML to use an applet tag ?
It’s not 1 percent as complicated as manually update the registry, isn’t it ?
Just a suggestion…
mbw ;D
[quote]Love the sound FX, what a riot! I would like more control in the direction of the “ball” via the hit location on the “paddle” though. Nice and smooth and fun.
[/quote]
Thanks. I’ll modify the paddle/ball collision code a bit.
[quote]It seems to happen that a games starts w/o a ball on the paddle?
[/quote]
Yes, that’s a bug. It happens if you hit the mouse/keyboard too soon. If you wait until the title page appears (after the loading screen) it’s ok.
[quote]It was too fast, IMO, on my windows box.
[/quote]
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.
[/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.
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.
Any thoughts on whether this would work?
[quote]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 :-/
[/quote]
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).
There is an ordinary APPLET version here:
http://christian.net/games/jericho/Gamelet.htm
Try that one and see what happens…
I had the 1.4 issue with the first one, but the second works fine.
[quote]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]
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.
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.
[quote]I initially thought you didn’t have a FPS limiter.
[/quote]
I do, but I suppose it could be buggy. It seems to work fine for me on my two machines, but they are about equal and they both run Windows.
[quote]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.
[/quote]
The robot class doesn’t seem to work in applets anyway 
The tick mark idea might work, I’ll give that a shot. Thanks.
Yes !
The normal Applet-tag version works fine 
Nice game !!!
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 ?)
Excellent game. Top notch. I don’t have headphones for the sound, but sound is definitely key to any game.
-Chris
[quote]Yes !
The normal Applet-tag version works fine
Nice game !!!
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 ?)
[/quote]
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.
Hopes this makes sense without a drawing