Aaron's Independent Study

For my senior project I have been developing an educational computer game to teach digital logic, specifically the interactions of logical switches and gates. The working title is "Computer City: Sewers," since the game takes place in the lowest level of a city ( corresponding to digital logic, which is conceptually the lowest level of the computer architecture ). The game is puzzle-based and is written in C++ with the OpenGL API.

The game's source is available at http://github.com/amweeden06/SRSem-Project-2009/tree/master/Source/

I welcome any contributions to my project. See the directions below for instructions on how to do so, and my suggestions for adding to the game. Any questions, send email to amweeden06 at earlham dot edu .

Contributing to the project

Getting Started

github is the source code control of choice for this project. Below are the instructions for downloading the source code from github:

1. Set up an account at github (it's free)
2. Let me know your username once you have created an account so I can add you to the contributors list (send email to amweeden06 at earlham dot edu)
3. On a shell, type the following:

$ mkdir Sewers
$ cd Sewers
$ git init
$ git config user.name <your git username>
$ git config user.email <your email>
$ git remote add origin git@github.com:amweeden06/SRSem-Project-2009.git
$ git pull origin master
$ cd Source/ACL

1. You should now be in the directory with the source code. To build, type

$ make

1. This will make an executable called Sewers. To run, type

$ ./Sewers

Playing

Key commands

• w - up
• a - left
• s - down
• d - right
• f - action button -- behavior depends on which object the avatar is next to
• i - save -- save the current game state (avatar position and switch values)
• u - load -- load game state from a file
• h - help -- get information about the current game situation (description of objects)
• o - options menu -- change these key commands
• q - quit

Notes on style

The following are stylistic conventions that I would ask you to conform to as you make changes to the program. This will help improve overall readability. Any questions, comments, or suggestions with regard to style decisions can certainly be directed to me via email (amweeden06 at earlham dot edu).

Variable names

• I use variable names that are as descriptive and short (in that order) as possible. For example, I prefer `num_inputs' to `n'. The exception are local variables that are used quickly, and for-loop indices.
• I use all lower case names, with underscores used for whitespace (as in `num_spaces'). The exception is global constants (see below)

classes

• For classes, I use CamelCase, and start with capital letters (e.g. CircuitObject)
• Each class should have a default constructor and a copy constructor (see Object.hpp for an example). If a default constructor is used, any parameters that can be passed to it should have default values in the header file. For example:

Object(string type = "");

• If applicable, each class should have an extraction operator '<<', so that all of the relevant information of an instantiation of the class can be obtained by simply saying cout << classname << endl;

Member variables

• I follow the convention of putting an underscore (_) at the beginning of private member variable names to help distinguish them from local or public variables.
• Each member variable should be given an accessor (a constant member function that just returns the variable) and a mutator (which assigns the variable the value passed by a parameter), except for vectors and classes. Vectors should have an accessor that takes a size_t and returns the element at that position in the vector)
• If a member variable is to be changed, I always do it with a mutator, never directly (e.g. set_value(1); rather than _value = 1;)
• If a member variable is to be used, I always do it with an accessor, never directly (e.g. new_val = value(); rather than new_val = _value;

Global constants

• These are declared in the file constants.hpp
• I follow the convention of declaring global constants in ALL CAPS, with (_) to represent whitespace (e.g. WALL_WIDTH).

Const member functions

• Any function that does not modify a class's member variables should be declared as const.

Indenting, whitespace, and bracing

• I use 4 spaces for indent.
• I use this style of bracing:

int main()
{
...
}

Comments

• Wherever possible, I like to put a comment per line of code. I find this greatly improves readability.
• Functions should list their preconditions and postconditions.