Some technology behind Tetris-Power
Feb. 19th, 2010 11:03 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
carlfoxmartenTo help me get more interested in starting up work again on Tetris-Power, I've decided to compile a list of all the modules I've written so far and what they do and support.
In no particular order:
Fonts module:
Loads, stores, and renders bitmapped fonts. This means that I can't scale the fonts on the fly, which might be important.
Grid module:
Contains two classes, a GridBit (a small 1x1 block) and a Grid to contain the GridBits. This is separated because it's generally good style, and there will (eventually) be quite a lot of code in here. So far, it works, but will need tweaking a bit later on when I add powerups.
Screen module:
Maintains the screen stack and controls which screens are visible at the moment, which screens get input events, etc., as well as a Screen class that screens subclass to get displayed.
Screens come in two types: Transparent and opaque. Transparent screens are used for stuff like dialogs and small menus, while opaque screens are used for everything else.
Main Menu module:
I've put each implemented Screen in its own module to keep things nice and separate (also because I started my Object-Oriented programming with Java, which liked each class to be in its own file). The Main Menu module implements the main menu of the game, which you see when you start the game and when your game is over.
Splash module:
The splash screen for the game. This interfaces with the loading system a bit so I can show a progress bar of how loaded the game is. After loading is complete, any input to the screen (either mouse click or key press) drops us down to the main menu.
Widget module:
Contains a number of widgets (such as buttons, labels, panels, progress bars, "floaty labels" (labels that move upwards after creation. Used for score indication), and spinners (for numbers or options).
Score module:
Stores, retrieves and displays the current high scores. I'm not finished this module yet, I'm trying to figure out how to use SQLite for storing and retrieving data.
(the display part is done by yet another Screen)
Shapes module:
Reads a set of block shapes from a file, and allows selection of a random next block. Handles dynamic storage of all information about a particular block, including colour, position, etc., as well as rendering and reacting to controls.
Play module:
The main play Screen. This instantiates many classes used during gameplay, such as a Grid, a few Shapes, a Control system for customizable controls, and will eventually handle levels of play.
Mesh module:
Handles loading, dynamic storage, and rendering of meshes. Currently, I only support Wavefront Object files for loading from (as it's all I've needed so far), but it will need to be improved a bit, due to a lack of capabilities for putting more than one texture on a mesh.
Texture module:
Handles loading, storing on the graphics card, and selection of textures for OpenGL rendering. I'm using SDL's Image library for loading images, so a fairly large array of image types can be loaded. Also included are a couple of runtime-generated textures, such as a black-and-white checker board and curves (intended for curved borders on widgets, but needs lots more work).
Common module:
Generic dropping-ground for tons of random important stuff. Some of the stuff included are Colours, 3D Positions, OpenGL Lights, Bezier curve classes, Cameras, custom draw functions for cubes, functions to get random numbers, string handling functions not covered by the system libraries, drawing 2D rectangles, rounded or otherwise, and some important global variables, such as commonly-used fonts.
As it stands, the game barely works. But that does NOT mean it is complete.
A small list of things to add:
It's also looking like I might need to switch to a more event-driven approach sometime, as what I'm currently doing will require a fair bit of work to connect certain things together.
In no particular order:
Fonts module:
Loads, stores, and renders bitmapped fonts. This means that I can't scale the fonts on the fly, which might be important.
Grid module:
Contains two classes, a GridBit (a small 1x1 block) and a Grid to contain the GridBits. This is separated because it's generally good style, and there will (eventually) be quite a lot of code in here. So far, it works, but will need tweaking a bit later on when I add powerups.
Screen module:
Maintains the screen stack and controls which screens are visible at the moment, which screens get input events, etc., as well as a Screen class that screens subclass to get displayed.
Screens come in two types: Transparent and opaque. Transparent screens are used for stuff like dialogs and small menus, while opaque screens are used for everything else.
Main Menu module:
I've put each implemented Screen in its own module to keep things nice and separate (also because I started my Object-Oriented programming with Java, which liked each class to be in its own file). The Main Menu module implements the main menu of the game, which you see when you start the game and when your game is over.
Splash module:
The splash screen for the game. This interfaces with the loading system a bit so I can show a progress bar of how loaded the game is. After loading is complete, any input to the screen (either mouse click or key press) drops us down to the main menu.
Widget module:
Contains a number of widgets (such as buttons, labels, panels, progress bars, "floaty labels" (labels that move upwards after creation. Used for score indication), and spinners (for numbers or options).
Score module:
Stores, retrieves and displays the current high scores. I'm not finished this module yet, I'm trying to figure out how to use SQLite for storing and retrieving data.
(the display part is done by yet another Screen)
Shapes module:
Reads a set of block shapes from a file, and allows selection of a random next block. Handles dynamic storage of all information about a particular block, including colour, position, etc., as well as rendering and reacting to controls.
Play module:
The main play Screen. This instantiates many classes used during gameplay, such as a Grid, a few Shapes, a Control system for customizable controls, and will eventually handle levels of play.
Mesh module:
Handles loading, dynamic storage, and rendering of meshes. Currently, I only support Wavefront Object files for loading from (as it's all I've needed so far), but it will need to be improved a bit, due to a lack of capabilities for putting more than one texture on a mesh.
Texture module:
Handles loading, storing on the graphics card, and selection of textures for OpenGL rendering. I'm using SDL's Image library for loading images, so a fairly large array of image types can be loaded. Also included are a couple of runtime-generated textures, such as a black-and-white checker board and curves (intended for curved borders on widgets, but needs lots more work).
Common module:
Generic dropping-ground for tons of random important stuff. Some of the stuff included are Colours, 3D Positions, OpenGL Lights, Bezier curve classes, Cameras, custom draw functions for cubes, functions to get random numbers, string handling functions not covered by the system libraries, drawing 2D rectangles, rounded or otherwise, and some important global variables, such as commonly-used fonts.
As it stands, the game barely works. But that does NOT mean it is complete.
A small list of things to add:
- Background during gameplay. This would help indicate the current level of difficulty. I currently envision trees, hills, bushes, and stuff for the earlier levels and moving towards either more desolate places with cliffs, waterfalls, and the like or more populated stuff such as towns and cities. Right now it's a toss up, as I don't even have a mechanism for doing anything of the sort yet.
- Powerups. I have a list of them I want to add, and adding them would touch a very large range of places, but such is the price of adding such things.
- Sounds. Right now, it's completely silent. Adding sounds would greatly enhance play, I just have to figure out how to code for them, and what sounds to use for what.
- Levels of difficulty. Right now, it's all one level, and fairly easy at that. A good player could play for quite a long time, if they didn't get bored first.
- Multiple game modes. While this will require a great deal of work to get right, the results will probably be worth it. Will probably include modes like timed (get the most points in a given amount of time), endurance (play as long as you can and rack up as high a score as possible), and score target (reach or pass a given score in the fastest time possible).
- Initial difficulty level. Right now, all games start off fairly easy. However, really good players will probably want to start playing at a higher level of difficulty.
It's also looking like I might need to switch to a more event-driven approach sometime, as what I'm currently doing will require a fair bit of work to connect certain things together.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2010-02-21 03:13 am (UTC)no subject
Date: 2010-02-21 10:12 am (UTC)Even writing software in languages such as Java (as opposed to C++ in this case), there's a huge amount of code already written for you so you don't have to reinvent the wheel.
However, in this case I chose to write much of the code myself. A couple reasons are: So I don't have to learn someone else's code, and So I learn just how much code really does go into these projects.
(quite a lot of code. I'm actually kind of surprised)