• 0

[JAVA]Problem with game(simple block breaker game)


Question

Hey. I have a problem with my simple java game. It's a block breaking game and it's almost done. The last thing to do is make some of the detection methods perfect. The methods should detect if the ball hits one of the blocks in the air. My current code does it well if the ball hits one of the longer sides of the blocks(north and south), but if the ball hits the west or east side of the block, it starts bugging. The ball will move into the block, until one of the current if-tests detects it, and reacts by changing the y-axis direction. When it first reacts like this it may also bring some other blocks with it. This will all be fixed if I can get some rules/if-tests to detect when the ball hits the shorter sides of the block and then changes the x-axis direction. Could anyone help me, please? :)

The block to test is called b, and has the getX/Y/Width/Height methods to call. The ball has the ints ballX, ballY and ballSize. dy and dx are the directions the ball moves. So changing the direction on x-axis is of course dx = -dx;

Picture of the situations I need code to detect

Detection code

I really hope some of you guys could help me fix this. Been struggeling all day to get it right. The y-axis test might also need to be fixed for this to work, I actually don't know anymore :s Thanks

9 answers to this question

Recommended Posts

  • 0

I always cringe at this sort of style:

boolean predicate() {
    if (condition) {
         return true;
    }
    else {
         return false;
    }
}

Could be written in one line and much more legibly:

boolean predicate() {
    return (condition);
}

Also your:

if(checkHitY(b)) {
    if(checkHitX(b)) {
        addToScore(b.getValue());
        model.hitBlock(i);
        dy = -dy;
        i = model.getSize() - 1;
    }
}

Could be rewritten, more logically, as

if(checkHitY(b) && checkHitX(b)) {
    addToScore(b.getValue());
    model.hitBlock(i);
    dy = -dy;
    i = model.getSize() - 1;
}

Stylistic issues aside, I see a dy = -dy, but not a dx = -dx in your code. No wonder then, that side collisions are not handled correctly. You need not only to determine if the ball hits, but whether it's a side (dx = -dx) or frontal (dy = -dy) collision, before applying the right velocity adjustement.

  • 0

Dr_Asik:

Stylistic issues aside, I see a dy = -dy, but not a dx = -dx in your code. No wonder then, that side collisions are not handled correctly. You need not only to determine if the ball hits, but whether it's a side (dx = -dx) or frontal (dy = -dy) collision, before applying the right velocity adjustement.

Thank you for your answer, thought it didn't help. I'm aware of the kinda messy if-test structure at the moment, but they won't be like that. I change specifically to this style to try out new methods of detection. Siince I might need a seperate checkHitXdx() method to detect the sides, I found it would be better to seperate the if-test for checkHitY() and checkHitX() while testing.

When it comes to the dx = -dx; it's not written there because that's what I need help with. I need help finding a similar method as checkHitX and checkHitY that detects the side, because I'm struggelin to make the formulas/if-tests myself. So there's not dx = -dx; at the moment, since hitting the sides is atm not beeing looked for by the methods. I've tried multiple methods to detect just the sides, but the game just got lots of bugs when trying them out. The ball would hit the corner of a block, and always change direction in x-axis, even though it hit on the left end of the south wall, which should make it just change the y-axis direction.

  • 0

You could simply test for the ball being below or above a block. If yes, reflect on y, if no, reflect on x. This will break if the ball speed is too high, but that's a problem with all simplistic collision schemes. If you want perfect collision you need to take into account before and after points, trace a vector and find the intersections with the segments defining the blocks, so there's some linear algebra involved.

  • 0
  On 06/04/2011 at 18:46, Dr_Asik said:

You could simply test for the ball being below or above a block. If yes, reflect on y, if no, reflect on x. This will break if the ball speed is too high, but that's a problem with all simplistic collision schemes. If you want perfect collision you need to take into account before and after points, trace a vector and find the intersections with the segments defining the blocks, so there's some linear algebra involved.

Yeah, but then I'd be checking the y-axis for hit 5 times(the dy value) for each block on each frameupdate, which would be lots of work for this. I tried to fix this by adding a area it could hit on both sides. Checking if it hit on the border, or at least before (border +/- dy pixels). The problem with this is as since I'm not detecting the sides now, it may slide into the middle of a block, and both upper test(with +/-dy) and lower test would be true and the ball starts bouncing up and down inside :p

