“We’ve updated our algorithm so the hardest enemies don’t spawn until you reach higher levels.”
I’ve heard this phrase, or derivatives of this phrase, ad nauseam since I started learning game design. “What the heck does that even mean: updated our algorithm?” I told myself. At first, I thought it was just a fancy word game designers threw around to simplify an update they couldn’t really explain. I resigned myself to the idea of an intangible string of complex mathematics on a scientist’s blackboard that I’d never understand. I just figured they were above my head and I’d never understand the concept, or how to write them.
The fantasy of the algorithm in Hollywood is a hacker circumventing the complex electronic lock on a steel vault. “My mojo is way better than this corporate hack’s algorithm. Cracking it will be a cinch.” Turns out I’ve been making those algorithms all along. Of course, they’re much simpler and not used for security systems.
All games use some form of algorithm. In the past, I had referred to it as “game logic.” It’s an OK term, but we should use new vernacular. It was exciting to learn that I had been doing something I thought was reserved for mathematicians. They look and function exactly like a flow chart. There’s a question that goes through a series of causative statements, following the pathways until it arrives at a final output. Let’s deconstruct the idea of an algorithm into practical terms to better understand it.
Say we’ve got an actor, let’s call her GunGirl. We’ve placed GunGirl in our level. Now let’s make an attribute for her, we’ll call it “dead.” It’s a boolean attribute, which means it produces two outputs: true or false. Let’s set the default to false. When the level starts, there’s GunGirl, and she’s alive.
Now let’s put another actor on the floor in front of her. We’ll call this one “grenade.” Let’s pretend it has a timer set to zero. So when the level starts, it explodes. Now let’s tell GunGirl that “if grenade time = 0, and GunGirl position < grenade position + 5, set “dead” = true.”
The game starts. GunGirl has about a split-friggin’ second to live. It’s just long enough to notice something at her feet…BOOM! Grenade explodes, Gungirl’s position is checked against the blast radius of the grenade, “dead” outputs true, and GunGirl goes “POOF .”
That’s an algorithm.
Now, I just had this thought: “Maybe all this time I was confusing the word algorithm with logarithm.” Turns out that it’s just a case of continents vs. countries. Logarithms are the smaller calculations (mathematical formulas) that help the more complex algorithm. A logarithm’s basic function is to search a list of things, or log, in the most efficient way possible. Then it retrieves an answer and gives it to papa algorithm. Think of logarithms like little slobbery golden retrievers. Some algorithms even contain little sub-algorithms that behave like logarithms. When logarithms get to their smaller, programming language selves, that’s when they become the math-heavy enigmas that are best left for programmers.
Let’s look at the if/then statement we created before. Something has to govern whether the grenade timer counts down, the radius of the grenade and GunGirl overlap, and whether GunGirl is alive or dead. There’s actually about a dozen more sub-algorithms the game engine has to check, plus an exponential amount of little logarithmic calculations before our parent algorithm resolves. Each one of these actions can potentially trigger another algorithm. They’re all part of a massive web of causes and effects that make a game function.
If you get the chance to use a program like GameSalad, Creation Kit, or UDK, you’ll find that creating algorithms is 75% of game design and 100% of what makes a game function. Learning how to make them, and simplify them to their most basic math is fundamental for a game designer, in my humble opinion.
Now, hopefully, we understand the phrase at the top. For fun, let’s put it in the context of ice cream, cuz who doesn’t like ice cream?! If Baskin Robbins has 31 flavours of ice cream, they’re bound to have some nasty ones that didn’t make the cut. A child who has never had ice cream before (lvl 1 N00b) will go for the flavors that are easiest to swallow: chocolate, vanilla, strawberry, chocolate chip. A man with a clipboard (we’ll call him Assistant Manager Logarithm) records the number of cones each customer buys. The flavours that aren’t popular with the younger customers are now put in a separate place. That’s the job of Senior Manager Algorithm. The craziest flavors, like mint popcorn coffee marshmallow surprise, are only given to long-term return customers (lvl 100 badass). These guys are much more likely to try them and stick around to try another, instead of running out of the store vomiting.