As we talk and learn about trigonometry, keep one thing in mind: trigonometry is easy. In fact, I’d argue that the portion of trigonometry that we will cover in this article can be understood intuitively. And soon you shall.

We begin our task by considering the following standard Cartesian coordinate system.

Place a circle with radius 1 at the center of the graph, such that the circle’s center is aligned with the origin of the coordinate plane. This circle is called the unit circle.

Let’s see this circle in greater detail by zooming in on it.

The line that we draw is called the terminal side of our angle. All angles are measure from their initial side (the x-axis) to their terminal side. The angle created in the diagram below is 45 degrees. The green line below intersects the circumference of our circle at a specific point on the coordinate system.

This is true for any line drawn from the origin through any position on the circumference of the circle, as illustrated in the next diagram.

The upshot of all this is that, no matter the angle, given a point along the circumference of a unit circle, we can construct a right triangle, like so.

The terminal side of our angle forms the hypotenuse of our right triangle, and is always equal to 1, as mentioned earlier. The point at which our line crosses the circumference of the circle actually gives us the lengths of the remaining two legs. The x-value of our point equals the length of the leg that lies along the x-axis (“side x”). The y-value of our point corresponds to the length of the leg that lies parallel to the y-axis (‘”side y”).

Armed with the lengths of each leg of our triangle, it’s time to learn about two trigonometrical functions, sine and cosine. These functions will allow us to extract the information necessary to draw objects moving at any angle we want. Both functions take as their argument an angle, but in practice this can be any real number.

Side x of the triangle indicates how much horizontal distance is composed within the hypotenuse. This value is given to us by the cosine function, abbreviated in algebra as “cos”. The y side of the triangle indicates how much vertical distance is composed within the hypotenuse. This value is given to us by the sine function, abbreviated in algebra as “sin”. Together, these values tell us the amount of vertical movement needed and the amount of horizontal movement needed to move at the desired angle for 1 unit. “1 unit” in our case is “1 pixel”.

The sine and cosine functions return numbers between -1 and 1, inclusive. Because of this, using sine and cosine gives us the core of what matters in all this — the direction of the angle without any significant distance (we can’t well represent 77% of one pixel!). Once we have our direction, we can multiply the factors given to us by sine and cosine functions to draw lines.

• Retris screen cast (large version)
• Github repo: http://github.com/angryrabbit/retris/tree/master
• gosu library

There are quite a few missing features, but it’s playable. There are probably a small handful of bugs. I’m only aware of one or two. Both are documented in the readme.

I want to thank Julian Raschke and the other gosu contributors. I love Ruby and it’s awesome to be able to concentrate on my game rather than dick around with low-level details.

As happy as I am that I’ve “finally made a game”, I have to confess, I don’t care for Tetris. I suck at it, too. I wrote it because I read in an old game programming book that Tetris is a good first game.

So what’s next? Well, I have a few things I want to finish up. As Diana Gruber says, “the last 10% of the game takes as long as the first 90%”. Or something like that.

At the very least I need to instate loss conditions. Currently, overflowing the grid simply causes the game to go on a freak rampage, creating shape after shape in the grid’s origin. It doesn’t crash, but you can’t do anything but exit when you reach that point.

I’d also like to put in a menu, pause feature, difficulty levels and a menu.

When those things are done I’ll start to think about another game.

I’d like to point out that I ditched the idea of using a matrix (nested arrays, actually) to model either the grid or shape objects. I made this move for several reasons:

• Nested arrays require some math
• I can’t ask a nested array meaningful questions
• Previous attempts at using nested arrays fell short for me
• It doesn’t feel very object oriented

There’s no doubt in my mind nested arrays are a viable implementation to Tetris, but personally, I prefer objects.

True, I could have wrapped the nested arrays into an object and queried that, but it’s just not decomposed enough for my tastes. My landscape (objectscape?) includes Grid, GridLocation, Cursor, Shape, Location and Block objects to orchestrate the interactions required of Tetris. (There are a few more objects, but the ones I listed are my solution to NOT using nested arrays.)

Similar to my object-oriented solution to the Tower of Hanoi, (portions of) my code read like a story. Stories are easier to grasp than mathematics. At least for now they are. I’ve decided to go back to school primarily for math.

I imagine though, that even as I become more proficient with math, the “stage” my code lives in, and the messages passed back and forth, will remain largely true to my current style.

In fact, if object-oriented programming is really all it’s cracked up to be, my style will only get tighter and more nuanced; only the implementations will change.

Five years from now I just might use an (actual!) matrix object to handle the implementation for Tetris interactions. But, my guess (indeed, my hope) is that the act of sending messages to create a story will remain in force.

Here’s to the human mind.