Fundamentals of Software Engineering


Lab Image
Today's goal: Get familiar with labs for this course, and software engineering practices in C++. Read all of the directions. Find your partner in the spreadsheet here


Description


We want to get in the habit of writing code that can be used over and over again and is well formed. Remember, we are building game engines and trying to solve problems that we will run into over and over again. In today's lab you will refresh on some important practices for building software.

Your Task(s)

  1. Game Programming Tools
  2. Setting up SDL in C++
  3. Code Style
  4. Write Object-Oriented Code in C++

Files Given/Starter Code

  • Clicking the following link gives you immediate access to your github repository.
    • You may use your personal or Northeastern github account. I do not care, but please be consistent with what you choose.
    • Please do not click until class starts. Occasionally I make changes until a few minutes before class (usually spelling corrections and other small typos).
    • Click now: https://classroom.github.com/a/5F6Ea-PG

1. Game Programming Tools


Subversion - Familiarize yourself with git

Complete: An interactive tutorial on Git in 15 minutes (especially if you have never used git!).

Additional notes: Some things to know are that git is not the only source control system in town. In fact, in the games industry, there are revision systems more popular, and even explicitly designed for managing game assets. For instance, what do you think git is really good at? Take a moment to think. The answer is: that it is very good at managing text based assets. With that in mind, there are other tools.

  • Perforce - Historically has had better performance working with large repositories, and has useful tools for working with non-text assets (a.k.a binary files) that make it more appealing. Youtube has many videos on perforce [ Prince of Persia and Perforce]
  • Alienbrain - Version control designed explicitly for the game industry.
  • A decent summary of other subversions lives here.

The C++ Compiler

The C++ compiler is one of our most important tools. It does the hard work of compiling our C++ code down to assembly (and then the assembler creates object files, and finally we link everything together to build an executable). Something we want to be careful about when discussing the compiler, is what it does and does not 'magically' do for us. The C++ Standard is the sort of 'all knowing' source of what information is correct. A link to a version of the C++14 standard is here . Reading the standard for the purpose of this course is not necessary, but I do want to bring up some best practices.

    What does the compiler automatically generate when creating a class?
  • Default Constructor - Called when an object is created.
  • Destructor - Called automatically when an object leaves scope and is responsible for cleaning up resources.
  • Copy constructor - Called when an object is copied (including when passing an object by value).
  • Copy assignment operator - Called when using the assignment operator. (e.g. a = b)
    What optimizations are actually performed?
  • This depends on the flags passed and the code itself. We do not know the answer until we look at the assembly. Some common optimizations are listed on http://www.compileroptimizations.com
    Does C++ fill in default values for us?
  • This is compiler dependent! It is a best practice to always initialize values of variables.

Choosing a compiler

