Tetris blocks construction
Ok, as a little side project to my mega complex pacman thing (not joking - plans for multiplayer over TCP/IP and everything ), i thought i''ld do a tetris clone. Now, the blocks... I dont know how to approach it. Do i draw a little singular block and "build" the bigger L-shapes etc out of them or should i draw the bigger blocks themselves into bitmaps?
Problems:
Using the "building" technique it requires a lot of coding on my behalf to construct the bigger blocks.
Using the plain bigger blocks straight from bitmaps its harder to chop them up when players get "lines" - hmm... i can tell im not explaining properly... Could i use the DX clipper to do this? I dont quite understand how to use it so any help appreciated
jumble
---------------
"Witty comment needed for signature. Current owner has no sense of humour"
jumble-----------
Use a table data structure, and build all of the shapes out of a single block (or several for each color you wish..)
Simply have an array of offsets from the first block for each shape. (for example, a long line down would be {0,0},{0,1},{0,2},{0,3}) You can also build in most of your game mechanics into this table -- for example, to which shape does the line rotate to when rotated, how much score for dropping the particular block, how much deduction for rotating it, etc.
It doesn''t take much time to build this table, and then it is simply compiled into your program. Actual blocks shown on the game are just an x,y value of the first block location and an index into the table for which block to draw.
Notwen
www.xbox.com
Simply have an array of offsets from the first block for each shape. (for example, a long line down would be {0,0},{0,1},{0,2},{0,3}) You can also build in most of your game mechanics into this table -- for example, to which shape does the line rotate to when rotated, how much score for dropping the particular block, how much deduction for rotating it, etc.
It doesn''t take much time to build this table, and then it is simply compiled into your program. Actual blocks shown on the game are just an x,y value of the first block location and an index into the table for which block to draw.
Notwen
www.xbox.com
Notwenwww.xbox.com
Interestingly enough, I''m getting ready to work on the same project. Plus, I thought about that same question! Even though I haven''t finished, I definately think that the bigger blocks made of individual blocks is the way to go. The cool thing about individual blocks is that it really fits in the object oriented mold. I''m thinking of deriving the shapes from my blocks class. At the very least, you will only need 1 collision detection routine. The shapes objects will just have to determine which blocks need to do detection.
There may be something wrong with this design, but that''s where I am : )
Take care, and good luck!
Req
There may be something wrong with this design, but that''s where I am : )
Take care, and good luck!
Req
dddDDDdddDDDdddDDDdddDDDddd Big Brother is Watching
Wow thanks for the quick responses! Using the building thing and offsets, should my reference x,y point be in the centre of the block or the top-left corner? I'm trying to think about this... which would make rotation and collision easier?
Thanks for the luck btw, i need it
jumble
---------------
"Witty comment needed for signature. Current owner has no sense of humour"
Edited by - jumble on May 8, 2000 4:47:14 PM
Thanks for the luck btw, i need it
jumble
---------------
"Witty comment needed for signature. Current owner has no sense of humour"
Edited by - jumble on May 8, 2000 4:47:14 PM
jumble-----------
Unless you want a coding nightmare later, use smaller blocks that make up your dropping piece. You don''t need to use the same building block throughout. What I did was build a table of piece images, one image per piece per unique rotation. And then I used a lookup table to decode the current piece and rotation to get the image.
For the pivot point, I used the upper left corner. In the game board, I built a border so that the piece couldn''t possibly get out of bounds. Collision detection came down to checking 16 array elements, regardless of the actual piece.
Hope this helps.
MartinJ
-Making life more interesting through creative confusion
For the pivot point, I used the upper left corner. In the game board, I built a border so that the piece couldn''t possibly get out of bounds. Collision detection came down to checking 16 array elements, regardless of the actual piece.
Hope this helps.
MartinJ
-Making life more interesting through creative confusion
I looked up the version I wrote a couple of years ago..Here is my relevant data structure, for reference.
Sorry if the formatting looks a bit screwy..
Notwen
www.xbox.com
//
// The basic block structure. The global array of
// BLOCK info maintains the necessary information to create and place
// new blocks, rotate them, use them in scoring, etc.
//
typedef struct {
INT MaxStartX;
INT BaseScore;
BLOCKTYPE BlockId;
BLOCKTYPE RotId;
POINTS Tiles[4];
} BLOCK, *PBLOCK;
BLOCK g_BlockTemplates[BLOCK_LAST] = {
{GRIDSIZEX-1, 10, BLOCK_LINEUP, BLOCK_LINEACROSS, {{0,0},{0,1},{0,2},{0,3}}},
{GRIDSIZEX-4, 10, BLOCK_LINEACROSS, BLOCK_LINEUP, {{0,0},{1,0},{2,0},{3,0}}},
{GRIDSIZEX-2, 40, BLOCK_LUPLEFT, BLOCK_LACROSSRIGHTUP, {{0,0},{1,0},{1,1},{1,2}}},
{GRIDSIZEX-2, 40, BLOCK_LUPRIGHT, BLOCK_LACROSSRIGHTDOWN, {{0,0},{1,0},{0,1},{0,2}}},
{GRIDSIZEX-2, 40, BLOCK_LDOWNLEFT, BLOCK_LACROSSLEFTUP, {{0,2},{1,2},{1,0},{1,1}}},
{GRIDSIZEX-2, 40, BLOCK_LDOWNRIGHT, BLOCK_LACROSSLEFTDOWN, {{0,2},{1,2},{0,0},{0,1}}},
{GRIDSIZEX-3, 40, BLOCK_LACROSSRIGHTUP, BLOCK_LDOWNRIGHT, {{0,1},{1,1},{2,0},{2,1}}},
{GRIDSIZEX-3, 40, BLOCK_LACROSSRIGHTDOWN, BLOCK_LDOWNLEFT, {{0,0},{1,0},{2,0},{2,1}}},
{GRIDSIZEX-3, 40, BLOCK_LACROSSLEFTUP, BLOCK_LUPRIGHT, {{0,0},{0,1},{1,1},{2,1}}},
{GRIDSIZEX-3, 40, BLOCK_LACROSSLEFTDOWN, BLOCK_LUPLEFT, {{0,0},{0,1},{1,0},{2,0}}},
{GRIDSIZEX-3, 50, BLOCK_SLEFT, BLOCK_SDOWN, {{0,0},{1,0},{1,1},{2,1}}},
{GRIDSIZEX-3, 50, BLOCK_SRIGHT, BLOCK_SUP, {{1,0},{2,0},{0,1},{1,1}}},
{GRIDSIZEX-2, 50, BLOCK_SUP, BLOCK_SRIGHT, {{0,0},{0,1},{1,1},{1,2}}},
{GRIDSIZEX-2, 50, BLOCK_SDOWN, BLOCK_SLEFT, {{1,0},{0,1},{1,1},{0,2}}},
{GRIDSIZEX-2, 20, BLOCK_TLEFT, BLOCK_TUP, {{1,0},{0,1},{1,1},{1,2}}},
{GRIDSIZEX-2, 20, BLOCK_TRIGHT, BLOCK_TDOWN, {{0,0},{0,1},{0,2},{1,1}}},
{GRIDSIZEX-3, 20, BLOCK_TUP, BLOCK_TRIGHT, {{1,0},{0,1},{1,1},{2,1}}},
{GRIDSIZEX-3, 20, BLOCK_TDOWN, BLOCK_TLEFT, {{0,0},{1,0},{2,0},{1,1}}},
{GRIDSIZEX-2, 10, BLOCK_BLOCK, BLOCK_BLOCK, {{0,0},{0,1},{1,0},{1,1}}}
};
Sorry if the formatting looks a bit screwy..
Notwen
www.xbox.com
Notwenwww.xbox.com
quote: Original post by jumble
Ok, as a little side project to my mega complex pacman thing (not joking - plans for multiplayer over TCP/IP and everything ), i thought i''ld do a tetris clone.
Hey, it seems we are getting on the same things...
quote: Original post by jumble
Now, the blocks... I dont know how to approach it. Do i draw a little singular block and "build" the bigger L-shapes etc out of them or should i draw the bigger blocks themselves into bitmaps?
Problems:
Using the "building" technique it requires a lot of coding on my behalf to construct the bigger blocks.
Using the plain bigger blocks straight from bitmaps its harder to chop them up when players get "lines" - hmm... i can tell im not explaining properly... Could i use the DX clipper to do this? I dont quite understand how to use it so any help appreciated
I don''t really understand why you haven''t planned to use some cute arrays to define the blocks structure using a single "small square" primitive. No additional code. Easy and efficient.
Doing this way you (as I did several years ago) have no problems in implmenting the collision detection ruotines.
Bye,
Karmalaa
---[home page] [[email=karmalaa@inwind.it]e-mail[/email]]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement