Tetris game design document

As Jim Highsmith, one of the 17 original signatories of the Agile Manifesto, said, " We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. So rather than doing away with game design documents altogether, the documentation process can be adapted to support the creative, iterative, and collaborative process of game development.

Keep the game documentation lightweight. You might have to scrap the game, or pivot in a different direction. Either way, keep the inital documentation to a minimum so you don't have to rewrite a multi-page document. Fit it on a single page and let it evolve from there.

Write the GDD collaboratively. Unless you are an indie game developer working solo, involve your team in the process from the start. Make your GDD the central hub where your team members discover, discuss, and solve issues together. The GDD should evolve together with the project. A GDD is only useful when it's up-to-date. Choose a documentation tool that preserves a version history and let your design document evolve together with your game by updating it daily.

Use visual aids. Don't let your readers drown in text. Many ideas can be much clearly conveyed using graphs, flow charts, and concept art. Or turn your entire game design doc into a mind map and watch it grow as your game evolves. Learn more about how to write a modern game design document. No two game design documents will be the same. However, a GDD template may be a good starting point. Depending on the scope of your game development project, your design document may end up being very brief or fairly long and complex.

Your first iteration can be a simple one-page overview. Copy this template and customize it to fit your needs. As your game evolves and details begin to take shape, you may want to create dedicated documents for different topics. Better yet, turn your game design doc into an internal wiki and organize your work in a more structured way. Mike Dailly, one of the lead designers of Grand Theft Auto — originally called "Race'n'Chase" — shared the iconic game's design documents that date back to March 22, The original design doc of Silent Hill 2 is a lengthy but nonetheless great example of a well-written GDD.

For example, numbers -1, 1 , -1, 0 , 0, 0 , and 0, -1 represent a rotated S-shape. The following diagram illustrates the shape. This code rotates a piece to the left. The square does not have to be rotated. That's why we simply return the reference to the current object. Looking at the previous image will help to understand the rotation.

We have four constants. Some important variables are initialized. The isFallingFinished determines if the Tetris shape has finished falling and we then need to create a new shape. The isStarted is used to check if the game has started. Likewise, the isPaused is used to check if the game is paused.

The numLinesRemoved counts the number of lines that we have removed so far. The curX and curY determine the actual position of the falling Tetris shape. We determine the shape at the given coordinates. The shapes are stored in the board array. We create a timer. The pause method pauses or resumes the game. When the game is paused, we display the paused message in the statusbar.

Inside the doDrawing method, we draw all objects on the board. The painting has two steps. In the first step we paint all the shapes or remains of the shapes that have been dropped to the bottom of the board.

All the squares are remembered in the board array. We access it using the shapeAt method. If we press the Space key, the piece is dropped to the bottom. We simply try to drop the piece one line down until it reaches the bottom or the top of another fallen Tetris piece. When the Tetris piece finishes falling, the pieceDropped is called.

In the oneLineDown method we try to move the falling piece down one line until it is fully dropped. The clearBoard method fills the board with empty Tetrominoe. This is later used at collision detection. The pieceDropped method puts the falling piece into the board array. Once again, the board holds all the squares of the pieces and remains of the pieces that has finished falling.

When the piece has finished falling, it is time to check if we can remove some lines off the board. This is the job of the removeFullLines method. Then we create a new piece, or more precisely, we try to create a new piece. The newPiece method creates a new Tetris piece.

The piece gets a new random shape. Then we compute the initial curX and curY values. If we cannot move to the initial positions, the game is over—we top out. The timer is stopped and we display Game over string containing the score on the statusbar. The tryMove method tries to move the Tetris piece. The method returns false if it has reached the board boundaries or it is adjacent to the already fallen Tetris pieces.

Inside the removeFullLines method we check if there is any full row among all rows in the board. If there is at least one full line, it is removed. After finding a full line we increase the counter.

We move all the lines above the full row one line down. This way we destroy the full line. Notice, that in our Tetris game, we use so called naive gravity. This means that the squares may be left floating above empty gaps. Every Tetris piece has four squares.