Reposted from Shamus’ Good Robot Devblog
Some other indie developers were nice enough to play the game and send us their feedback. A common theme in the feedback was that things were too chaotic. Or too random. Or unfocused. Or too busy.
Looking at the game, it’s easy to see why, and it’s easy to see how we slipped into this state. We made a system that let you make wildly divergent robots, simply by tweaking a text file. Since creating robots is easy and variety is good, then more robot types = more good, right? Aren’t games always bragging about how many enemy types they have? Isn’t this a selling point? “Fight over 12 different enemy types!” it says on the back of the box.
Only 12, AAA game? Pshaw. We have that many in the first 15 minutes of the game!
It made sense at the time, but when the feedback rolled in it was a forehead-slapping moment for all of us. Of course this will seem like random chaos to someone who hasn’t played the game constantly for 6 months.
It’s like a version of Half-Life 2 where your first fight is against a group of foes with the behaviors of an antlion, a zombie, two soldiers, a metrocop, a strider, and a gunship. It’s not about being “too hard”, really. Even if you lower the hitpoints and damage output on the gunship and the strider to bring them into line with (say) a metrocop, the player still can’t be expected to parse all this chaos. They’re not going to appreciate the differences between the soldier and the zombie when both foes die in the same panicked volley of weapons fire.
The Debate
 |
I have to be careful and diplomatic here, because the team isn’t in agreement on what needs to be done just yet, and I don’t want to use this blog as a bully pulpit to sell my vision of the game and discredit theirs. There’s a lot of debate on how much of a tutorial we need, what form it should take, how long it should be, what concepts it should cover, and what coding changes we should be willing to apply to make it happen.
Sure, as a senior member of the team I could probably throw a tantrum and get my way, but bullshit like that is how you end up with Kai Leng. Assuming you’ve got a good team of smart people, then you should be worried about any idea you can’t sell to them. Maybe they’re just too dim to see the grandeur of your vision, but maybe there’s something wrong with your idea and you need to discover that flaw through debate. To put it another way, if the smart people on your team aren’t buying your idea, how will that idea fare with players? You planning on arguing with them, too?
All of this sort of sums up my creative / managerial / philosophical outlook: Hire smart people and trust them to know their jobs.
But here is my thinking on the matter anyway:
Building Complexity
 |
We’ve been taking things for granted, but there’s actually a good bit of complexity in our game. This is good, because it means there’s a lot to keep people engaged. On the other hand, we need to be careful about how much of that complexity we deliver at once. Here are what I consider to be the core combat concepts of the game, from the simple to the challenging:
The Fundamentals: The player can fly across the room and hit a stationary target. The game looks like a twin-stick shooter, inasmuch as you have two sticks for aiming and moving. (Mouse and keyboard also works, and is how we do most of our testing.) But you don’t just press left on the stick to shoot left, because your weapons fire at different speeds and have cooldowns. You wouldn’t want to continuously fire the Half-Life shotgun as you walk forward, after all. It’s a weapon that requires timing. A lot of weapons in our game – like the “shotgun” style stuff – are designed so that you want to fly right up into a robot and nail it at point-blank. That feels really fun, but it’s incompatible with the spammy twin-stick style of gameplay.
So if the player is new to twin stick shooters, they need a minute or so to get used to the idea. If they’re familiar with the genre, they need about the same interval of time to see how this game might diverge from their expectations.
Basic dodging: The player can evade incoming bullets. Pretty straightforward. The Good Robot actually has a tiny bit of heft. It takes a fraction of a second to accelerate and change direction. I think we just need to give the player a little bit of time to get used to their movement speed and inertia.
Hitting fast-moving targets: The player can properly lead a target. This will vary from weapon to weapon, so every new weapon will have a bit of a learning curve associated with it. That’s fine, but the player needs to get some practice shooting at speedy targets before we dump other challenges on them.
Melee attackers: The player needs to spot and prioritize melee attackers before they can close the distance. Melee attackers are fast and do high damage. Worse, they knock you around, which tends to be disorienting. The player needs to learn to spot melee foes. Originally I made melee foes out of saw-blades to telegraph their nature, but I’ve lost track of our visual language since handing the art off to those more qualified. I spend most of my testing time on one dev level with my own testing robots. I don’t know what (if anything) we’re using to convey the idea of melee foes.
Missiles can be shot down and evaded: This is a tricky one. If the player acts on instinct alone, they might simply try to back away from missiles. This won’t work, since missiles are faster than the Good Robot. Missiles have a terrible turning radius, so you actually need to move perpendicular to their flight path to avoid them.
I’m not sure how to “teach” this. I’m very much against the idea of popups that just spell things out for the player. It’s ugly and often feels patronizing. Players enjoy figuring things out for themselves. Valve is actually really good at constructing scenarios where they funnel you into a course of action but trick you into thinking it was your idea. That kind of balance takes a lot of time and iteration. We don’t have the resources to finesse scenarios like that, but I’m not eager to give up and just tell the player what to do with popups.
 |
