• Advertisement
Sign in to follow this  

3d tetris

This topic is 4251 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

For everyone that's made a tetris game, I'm asking you a question. [smile] I'm working on a 3d tetris game, and I'm a little stumped as to how I'm going to implement a tetris 'piece' (one or more blocks together). I'm planning on only have a single block (a model with textures and shaders, and pretty stuff) and then just translating it and calling 'render' in every place it needs to be. So, I have a 'play area' made up of 'block spaces' which basically keep track of the position of the 'space', whether the space is occupied by a block, and what color the block is. I figure I don't really need more than that. But, with an actual piece, I'm having problems designing it. I suppose that there'll have to be a central block of sorts that will be used as a "root block" for the piece, but I'm not completely sure. Should I just have a base class with a list of "blocks", or rather the index of "blocks" relative to the root block, and then just have classes inherit from that for every special kind of block and just construct them differently. Or something.

Share this post


Link to post
Share on other sites
Advertisement
Well how you are going to implement the peice depends on how you are going to show the different levels of depth.

Look at this example that could be a problem.
(The number is the number of blocks in that column)

Top View(3333 being the front row.)
0000
0110
0120
3333

To player looks like: (* being a block)
0000|0000
****|*000
****|**00
****|***0
That suppose to be a corner view.
I can see a problem where you cant see where it is going
Depending how you fix that problem is how you fix piece problem

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by slymr
Well how you are going to implement the peice depends on how you are going to show the different levels of depth.


What? No.

Well, if this is a 2d sprite based graphics API *maybe*
but he's already mentioned models, textures, shaders, so I'm assuming OpenGL or DirectX.
So rendering and actual game logic are going to be pretty well separated.




Thinking about representation...
A list of blocks and their locations for each piece sounds simple. but I forsee potential difficulty when trying to rotate pieces...
I guess the structure could also include a centerpoint coordinate, and all blocks in the piece could be positioned relative to that, it should make rotation easier...
This is purely from a rendering standpoint though, how do you plan on doing actual block collision/position detection?
Id probably do a 3d boolean grid for the actual collisions, while the rendered pieces use separate floating point coordinates (for smooth animations).
The grid would probably contain only the 'stopped' blocks, not the ones in the piece that is currently falling...(since that one changes a lot)
Maybe cast the float coords of individual blocks to integers to get their grid position?

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Quote:
Original post by slymr
Well how you are going to implement the peice depends on how you are going to show the different levels of depth.


What? No.

Well, if this is a 2d sprite based graphics API *maybe*
but he's already mentioned models, textures, shaders, so I'm assuming OpenGL or DirectX.
So rendering and actual game logic are going to be pretty well separated.




Thinking about representation...
A list of blocks and their locations for each piece sounds simple. but I forsee potential difficulty when trying to rotate pieces...
I guess the structure could also include a centerpoint coordinate, and all blocks in the piece could be positioned relative to that, it should make rotation easier...
This is purely from a rendering standpoint though, how do you plan on doing actual block collision/position detection?
Id probably do a 3d boolean grid for the actual collisions, while the rendered pieces use separate floating point coordinates (for smooth animations).
The grid would probably contain only the 'stopped' blocks, not the ones in the piece that is currently falling...(since that one changes a lot)
Maybe cast the float coords of individual blocks to integers to get their grid position?


I can't do a proper reply, but I'm just doing a quick one to let you know that I've been back.

In regards to the "3d boolean grid", that's basically what I have. I reasoned that all the blocks will have the same shaders and effects, but only different colors. So, I have a 3d grid of what I call "BlockSpaces", which keep track of their own position (position in 3d space, not grid position), the color of the block currently in that space, and a boolean which indicates whether there is a block in that space.

Great minds think alike, eh? [grin]

Anyway, something like that makes it childs play to find if there is a complete line. All you have to do is walk the grid at a specific height and depth and check if the full line is occupied.

What you said about the rotation is my main problem. The problem is that I won't be able to rotate in a rendering sense. When a piece rotates, I'm obviously going to have to change their grid positions so that the spaces they appear to occupy are the spaces that they are actually occupying. If that makes any sense.

Anyway, the way I'm rendering it is that I basically iterate through every element in the 3d grid and just call render for that BlockSpace, which will change the color of the block (which is a model and only one of which is actually loaded), and then render it at it's (the BlockSpace) own position.

This way I can simply change which BlockSpaces are occupied and their colors whenever the tetris piece moves.

I hope that makes sense. I'll be back, probably sometime tomorrow to do some more work on this and hopefully crystalize my ideas some more.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement