LÖVE

Posted: **Wed Oct 19, 2016 8:36 pm**

Hello.

I'm writing an arkanoid (breakout)-type game, and it is mostly in a playable state (see attachment).
However, there are some problems with code and art, and I would like to ask some help regarding them.

1) I'm using HardonCollider to detect collisions.
At high speed the ball sometimes passes through blocks, walls, or the platform.
What can be done to fix such behaviour?

2) On my machine the game sometimes noticeablay lags.
I've tried to adjust cellsize in spatialhash of HC, but I'm sure this is not a sole reason for low performance.
I would appreciate any advice on how to improve performance and make the game run more smoothly.

3) I'm planning to write a tutorial, describing the whole development process.
First few parts are available on github.
The code is finished, but the explanatory text is not in a readable form yet.
The general plan is approximately following:
1. The Ball, The Brick, The Platform
2. Modules
3. Classes
4. Container Classes
5. Detecting Collisions
6. Resolving Collisions
7. Loading Level From External File
8. Changing Levels
9. Basic Gamestates: Game and Menu
10. More Gamestates: Gamepaused and Gamefinished
11. Tiles
12. Bonuses
13. Menu Buttons
14. Scores and Lives and Fonts
15. Sound
16. Animation
17. Finishing Touches
18. Packaging and Distribution

I would appreciate any ideas, suggestions, improvements or just any other feedback you have.
I think, after I rewrite the text into readable form, I'll start a separate forum thread dedicated to this material.

4) I'm open for collaboration.
Help with graphics and sound is desperately wanted.
Ideas on level design and final screen also would be useful.
A goal is to make a decently polished, though simple game, that can serve for educational purposes.
If volunteering work is against your principles, compensation is negotiable.
( But don't expect much more than a couple of beers, since it is a hobby and non-for-profit project ).

Posted: **Thu Oct 20, 2016 9:15 pm**

Hey, cool, I've always liked arcanoid (especially the ones with cool power-ups)!

To 1): If you really want to stick to HardonCollider, can you maybe make multiple updates per frame? I hear physics-engines sometimes do that.
If not, programming your own physics for a game like this should be simple enough. Since Physics libraries often only calculate "is the shape inside another shape" to detect a hit, they won't detect collisions if the ball is in front of the object in one frame and fully behind it in the next. I'm guessing that's how HardonCollider works as well. If you want to program this yourself, you can simply check the full line of movement (calculate whether the line of movement which the ball is to make this frame intersects with any boxes). Of course, you'll actually need to calcuate two lines (the center line, offset by the radius) to make up for the width of the ball.
This would be the most fun way to solve your the problem, but definitely not the quickest...

Posted: **Sat Oct 22, 2016 3:05 am**

Thanks for suggestions.

Since Physics libraries often only calculate "is the shape inside another shape" to detect a hit, they won't detect collisions if the ball is in front of the object in one frame and fully behind it in the next. I'm guessing that's how HardonCollider works as well.

Indeed, it works like that. It doesn't have any notion of speed of shapes. Maybe HC just isn't an optimal choice for a high-paced game.

1): If you really want to stick to HardonCollider, can you maybe make multiple updates per frame? I hear physics-engines sometimes do that.

That can be done, but obviously that would just increase an upper limit for the ball's speed.
On the other hand, it could be enough for practical purposes.
I'll test this idea.

If you want to program this yourself, you can simply check the full line of movement (calculate whether the line of movement which the ball is to make this frame intersects with any boxes). Of course, you'll actually need to calcuate two lines (the center line, offset by the radius) to make up for the width of the ball.
This would be the most fun way to solve your the problem, but definitely not the quickest...

I think I'll first try to use 'several-updates-per-frame' method. If that doesn't work, than it would be necessary to code collision detection manually.

Posted: **Sat Oct 22, 2016 11:21 am**

noway wrote:
Since Physics libraries often only calculate "is the shape inside another shape" to detect a hit, they won't detect collisions if the ball is in front of the object in one frame and fully behind it in the next. I'm guessing that's how HardonCollider works as well.
Indeed, it works like that. It doesn't have any notion of speed of shapes. Maybe HC just isn't an optimal choice for a high-paced game.

If i remember correctly, HC indeed doesn't do "tunneling", but kikito's bump does.... however, that can only handle Axis-aligned bounding boxes, so no circles or arbitrary polygons.
Since in arkanoid, the ball technically doesn't rotate, you could treat it as an AABB from a collision perspective, so bump may work out for you better than HC.

Posted: **Sun Oct 23, 2016 7:34 am**

If i remember correctly, HC indeed doesn't do "tunneling", but kikito's bump does.... however, that can only handle Axis-aligned bounding boxes, so no circles or arbitrary polygons.
Since in arkanoid, the ball technically doesn't rotate, you could treat it as an AABB from a collision perspective, so bump may work out for you better than HC.

Ok, thanks. I'll take a look at it.

Posted: **Sun Dec 04, 2016 10:07 am**

LÖVE

One more arkanoid clone

One more arkanoid clone

Re: One more arkanoid clone

Re: One more arkanoid clone

Re: One more arkanoid clone

Re: One more arkanoid clone

Re: One more arkanoid clone