The above image is a great illustration of Valve’s ‘invisible tutorial’ technique. The table is there to force you to get out the gravity gun. Now that you’re holding the gravity gun, it’s probably more expedient to use it to yank the saw blades out of the wall, as opposed to crawling under them. Once you pull the saw blade loose, a zombie will come around the corner and you’re very likely going to reflexively fling the blade at them. The half-zombie on the right is there to give you a subliminal shove in the right direction. And when you discover the usefulness of saw blades, you’ll feel like you figured it out yourself instead of just doing what some obnoxious NPC told you to do.
Luckily, we don’t have any mechanics quite this complex to present, but “How do we teach them to properly dodge missiles?” is still an open question.
Suicide bombers: The player needs to spot and prioritize bombers. I never did figure this one out. How can you telegraph that a robot is going to blow up? I mean, you can just make bombers look like another random robot and let the player learn to spot one through brute force, but I don’t think that’s really satisfying. Or at least, it’s better if we can develop a coherent visual language for the game. Should they be red? Blinking lights? A warning sound seems obvious, but we already have a warning beep when missiles are homing in on you, and the two sounds together would just make for cacophony and confusion. Although you could solve it by simply never having homing missiles and bombers on the same level. But that seems kind of limiting, in the long term.
Mine layers: The player needs to recognize and deal with mine layers. Mine robots dash in, drop some mines, and then sprint away. The mines they leave behind will limit your ability to move freely. It’s a pretty good mechanic. Ross actually came up with this. It wasn’t something I specifically designed the game to do. He just figured out how to make it work within the existing systems. (The “mines” are really just suicide bomber robots with their movement speed set to zero. Although now that I think of it, a really slow speed might be better, to make them slowly creep towards you and force you to deal with them.) These were interesting when they were first introduced, but they get lost in the chaos now.
Link (YouTube) |
There are other concepts that the player needs to learn about: Their secondary weapon, the vending machine upgrades, buying a warranty. But these aren’t really combat concepts, so I’m sort of setting them aside for now. These are things that the player can learn somewhere outside the pressure of combat. And I actually wouldn’t mind tooltips for these, although obviously having the player discover these things organically would be even better.
My thinking is that we should adopt a Valve-style approach to teaching concepts. Let the player face A. Once we’re sure they’re comfortable with A, then set A aside and let them face B in isolation[1]. Once they’re competent at dealing with B, we can let them face A and B together. Then take A and B out of play again and give them C. And so on. Late-period Mario levels work in a similar way.
That sounds simple enough, but it’s a little more problematic than that because the game is a bit like Spelunky. There’s not a fixed progression of maps but instead a pool of possible encounter types that the player will draw from, and this is driven both by player choice and a little bit of dice rolling. It’s easy to say, “Make the player master A before they face B”, but it’s not quite that simple when you don’t have direct control over when they encounter B for the first time. And imposing strict linearity is probably a terrible idea for a game designed specifically for repeated play-throughs.
Complexity Can be Good!
 |
The problem isn’t that there’s no solution to the need for clarity and teaching. The problem is that there are a dozen ways to approach this and we need to nail down the best one as quickly as possible.
On the upside, I think we’ve really solved the blandness problem that made me abandon the project a year ago. The new ideas that everyone else brought to the game have given it the kick it needed. And I think it all came together in a short time, all things considered. But now we need to fit these ideas together so the player can make sense of them.
We have a little under a month to solve this. We want the art assets finalized before the end of year, which would just leave Arvind and I on polish and bug-fixing duty until the game goes “gold”.
Fingers crossed.
Posted In: Games, Good Robot
Tagged: good robot, video games