gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Beginners > Collision map for bricks game

#12877 - cooper - Sat Nov 29, 2003 7:51 am

Hello All!

I'm attmepting to make a breakout type clone, and I've been succesfull at getting the ball to bounce around on the screen, and off the paddel, but now I would like to add some bricks. I'm familiar with C, C++, but very new to game programming. From a high level, what would be the best way to do this? Should each brick be a sprite, then have a collision map for each level? Or should I do a map with brick tiles, and have an ID set for the bricks? I've only found the source for one breakout clone on GBA, and unfortunatly it was a bit confusing. Any suggestions would be greatly appreciated.

Thanks in advance!

#12882 - tepples - Sat Nov 29, 2003 3:01 pm

Arkanoid on the NES and Alleyway on the monochrome Game Boy draw the bricks with tiles. Then you can read the tile map to see if the ball has overlapped a brick.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#12924 - NeoGeo - Mon Dec 01, 2003 1:17 am

Here is a nice tutorial on collision detection

http://www.ahchay.com/ngpcdev/tutorial4.htm

#13115 - sgeos - Fri Dec 05, 2003 7:53 pm

Your display should reflect the contents of your game state. Your game state should not be stored in the display. It is not important how you display your blocks.

I'd use an array of ints for the collision map:
Code:
#define MAP_W 10
#define MAP_H 5

int cmap[MAP_W * MAP_H];


When you start a map, copy the stage data into your array:
Code:
const int stage1[] = {
   3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
   2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
   1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
   1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
   1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
};

void load_stage(const int *src, int *dst)
{
   int i;

   for (i = 0; i < MAP_W * MAP_H; i++)
      dst[i] = src[i];
}


When a block gets hit, reduce that member by 1. The stage map indicates number of hits to destroy the block. When that number is 0, the block is destroyed:
Code:
void hit(int y, int x, int *map)
{
   if (may[y * MAP_W + x] == NOBREAK_VALUE)  /* Can't break me! */
      return;
   if (may[y * MAP_W + x])
      may[y * MAP_W + x]--;
}


By isolating the display code, you can do different things. 3 hits can be yellow, 2 hits red, and one hit blue. For bonus stages, each block can be a random color, and change to a random color when hit. Anything else could be done. My point is that the game state should not be tied to the display.

I'd used a 16 color text BG for the display. When you hit a block, I would do this:
1) Cover the block with a sprite
2) Change the color (palette) of the text BG block
3) Make the sprite flash
4) Move sprite offscreen to show the block underneath

If you feel like making things simple, palette 0 could be all balck, that way you do not have to remove an blocks from the map.

-Brendan

#13147 - sajiimori - Sat Dec 06, 2003 5:29 am

Quote:

My point is that the game state should not be tied to the display.

Absolutely. But we can surely forgive NES developers for being thrifty with their memory usage. On the other hand, given 144 times as much RAM with the GBA, we have no excuse. ;-)

#13154 - jma - Sat Dec 06, 2003 1:40 pm

While coded in BASIC, perhaps my version of Breakout for Dragon BASIC will help? Check it out at http://www.jm-basic.com/dragon/code/gallery/breakout.zip

Jeff
_________________
massung@gmail.com
http://www.retrobyte.org

#13162 - NeoGeo - Sat Dec 06, 2003 8:30 pm

I could give you the code for my gba game Paddle Panic a four way breakout game I made for the gbadev compo in september. If you want it just mail me :)
its just 1000 lines

#13173 - sgeos - Sun Dec 07, 2003 3:49 am

sajiimori wrote:
Quote:

My point is that the game state should not be tied to the display.

Absolutely. But we can surely forgive NES developers for being thrifty with their memory usage. On the other hand, given 144 times as much RAM with the GBA, we have no excuse. ;-)


Actually, I was not responding to tepples comment. When I was less experienced, I did not realize where the state of a progrom should be stored. I remember reading an Open GL book and thinking that I could use Open GL to *store* 3D worlds, as oppose to putting them on the screen. That would be backwards.

This is what I was responding to:
Quote:
... now I would like to add some bricks ... what would be the best way to do this? Should each brick be a sprite, then have a collision map for each level?


Should implies a goal. What one "should" do depends on one's goals. To the extent that a single question involving both game state and display was asked, my recommendation is that the display should be kept separate from the game state. There are a bunch of good ways to add bricks to a game like this.

-Brendan

PS 144 times as much RAM? That is a fair bit more memory.