…but the problem (the argument goes) is that procedural programming (PP) can get out of hand in terms of complexity. <\/p>\n
Let’s say we’ve got a game. We’ve got a big list of (say) space marines taking part in the simulation. Each space marine is nothing more than a block of data describing where it is, how it’s moving, what weapon it has, how many hit points it has, what team it’s on, what it’s AI is up to, what character model it’s using, if it’s dead, and so on. <\/p>\n
Here, let’s make up a pretend data structure to hold our marine:<\/p>\n
<\/p>\n
\r\nstruct space_marine\r\n{\r\n char* name;\r\n int character_model;\r\n int current_weapon;\r\n int ammo;\r\n bool dead;\r\n int hitpoints;\r\n vector3d location;\r\n vector3d velocity;\r\n int animation;\r\n int animation_frame;\r\n};\r\n<\/pre>\nSomewhere else in our code we’ll loop over all the space marines and see if they’ve been crushed under any vehicles. Another bit of code checks to see if they’ve been hit with bullets. Another checks if they’ve been eaten by aliens. Another checks to see if they have picked up weapons. Using vehicles. Interacting with doors. Reaching checkpoints. Using cover. Often these systems need to change the space marine in same way. If they get hit with bullets they need to take damage. If they are knocked into the air they need to play a new animation. And so on.<\/p>\n
The first problem.<\/h3>\n
Every single programmer that writes code to change the state of a space marine needs to know exactly how the internal systems of a space marine works. If they don’t, then they will write code in a way that makes sense to them, but doesn’t work with the code that already exists.<\/p>\n
The guy coding the “getting crushed by machinery” code just subtracts a million hitpoints when a marine is crushed. He didn’t notice the variable called “dead”, which is what actually causes the marine to behave<\/b> like it is dead. You’re supposed to see if HP is at or below zero, and then set the variable “dead” to “true”. Since this programmer didn’t, you wind up with a bug where a character has negative one million hitpoints and yet is still running around alive. <\/p>\n
Maybe another coder comes along. She’s a little more careful, so when she writes a new system for characters running into forcefields she notices the “dead” variable and correctly intuits what she’s supposed to do. However, she writes it so that the “dead” flag is set if hitpoints are below<\/b> zero. Which means that if you’re damaged by a forcefield, it’s possible to have exactly zero hitpoints and still be alive, while most other kinds of damage kill you at or below zero. This creates annoying inconsistencies that are hard to track down. <\/p>\n
Our space marine example above is pretty simple, but in real applications things aren’t always this straightforward. In my game Good Robot<\/a>, the data structure for enemy robots has over 70 fields in it. And that’s just a simple 2D game. As the data becomes more complex, it becomes unreasonable (and infeasible) to expect that every programmer on the project should be able to fully understand every data structure. As the number of different types of data (space marines, weapons, vehicles, multiplayer connections, particle emitters, physics objects, HUD elements, projectiles, menus, etc etc etc.) grows it becomes difficult for any one person to get a a handle on the whole thing and how it all connects. <\/p>\nSo now you’ve got half a dozen people all interacting with data structures they don’t fully understand, which can lead to bugs. This leads us to…<\/p>\n
The second problem.<\/h3>\n
<\/div>These guys are bad dudes who don't play by the rules. Specifically, they clip through scenery, get stuck on terrain, or end up locked into a fixed pose while running.<\/div><\/p>\nIn PP, any part of the code can act on any bit of data at any time. <\/p>\n
Let’s say a bug crops up. At the end of a game loop you find a space marine is in an invalid state. Maybe it has a negative one million hit points, yet isn’t marked as “dead”. Or perhaps it has a negative number of bullets. Perhaps it’s far outside the game area, or swimming when it shouldn’t be. Maybe they’re holding a six-shooter that somehow has 400 bullets in it.<\/p>\n
The programmer discovers this incorrect state, but they have no idea where in the code this might have happened. A hundred different systems modify space marines every frame. There’s no way to even begin the search for the problem. As the number of systems that can act on one another grows, the program quickly becomes a terrifying mass of chaos.<\/p>\n
Managing State<\/h3>\n
In the most abstract sense, the program is nothing more than a bunch of logic designed to change the state of variables. At one point in Half-Life 2 Gordon Freeman is running around the city with no weapon, and at another point he’s out in the abandoned highway, running over combine soldiers in his laser buggy. It’s still the same program. The only thing that’s changed are the values stored in all the variables. A particular arrangement of variables is called the “state” of the program. A program like Half-Life 2 does a lot of changing state. A lot of bugs are the result of some unforeseen change in state.<\/p>\n
Maybe your game is processing animations for various objects in the scene. A door moves along its open animation and bumps into an explosive barrel. It nudges the barrel, which suddenly can’t cope with the fact that it’s sharing space with another object. This triggers an explosion, which kills the player character.<\/p>\n
Meanwhile, somewhere in the high-level code of the game we might have something like this:<\/p>\n
\r\n\/\/See if the player is dead.\r\nif (player.Dead ()) {\r\n OpenGameOverMenu ();\r\n return; \/\/no need to process the scene from here.\r\n}\r\nUpdateAnimations ();\r\nUpdatePlayer ();\r\nUpdateAI ();\r\nUpdateNetwork ();\r\n<\/pre>\nOn line 2 we abort processing if the player is dead. Because of this, we assume the player MUST be alive when we update them on line 7. But in the scenario above, we found an edge case where the player could die during the animation update. <\/p>\n
It’s not possible for a programmer to understand how every object in the game can impact every other object in every situation, and it’s certainly not possible for them to grasp all of the cascading changes that might result from interconnected systems. Which means they probably didn’t ever imagine that it would be possible for the player character to be dead when we reach line 7. All of the code in UpdatePlayer () is probably written under the assumption that the player is 100% guaranteed to be alive at this point.<\/p>\n
We refer to this problem as “side effects”. Running a bit of code has unexpected side effects on the state of the program, and there’s no way to account for all of the possible side effects of any given action. The systems are too large, the connections between them are too numerous, and the possible side-effects are too complex to be fully understood. The above example is trivial(ish) to detect and fix, but in a real game subtle stuff like this can hide in the crevices of the structure and bedevil our poor programmer.<\/p>\n
The Solution<\/h3>\n
<\/div>These represent class objects. Look, just go with it.<\/div><\/p>\nHere is where we see the desire to use Object-Oriented programming. Instead of a program where any part of the software can reach in and modify any part of a space marine at any time, we hide all of those internal variables away and build an interface for them.<\/p>\n
We create a “class” called SpaceMarine, we stick the variables inside of it, and we lock those variables away so that other parts of the program can’t change them whenever they like. Then we build an interface – a set of controls – by which other programmers can manipulate a SpaceMarine. The variables are essentially in a black box and (we hope) the object can be used without knowing how it works on the inside.<\/p>\n