SQUARISM addicted to pixels

Making Tetris

Backstory

In my last job, I was a hourly contractor who had finished a project and was transitioning off to other things. By a chance of fortune, I had an opportunity to take some time off and do whatever. I had one week on, one week off for a period of over a month. I was extremely excited because I have a lot of hobbies that are bound by time and this was exactly what I wanted. Time to do whatever. I was curious to see whether I'd waste it or actually produce something. I'm happy to say that I did not waste the time I had and I produced the most intense gamedev learning experience I've ever had. By no means, am I claiming to be an expert. I'm just documenting a very large personal effort.

Ok, enough of all that personal crap. In reading game development community sites (like gamedev.net and idevgames.com), something that was a near cosmological constant is the post "OMG I wnt to make mmo, pls halp!". It's like a nuclear clock. Someone does some subscription revenue math, gets excited with dreams of being rich, tries to start something ridiculously complicated, gets stuck and runs to a forum looking for members or advice. On a forum like idevgames.com, there are exceptional members (who should be praised for their patience and humanity) that take the time to respond to this never-ending line of questioning. The most effective response is, "have you made tetris yet?". Usually the person has not made a simple game and I doubt that they end up doing so. However, eventually this idea sunk in and I realized: I do not want to make an MMO but I should make Tetris. Because someday I might want to make something more complicated (not an MMO). So let's do this.

The Plan

Firstly, I had been doing Java at my job for a while now and am fairly comfortable with it. Outside of this, I had been messing around with a project called Processing which makes graphics and generative art really easy. I knew this was going to be complicated so instead of diving into code, I made a plan first. I started breaking down what Tetris is and mapped out classes and responsibility. This planning bit I've always been bad at and I spent maybe a day thinking and writing down like "what a tetris piece is" and what minimal features there should be. The gameplay and design is already done and this fact is a big step compared to coming up with something by yourself.

For sure, the lesson I learned is: "it's just a plan". You can change it as you go and eventually it's best to throw it away after things are sufficiently started. As the code grew, the plan was put away; which is good because my plan wasn't really all that special or well organized. I had some ideas about pieces to be written and what the hard parts were but honestly the best lesson I learned was "it's just a plan". You're not going to pre-write and pre-solve all the problems.

Next was research and learning. I studied other processing games (like MonkeyPatrol by Joshua Minor) and white papers from university CS classes. I played Quinn (a mac OSX clone) a bit. I knew a few things to start with. For example, game objects should draw themselves. There are 7 piece types (which look similar to the letters: I L O J S Z T) and many things are similar between them so I planned for a base Piece class and named the pieces after the letters they looked like (IPiece, LPiece, etc). I collected some screenshots of existing games to use as inspiration.

Drawing a Piece

Ok, I had my plan and similar stuff done. Ok, where to start? I like to start from the top down. IE: from the interface backwards. So I start with a graphical mockup and then make the mockup actually function. So started out with drawing. First, I created a Block class. This is a single square with an x,y,height,width,color etc. It's a component of a Piece. Before going any further. I have to explain that I intentionally did not do Tetris the easy way. The easy way is having a bitmap style grid of blocks and simply moving the bits down and around. Then you just represent the bitmap with graphics. I did not do it this way because I wanted an excuse to do sorta a "2d model" where the piece is constructed from a central point, rotated etc more like what someone would do with a 3d model in a modern game. This single decision made things extremely complicated for me but it also made it a more useful learning experience for when I want to do something like a platformer or a shooter because these game types use collision detection in a 2d/3d space similar to how I did it. So a Piece consists of Blocks with a model describing the shape of the Piece. For example, an LPiece looks like this:

1
2
34

And the IPiece looks like this:
1
2
3
4

And the OPiece looks like this:
12
34

So I created all the Pieces and eventually had a test app that looked like this:

Next, let's move on to piece movement.