Games are a young medium, and we’re still inventing (or appropriating) nomenclature for it. Ludonarrative Dissonance, Kinesthetics, skinner box, gamification, consolification, boss fight, quicktime event, RPG, difficulty curve, level scaling, HOTs and DOTs, raid, crowd control, pay-to-win, force feedback. Twenty years ago these terms either didn’t exist, or they meant something else to the average person. Some of these terms came from the audience, and some of them came from game designers, but they all arose out of a need to talk about a thing that didn’t have a name yet.
One concept I’ve needed a word for is the way games use multiple audio / visual cues to let you know that a thing happened. The term I’ve settled into was “feedback channels”. But lots of people have run into this concept long before I showed up, and they already had their own terms. These two guys call it “juice” or making a game “juicy”:
Actually, “Feedback Channels” and “Juice” might not be the exact same concept. I think of it in terms of making specific events in the game have as many possible routes of player feedback as possible, while these guys are more talking about making the game as a whole have more stimulation. But it’s very nearly the same idea, and I’m sure there are a hundred other developers with their own name for the concept.
Let’s say you’re playing some kind of shootin’ game of the first-person variety. You pull the trigger to make the gun do what it does. How many different ways does the game let you know what happened?
- Boom! The gun makes a gunshot sound.
- The player’s view is kicked slightly upward to simulate recoil.
- The weapon itself jerks backwards/upwards to further sell the notion of recoil.
- Perhaps the mechanism of the gun moves somehow. The barrel spins, the character’s hands pump the shotgun, a bolt slides, etc. Some sort of animation to show that this is a machine with moving parts.
- The spent round or shell casing is ejected from the firearm.
- There’s a muzzle flash / puff of particle smoke from the barrel.
- If the bullet hits a flat surface, then the game slaps a bullet decal (a picture of a bullet hole) onto it.
- The struck object will give off a puff of particles depending on what it’s made of: Concrete dust, splinters, blood, etc.
- If the bullet hits a physics object, the object will be knocked around by the force of the impact. It might shatter entirely.
- If the bullet hits an enemy, they will usually jerk backwards, flinch, etc.
- There’s a sound from whatever was hit: Shattering sound, a metal ping, cry of pain, etc.
- The bullet impact makes a sound, although it’s usually lost in the roar of the gunshot.
The game has about a dozen or so different channels it uses to convey the action. And keep in mind we’re mostly just talking about cosmetic stuff. This is in contrast to the mechanical stuff like your ammo count going down, the enemy hitpoints dropping, your aiming reticle expanding as you lose accuracy, etc. (The view kick is an example of an effect that falls into both categories.) You could remove all of these effects aside from the view kick and the game would play exactly the same. It would be mechanically identical, but it would feel incredibly numb, muted, or distant. When people say the guns in a game feel “weak”, I suspect they’re often not talking about mechanical stopping power but about the lack of key feedback channels.
Now think about how many other actions there are and all the feedback channels we have for them. How many cosmetic ways does a game have to let you know you’ve been shot? That an explosion happened nearby? That you’ve hit the ground after falling or jumping? That you’re running?
One of the things I wanted to mess around with in this project was coming up with as many feedback channels as I could.
This is an interesting exercise. It’s also pretty rewarding from a code standpoint. Adding cosmetic systems is easy because they don’t have a lot of interplay. I can make the game rewarding and visually interesting by adding effects to the scene without worrying that I’m going to break the AI, mess up the controls, or unbalance the game.
When I kill a robot I’ve got:
- It’s hard to see in the animation because the bullets I’m using are practically particle clouds themselves, but when you kill a robot a cluster of sparks fly out the back of the robot as if you were blowing its robo-brains out.
- The lights on the robot go out, turning it into a pure black silhouette.
- The robot falls.
- When it hits the ground it breaks into a cluster of debris particles. (Which also doesn’t show up in the animation above. Did I break that without noticing, or is it just lost in this low-framerate animation?)
- The robot might have a bit of spin on it, like a billiard ball. If you’re to the left of the robot and your shots grazed the top of its head then it will spin away from you. (Clockwise.) If you hit its base then it will tumble counter-clockwise. If you hit it center-mass then it falls straight down with no spin.
- While falling, it leaves a trail of black smoke.
- It makes some kind of death sound when you kill it, then an exploding sound when it hits the ground.
#5 was interesting to implement. It seemed simple in my head. I mean, I just look at the position of the impact and use it to create spin:
But hang on. Hitting the robot like this should create a clockwise spin. But hitting in the exact same spot from above should produce counter-clockwise spin. That means that… um…
I spend a couple of minutes staring at the screen. This is a simple problem. Or at least, I’m pretty sure it is. I’m willing to bet it’s not more than a couple of lines of code. But I can’t picture it. I know intuitively which way an object should spin based on the point of impact, but I don’t know how to express it. Like, if you asked me to explain why an object spins a particular way I’d result to pointing at the impact in illustrative ways. That doesn’t translate into c++.
Okay, we’ve got at least two important bits of information. There’s the angle of the impact, and there’s the angle from the point impact to the center of gravity. (Which -in our hilariously primitive little 2D world – is just the center of the robot’s rectangle.)
I don’t know how to put these pieces of information to use. As a way of visualizing the problem I just take the difference between the two and… what? I guess I’ll just take that number and apply it to the spin of the robot when it dies. Then I’ll shoot a few down and see if that helps me picture the problem.
Oh. That was actually the solution. Take the difference and apply it as spin. It works perfectly.
This is actually kind of disappointing. It’s like that feeling when you’re just screwing around in Portal because you’re stuck and you end up accidentally solving the puzzle. You’re robbed of that delightful “Eureka!” moment.
Ah well. It works.
What Does a Robot Want?
No, self-aware robots aren't going to turn on us, Skynet-style. Not unless we designed them to.
The Mistakes DOOM Didn't Make
How did this game avoid all the usual stupidity that ruins remakes of classic titles?
The Truth About Piracy
What are publishers doing to fight piracy and why is it all wrong?
Mass Effect 3 Ending Deconstruction
Did you dislike the ending to the Mass Effect trilogy? Here's my list of where it failed logically, thematically, and tonally.
Diablo III Retrospective
We were so upset by the server problems and real money auction that we overlooked just how terrible everything else is.