Brixtar - Day 1

Published May 21, 2007
Advertisement

I wasn't feeling that well yesterday - probably a result of pushing myself too hard to finish the Diagonal Game Library prototype by the end of the weekend - so I didn't get that far in my first demo game. Currently all I've got is some sample game objects displaying placeholder graphics I whipped up in Inkscape, a paddle you can move with the arrow keys and a ball that bounces around the screen but doesn't interact with anything.

Tonight I'll implement the collision detection to turn this into a game. The collision detection is essentially the only challenging thing with an Arkanoid/Breakout type game; it's pretty easy to hack together something that works in the trivial case, but harder if you want to implement multiball or balls that move at significant speed.
Previous Entry Mission Complete!
Next Entry Brixtar - Day 2
0 likes 4 comments

Comments

ArchWizard
Let us know how you do the collision detection. I still haven't implemented that in my breakout clone, Acid Trip Redux. If I'm not going to finish Generic Fantasy Quest any time soon, I should at least finish ATR soon :P
May 21, 2007 05:04 PM
Trapper Zoid
Sure thing. I was originally thinking to integrate physics and collision detection within the game library itself, but I now think the algorithms involved are highly dependent on the nature of the game.

I think it isn't that hard to do collision detection with a slow moving object, but for an object that moves quickly (like a high-speed ball) there's a chance that in a single frame the object will move straight through the item it should collide with. This means I'll have to implement a method for checking all possible collisions within the time between frames. It's a bit easier in Arkanoid/Breakout games where the bricks are stationary, but gets more complex when you factor in multiple balls (which one hits the brick first?)

May 21, 2007 05:55 PM
Driv3MeFar
There are some general purpose physics/collision things you could integrate if you really wanted to. Things like bounding volume, ray-volume and line segment-volume intersections (which would be useful in this case).

I don't know if you have anything planned out, but this is how I wold do collision for a breakout style game:
Just create a line segment from the center of the ball to the center of where it will be at the end of the frame. Then, for each brick just check for intersection with the segment. To accommodate for the actual size of the ball, you have to "inflate" the size of the bricks by the radius of the sphere, if that makes sense. Using a parametric equation for your line segment, you can determine the correct time of intersection pretty easily to handle reflection and whatnot.

Hope it helps!

Edit: Since I don't feel like doing homework, here's a diagram and some math:

Let C be the center of the ball, P be a vertex of the block, and V be the path of the ball.
U = P - C
Q = (U dot V / |V|*|V|) * V
R = P - Q
if |R| <= radius of the ball
collision!

This is pretty slow, but it should work for a first pass. Once you get Q, you can find the time of collision:
t = Q - C / V

I didn't test any of this, so I probably made a mistake or two somewhere, but hopefully it gives you some ideas as to where to start.

Edit 2: Yeah, a grid based system would probably work really well for breakout. And you can never have too much coffee.
May 21, 2007 07:23 PM
Trapper Zoid
Quote:Original post by Driv3MeFar
There are some general purpose physics/collision things you could integrate if you really wanted to. Things like bounding volume, ray-volume and line segment-volume intersections (which would be useful in this case).

I might end up throwing a few of those algorithms into my collection of miscellaneous utilities; it's some of the more domain specific elements such as the data structures used to contain game world objects for fast culling of collision candidates that I'm not sure can be that generalised. A grid based system is perfect for Breakout, but might need some heavy tweaking for something like Asteroids, for example.

Quote:I don't know if you have anything planned out, but this is how I wold do collision for a breakout style game:
Just create a line segment from the center of the ball to the center of where it will be at the end of the frame. Then, for each brick just check for intersection with the segment. To accommodate for the actual size of the ball, you have to "inflate" the size of the bricks by the radius of the sphere, if that makes sense. Using a parametric equation for your line segment, you can determine the correct time of intersection pretty easily to handle reflection and whatnot.

That's pretty much what I've got planned, except my roughly sketched plan was more based on the potential grid lines that define the brick field. The main problem is that my brain feels like mush at the moment so while it's trivial to do the mindless slog parts like the base code shown in the screenshot various parts of my head protest when I get to the "thinking" parts.

It's probably down to my overuse and abuse of coffee. I'm not sure what the best solution is - cutting back significantly or more coffee.


May 21, 2007 08:38 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement
Advertisement