Difference between revisions of "Aaron's Independent Study"

From Earlham CS Department
Jump to navigation Jump to search
(→‎Global constants)
 
(11 intermediate revisions by the same user not shown)
Line 5: Line 5:
 
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 .
 
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 .
  
−
= Code description =
 
−
Computer City:  Sewers' Code is written in C++ using a hierarchy of classes:
 
−
* Object -- contains information to display an object graphically using OpenGL.
 
−
** Avatar -- subclass of the Object class.  Represents the player-controlled object.  A blue-green figure that walks around the screen, interacting with other objects.  Named "Bitty" when speaking of the game's narrative elements. 
 
−
** Entrance -- subclass of the Object class.  Representation of how the player entered the current room.  If the current room is the first room, the entrance is a ladder (Bitty climbed down into the Sewer), otherwise it is a doorway.
 
−
** Computer -- subclass of the Object class.  A computer located in the top-right corner of the room that turns on once the current room's puzzle has been solved, at which point the avatar can interact with it.  In interacting with this computer, the player fills out a truth table for the current room.  If the player fills out the table correctly, he/she receives a blueprint, which just increases the player's score for now.
 
−
** CircuitObject -- subclass of the Object class.  Can be linked together in a "circuit" with other CircuitObjects.  Circuits are loaded from a circuit file (*.sew)  A CircuitObject contains 0, 1, or 2 inputs and 0 or 1 outputs.  It determines its output based on its inputs and the type of object it is (for example, a NOT gate performs a logical negation on its input to produce its output).
 
−
*** Switch -- subclass of the CircuitObject class.  Has 0 inputs and 1 output.  Its output is loaded from a circuit file.  Has an optional button, which can be flipped by the player to change the output value
 
−
* GameEngine -- contains data corresponding to a "room," which can be thought of as a "level" in the game.  The room is a collection of Objects (see below), some of which are grouped into a circuit (see CircuitObject below)
 
  
  
Line 42: Line 33:
 
* s - down
 
* s - down
 
* d - right
 
* d - right
 +
* f - action button -- behavior depends on which object the avatar is next to
 +
* q - quit
  
−
== Tasks ==
+
== Notes on style ==
−
Here are some of the things that the game needs.  I've broken them down into small, medium, and big based on how long I think they'll take.  Let me know if you'd like a better description of any of these, or if you have other ideas!
+
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).
  
−
'''Small'''
+
=== Variable names ===
−
# Implement a counter for number of rooms completed
+
* 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.
−
# Implement a counter for number of blueprints collected
+
* I use all lower case names, with underscores used for whitespace (as in `num_spaces').  The exception is global constants (see below)
−
# Implement a counter for number of steps taken in a room
+
 
−
# Make a function to detect whether the avatar is next to an object (rather than intersecting it)
+
=== classes ===
−
# <s>Fix 'f' so it doesn't always implement truth table</s>
+
* For classes, I use CamelCase, and start with capital letters (e.g. CircuitObject)
−
'''Medium'''
+
 
−
# Get a mechanism working for saving and loading game states.  This will likely take place in the file GameEngine.cpp.
+
=== Member variables ===
−
# Right now there is a mechanism in place for loading a "room file", which describes the circuit of a given room (e.g. Room1.sew).  Get a mechanism working to load a series of rooms as the player progresses through the game.
+
* 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.
−
# <s>Fix the bug on Linux that places the gates on top of each other rather than spread out</s> Fixed -- uninitialized variable
+
 
−
# Implement a timer to record how long it takes a player to complete a room
+
=== Global constants ===
−
# Implement an interface to allow the player to change game controls -- e.g. movement speed and keyboard controls
+
* These are declared in the file globals.hpp
−
# Implement a help button interface -- if the player pushes the help button, a small description appears of any objects the avatar is next to
+
* I follow the convention of declaring global constants in ALL CAPS, with (_) to represent whitespace (e.g. WALL_WIDTH).
−
'''Big'''
+
 
−
# Evaluate the code's simplicity, clarity, and generality and suggest/implement corrections to this
+
=== Const member functions ===
−
# I envisioned the player interacting with the computer in the top right corner of the room as follows:  when the player completes the room, a truth table of the room is presented to the player to be filled out.  Get this interface working or come up with a better one.
+
* 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.

Latest revision as of 15:56, 1 April 2010

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
  • 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)

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.

Global constants

  • These are declared in the file globals.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.
Retrieved from "https://wiki.cs.earlham.edu/index.php?title=Aaron%27s_Independent_Study&oldid=10961"