When choosing a compiler (whether it is g++, clang++, or MSVC) they must obvey the C++ standard for features defined. For the purpose of this class, you may use whatever compiler or environment you like, assuming that it supports at least the C++14 standard (C++17 may not be fully supported on all compilers yet. (e.g. Clang++ status, g++ status, MSVC status ). Note that if you start having problems, you are welcome to switch compilers or environments at will. I recommend however, sticking with g++, clang++, or MSVC which are all freely available.


2. Setting up SDL in C++


Simple DirectMedia Layer (SDL)

For this course, the Simple DirectMedia Layer (SDL) will be our tool of choice. It is a cross-platform library that allows us to work with Audio, Keyboard, and Graphics libraries amongst other tools. It is well supported (in my opinion), was developed by game industry veterans, and has been used in a significant number of commercial desktop and mobile games.

You will download and install the latest stable version of SDL from the following url: https://www.libsdl.org.

Complete: SDL 2.0 tutorial for your specified platform. You should complete to the point where you can render a window (This exact tutorial). You should cite your source as this tutorial in the README when you upload your code to your github repo.

By completing the above lab/tutorial, we should confirm that your machine is able to run Desktop SDL and OpenGL applications. Note that SDL has an additional software renderer sufficient for 2D projects (like the breakout game we will be developing).


3. Code Style


C++ Coding Style

Complete: Read through the following notes and add to your github repo one style practice you have learned.

Consider this section a crash course in C++ coding style rules. Read through the following rules, and then fix your implmentation from "Setting up SDL in C++" to make sure C++ style is adhered to. The compiler in particular does not care about the code we write (indendation, naming conventions, etc.), but the programmers who read our code will.

  1. C++ divides code into two different parts. The interface, and the implementation. We want to follow this convention.

    • Header file - Interface. Typically a file ending with a .h, .hpp, or .hxx extension.
      • Typically there should never be implementation code in a header file. When this does occur, it is the equivalent to using the 'inline' keyword on a member function(7.1.2)
    • Source file - Implementation. Typically a file ending with .cpp, or .cxx extensions.

  2. Be consistent in your naming conventions.

    • Match the capitalization of functions
      • If all of your function start with capital letters, make sure they all start with capital letters.
      • Perhaps you start with a letter for the data type, or some other qualifier, then be consistent.
    • This additionally applies to how you name classes.
    • By convention, consts are capitalized(e.g. const float PI = 3.1415....;

  3. Use a consistent style with how you format your curly braces.
    • I personally prefer K&R style. Others feel strongly against it, and perhaps other style avoid bugs. Be consistent whatever you choose.
  4. I am stopping at rules here. The long story short is good style can prevent errors in our projects. After the lab you may read The Ronimo coding style guide as a sample of what a style guide looks like in the game industry. Additionally, Google has a popular style guide here. Throughout the course, you may consider building your own style guide as you pick up best C++ practices!

4. Write Object-Oriented Code in C++


Object-Oriented Code

We want to get in the habit of writing code that can be used over and over again. We also want a codebase that is fluid and can be changed without major rearchitecture. Remember, we are building game engines and trying to solve problems that we will run into in potentially many domains. Coming into this class, many of you have C++ and Object-oriented design experience.

At this point (if you have not already), click the following link to gain access to your github repository: https://classroom.github.com/a/THrQnlSf. Make sure to edit the README with the appropriate deliverables.

Take a moment to look at the code to the right (also located in the repository). The code compiles, but it honestly looks awful! Why?

  • First it looks like I have ignored all of the style rules previously stated, including capitalization of the class names.
  • Second, the files are not split up! The implementations and headers of several classes are split up and honestly are all over the place!
  • There are several levels of inheritance going on. Running the program, you can see the variety of constructors and destructors that are called. This could cause hidden performance costs!
    • We really want to fix this, so we "flatten" our hierarchy.
    • It may be more beneficial if classes have a "has-a" relationship, rather than an "is-a" relationship.
      • In short, inheritance is different than composition. One may also be easier to refactor.
    • What do you think of the usage of Vector3?
    • What do you think about the initializer list in Bullet's constructor? Could that be confusing to a new programmer?
    • If we look at the code some more, there are even more problems!

Complete: Improve the code making at least 4 code changes and documenting them in the github repository. Make sure to commit your improved code as well!


Going Further


Finished Early? Did you enjoy this lab assignment? Here are some (optional) ways to further this assignment.

Evaluation


  • You and your partner will receive the same grade from a scale of 0-2. (Individual labs you get your own grade)
  • At the start of the next lab I will circulate to check off your lab. You or your partner should be ready to show it.
    • 0 for no work completed.
    • 1 for some work completed, but something is not working properly or missing
    • 2 for a completed assignment (with possible 'going further' options completed)

More Resources


Some additional resources to help you through this lab assignment

Found a bug?


If you found a mistake (big or small, including spelling mistakes) in this lab, kindly send me an e-mail. It is not seen as nitpicky, but appreciated! (Or rather, future generations of students will appreciate it!)
  • Fun fact: The famous computer scientist Donald Knuth would pay folks one $2.56 for errors in his published works. [source]
  • Unfortunately, there is no monetary reward in this course :)