Game Logic of Tetris

So when you think of a way to implement Tetris, obviously using an array pops out at you right? Siva seems to think my use of arrays in this game is blasphemous. The basis of my game logic coding started at designing a class to encapsulate the object the player manipulates. I extended the Sprite class previous created and added a bunch of fields to store various data needed to keep track of a single block in the grid. The main game world would be an array of these objects. All the handling of the seven tetriminos would be on a block by block basis, rather than manipulating a 4 block object all at once. In retrospect, the way I designed this is vastly inefficient and contained an enormous amount of hard coding. But for a game like Tetris, I really still can’t think of a better way.

Once the game state entered the activegame, the first thing the game would do, is instantiate the playing field. This consisted of rendering the HUD that contained simply a window for the game world array, a fancy little title and a window to display what the next block would be, standard Tetris stuff. It would than create an element in every position in the rectangular array. The reason for this was twofold. First, when I was designing this system, I thought, though it may not be much, perhaps it might be more effective to pre-create all the blocks at the beginning of the game and never have to worry about creating and destroying objects throughout the code, it might even improve game performance during play, since that piece of CPU allocation never had to be dealt with again for the lifetime of the game. Though that seemed like a valid train of thought, I retroactively came to the realization that memory is a much more precious resource than CPU; objects should only be in existence when required.
But what’s done is done, that is how the system is. So the way I differentiated between my various blocks was through the use of an int identifier. A field inside the block class would keep track of the color code of the block. Each color co-responded to a different tetrimino. This color code would also be kept inside a global variable, in the form of Currentcode and Nextcode. The second variable contains a randomly generated number that displays an image showing the players what the next block would be. Once it’s time for the next piece to drop, the Currentcode is set equal to the Nextcode, and a new number is generated for the NextCode.

The game itself runs even without user input. The active block is always falling down. What the user can control however, is whether or not the block moves sideways at all, as well as the ability to speed up the rate that the block can fall. For the blocks fall speed, I had a counter that read the GameTime and would only allow the block update method to run once every second. User input would change the time the amount of time in between each update cycle, in milliseconds.

The way the lateral movement was implemented was to check for one of the left or arrow keys to be pressed. One key press would allow the block to shift one column over. In retrospect, I should have implemented the lateral movement the same way I did the vertical movement. Where keeping the side arrow keys depressed continuously would allow the game to call a lateral update method periodically.

The rotation of the blocks is a completely hard coded feature. For a specific block, in a specific orientation, where would each of the 4 blocks go in the next rotation. For laziness sake, only clockwise turns were implemented. If I were to redesign this, I would have used a database of this information that would have been called by various turn methods, rather have hard coding nested If statements.

One problem I encountered was that when I tried to replace the contents of one block with the contents of another, the objects would be passed by reference. As of the writing of this post, I’m still unsure as to how to fix this. The hack that I had to put in was to individually update the fields of the blocks.

I hope this provides a good introduction of the thought process I went through when making this game. I apologize for the lack of detail, seeing as I only thought to write this all up after the fact. For my next project, documentation is a priority.