To check the movement pixel for pixel for each frameupdate, would you simply check every object dy times, with lastX + (dx/dy) and lastY + (dy/dy) to check for hit? Is that a better solution then the "overflow" tactic (or whatever you could call my current method), or would that be too heavy on resources, with lets say 5 tests just for the y-test, for 100blocks on every frameupdate ?

  • 0
  On 06/04/2011 at 19:45, Graimer said:
Yeah, but then I'd be checking the y-axis for hit 5 times(the dy value) for each block on each frameupdate, which would be lots of work for this.
No, you start by detecting if there is a collision, and only if there is a collision you check on which side it is. So this usually adds 0 test per update, and at most 2 (when there is a collision). Unless you're running a 386 this should not present any performance problems.
  • 0
  On 06/04/2011 at 21:43, Dr_Asik said:

No, you start by detecting if there is a collision, and only if there is a collision you check on which side it is. So this usually adds 0 test per update, and at most 2 (when there is a collision). Unless you're running a 386 this should not present any performance problems.

Okey, I understand how you think. But would you mind actually making the tests for me, if it isn't too much to ask for? I've tried so many methods the last days I'm actually getting dizzy :p

I know it's asking a lot, but it seems like you got both the experience and a clear vision of how to solve this puzzle :)

  • 0
  On 06/04/2011 at 23:18, Dr_Asik said:

I'm sorry but I don't have time for this atm.

Well anyways, thank you very much =) Now I'll just need to get my sketchboard and start drawing/making test-conditions.

  • 0
  On 07/04/2011 at 21:02, Graimer said:

Well anyways, thank you very much =) Now I'll just need to get my sketchboard and start drawing/making test-conditions.

Last update: Made it work now. My tries with vectors(or one pixelmovement at a time) didn't work to well. But I found another solution and thought I'd share some hints of how I did it in case someone else is wondering about the same thing.

