I wanted to get the game done by today, but I didn’t. Instead, enjoy the current build. Move piece with arrow keys, rotate with z and x. Press 1 once you’re seeing the game board to get pieces moving.
Detritus build – 20120405
It’s still very incomplete, but on the off chance you heard about this from me at PAX East, you can get an idea of what’s in place so far.
The modifications to change the array indexing to have 0 at the bottom instead of the top have been implemented. It took a bit of finagling with the draw code because 0,0 is going to be in the top left whether I like it or not. So for the board drawing, I subtracted the current amount from the drawable height, then adjusted up equal to the height of the sprite to adjust it into the original position. I suppose another choice would have been to change what the origin point of the sprite was, but that seemed like trouble. Importantly, things can now go off the top without causing a crash, although they end up piling up in a fabulous disco mess.
Other changes: code to drop faster when a key is held was added about a week ago that I neglected to post about. The method to detect lines was added, but the update loop currently doesn’t do anything with the result of that method. It returns an array of ints, with each item corresponding to a row that has a complete line. An empty array means no complete lines.
Getting rid of lines comes next. Until then, enjoy my fabulous disco mess.
a fabulous disco mess at the top of the screen
After finishing the function that checks for completed lines, I realized I had made a small but annoying mistake in my code. In the array that stores the current board, I had made 0 represent the top of the screen and the maximum index represent the bottom. This presents the issue of new pieces existing in negative indices. This is normally not a problem, as pieces only become part of the board once they stop moving. However, this would require me to do some unnecessarily complicated work when a piece wants to lock to a position that goes off the top of the screen. This is complicated further by the fact that it is possible such a piece could complete lines, lowering the piece to be within the boundaries of the board, thereby not resulting in the usual out-of-bounds conditions to be met. The solution I have chosen is to flip the board: 0 now represents the bottom of the screen, the maximum index is increased to allow for space off the board, but when drawing or checking for out of bounds, I can get a board height attribute from the board object to see what value I should be comparing against.
The code is at a point where everything compiles and all completed features work properly, so I at least have a good baseline of functionality to meet with this recoding effort.
I’ve implemented piece rotation. Pieces can be rotated clockwise and counterclockwise. No other directions of rotation are possible. However, there are some rule choices that were made while implementing rotation that I should mention:
These decisions were made more or less arbitrarily, but they are the decisions I’m going to stick with until all the basic features are implemented and testing begins. If any of them really mess with the testers, I’ll think about changing them up, but it’s not something I’m going to be thinking about right now.
Still to do: detecting and clearing lines, dropping pieces faster, detecting when pieces have gone off the top of the screen.
Updated game screenshot
Block rotation: sweeping through blocks while rotating is okay, kicking off the wall is okay, kicking off the floor or other blocks is not okay.
Thanks to the occupied-square-calculating utility method, I was able to remove a lot of redundant code. Furthermore, more handling code has moved out of my Screen class and into my Board class. To this end, I added some try-and-do-a-thing methods to my Board class. They all return true if the thing that was attempted, such as “move the current piece left,” was successful. Otherwise, they return false. This has me at the point where I am randomly generating pieces, I can move them left and right (but not outside of the board or into other pieces), and they stop when they hit the bottom or another piece. Also, I noticed that the pieces weren’t actually stopping when the game was paused, so I fixed that as well. Next up is adding the tryRotateClockwise and tryRotateCounterclockwise methods to have full block manipulation functionality. I may also add support for the down arrow key as a drop button to facilitate some testing. Oh, and maybe do something about the fact that certain block types begin their life outside the visible area.
When I opened up the old edit-box this morning, I realized that I had conveniently forgotten to add the S, Z, and O pieces in my utility method. Whoops! This has been rectified. While adding in these cases, I noticed an interesting pattern. Based on the default rotations I had chosen for the L and S pieces, only one block was different between the two. The “extra” block that made up the long bit of the L piece moved to become adjacent to the other arm of the L piece, and in the S piece, it pointed the opposite direction that it had been pointing in the L piece. The same was true of the J and Z pieces. It makes more sense if I show you a picture of it.
L-S piece relationship
Realized that I had code in three places that calculated the spaces occupied by a piece given the piece type, its center coordinates, and its rotation. So, I made a general method in the gameBoard class that returned the spaces occupied by the currently falling piece. If need be, I’ll overload it to take piece type, coordinates, and rotation as arguments, but so far I’ve only ever cared about the currently falling piece, so the function takes no arguments.
Didn’t get nearly as much done this weekend as I would’ve hoped to, but what I do have is some debug methods that will spawn a block of a chosen type at the top of the screen. I can rotate it, and it falls over time. Still need to add in moving it horizontally, and colliding with the bottom and stopping. After that, probably also checking for collisions with other pieces, both when falling and when responding to user input for movement and rotation.
Geometer is 1. bad and 2. too complicated, so until I can fix the first one and develop my skills enough to handle the second, it’s on hiatus. Not posting about it since August is also an indication as such. So what am I doing instead? Excellent question! The answer is: a different, much simpler puzzle game! It is called Detritus. Well, it’s also barely even a game, for reasons that will be clearer when it is done, and the magic is kind of lost if I give away too much about it. However, giving a screenshot shouldn’t spoil the surprise.
Found some great code to steal for screen management, so I’ve been mucking around with it to get the hang of how it works. The plan is to refactor what I’ve got so far to use these fabulous new classes. After that, I’ve got some options, and some options about those options, depending.