Yeah, you’ll definitely want to start thinking about how to split the code into multiple files soon.
The first thing I’d recommend is moving every type defintion (
enum class et cetera) into a separate file,
though you may want to group related types (like
Enemy) if you feel that doing so makes life easier.
In fact, looking at your functions, it probably makes sense to move all the background-related code into one file, all the player related code into another and all the enemy related code into another.
That’s why GitHub exists. Commit little and often!
As long as it’s been commited somewhere you can easily go back to that point in history and retrieve the code as it was.
This is where branching comes into play.
Instead of creating X copies of the same file with slightly different names and slightly different states of completeness, add more branches to your GitHub repo and commit your modifications to separate branches,
then download them as needed or delete them when you’re sure they’re no longer relevant.
When you download them, you’ll get a zip of the form
<repo_name>-<branch>.zip, which will unpack to a
repo_name-branch folder, so it’s easy to tell the different variations apart by looking at their file path.
Yes and no.
No in the sense that you can just stuff all your globals into a single header file and then include that file,
but yes in the the sense that you’ll get problems if you don’t do that.
That said, I frown immensely at the idea of having a
globals.h because relying too heavily on global variables is a bad thing, and you should aim to avoid global variables where possible,
either by packing variables into data structures or by passing variables as parameters to functions.
For my games I tend to have a
Game class, and instead of having global variables dotted around,
all the would-be globals become members of the
and I’m left with a single global variable - the instance of
But even then, I try to keep the number of variables in the
Game class small.
In your case, before even thinking about a solution like that you should focus on the smaller things.
For example, packing all your player variables together into a single player structure would make the code a lot easier to manage.
And in particular I think learning about references would help simplify a lot of the code where you’re continually indexing arrays.
Also I think renaming your variables and functions would help make the code easier to follow, and thus easier to edit and add to.
Ideally functions should be like verbs, variables should be like nouns,
and the code should be able to be read like English.
- Instead of
- Instead of
if (collisionWithEnemy(enemyList[i].x, enemyList[i].y, ghostb)), have:
// The '&' means that 'enemy' is a reference
Enemy & wisp = enemies[index];
if(isCollidingWithEnemy(wisp.x, wisp.y, wispImage))
increaseDifficulty() is a good function name because it’s verb-oriented and describes an action.
titleScreen() is not as good because it’s a noun (a titlescreen is a thing) and doesn’t describe an action.
updateTitleScreenState() would be better - verb-based, describes an action and describes what it does precisely.)
One last thing:
x -= y is shorthand for
x = x - y.
The same is true for
%= et cetera.
They can help readability by getting rid of redundancy.
Sorry if I’ve overloaded you with information,
but it’s a lot easier to get this stuff sorted when the code is still smallish.
If you wait until the code grows larger then you end up having to expend a lot more effort to get everything sorted.