1. Development Tools

2. Programming Convention

3. Collaboration Tools

4. Priority

1. Development Tools:

At the moment, CGD is mainly programming games in C++ using the 2D cross-platform development library, SDL 2.0. Our main focus is on computer games for Windows and Mac OS X (possibly Linux if there are members who use the operating system). Porting to mobile devices is a possibility but is not the primary objective of CGD. Game textures are PNG formatted, fonts are TTF or OTF formatted, music are WAVE, MOD, MIDI, MP3, OGG, or FLAC formatted, and sound effects are WAVE, AIFF, RIFF, OGG, or VOC formatted. The links below provides tutorials on using SDL 2.0 and how to install it.

USEFUL TOOLS:

• C++ Check – free tool for detecting the types of bugs that compilers normally does not detect
• Visual Studio Code Analysis
  1. Right click “Solution” and open up the “Properties”
  2. Go to the “Code Analysis Settings” and set the rules (i.e. Microsoft All Rules)
  3. Go to the “Analyze” drop down menu at the top and click on “Run Code Analysis on Solution”
• Visual Studio Performance Wizard
  1. Go to the “Analyze” drop down menu and click “Launch Performance Wizard”
  2. From here you can choose to “CPU sampling”, “Instrumentation”, “.NET memory allocation”, “Resource contention data”
     • For optimizing code, analyze the instrumentation results and see which functions are taking up a lot of time

The SDL library provides low-level access to game assets but doesn’t provide much of a template to work off of. So, we’ll be using a small template for the club to use collaboratively; or if you’d like you can create your own template, but if you do make sure to have some kind of documentation (separately or in the template) that tells users how the template actually works. The template will help you get started on programming SDL games more quickly than having you learn how to use the entire SDL library (College students are busy, right). However, it is still recommended that you read the tutorials since it will help you better understand the template.

The template is on Bitbucket which you can pull using SourceTree (read 3. Collaboration Tools)

After you pull the template, don’t alter it. Just make a copy of the template and use the Project Renamer.py script to rename the project to whatever you want.

You should be able to compile and run right away without any problems if you use the template. But if you encounter any errors please contact CGD President.

SDL 2.0 Tutorials

2. Programming Convention:

It is highly recommended and urged that all of our programmers use the programming convention written below; it will definitely aid your collaborative programming experience.

Classes and Structs:

• Identifiers in Pascal Case (e.g. class MyClass)
• Abstract base class identifiers start with an I (e.g. class IBaseClass)

Functions:

• Identifiers in Pascal Case (e.g. void MyFunction())
• R_
  • void R_MyFunction() : This function is reserved for a specific use  (e.g. helper functions)

Variables:

• Identifiers in Camel Case (e.g. int myVariable)
• Constant variables in All Caps (e.g. const int CONSTANT)
• header
  • headerVariable : For global variables located in header files (since these variables can be used in other files) start the name of the variable with the header name in camel case. This will reduce variable name conflicts when collaborating with other people.
• m
  • mVariable : The variable is a private/protected data member of a class  (public variables do not have the m and neither do private/protected constant variables)
• i
  • iVariable : The variable is an initializer, this is mostly used for class constructors where the arguments in the parameter and public data members have similar identifiers
• d
  • dVariable : The variable is a transformer (e.g. add/subtract), this is mostly used for functions that add the argument to an exisiting data member
• n
  • nVariable : The variable is a replacement, this is mostly used for functions where the data members are being replaced by the arguments
• g
  • gVariable : The variable is a global variable BUT is used by the template for a specific purpose and SHOULD NOT be modified. (In general just don’t use them for anything unless you know what it’s used for and how it works)
• r
  • rVariable: The variable is reserved for a specific use

Enumerations:

• Identifiers in Pascal Case (e.g. enum MyEnum)
• An E at front of the identifier (e.g. enum EColor) is optional but will mean that the identifier is an enum
• Integer identifiers in All Caps (e.g. CONSTANTS)

Pointers:

• Same conventions as variables
• //DESTRUCTOR:
  • //DESTRUCTOR: ~Game() : (NON-LOCAL POINTERS ONLY e.g. data members) This comment is used to give indication as to where the pointer will be deleted; this will be useful for when you are checking for memory leaks
  • Some pointers might not have a destructor (e.g. int *x = &y; [the y is still being used somewhere else]), if that is the case write //DESTRUCTOR: NONE

3. Collaboration Tools

CGD currently uses Bitbucket and Source Tree (you can also use command line instead of Source Tree) for collaborative programming. You can go to https://bitbucket.org/ to create an account and install Source Tree. When a project begins all programmers will be given write access to the project repository by the Project Manager or Lead Programmer. Look through the tutorials below to familiarize yourself with Bitbucket and Source Tree (or command line).

Tutorials

The ones you should definitely understand are branch, checkout, commit, push, and pull. Merges will usually be done by the Project Manager or Lead Programmer. Whenever you work on any code always be sure to create a separate branch. DO NOT edit/write the master branch code a.k.a trunk (the master branch is where you branch off from and merge into). After finishing any of your code make sure to commit and push. If you feel that your code works and is ready to be merged into the trunk of the program, go to the Bitbucket site and create a pull request to the master branch. For merging multiple branches that are yours and not the master branch, you can do that without having to create pull requests. However, MAKE SURE before submitting a pull request to the master branch that your code works with the existing master branch code.

There are some options in Source Tree that you can set to make collaborative development better.

Remote Branch Update: This will allow you to see on Source Tree if there are any new repository updates that need to be pulled.

Options->General

->Check default remotes for updates every # minutes

I would suggest using a small number (1 min) so that you can constant updates on changes. Also make sure to set:

Repository->Repository Settings->Advanced

->Refresh remote status in the background

Auto Push after Commit: This setting will make it so that when you commit your files they will be automatically pushed to the default/origin remote.

Options->General

->Push to default/origin remote when committing

One thing not included in SourceTree is an external diff program. However, in the options you can set what diff program to use. But you’ll have to install one first such as DiffMerge.

4. Priority

1. Meet your assigned deadline (Make sure your code works; this only applies when creating a pull request into the master branch)
2. Your code should be flexible to changes and as independent of other components as it can be (to the best of your ability)
3. Optimize your code to be efficient (to the best of your ability)