EPTIn my previous blog, I was simultaneously impressed with the capabilities of SFML for making simple games, and frustrated with the tutorials and textbooks I had followed so far at the lack of good suggestions regarding how to organize the code. Horton in particular even started to hint at a potential code organization (put all your objects in a big vector of pointers to a base Object class, and give them each an update() and draw() function that you call each frame), only to essentially say "As you can see, it's not obvious how you'd handle something like collisions with this. Anyway, good luck!"
Frustrated, I thought I'd like to go look at an *actual* game, not just an educational tutorial. Then I could get some hint of how real programmers are programming real games. And fortunately, the SFML website has a "Projects" forum where people can post about actual projects they're building! And there's some pretty neat stuff, like a dynamic light and shadow casting library or a GUI library.
That's all well and good, but I wanted a full game. And clicking through I found a tantalizing post titled "Isometric RTS" that, I mean, I couldn't *not* click on, right? It's by a guy with the handle "Switchboy" who the forum identifies as a "Newbie" (only 4 posts). There's a brief introduction to the project: he's been working on it for a couple of months, it's his second big C++ project (he abandoned a previous RPG roguelike because the codebase got too messy), and it's inspired by Age of Empires. He's also got a feature list (already reached, planned, and stretch goals), a github link, and a video (in Dutch):
I'm gonna look at this guy's code in a moment, but I want to pause here to say the stuff he's shown so far is awesome. Fucking incredible. I'm simultaneously impressed and excited that it's possible to build so much as a random guy working on a project in his spare time, and intimidated that other people are managing to do so much more than I would know how to do. I'd be thrilled to have built anything close to the project he's demonstrating there. The post was in June 2020; I wonder how much more he's managed since then! On the off-chance Switchboy ever winds up reading this blog, I hope his main takeaway is that I think his project is fucking sweet and I'd love to play his game if/when he finishes it.
Okay, so I don't really understand how github works, but I figured out how to download his code. First things first, it doesn't build. At some point I'll do a blog solely complaining about the awful and unintuitive interface of Visual Studio and, really, everything you have to start out doing when you want to learn C++, but for starters, there's a whole song and dance you have to do to make an SFML project build, including going into a bunch of different submenus, specifying filepaths to find SFML stuff, specifying specifically what SFML stuff you want to use, and copying some SFML stuff directly into your project folder. Near as I can tell Visual Studio doesn't even want to give you a "Save As..." function to copy a blank project with those adjustments already made, so I've just been having to do that whole song and dance every time I start a new SFML project + Show Spoiler [template aside] +
VS does have a "Template" feature where you can create a blank project, save it as a "template", and it should get copied. Near as I can tell, it just doesn't work? If I create a new project from the template, it still isn't configured in any of the ways that tutorial specifies, so I still have to do all that from scratch
But whatever. I'm not here to play his game, I'm here to look at his code. I don't need it to build for that. But where to start? He's got 13 different header files and 13 different .cpp files, with names of varying clearness about what they actually do + Show Spoiler [list] +
actors.h and .cpp
buildings.h and .cpp
button.h and .cpp
gamestate.h and .cpp
gametext.h and .cpp
globalfunctions.h and .cpp
main.h and .cpp
objects.h and .cpp
orderCursor.h and .cpp
player.h and .cpp
projectile.h and .cpp
randomMapGenerator.h and .cpp
tooltip.h and .cpp
buildings.h and .cpp
button.h and .cpp
gamestate.h and .cpp
gametext.h and .cpp
globalfunctions.h and .cpp
main.h and .cpp
objects.h and .cpp
orderCursor.h and .cpp
player.h and .cpp
projectile.h and .cpp
randomMapGenerator.h and .cpp
tooltip.h and .cpp
How about main.cpp? That's where the compiler starts, so why shouldn't I? Right off the bat, he's got 13 #include's - 7 of his own creation, 1 from SFML, 3 pretty normal stdlib ones, and <future> and <mutex>. I think that means he's multi-threading? Okay. And then the first thing he does is create a global variable:
gameState currentGame;Okay, I know global variables are frowned upon, but sometimes they're hard to avoid. Maybe he's just storing a couple convenient objects like the RenderWindow in a global object for easy access. Let's just go check out its declaration... fuck.
gamestate.h starts out by linking to 17 different global variables from other files using the "extern" keyword. Then it declares a couple simple structs. Then it declares the class gameState, which has no less than 60 public functions, 83 public variables (including 37 sprites, 37 textures, and 5 int arrays indicating the world map, building locations, object locations, and more), and a few dozen private variables (a couple of which are misspelled). gamestate.cpp is nearly 2500 lines of code, with scarcely a comment to be found.
Not to put too fine a point on it, but I think I might be starting to see how he wound up abandoning his first project due to the codebase getting too messy. I've been reading Game Programming Patterns by Robert Nystrom, and I thought of this part:
Before you can change the code to add a new feature, to fix a bug, or for whatever reason caused you to fire up your editor, you have to understand what the existing code is doing. You don’t have to know the whole program, of course, but you need to load all of the relevant pieces of it into your primate brain.
We tend to gloss over this step, but it’s often the most time-consuming part of programming. If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves.
Once you’ve got all the right context into your wetware, you think for a bit and figure out your solution. There can be a lot of back and forth here, but often this is relatively straightforward. Once you understand the problem and the parts of the code it touches, the actual coding is sometimes trivial.
sourceWe tend to gloss over this step, but it’s often the most time-consuming part of programming. If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves.
Once you’ve got all the right context into your wetware, you think for a bit and figure out your solution. There can be a lot of back and forth here, but often this is relatively straightforward. Once you understand the problem and the parts of the code it touches, the actual coding is sometimes trivial.
I'm trying to imagine how you would ever edit this code to make changes. If a function uses gameState for anything (and with 60 different functions locked up in it, it's likely to), you'll have to load that whole thing, all 60 functions, 83 public variables, and 2500 lines of code, into your cerebrum by reading through it line by line in your IDE (which is technically an OCR process, as Nystrom points out elsewhere). I imagine Switchboy only got this far by virtue of having built all this himself, and having relatively clear memory of exactly what he had done. But is even that going to hold up after, say, a year of development? I'm looking at these variable names and wondering why there's a vector<float> called "mousePosition" and another vector<int> called "mouseFakePosition." Why does he need to store a fake mouse position? Is the other its "real" position? How long until Switchboy himself doesn't even remember why these both exist, and what the difference is?
So in my hunt for good examples of effective OOP architecture for building games, I'm gonna pass on Switchboy's (again, fucking awesome) project as an example I should follow. But I might check up on that YouTube channel periodically and see if he ever finishes the thing. I'd love to play it!
