EPTIrrelevant Metablogging
Every blog has to start with a few irrelevant paragraphs about why you're blogging, right?
I want to write more blogs on stuff I'm ignorant about.
It's not a natural impulse for me. When I first made a TL account I was terrified that these internet strangers would think I was ignorant or immature or bad at Starcraft (it didn't help that I was ignorant and immature and bad at Starcraft), so I tended to want to agonize over every single thing I wrote and make sure it was completely buttoned up and unassailable before I posted it. That went okay, I guess – it doesn't hurt to want to be a good poster. But if there was something I knew I was ignorant about I tended to want to hide it. Either I'd avoid posting about that thing entirely, or, if I had to for some reason, I'd go study up really quick and try to learn about the thing as much as possible, then come back and pretend I'd always known about that thing. That habit continued as I started posting in the politics thread, leading to a tendency to post about trivial things I knew I was right about, rather than important things I didn't feel confident about. I would reread every post about 3 times before posting, and about half the time I'd finish typing it up and then change my mind and close the tab instead of posting.
It's a terrible approach for self-improvement, for one thing. If you only ever talk about something if you're certain you don't need to adjust your thinking about it, you don't give people a lot of opportunities to point out what you're wrong about. But the forum tends to suffer for it, too, especially if other people are doing the same thing you are. USPMT used to suffer from a phenomenon where if someone posted a serious, reasonable attempt at addressing an important question in a nuanced way, nobody would respond to the post; but if some numbskull came in spouting some idiotic nonsense, the thread would light up as 30 posters jumped in to tell them just how dumb and wrong they are (and a couple of those would also be dumb and wrong, prompting another 30 responses, etc.). Once upon a time there were hundreds of new posts in the thread per day, and 90% of them were replies to someone else trying to tell them how wrong they were.
Maybe it's better to talk (humbly, maybe) about the stuff you're most interested in, even if you're not totally confident in your thoughts and you're probably wrong about a lot of it. With that in mind:
Game Programming with SFML
The reason you're here, presumably.
I've been trying to teach myself some programming recently. I've written acouple blogs about my programming skills over the years, and you'd probably get a pretty good idea of my (lack of) skill level from those - I've done a little learning since then, worked (most of the way) through a couple programming textbooks, but I'm still pretty novice.
But one of the textbooks I've worked through (Beginning Game Programming by John Horton) taught me how to use a pretty neat little library called SFML (short for Simple Fast Media Library), a pretty straight-forward graphics library for C++ that seems to be pretty powerful. Horton teaches you how to make a couple very simple games with it (a tree-chopping arcade game, a little zombie arena shooter, and a very simple platformer).
I'm really impressed with SFML. Previously even simple video games seemed like massive undertakings, but after that textbook they seem totally achievable. In fact, here's a video series that uses SFML to make some classic games that writes the code for the entire game from scratch, demonstrates each element of the code as it's added by running the program, and finishes the whole thing in ~5 minutes:
I think this video is more impressive as a performance piece than a tutorial, but damn it's cool.
The obvious thing to do after finishing a textbook about how to program video games is to go try to program a video game. The problem, though, is that none of the game-making resources I've encountered so far actually give very good ideas about smart organization or code design. That Tetris video is just declaring everything it uses in main with one- or two-letter variable names. Horton's code architecture in that textbook starts out atrocious (declaring separate cloud1, cloud2, cloud3 variables) and by the end he's abstracted things out a bit (creating a global Engine object with separate input(), update(), and draw() functions (each in their own source code file) that each run once per frame). Near the end he kind of gestures in the direction of what sounds like some good object-oriented design; but he doesn't actually cover it, he just finishes the platformer and leaves you with "okay, have fun!"
Example:
Now look at this hypothetical code:
+ Show Spoiler +
The preceding code is a big step up in terms of encapsulation, code manageability, and
elegance when compared to even this final project. If you look at the previous code, you
will notice there are, however, unanswered questions, such as where collision detection fits
in, for example. Hopefully, however, you can see that further study (by building lots of
games) will be necessary to master C++.
Although we will not be implementing an entire game in this manner...
+ Show Spoiler +
vector<GameObject> m_GameObjects;
// Code to initialise all game objects
// Including tiles, characters, enemies, bullets and anything else
// In the update function
for (i = m_GameObjects.begin(); i != m_GameObjects.end(); i++)
{
(*i).update(elapsedTime);
}
// That's it!
// In the draw function
// Rub out the last frame
m_Window.clear(Color::Black);
for (i = m_GameObjects.begin(); i != m_GameObjects.end(); i++)
{
m_Window.draw(*i);
}
// Show everything we have just drawn
m_Window.display();
// That's it!
The preceding code is a big step up in terms of encapsulation, code manageability, and
elegance when compared to even this final project. If you look at the previous code, you
will notice there are, however, unanswered questions, such as where collision detection fits
in, for example. Hopefully, however, you can see that further study (by building lots of
games) will be necessary to master C++.
Although we will not be implementing an entire game in this manner...
-Beginning C++ Game Programming by John Horton, pg. 459
I get the impression that game programmers tend to be a... pragmatic bunch. Partly because most of the computational tasks you actually need to accomplish in a video game aren't actually all that complicated - stuff like update each object's position based on its velocity, detect collisions, read inputs and update whatever the input is supposed to change, and draw everything once per frame. But maybe the bigger reason (and this is purely a guess on my part) is that game programmers are a lot more likely to be self-taught nerds that started programming in high school and may or may not have ever had any formal training (like me! ...except the starting in high school part).
That's not to say game programming is easy or game programmers aren't smart. Just that games (especially hobbyist/indie games) are probably more likely to employ the kind of code that folks on Stack Exchange will probably say you really shouldn't be doing. Manually creating objects with new() and killing them with delete(), for instance, and managing them with raw pointers. Brute forcing some conditional with a massive if...else tree. Lots and lots of global objects and variables. That sort of thing.
For instance, from a book by Robert Nystrom I'm thinking of reading next:
In 2001, I landed my dream job: software engineer at Electronic Arts. I couldn’t wait to get a look at some real games and see how the pros put them together. What was the architecture like for an enormous game like Madden Football? How did the different systems interact? How did they get a single codebase to run on multiple platforms?
Cracking open the source code was a humbling and surprising experience. There was brilliant code in graphics, AI, animation, and visual effects. We had people who knew how to squeeze every last cycle out of a CPU and put it to good use. Stuff I didn’t even know was possible, these people did before lunch.
But the architecture this brilliant code hung from was often an afterthought. They were so focused on features that organization went overlooked. Coupling was rife between modules. New features were often bolted onto the codebase wherever they could be made to fit. To my disillusioned eyes, it looked like many programmers, if they ever cracked open Design Patterns at all, never got past Singleton.
Cracking open the source code was a humbling and surprising experience. There was brilliant code in graphics, AI, animation, and visual effects. We had people who knew how to squeeze every last cycle out of a CPU and put it to good use. Stuff I didn’t even know was possible, these people did before lunch.
But the architecture this brilliant code hung from was often an afterthought. They were so focused on features that organization went overlooked. Coupling was rife between modules. New features were often bolted onto the codebase wherever they could be made to fit. To my disillusioned eyes, it looked like many programmers, if they ever cracked open Design Patterns at all, never got past Singleton.
source
On the one hand, if I'm going to start on some big project, I'd like to figure out some decent architecture first so it doesn't get too unmanageable (and/or I don't have to spend a lot of time later going back and rewriting everything to fit an architecture I should have thought of in the first place). On the other hand, I'm maybe suffering from some analysis paralysis here – perhaps its best to just write the spaghetti code for a while, until you have a better idea why spaghetti code is bad (and what you could do better).
This blog is already too long, so I'm gonna end it here. But...
[radio voice]Next time on ChristianS's occasional programming blog...
I'm gonna take a look at the code of an actual (more or less) functional RTS, in hopes of learning something about how to smartly organize a game's code.
