   Tetris, collision detection and ideas.
  Hi there I'm new here and am learning some techniques for programming, I am trying my best to get a little head start as I am hopefully going to be attending University of Teessides game programming course.Anyway I have been trying to jot some ideas down for a good first game well 3rd/4th if I actually count up but the others were merely tests. Basically it's going to be a Tetris clone. I have been looking at ideas for how to store the blocks data. Do I maybe make a block class and intialise loads of blocks at run time. And then move them down in the shape defined. Or maybe I have blocks which are set in place only when a shape collides with either the bottom of the area or with another static block. Which makes me think about how to actually store the data of each shape and also how to detect whether a collision has taken place. Knowing that with tetris any shape is made up of 4 blocks. Would initialising an array of 4 blocks be ideal?I have looked through the tutorial/article on "Tetris in an hour", be it a great article I would like to try and come up with another approach to the game as this would stop me from simply copy and pasting *AHEM CHEATING!!!* :D. Plus I think I would learn more. I would rather take a more object oriented view at this, there probably isn't any point on a small project like this but like I said the goal is to learn as much as possible.I will be working with Allegro since I like its simplicity and its pretty easy to follow. Any advice or guideance would be greatly appreciated.   
  I have not read any Tetris tutorials before, so my own implementation may be like what you've already read.  But in case it is not...For blocks, I just used a 4x4x4 boolean array for each one.  The first dimension refered to the 4 different rotations that the block could be in.  (For some shapes, this produces redundancy, but it hardly matters.)  The second and third dimensions are just a 4x4 square that defines which cells are empty, and which are full, for the given rotation.  There were seven types of blocks total, so I ended up having a static 7x4x4x4 boolean array with all the information for any block/rotation.  So for each instance of a block (which could indeed be represented as an object), all you need to store is the index to which block (0-6), the index to which rotation (0-3), and an (x,y) location for where it currently is.For the hole where all the blocks fall, once a block has fallen, there is no need to remember it as a block.  All that is needed is to remember the individual solid cells that make it up.  So the hole was actually just a 10xH boolean array (which could also be wrapped up as an object).  When a block has fallen and come to a stop, I just went through the 4x4 block array, and for every true cell, I set the corresponding hole cell to true, based on the block's location.For collision, I moved the location of the block, or changed the rotation, to the proposed location/rotation.  I then went through the 4x4 array for that block/rotation, and compared each cell with the corresponding cell in the hole, based on the block's proposed location.  If for any cell pair, both cells were true, that means that the proposed movement of the block would result in overlapping solid parts, and was thus invalid.  Depending on whether the move was a drop, a left-right slide, or a rotation, I could then take the appropriate actions.  If the proposed move did not result in overlapping cells, then I simply accepted the move.   ;  I did it almost the same. Instead of boolean I used int, to introduce some color (0 being invisible, 1 being red, 2 being green, etc..) and for a block i used a 4*4 array of these ints. the 3d dimension for rotation i didn't need cause i wrote a function rotate() that changed the matrix-element's positions.for the grid i used a 10*heighth array of ints also with 0 being invisible, 1 being red, 2 being green, etc..   ;  Ah very interesting. Both are indeed similar to the examples I have seen where the shape is stored in a 4x4 array and then if it's not visible set the desired array location to -1 otherwise another number for a colour.So you're saying have two arrays. One for the grid and another for the shape. Manipulate the shape how I need to during game time. And for collision detection it would be more ideal and optimised to keep track of the shapes location relative to the grids location this way I can just compare all visible blocks in the shape to the proposed location and determine if false or not. I had this idea in my head but couldn't for some ungodly reason express it in design terms or even English :D. Many thanks. I may now actually be able to get some programming done soonish once I'm solid with a rough design on paper.   ;  I have also made my own tetris clone without any tutorial! :)Its not completed yet, but it uses a structure similar do Agonys but less optimized. I have a class for each block (and a baseclass ofc), where each block has a list of 4 blockparts. The blockparts are structured in the same way, each blockpart (red, green,... and some special blocks) is a class which inherits the blockpart baseclass. Rotation is calculated by a function in the block class (just set one block as center and do simple 90 degree rotation on the others).I store all blockparts in the field in an array 10x23 and a list (just for easy access). Collision detection is done in the same way as Agony, move/rotate the current block and check if the array is empty for all blockparts.x/.y in the block.Im programming this in python, first using pygame (its a sdl wrapper + a little more for python) and later using opengl for the drawing. I made the change because of performance, I first made an redraw of each blockpart each frame using pygame/blit, and that made the fps go down a lot (especially with 4 players). So, I could either implement more logic to prevent already drawn blockparts be redrawn each frame or switch to opengl for rendering. I was more interested in game logic than sprite rendering, so the choice was quite easy. I havent used allegro but I don't think the sprite drawing differs that much from sdl, so keep in mind that drawing a lot of different things to the screen each frame is slow. The game is still limited by the drawing. Therefore I advice you to don't spend too much time optimizing game logic when you almost certainly will be limited by how you handle drawing.   