Reposted from Shamus’ Good Robot Devblog.
Let’s talk about little things that make a big difference.
The game was lacking something. It was just too static. The world didn’t move, didn’t animate, didn’t react. The screenshots looked good, but when you were playing the game it felt like you were flying past a painting or something.
So my first solution is dust particles. Here is a shot of them, zoomed in so everything looks terrible:
The little specks are the thing we’re interested in here. In still frame, they just look like part of the background. But in gameplay they drift around. They get brighter when you hit them with your flashlight beam and they’re obscured by walls.
Like a lot of “field” effects, this one is pretty simple. There are only 400 dust motes in the game. They drift slowly, so the game doesn’t even have to move all 400 every frame. Each one of them moves in a different (but constant) direction. If it drifts off one side of the screen (either because you’re moving, or it is) it simply re-enters from the opposite side. If you could zoom out, you’d see your character has a rectangle of white particles following them around.
It sounds simple, but it’s amazing how much more alive this made the game seem, particularly since the movement is so slow.
So I thought that maybe we’d get an even bigger return if we took it to the next level. I made a version where the dust particles would tumble away from you in your wake. The result was… nothing. I barely noticed the effect. It also took more than twice the CPU. So I’d managed to hit the sweet spot on the cost / benefit curve on the first try, and then took it a step further and realized I’d wasted my time. (I undid these later changes.)
The other big thing I added to the game is the concept of machines. I mentioned them earlier in this series, but skimmed over the details.
The game is creeping towards rogue-like gameplay as it develops. We’ve added permadeath. However, you can sometimes find a vending machine that will sell you a warranty. If you’ve got a warranty, then when you die this machine will put you back together:
Being revived consumes the warranty. If you can reach another vending machine you can buy another warranty, but they get more expensive every time. That will consume precious money better spent on upgrades. I like this because it forms a nice compromise between the severe cruelty of a roguelike and the coddling of an action game. Making a single mistake won’t end your whole game (Spelunky was actually way too frustrating for me) but you will still carry the burden of that mistake going forward. The money spent on the warranty means you’ll be getting upgrades just a little later. (Or if you keep dying, way later. Or never.)
If this kind of roguelike gameplay sounds a little strange coming from me, it’s probably because I’m part of a team now. A lot of these gameplay decisions emerge after literally hours of debate and playtesting. Everyone has their favorite gameplay mechanics and styles, and a lot of the current design process is looking for a mix that makes sense to everyone. There have been a few decisions that I disliked as a matter of personal taste, but when other people seem to be really passionate and enthusiastic about an idea, I’m willing to let it go. If they love it more than I dislike it, then it’s probably a net win. As long as the final whole makes sense, then it’s all good.
There’s always a trade-off here:
Danger #1: Compromise too much, and it might ruin your creative vision. You won’t end up with the game you wanted to make. If the game does poorly, you’ll always worry that maybe you should have fought a little harder for that thing that might have fixed it.
Danger #2: Never compromise, and you won’t have any way to detect and correct bad decisions. David Cage, Peter Molyneux, and the writers of the Mass Effect 3 ending are all people that seemed like they need to be more responsive to their teams and self-aware about their excesses. You’ve got smart people on your team. Trust them!
Since this will be the first time I actually ship a game, I’m more worried about danger #2 than danger #1. If I design a hit game, then maybe I can think about embracing the mentality of a swaggering, uncompromising auteur.
Anyway. Back to the machines.
The goal wasn’t just to put some detail on the bare rock walls, but also to add some stuff that was animated in some way. The little gears in that respawn machine actually rotate, the pistons on top pump up and down opposite one another, and some of the lights blink on and off at fixed intervals. Like many other things, machines are defined in text files like so:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
<Spawner Message="" Use="spawn" Offset="0 0.4" MaxActiveRobots="6"> <Part0 X="0" Y="-0.050" Depth="0" Color="#FFF" Glow="0" Size="2.5" Spin="0" Sprite="machine9" />
The artist can specify any number of parts of the machine. They can give it a specific sprite image, offset from the center of the machine, rotation, and color. They can also tell it to spin, or move back and forth between two points.
This gives us some moving, blinking, spinning crap to look at, which saves the game from looking too static.