(Reposted from Shamus’ Good Robot Devblog)
So the team is back from Europe and the public has played the Pyrodactyl build of Good Robot for the first time. Here are the notes and observations from this ad-hoc playtesting, along with my commentary:
1. Weapons with charge-up need a spinning animation so there is visual feedback that the weapon is doing *something*. Many players need to be told to hold the mouse button down in cases like the minigun.
 |
As I mentioned last time, we’ve added a ton of guns to the game. One of the things that makes a videogame gun interesting is its firing rhythm. Some guns fire the moment you pull the trigger, but then have a long cooldown before you can fire again. (Doom 2 double-barrel shotgun.) Some spew out bullets instantly but have reload intervals that must be accounted for. (Half-Life 2 machine guns.) Some games have a long spin-up time. (The Team Fortress 2 Minigun.)
It’s this spin-up idea that’s a problem right now. Currently, a player using the minigun will have audio as their only cue that the gun is doing anything. They will depress the trigger and hear a long wind-up sound before the gun starts firing. Obviously on the show floor the player was effectively deaf, so it felt like the gun wasn’t doing anything.
But even in a more normal play situation this is clearly bad. Maybe they’ll have the volume turned down. Maybe there will be so much chaos around them that the spin-up sound will get lost. The barrel needs to rotate as the gun spins up, a light needs to come on, and maybe some particle effects.
2. People try to shoot the glowing machines because anything glowing = enemy. If you can shoot machines and they spit out all their robots and then they go dark, that would be great.
 |
We’ve added these robot factory machines to the game that produce robots for you to fight. Each room has a few factories, and a fixed pool of robots in reserve. As the player fights, the factories take robots out of the spawning queue and add them to the gameworld. Right now there’s a population cap. There can only be N robots in play at any given time. Once N robots exist, the factories will stop adding more until the player kills a few. Once the queue is empty, the factory goes dark and it stops spitting out robots. This is a good first draft of the idea, but it’s clear we need to iterate a bit.
I’m not sure if the current population cap could be higher or lower, but what I don’t want is to build a game around fighting 300 robots and then find out it’s not possible to get that running smoothly on our target platform, known colloquially as “old laptops”. It’s much easier to relax the restrictions late in development than it is to lower them, since the latter requires changing huge parts of the game. So we’re keeping population counts low for the time being until we get the gameplay ironed out.
What happens is that people try to attack the machines that are releasing robots. That’s a perfectly valid thing to do, but right now the machines don’t take damage. In fact, your attacks pass right through them. This is unsatisfying and dumb.
There are a lot of ways of handling this. No matter what, machines need to react to player fire. Maybe they should be invincible, but release robots when hit? (Provided we’re not at the population limit.) Maybe after taking X points of damage a machine should shut off? Maybe it should be destroyed entirely, removing the device from the gameworld?
We’re leaning towards giving the player as much power as possible. More interactivity = better. I also like the idea of machines releasing robots as they’re hit. So if you keep shooting a factory, it keeps spitting out robots to attack you. This is a problem that will solve itself. Eventually the crowd will be so big you’ll have to stop shooting the machine and pay attention to the robots.
It will take some playtesting to get a feel for how tough factories should be, how fast they should release robots, and what the population cap should be.
3. There are machines in the first and final room where robots cannot spawn. Machines should only be in rooms where enemies can occur.
Yeah. That’s something I wanted to fix before EGX, but ran out of time. Right now factories will appear in rooms even though there’s no robots to spawn. Silly.
4. Doors need to be signposted better. Many players try to shoot them thinking they are enemies. If the door you shoot opens it would be much better.
 |
