GPiC++Stf Chapter 3 Part 1: Planning Our Code and Naming Conventions

---

Hello Everybody, Earth Otherwise here to continue our journey into Game Programming in C++: Start to Finish by Eric Yuzwa. In this chapter the book seeks to teach us about SDL and Windows. In this part we'll be using ArgoUML, or your UML of choice to plan out the code we'll be making later.

We'll be making several systems. At the start of a project, particularly if you don't have an engine to rely on, you'll need several systems to handle things like error checking and working with an initialization file. The book covers these basic parts of a game in this chapter, so I too will show you how to implement them, using all the tools at our disposal.

Now, before we actually start to code we'll need to ask ourselves how we will be naming things like classes, variables, and functions. I'll leave a link to a google style guide if you want to look into this more, but here are the basics.

No one cares what you do so long as you don't break any of the basic rules. Standard code that everyone uses abides by certain rules so that we don't make code that will conflict. You don't want to be messing with the definitions of the standard template library unless you really, really have to. Thus you never want to use double underscores at the beginning of a name. You don't want to use an underscore and then a capital letter. You also don't want to define anything in the std namespace, because that's standard stuff as well.

Here are some other simple rules

1. Do not use double underscored for names. You are allowed to use it in certain specific scopes, but it's easier just to avoid doing so entirely
2. Do not use an underscore followed by a capital letter. Same caveat as previous applies.
3. Avoid abbreviation when possible
4. Function names have a descriptive verb, like get, or set
5. Types, such as classes, use a capital letter for each word, like MyScreenInterface
6. Variables begin with a lower case letter, member variables start with an m so that if you have public variables you know when typing them out that they're part of a class, just in case you weren't aware at first.

It's suggested that you keep all letters lower case in variable and member names, and a whole bunch of other stuff. But really, so long as you keep it consistent across code and don't mess with the standard code no one cares. Doubly so for indie developers who's code will probably never be seen by anyone besides the programmer.

On to the actual classes, structures, and functions we'll need. First is the FileLogger. As it's described in Game Programming in C++ Start to Finish this is a class which will log any error that the application throws in the event that the program does not have access to the console or for some reason can't print to the console. Now, I'm going to be changing this class. First off, it's not a class. It doesn't need to be.

Instead our FileLogger will be ErrorsOtherwise. Insert your engine name of choice. This will also not be an actual class, that's just what we're going to be calling the .h and .cpp files that will hold our functions. Simple fact is that this doesn't need to be a class. A class needs to be instantiated to be functional. Instead we're just going to be creating a bunch of useful functions which we can insert into any code so that if something we don't want to happen happens the program will stop and tell us what's going on.

The structure will be thus: A function called ThrowConsoleError which will pause the program and print the error to the console. A ThrowFileError which will save the error to a file that will be titled with the date and time as well as one word about what kind of error it was so that errors are documented in chronological order, don't overwrite each other, and you might be able to solve the problem without even having to open the file.

These error functions will take parameters which will tell it what to print, since each error will be unique. We know each error will be unique because if it weren't unique then we'd probably be writing duplicate code and we shouldn't be doing that.

The console error will offer to continue the program, shut down the program, or restart the function which caused it to throw the error. This will be useful if we, say, misnamed a file and can simply change the file name to the correct one in order to get everything rolling.

There will be a final, or perhaps first function just called ThrowError which will be the function that we actually use. Here we will determine which error function we need to use. If the program is using the console then it'll throw a console error, otherwise it'll throw a file error.

Next is the ability to read an INI file so that we have some initialization specifications without the need to recompile the executable.

This also doesn't really need to be a class since it doesn't hold any data that can be changed outside of itself. This code is pretty similar to the error code, just reading instead of writing, though later we'll want to write to this file.

Third we will create a basic class from which we can inherit a few very important functions which will keep us from leaking memory. Now, I also tend to use standard containers which do memory cleanup when they exit, but it's good to keep track of these things. The more you can track in your game the easier it becomes to locate problems and find interesting statistics.

Fourth we shall create our input class which will get our inputs and call the necessary functions to get the program working.

Finally we shall create the window class and the main file that opens it. For being the stated task of this chapter it's probably the easiest. The window class will contain the functions needed to open the window and the main file will only really have the arguments we need to pass to SDL to get it to handle our operating systems queries and a call to our startup function or if we put our game in a class it'll have that class instanced.

---

▶️ DTube
▶️ IPFS