0.7 The document you read now describes the design of OpenMortal. This page serves as a starting point. The documentation is generated with doxygen (http://doxygen.org).
OpenMortal consists of two main parts: the frontend and the backend.
- The frontend is a C++ program, responsible for multimedia (sounds, music, graphics) and general interaction with the players (menus, keyboard input), and the demo and intro screens.
The classes of OpenMortal are organized into the following groups (see Modules above).
- The backend is written in Perl, and is incorporated into the C++ program with Perl embedding.
These global functions implement important parts of the program. They serve as entry points into functional parts.
Here are the definitions of terms used in this documentation.
Historically two different coding conventions were mixed in OpenMortal. Hopefully most of the old conventions are eliminated by now. Here I will describe the new conventions:
- Player refers to one of the two persons playing the game. A player chooses a fighter. The two players are referred to as "Player 1" and "Player 2", even though the C++ and perl code count arrays from 0.
- Fighter is one of the many available characters. Usually there are only two fighters loaded at any time. Fighters are static: their properties never change. Maybe Fighter should be renamed to Character?
- One game is the part of the program in which the players actually compete. The game consists of a number of rounds. The player selection, and gameover screen are not part of this definition.
- One round starts with both players at full health, and ends either with a timeout or with a ko.
- A graphical element on the game screen that is not the background or the characters. E.g. the "3x combo" text or a thrown projectile are doodads.
- A tint is a methodical change in a palette. There are many ways to tint (e.g. grayscaling, darkening, green chroma, etc). Usually when two players choose the same fighter, the fighter of player 2 is tinted.
- The description of a frozen moment in the course of a game. The Backend is responsible for calculating each consecutive scene. The number of scenes calculated per second is constant (except for the "hurry up mode", or if the computer is too slow).
- Frames Per Second. The FPS indicator on the screen during a game indicates the number of scenes drawn, not the number of scenes calculated by the backend.
The prefixes used are:
- Class names: CMixedCaps.
- Struct names: SMixedCaps.
- Typedef names: CSomeTypedef (There's some traces of the old TSomeTypedef left, these should be eliminated.
- Enum names: SomeThingEnum.
- Enum values: Prefix_ENUM_VALUE
- Method names: MixedCaps.
- Variable names: <prefix>VariableName.
- Instance property names: m_<prefix>VariableName,
- Class property names (a.k.a. static class variables): mg_<prefix>VariableName.
- Method argument names: a_<prefix>VariableName. If a reference or pointer argument is "output-only: a_<prefix>OutVariableName.
- Global variable names: g_<prefix>VariableName.
- Array of something: a<something>
- Pointer to something: p<something>
- Reference of something: r<something>
- Basic types: Integer: i; char: c; double: d; enum: en; object (class or struct): o; std::string: s;
CSomeExampleClass: public CSomeBaseClass
void SomeMethod( int& a_riOutSomething );
static enum SomeThingEnum