It’s really surprising to me that I overlooked this detail, given that this game began as a “2D Descent”. In Descent you could open doors by shooting them. In fact, that was the preferred method of opening doors, since slamming into them face-first felt stupid.
5. We only have 3 door icons, we should include more types of rooms.
Whoever wrote this note wan’t talking about “rooms”. They were talking about “zones”. Let’s talk about nomenclature problems.
Here are the names for some of the things in our game:
A ROOM is a single 24×24 chunk of the gameworld. In the code I actually called these things “pages” for some stupid reason. The internal structure of a room might look complex. There might be side-tunnels, alcoves, cul-de-sacs, tight corridors, or whatever, but they’re all part of the same room. Rooms are arranged linearly. So the first room leads to room 2, which leads to room 3, etc, all the way to the final room. It might seem more complex than this to the player because their camera is zoomed in and they can never see the big picture.
I keep wanting to rename PAGES to ROOMS in the code. But then I talk myself out of it because that’s not a good use of time. But having a system named something dumb is really annoying. Someday my OCD will overcome my pragmatism, but it hasn’t happened yet.
A ZONE is a linear collection of rooms. A zone can have a distinct color scheme. A zone begins with an entry room, and goes through a linear sequence until you reach the final room, where there will usually be several exit doors. Each door leads to a different zone. Maybe one zone has a shop, another zone has an upgrade station, many zones are simply straightforward robot fights, and the last zone is a final boss. There are supposed to be icons on the doors, letting you know what sort of zone it leads to. When the player chooses a door, the screen fades out and they appear in the chosen zone. (You can’t go back.)
A LEVEL is a collection of zones. The player will be allowed to choose what order to visit the zones in by choosing doors. A level uses a common tileset an theme. So one level is a garbage dump, another is caverns, etc.
Picture Spelunky: A zone is a single trip to the exit, while a “level” is like, “the ice level” or “the temple level”.
“Hey Shamus, it seems like it would make sense to swap the names of levels and zones. See, in the games I’ve played…”
Sure, you can argue about this stuff all day. For the record, “zones” were added late in development. Re-naming complex, far-reaching classes in source code is an annoying hassle. SWAPPING names is doubly so. Even once you’re doing juggling all those lines of code, you still have to swap the ingrained names inside your head.
I named these concepts in the code, but since the rest of the team doesn’t read the code they don’t use the same nomenclature I do. Which is understandable. If I’m looking at a 6-sided solid in a Quake level, I’m probably going to call it a “cube” and not a “brush”, which is what Carmack named them in the code. (For some reason.) Sometimes the rest of the team uses the words “level” and “room” interchangeably with “zone”.
It’s confusing to me to have everyone using random words for things, while I’m sure it’s annoying to artists to constantly be corrected when the terms all seem arbitrary (if not counter-intuitive) from their standpoint.
I wonder how larger teams handle this programmer / artist division of nomenclature. It seems like this problem could get pretty big and out of control when you’ve got ten times as many people and a hundred times as many concepts.
Right now we have zones built around:
1) Shops. (Vending machines.)
2) Upgrade stations.
3) Regular mook fights.
4) Boss fights. (Always the last zone.)
We need more variety. Maybe some that are rare, like the Spelunky “undead” level type that randomly pops up once every few games. Maybe some doors should be mysteries so the player doesn’t know what they’re going to get. More variety = more interesting.
6. Spawn points should play a little animation/light sequence and say “checkpoint activated” or something, so players know what they are.
 |
The game is a rogue-like. But you can buy a warranty for your robot so that if you die you respawn at the start of the level. (These warranties can only be purchased at shops, and escalate in price, so you can’t just trivialize death with warranties. This takes the harsh edge off of death, while still requiring you to master the game in order to have a serious chance of reaching the end.)
We need to communicate to the player what’s going on with this respawn machine. We could call the respawn machine “repair station”, but then players will try to interact with it, hoping for repairs.
Essentially, shooting everything should do something because players shoot everything. Everything that does something should react to the player shooting it, hopefully in a manner that shows what it actually does.
7. Basically, EVERYTHING needs to be interactive.
As Arvind said in a meeting, “Our game only has one verb.” The player can only shoot things. So we need to make the game responsive to that. This doesn’t mean everything needs to be destructible. But it does mean that everything needs to react to bullets in some way.
So that’s how things went at EGX. Arvind says people’s reactions were “very positive”. So I think we’re on the right track.
Posted In: Games, Good Robot
Tagged: good robot