So, I'm programming Tetris at the moment. I researched around on how people approached their design of Tetris. That's when I came upon this article. The one part I got stuck on was the explanation of rotating a piece. It reads:

Next, we compute the new location. Our goal is to keep the center of the falling piece constant (or, given that this is not possible if we have an even number of rows or columns, to keep the center as constant as possible). Keeping the center of the falling piece constant during rotation is the most difficult part of Tetris, so read this part very carefully (though that is always good advice!). Besides making rotation more intuitive, we want to keep the center constant so that if we rotate around and around, the center does not "drift" -- a full 360 degree turn should bring us back to where we started. To meet these conditions, we observe that we just need to adjust the left column and top row of the falling piece by subtracting half of the change in the size of each dimension that results from each turn, where the change in the size of each dimension equals the difference between the number of rows and columns (though you have to think about whether this difference should be positive or negative). Read and re-read the preceding paragraph. Draw pictures. Make sense out of it. When you finally convert it into Java, you will find there are two simple lines that make rotation-about-a-fixed-center work: fallingPieceRow -= <something>; fallingPieceCol -= <something else>;

Doing as he said, I've been writing and drawing stuff for an hour, and I still haven't figured out what he means. Is he referring to subtracting the half of "change in size" from the top left most cell of each piece to keep the center orientated throughout rotations? I'm having trouble wrapping my head around what he meant.

I assumed there was some logic behind it, mainly because what happens when there's a variable set of rows and columns for each piece, aka custom pieces. Normally, it would be easy to say "choose this center block," but I figured he was explaining it because when you do rotate a piece, it ends up in the same spot, but not using like a single cell of the array.

It's pretty hard for a lot of people because it involves Algebra, and we all know that many people prefer to only touch Algebra with a ten foot long stick.

I'll try and explain the situation as best as I can using C++ and SDL as an example, but the problem is the same in any library/language:

First, you might want to try and center the X and Y coordinates of the focus block(the block that's currently falling and you're moving):

int Xcenter;
int Ycenter;

Next, you can try and implement a median (the distance from the center of the focus block to its sides ) like this:

Xcenter -= MEDIAN * 2;
Xcenter += MEDIAN * 2;
Ycenter += MEDIAN * 2;

Then, you can use a coordinate variable (e.g. int x, int y, int x1, int y1, etc.) to call a function (accessor) to return the center of the square, and position it at its origin:

x1 = Xcenter;
y1 = Ycenter;

Then, perform the rotation like follows:

x2 = - y1;
y2 = x1;

Make the necessary adjustments to your control, engine, etc. to change the image in memory of the rotation angle by the 90 degrees or -90 degrees as necessary, and you can get your original location like:

x2 = Xcenter;
y2 = Ycenter;

Of course, there's a bit more to it than just that. You can't expect to rotate an L-block without pre-checking to see if there's a collision at the position, and without not knowing the positions in any sense, or else you'd expect a creepy little bug.

But you said rotation was your problem. The solution I enlisted shows you how to fix a median from a centered image, and then rotate negative or positive, and move around the center of the origin.

Of course, again, someone not being so sufficient in math would probably gain very little from this.

But it's basically a rotation of four 90 degree angles. Whatever you ultimately can put together is up to each person.

If it works, it works. Those are the basic steps. Cleaning up messy code, working on memory use, and fixing small bugs can done progessively through the production, but testing a well-working program always should be satisfactory.

I preferred a source that described the game itself. Search for section 5.3 on this page: Link It helped me a lot.

Indeed. Rotating Tetris pieces doesn't need "general" algorithms, only a table of how each actual piece rotates. It is the heart of the game, and it has to be perfect: for example, if rotating an O piece, an horizontal I piece twice, or a S,Z,L,J,T piece four times in the same direction shifts it left or right we are playing a major variant, not standard Tetris.

Transform matrices might be a good idea (depending on the game engine architecture in use), but they are only useful to implement the desired piece moves, not to design them.

Indeed. Rotating Tetris pieces doesn't need "general" algorithms, only a table of how each actual piece rotates. It is the heart of the game, and it has to be perfect: for example, if rotating an O piece, an horizontal I piece twice, or a S,Z,L,J,T piece four times in the same direction shifts it left or right we are playing a major variant, not standard Tetris.

Transform matrices might be a good idea (depending on the game engine architecture in use), but they are only useful to implement the desired piece moves, not to design them.

Part of my reason for using it was to lay out all the rules and moves and allow me to come up with how I wanted to implement them. The state space is small enough you could just save each rotation and move between them, using checks to see if the new move would be possible or not.

I recently challenged myself to make a tetris game in one day, using XNA. I too spend a lot of time trying to figure out how to rotate the pieces, but I came to the conclusion that it was overkill for such a simple game. I went with hardcoding each possible rotation for the pieces, which isn't that much (Four rotations for L, J and T, Two for S, Z and I, and none for the O).

If you want to calculate rotations because you want to learn how to, it's a good idea- If not, I would consider it overkill.