Hello Everybody, Earth Otherwise here with part three of chapter one of Game Programming in C++: Start to Finish. Ok boys and girls. I've never used either of these products, so we're going to be learning together. I'll post links to the various tutorials that I use and I'll also have a video of me setting things up, so here goes.
As you know from the last part DOxygen is a software that allows you to create comments outside of your code. This is useful if someone is using your custom game engine and doesn't want to go through the code itself to figure out how and why they might use a piece of your code.
And Git is versioning software that keeps track of changes in our code so we can better pinpoint when things go wrong. Though we personally won't have much use for either of these programs since we're single developers working on all our own code and I personally have a policy of making sure that my game runs after every change, in the event that you or I one day get to work for a company where there are multiple people all looking at the code base at once then this is an excellent learning tool.
Now, this kind of post will be the most dated since it will be using code and programs that are available and cutting edge when I'm writing this in 2017. If it's not 2017 for you then you'll have to look at more modern versions of what I'm doing.
Let's start with DOxygen. I've downloaded the 1.8.13 version for windows that has the installer. Since I used an installer it installed correctly. Now to set it up. I watched a video tutorial on how to set up DOxygen from March of 2016. Link. It mentions a few things that may or may not be of use to you depending on when you are seeing this.
1: DOxygen will wipe whatever folder you use as your working directory, so always find or make a blank folder to use as DOxygens working directory.
When you pick your source code directory you must select the folder that actually has the .h and .cpp files in it. DOxygen only reads the files in the folder you selected, not any files in folder inside that folder. The 'scan recursively' function may do this, however, you may not want to use that option if you have dependency .h and .cpp files in your project or code folders, since it would mix the dependency documentation with your own.
Check the mode tab to make sure that DOxygen is optimized for your code language.
Finally, 4. In the expert tab, in build, you want to check EXTRACT_STATIC, EXTRACT_PRIVATE, and INTERNAL_DOCS. This will have DOxygen get the documentation for private variables, static variables, and documents that are marked as internal. DOxygen does not do this by default.
I'm going to have two sets of documentation. One for my engine, and one for each game that uses it.
I'll also be keeping the engine and game separate from now on because the next thing that I'll be doing is working with Git and Github. Github is an online service that allows you to keep your code on their servers. I've installed the github desktop, which allows me to easily store my stuff without having to log into the site.
Now, there is a guide on the site. Several, in fact, and I suggest you read them. Link. The basics are, for those on windows. Install the github installer, make an account, set up a project, either set the github desktop folder to be where your code is, or drag your code into the github folder.
From there the process is simple. You create a branch, that is, a copy, of your project. Do all your changes inside that copy, and then submit that copy to be merged with the main files. If you aren't an admin on the project then you will probably have to ask an admin to add what you did, but if you are an admin you can just say yes to the changes. Then you delete the copy branch and repeat.
This is useful because github will keep track of each change you make, meaning that if you or someone else makes a change that breaks the game you can roll the main branch back to when the software was working.
These two programs working together will create a system by which we can hand our project to anyone who can program in our language and they can understand the entire timeline of the creation of our software.
So, with this final post we are done with the introduction chapter of "Game Programming in C++: Start to Finish". Join me next time with the first part of chapter two, where we will look at the part of the book which will hopefully have aged the best. Game Design Fundamentals.
