I think it's good that you're working through some design before starting to code. Also, I can confirm that's quite a lot of questions [smile]
But hey, remember that it can greatly help realizing how things can be done by coding short prototypes for the parts you're not sure about, to see how they work and can fit together.

Quote:Original post by JBS103
If I decided that I wanted to make a Tetris clone using OpenGL (2D), would I create each falling block out of squares and then texture each of them?

That's a good idea, OpenGL is capable of rendering textured squares/quads. Also think about how you want to move the blocks. OpenGL provides functions for moving subsequently rendered geometries, like glTranslate and glRotate. This means each block can have a single position to translate to, and an angle of rotation (for example about the z-axis). It's also possible to move the coordinates of the squares or rotate them about their center (using sin and cos functions) before sending the coordinates to the rendering calls. For a Tetris-like game which method to use is a matter of preference, rotating the coordinates yourself is intuitive (and you can use them for collision detection), if you want to hide the calculations the OpenGL functions can be used instead.

Quote:Original post by JBS103
Should each block be created out of a class that also has control of its display, texturing, and rotation?

It depends a bit on how you decide to go about the last question, if you move and rotate the coordinates yourself, then it'll make the code much cleaner if this is done encapsulated in a block class. Textures should be stored centrally (loaded once) to save texture memory, so a centralized render class that stores textures and sets OpenGL states is useful. Also, since OpenGL is state-based, meaning if a state like lighting is set when displaying one block, it'll remain when displaying the next block, if the display is made in a block class, it has to "clean up" states. Personally I would go for the centralized renderer, mostly because the rendering code can be changed under the hood without having to go through different block classes. For this game, you can have a function in the renderer like DisplayBlock that takes a reference to the block to display, gets it position/rotation/coordinates and type to determine texture. The function can be called for each visible block in the game loop.

Quote:Original post by JBS103
How should I store each individual block layout?

A fixed-size two-dimensional array, the Tetris clone in an hour topic shows this well in the NewBlock function.

Quote:Original post by JBS103
In terms of laying out the entire game, can I put all of the game functions within one "umbrella" class? I was thinking a general game class could be used to initialize, loop, keep score, restart and quit the game.

I agree, you can break up the initialization functions to within the objects being initialized. For example, the game class can decide when to initialize all blocks but the block class decides what an initialized block is like (size and rotation for example). game.Initialize calls block.Initialize (actually, constructor stuff). If the game class requires a specific set-up of the blocks, it can do this after the visible blocks have been individually initialized.

If you have a centralized renderer, the game class ties the visible blocks (passes on their data) to render to the renderer. The Loop function will do a lot, maybe more than the Initialize function, so to avoid code overflow (generally bad for the brain [grin]) break it up into smaller functions. To mention some examples; GetInput, MoveBlocks, CollideBlocks, UpdateScore, RenderBlocks.

In a Tetris-like game there are two important types of collision detection. Collision detection to detect if objects collides (touches) should be done at the moment of movement in the fashion "can this block move to there without overlapping any block that's there?". Collision detection to detect if colliding blocks changes score should be done when all the blocks have moved to detect the complete game state. If using a single block class, individual blocks don't know about each other, in that case collision detection should be done outside, in the game class. Another possibility, is that you to have a block supervisor class that holds all blocks and detects collisions between them, if you want more layers of abstraction, but don't over-complicate it!

Quote:Original post by JBS103
Am I correct to assume that the Win API opens and creates the window while OpenGL deals with what goes inside of it?

Yes, OpenGL is a graphics library only, it gets dedicated access to render graphics inside the gray client area of a window.

Lastly, I want to mention that these are opinions from my experiences, so like any solution it's not universal. And hey, good luck, it seems that you're on the right track!