I found out that the Rectangle class had a bool intersect(rectangle r)-method and a rectangle intersection(rectangle r)-method. So I made a rectangle out of the block to check and one for the ball, checked it ball.intersect(block), if so , found the hitZone/intersected area with ball.intersection(block) and made tests on this very small rectangle to check if the ball hit on top, left, right or bottom side and the correct action for each side. Ex. if the ball hit the left side, the ball would now change to move to the left.

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • It’s encouraging that Intel is still competing, the best they can, in the gpu space.
    • Windows 11 KB5062233/ KB5060843/ KB5062197/ KB5061090 setup, recovery updates released by Sayan Sen This week Microsoft released non-security preview updates for Windows 11 22H2 and 23H2 under KB5060826 as well as for 24H2 under KB5060829. The company also published dynamic updates alongside them. Dynamic updates bring improvements to the Windows Recovery in the form of Windows Recovery Environment (WinRE) updates, also called Safe OS updates, as well as to the Setup binaries in the form of Setup updates. These Dynamic Update packages are meant to be applied to existing Windows images prior to their deployment. These packages include fixes to Setup.exe binaries, SafeOS updates for Windows Recovery Environment, and more. Dynamic Updates also help preserve Language Pack (LP) and Features on Demand (FODs) content during the upgrade process. VBScript, for example, is currently an FOD on Windows 11 24H2. Both setup and recovery updates were released. The changelogs are given below. First up we have the Setup updates: Up next, we have the recovery updates: Microsoft notes that the Recovery updates will be downloaded and installed automatically via the Windows Update channel. The Setup updates, however, need to be downloaded and installed manually. You can avail them on Microsoft's Update Catalog website: KB5062233, KB5060843, KB5062197, and KB5061090.
    • Gaming mouse review: Keychron Lemokey G2 8K Wireless, high performance, light in weight by Robbie Khan Available in the UK and USA, the G2 is a wireless gaming mouse by Lemokey, the customised gaming peripheral arm of Keychron, a brand many readers will know well. I've checked out Keychron keyboards recently, models such as the top-tier Q6 Max, and the bargain priced B6 Pro. I never got the chance to check out the G1, but the G2 seems to put itself firmly in-between competing 8K gaming mice out there whilst coming in at a decent sum under £100/$100. The other benefit is that it uses Keychron Launcher, the web-based software that has been a staple part of Keychron keyboards for a long time now. I rate the launcher highly and have rarely had a problem with it, so it is great to see a robust piece of software being used on an affordable gaming mouse that's not only built well, but performs well, too. As it's a high performance gaming mouse with a flagship PixArt sensor, I will be comparing the G2 directly against my personal mouse, the similarly sized Pulsar Feinmann F01. Both mice are priced wildly differently, so it was interesting to compared several factors between them to see if one bests the other where it matters most, or if it just comes down to individual preferences. Let's check out the specs... Keychron Lemokey G2 SKU G2-A1 Sensor PixArt 3950 IPS 750 MCU Realtek 8762G Connectivity Bluetooth 5.1 / 2.4 GHz / Wired (type-C cable) Polling Rate Up to 8000 Hz (2.4 GHz / wired mode), 125 Hz (Bluetooth mode) Motion Sync Yes Angle Snapping Yes Acceleration 50g Cable Detachable Type-C to C Cable + Type-A to Type-C adapter Dongle Micro USB-A dongle Main switches Huano Micro Switch Switch lifespan 80 Million Clicks Battery 300 mAh Battery life 60 Hours (Under 1000Hz) 35 Hours (1000-4000Hz) 20 Hours (4000-8000Hz) Skates Teflon / PTFE Lift Off Distance 0.7 / 1.0 / 2.0 mm Material (Body and Grip) ABS Dimensions 118mm / 62.6mm / 38.2mm Tracks on glass (min. 4 mm thickness) Yes (max 1000Hz report rate) Weight 52 ± 3 g Colours Black / White Price £73.99 / $69.99 Fit and finish Made of all ABS, it certainly doesn't feel anywhere near as nice as the F01, but then again it's priced much lower, so no complaints there. To me it feels more like a previous generation Endgame/Zowie mouse, before they started to use the more grippy textured finish. It's a fine finish but how long that lasts only time will tell. With the Endgame mice I always found that the side buttons would go shiny first, and I suspect the exact same to apply here with the G2, since the size and shape of them is similar, as is the material quality. Speaking of side buttons, my personal preference is flat and large buttons, the long and pointed ones like those on the G2 shown above and GAMIAC PX71 at the bottom always felt a bit awkward to me for naturally resting a thumb on, whereas the large surface area of the ones found on the Feinmann and others like it feel more ergonomic and comfortable for long usage sessions. Pulsar Feinmann F01 (ergo shape) Lemokey G2 (ambidextrous shape) Under my 19cm hand, the G2 feels comfortable and stable for both claw and palm grip styles, though my usual style is a hybrid approach. I like to pinch a mouse with a thumb and ring finger, then articulate forward or backward movement with them to adapt to different play-styles. Both mice have a sloping back hump that works brilliantly for this and i had no problem getting comfortable with the G2 here. The underside of the G2 hides a cool feature I wish more more mice makers adopted, can you spot what it is in the photo below? That little flap at the bottom to store the USB dongle, it's convenient, especially for gamers who travel with their mice or laptop gamers. The skates applied are PTFE and cover three zones on the underside, sadly I forgot to take a photo of them before swapping them out to my preferred skates, the Wallhack Pro UWMP yellow dots. I found no problem with glide resistance on the stock skates, though find dots glide nicer overall and these yellow dots slide around like butter. Lemokey states 52g for the weight, give or take 3g, so my scales measure up perfectly here. It's not as lightweight as the Feinmann which currently is 45g, but it's still considered super-light and honestly, under the hand, this weight difference on dot skates is hard to tell apart. Gripping the G2 hard on both sides shows no obvious issues with flexing, so the internal construction is also up to scratch and exactly what i would expect in this price range. The differences start to be noticed when you are using the G2 as a combination mouse, both in gaming and desktop use. The wheel is thinner than the one on the Feinmann and other gaming mice with fat wheels. I much prefer a nice wide wheel, the diameter is also much larger as can be seen with the overhead photo above. The button tops also have a distinct difference in feel when actuating the switches. there is more of a hollow feel to the G2's tops, as well as slightly more travel post-click. the Huano switches feel and sound excellent, though, but I think the ABS contact surface on the outside could have been slightly more distinct in feel. Here is a demo of how the main switches sound, you can also hear the switch tops clap if you pay attention: Likewise the side buttons have extra play after the switches actuate, something the Feinmann and others in the higher price category don't tend to have. Features & software Aside from the usual features that all gaming mice support these days, such as Motion Sync, lift off distance and Macro, the big feature with the G2 is that is uses Keychron Launcher, the web-browser based software. All changes are stored directly onto the on-board memory, here is what the sections within it look like: I found no bugs with the implementation here, and unlike other Keychron wireless devices I have used with Launcher in the past, the G2 connects and can be customised in it over both wired and wireless. Just be aware that the firmware update option when connected via wireless will only check the dongle's firmware. To check the G2's firmware, a USB cable will need to be connected. Performance Whether on the desktop in Windows or in games, the cursor and motion performance is excellent, though this is to be expected from all modern gaming mice, regardless of price. The higher priced mice tend to have better use of high quality materials, and implementation of software and physical features. I'm currently pacing through nine games, all mixed genre, and in each of them I had no troubles quickly getting comfortable with the G2. If you're used to an Endgame XM2we sized mouse, then this will be just as familiar to you. The convenience of the DPI button at the top of the mouse instead of underside makes instant switching simpler, although the button can be remapped to do something else for those who don't care about DPI toggling. Here is a demo of the G2 playing Doom: The Dark Ages: The sensor tracking performance at 8K was perfect, aside from the few moments my physical movement on the mousepad slowed down causing some drops in the Razer mouse tracking measurement graph below: A consistent 7900-8000Hz polling was observed, though keep in mind that using such high polling rates will impact CPU performance whilst gaming. How much this affects framerates will boil down to the CPU you have. On my i7 12700KF there was no change whilst gaming, but during the measurement above I did observe 13% CPU package utilisation. In practice, though, I saw no performance difference playing at 8K versus 2K or even 1K. Battery life will drastically be impacted at 8K polling rates for obvious reasons, and whilst many prefer 4K, there is a growing trend to just stick to 2K which feels the safe middle ground of great battery performance, whilst still being suitably responsive on paper for even the most fast-paced of gaming sessions. Conclusion The Lemokey G2 has proven to be a rather excellent mouse, not just for gaming, but general use, too. Though being excellent doesn't give it any special status, as there are equally excellent mice out there that cost the same, less and even more. A buying decision will come down to individual needs, do you value the use of a browser-based software tool like Keychron Launcher? If so, then this is right up your street. Do you want something lightweight but also supports the gaming features and feel in the hand as more expensive mice? Maybe the G2 will satisfy. It's not totally perfect, nothing ever is, the thumb buttons could have been a bit wider, and the switch caps have more travel after clicking than what I am comfortable with, but otherwise this is a great mouse with features that rival the competition. The sensors on gaming mice these days isn't a key selling factor any more either, since even entry level gaming mice are capable of precision tracking and speed that was only possible on the top-tier models of the past, like many things in tech now, the point of diminishing returns has been reached, and brands have to work harder at giving us consumers a unique selling point to attract interest. I believe the G2 has at least one USP (Keychron Launcher), it also helps that it's a very comfortable mouse to use for all-day sessions.
    • Delays can happen any time and names changed, but the joke was still there to be made.
  • Recent Achievements

    • Week One Done
      Alexander 001 earned a badge
      Week One Done
    • Week One Done
      icecreamconesleeves earned a badge
      Week One Done
    • One Year In
      PAC0 earned a badge
      One Year In
    • One Month Later
      PAC0 earned a badge
      One Month Later
    • One Year In
      Shahmir Shoaib earned a badge
      One Year In
  • Popular Contributors

    1. 1
      +primortal
      564
    2. 2
      +FloatingFatMan
      187
    3. 3
      ATLien_0
      185
    4. 4
      Skyfrog
      113
    5. 5
      Xenon
      109
  • Tell a friend

    Love Neowin? Tell a friend!