Sane

He would be spending the majority of his time reading and researching mathematical algorithms, such as Newton's method of approximation. There's not very much value there as a programming excercise. The making-your-own-language part is too advanced for most people here, forget an intermediate programmer.

slicksk8te

it seems that that could be a nice goal because I just recently perfected a line drawing alogorithim in one of my programs, but I think that I will probrably try to do the tic tac toe game first. I am thinking about tetris as well but I am not sure how to implement the basic gameplay of the game.

lectricpharaoh

Tetris gameplay is actually quite simple. If you're familiar with basic OOP techniques, it's really quite easy, depending on your approach. I'll describe how I did it.

The heart of the game was a 'block' class, an instance of which described a single block (ie a piece within a 4x4 grid, not a single square). The data members described which piece it was (there being seven in standard Tetris, with each being represented with some data structure, like a bitmap or 4x4 array to hold the 'shape'), what the rotation was (0-3, corresponding to rotations of 0, 90, 180, and 270 degrees), and the location within the larger play grid. This larger grid is a simple 2D array representing the squares of the play field, and what they are filled with (if anything).

Of course, you also need methods to do things, like rotate and move the blocks, as well as check for collisions. When a block attempts to move, I created a new block using a private constructor that allowed me to control all aspects of its creation (ie, position, rotation, and shape, rather than just shape, with a default 'top of the play field' positioning). The new block is created with the positioning and rotation that the existing block is trying to achieve. Thus, if I'm trying to move a block left, I create a new block that's identical to the existing one, except one square to the left. I then call the collision-detection method, which 'superimposes' the block over the play field, and detects if there is a collision. This boils down to a range check for the side and bottom edges of the field, and an iterative check for each square occupied by the piece. If a collision results from a sideways move or a rotation, the operation is prevented. If it results from a downwards move, the piece 'lands', which sets the appropriate squares of the play field, and also clears the 'moving' flag for the piece. In the main game loop, pieces are spawned, and live in an inner loop that handles user input. It looks like this in pseudocode:When a piece lands, you check to see if any lines were completed (you only need to check the ones that the piece could possibly complete, meaning four lines at most, depending on the piece and its rotation). If any were completed, you remove them and update the game field, along with any secondary effects (scoring, playing sounds, etc).

You can handle the drawing of the pieces in numerous ways. One way is for the block class to be entirely responsible; since it knows about the game grid and such, this makes sense. Of course, a more flexible way is to let the block class do it indirectly through a function pointer. This would be a static member of the block class, and you fill it in upon initializing the game. The benefit of this approach is that it lets you customize the drawing with ease. Parameters passed to this function would include things such as a single square's position (relative to the game grid), and the 'fill type' of the square (empty, solid, what color, etc). You could do all your updating with this function, but as it might flicker for larger updates (such as when lines were completed and removed, and the game field adjusted by the lines above 'falling down'), you could write optimized routines for those situations as well. They'd probably equate to a blit from one area of the game field to another.

There were also some members to control the speed of various things, like how fast the piece could fall, rotate, or move; these were used in conjunction with an incrementing timer to limit the speeds involved. For example, if you want to limit rotation to once every x 'ticks' of the timer, you set the rotation ticker to x plus the current time 'ticks' value inside the rotation methods upon a successful rotate. You also check to see if the current 'ticks' value is less than the rotation ticker before allowing a rotation.

Anyways, hopefully this has been enough to give you some ideas, if you're interested in writing a Tetris clone. Note that this isn't the only, or even necessarily the best, way to do it. It's just how I happened to do it, and I figured I'd share.

__________________
And once again, Probability proves itself willing to sneak into a back alley and service Drama as would a copper-piece harlot.
- Vaarsuvius, Order of the Stick

slicksk8te

Thanks for the help. This is a good next step for puting my new shape drawing functions to use. This is very helpful and I hope to get started on it within the next few days.

hunter123

read

hunter123

read read and read

slicksk8te

ok that is not helpful at all.

hunter123

im sorrry wrong thread to comment to.