PlasmaPong

Copyright ©2000-2005 Studio H Software™

Design Specification:

This page is currently under construction. It is basically a repository of my notes on how to implement this iteration of PlasmaPong. There isn't much organization to it at this point because my mind has a tendency to go off in strange directions. So, here' goes...

Main Game Loop:

The goal of the rest of the specification is to be able to have the main part of the Game class more or less exactly as follows:

void run()
{
    while ((ret = update()) !=   LOST)     // update() is what handles the gameplay aspects including 
    {                                      // player controls and the like. No visual processing is
        if (ret == HIT)                    // done here. 
        {
            ++score;
            palettes.set_rand();           // Palettes will most likely be emulated in true color. 
        }                                  // This will allow an arbitrary palette size (2^n, anyway)
 
        // Layers are where the real work is done. Initially, there will be two layers: effects and 
        // distortions. They will be derived from the Layers superclass. Layers do exactly one thing:
        // modify a buffer. Buffer will expose certain interfaces to Layers to allow it to do so.
        for (int i = 0; i < NUM_LAYERS; ++i)
        {
            if (ret == HIT) layers[i].set_rand();
            buffer << layers[i]; 
        }

        buffer.display();
    }
}

The OO nature of this will make it very easy to implement it piece by piece.

General Information:

PlasmaPong will be released under the GNU General Public License. It will use the Pixel Toaster graphics library (the successor to OpenPTC). Although the game is simple enough, it will probably need at least a couple hundred MHz processor because of the software interpolation, especially if I ever decide to use anything other than bilinear filtering. If anyone ever thinks highly enough of this to port it to a 3D accelerator, it would seriously improve its performance. Another note on efficiency: at this point, I am willing to take a performance hit in exchange for the convenience of OOP. If I think of any more General Information, I will add it.

Coding Style:

After much consideration, I have decided to strictly follow the following style conventions. The choices I made came from looking around at many examples of code, and hearing many arguments for and against various styles, as well as my personal experience. Here 'goes.

Identifier Names:

Identifier style can be further broken down into aesthetic style and semantic style. First the aesthetics: all multiple word identifiers will have their words separated by underscores. All constants, macros, and enumeration values will be in all capital letters. All user-defined types, i.e. classes, structs, unions, and enums will have the first letter of each subword capitalized, and the rest lower case (except for abbreviations--see below). All other identifiers including variables (instances of types), functions, class members, and namespaces will be in all lower case letters (except for abbreviations--see below).

Here are some examples:

MAX_PLAYERS, Human_Player, player_1

Now for the semantics. Abbreviations of individual words will be avoided in all but the most trivial or generally accepted cases like loc, len, num, max, min, init, etc. Similarly, choosing fewer words is preferable to abbreviating with initials. Again, generally accepted or obvious abbreviations like RLE, PCX, MMX, etc. will be allowed. As an example, get_pcx is OK, but set_time is preferable to st_tm.

Functions that do not return a value should have exactly one verb in the name. If the name has a verb and an object (in the grammatical sense), it should follow the pattern verb+object. Hence, init_sound will be used instead of sound_init. If a function does more than one task that makes it natural to use two verbs, the function should probably be decomposed. If a function returns a bool, it should always have a verb (like dog.is_animal() or bear.poops_in_woods()). Other

Comments:

Each file will start with a comment (within the #ifndef/#define of header files) formatted thus:

//  FILE: x.x
//  Copyright (C)20xx Studio H Software (TM)
//  
//  AUTHOR: Primary Author(s)
//  DATE: DD-MMM-YYYY
//  VERSION: x.x.x.x
//  
//  This file does this and this and this...
//  
//  This program is free software; you can redistribute it and/or
//  modify it under the terms of the GNU General Public License
//  as published by the Free Software Foundation; either version 2
//  of the License, or (at your option) any later version.
//  
//  This program is distributed in the hope that it will be useful,
//  but WITHOUT ANY WARRANTY; without even the implied warranty of
//  MERCHANTABILITY or FITTNESS FOR A PARTICULAR PURPOSE. See the
//  GNU General Public License for more details.
//  
//  You should have received a copy of the GNU General Public License
//  along with this program; if not, write to the Free Software
//  Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
//  
//  ----------------------------------------------------------------------------

Code Blocks:

Function calls will be written without a space between the function name and the open parenthesis, whereas control statements will have one:

open(some_file);
if (!some_file)
    return 0;

This website is being hosted by:

SourceForge.net Logo