Asteroids

[rodot]

My 2 cents: It's way easier to do rectangle collision (by checking coordinates) or circle collision (by checking distance). Interesting article though, thanks for the link

[ripper121]

yes but the asteroids are polygones

[yodasvideoarcade]

Right, in the original, the asteroids are polygons, and it's a vector-screen.

Here, we have a pixel-screen and a very small pixel-size. So doing polygons would waste a lot of resources, compared to using bitmaps and simple shape-based collission detection. Due to the small size of the sprites, it would be much easier and faster to either do pixel-collision or even simpler, a square-based collision.



Using a square-based collision, we could make it quite fair by using a slightly smaller rectangle (as seen on the left in the picture). Or, to make it easier to hit the asteroids, use the outer square (as seen in the middle), or even use a circle-shape for more accuracy (as seen on the right).

The ufos should be hittable easier, so outer square. The player's ship could be just the 3 x 3 pixel square, to make it a bit more fair i.e. less frustrating.

Of course all of this has to be tested to find the best playable solution.

I usually tend to focus on playability and fun, not on getting the technical side 100% accuracte or right. IMO it's most important that the game is as fun as possible, and the easier and faster this can be done, the better. I used to code in Basic, on Atari 8-Bit computers, long time ago.

[ripper121]

The Bounding Box Collision detection I use it in the BrickBreaker.
I think this is the easiest and fastest way to build the game.
I said yesterday i make a first version but i had strong headache , so i will see if i can do it today.

Do the UFO fire at the player?
Is there a collision between the asteroids?
Do the asteroids bounce against the wall or do they fly out of the top and come up at the bottom again?

[Myndale]

I usually tend to focus on playability and fun, not on getting the technical side 100% accuracte or right.

+1

The system is different to the systems that ran the originals, it makes sense that games may need to be re-balanced accordingly.

[Drakker]

You don't actually need bounding boxes or anything. Make the asteroids all black. Draw all the asteroids, then draw the ship, if any of the ship pixel ends up on a pixel that is already black, the ship is destroyed. Since the ship is so small, that not a lot of pixels to check. Then draw the projectiles, same check, if a projectile is drawn on black, determine which asteroid it hits based on distance and move on to the next frame.

[ripper121]

This detection is not bijective (one-to-one)
If 2 asteroids are in the same range when the pixel get methode returns true then which one will you select as hide?
And i think the bounding box is faster then the getpixel methode.

[Drakker]

For the ship it doesn't matter, for the asteroid you can fake circular bounding boxes with distance. The closest asteroid has to be the one that has been hit. If they are both exactly one over the other, it doesn't matter which one has been hit. Also, there is no getpixel method on the Gamebuino as far as I know, you just write directly in memory and send it to the screen when you refresh, so the check is in a 84x48 array. Myndale could clarify if needed, I've never programmed for this type of CPU (I'm a sysadmin turned geomatician, not a long-timer game programmer like Myndale. ;)

[ripper121]

I think i have seen the Display.GetPixel(x,y);.
When we use a collision detection we can do it with one method so we need only one.
So we have to test which one is faster

[Drakker]

But the data displayed on screen is the data from the previous frame, so you can't use it anyway. Speed will depend on the number of asteroids on screen, if there's only one, then yeah, checking positions and bounding boxes will be fast, if there's 20, then checking a few pixels will be faster.