Good Robot #35: EGX Feedback

By Shamus
on Oct 7, 2015
Filed under:
Good Robot

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.

KILL DEM WITH MENY BULLITS

KILL DEM WITH MENY BULLITS

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.

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.

Factories. Ignore the low FPS in the corner. I was taking screenshots in Bandicam, which for some reason tanks the framerate if you do too many at once. The game is normally a stable 60fps. (On my machine, anyway.)

Factories. Ignore the low FPS in the corner. I was taking screenshots in Bandicam, which for some reason tanks the framerate if you do too many at once. The game is normally a stable 60fps. (On my machine, anyway.)

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.

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.

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.

You actually have to get close to the doors before they`ll open.

You actually have to get close to the doors before they`ll open.

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.

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.

Spawn points should play a little animation/light sequence and say “checkpoint activated” or something, so players know what they are.

The green thing is where you`ll respawn if you die and you have a warranty.

The green thing is where you`ll respawn if you die and you have a warranty.

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.

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.

Enjoyed this post? Please share!


202020203There are now 83 comments. Almost a hundred!

From the Archives:

  1. Benjamin Hilton says:

    The real question is where we can get our mitts on some Good Robot swag. Will the be a store, or do we have to show up to a con and wait for Arvind to bring out the T-shirt gun?

  2. Zoe M. says:

    Have you thought about marketing yet? A 2d roguelike platformer is going to be a bit of a tough sell on Steam these days all by its lonesome… I’m worried about this being utterly lost in the shuffle.

    • Ilseroth says:

      Well, it’s a shooter not a platformer, but to the actual point.

      It is clear that Pyrodactyl has someone they go to for PR, as both Unrest and Will Fight got articles on key news websites. You may question whether that matters, but these websites get literally hundreds of games offered on review on a daily basis. While both of those games had unique concepts, the fact Pyrodactyl is fairly small studio means they have someone that acts as their PR guy enough to pull some strings.

      In addition to that Shamus has worked for Escapist for a while, so there is a good chance he can at least get reasonable price on ad space, if not straight up free.

      The third piece would be getting the game noticed by content producers (streamers/youtubers) which comes down again, to their PR guy. The previous games were heavily story based, which means that they are pretty hard for content producers to cover, and if they cover it extensively (full playthrough) the viewer isn’t too likely to pick up the game themself. However with Good Robot’s focus on gameplay mechanics means it is much more likely to get coverage.

      Based on what most content producers I know of say, they have a few people they trust to give them good games, and the email has to be succinct, and to the point. Offer the game straight up, say what it is in a few lines, a code for a review copy on steam and after that maybe a gif of gameplay/link to gameplay video so they can quickly see what they are diving into. You can put more info then that, but they are busy and just looking for content for their channel; make it too hard for them to get access to the game and they won’t.

      • Zoe M. says:

        I see you watched that TB video ^_^
        Incidentally, a 15 minutes of game would prolly be a good catch for Pyrodactyl here. It might be something TB would try out.

        • Ilseroth says:

          Not just that, several streamers have literally said the same thing on several occasions. A lot of the larger streamers (and youtubers) take in a lot of requests to cover their game. One streamer, who isn’t even *that* big (average of 1.5-2k viewers) specifically said that he gets a dozen games sent to him daily. Since he is a focus streamer (plays one game most of the time) he only covers maybe 1 random game a week.

          Also as someone who does game development as a hobby (mostly game jams for now), I have a vested interest in the particular topic so have done a bit of research on my own. But yeah with regards to getting Content Producers on the indie bandwagon, TB’s video was pretty spot on.

          • Galad says:

            As much as I don’t like the guy anymore, ManvsGame, the twitch streamer, is a great promotional tool, no pun intended. He normally gets “only” 2-5k viewers, because he usually has submode on (meaning that only people who pay him 5$/month get to use the chat), but has 400k followers. He’s promoted both big games like Witcher 3 or Shadow of Mordor, and smaller games like Crypt of the Necrodancer (while it’s indie, it still has sold something in the range of a few hundred thousand copies), the latter of which is one of my all-time favorites on steam, and still the game I’ve played the most amount of hours.

        • Mistwraithe says:

          What TB video?

    • methermeneus says:

      Well, Pyrodactyl does already have some games on Steam. “From the makers of Unrest and Will Fight for Food” should help.

  3. Eric says:

    Great article and it looks like you’ve come up with good solutions for those problems. It’s funny how the best-laid plans never survive first contact with the player. :)

  4. Da Mage says:

    I am not a fan of your solution to the factories….as having something ‘spawn’ enemies as you shoot will make players want to stay there and kill EVERYTHING before moving on (especially if they figure out that it will eventually stop spawning if they kill enough).

    It’s not an easy problem to solve, but another idea would be to have the factories either visually ‘shield’ from an attack (to show the player’s attack does nothing), or even have the attack reflect off (again, shows that the attack does nothing). I like the reflect personally, as it quickly shows the player’s attack will do nothing to a factory…whereas some people may still spend time to try and ‘break through’ a shield effect.

    • KingMarth says:

      Yeah, when you try to kill an enemy spawner it’s usually because you expect that to cut off the supply of enemies. If that makes enemies spawn faster without changing the stock, because there’s a fixed stock anyway, that strikes me as a trap option; if we know the rules then it’s a neat way to self-select difficulty, but this is a roguelike and unintentional difficulty spikes have serious consequence.

      On the plus side, you don’t need people to even realize that this is a spawner because the stock will run out. On the minus, you’re setting up a situation where I’d personally expect that I wouldn’t be able to progress without diverting shooting over time to take out the spawner. Making them visually invulnerable (reflection would be neat, as bounce shots could still kill bad robots) might help indicate that they are spawn points for enemies rather than targets to be destroyed.

      Dealing damage to the next robot in queue would also be nice, rewarding you for not dealing with present threats by cutting down on future threats.

      • Syal says:

        I was thinking that too; maybe if you shoot a factory it releases more robots but they’re all at reduced strength.

        Making them a whole lot bigger might do it too, so they don’t look like they’ll go down easily. Or even shove them into the background where players will know they can’t hit them.

        Or give them the old Super Mario Star flashing yellow invincibility color.

        • Wide And Nerdy says:

          I was going to suggest something like this too. Assuming the robots can take multiple shots, have them spawn having taken some damage (especially good if you have some visual indicator that they were indeed damaged, maybe they spawn trailing a little smoke or sparking).

          The reduced strength idea suggests that robots are rapidly assembled and that your shots are forcing the robots to be ejected into play before they’re completely ready. If thats how your world works, that could be an interesting idea.

          Going off the shield idea above, it might be neat if the shield kept the factory from being able to eject more robots for a moment. By periodically firing at the factory, you could constrict the supply line and keep the number of robots in play down to a more manageable number (not having played, I don’t know if this is practical with the player’s fire rate and maneuvering characteristics.)

          You could even have both of these types of factories to change up level design. In either case you’re giving the player power via tradeoffs.

          Also, I’ve been meaning to say. Its clear from the screenshots, your game is going to be a visual treat. I even liked the basics of what you were going for visually before you brought in Pyrodactyl.

      • Felblood says:

        You’re fighting decades of action arcade traditions here.

        The Gauntlet Commandments:

        1. Thou shalt “Learn to Block!” [scrub]

        2. Thou shalt “Destroy generators to stop Enemies!”

        3. Thou shalt “Collect gold to buy power ups!”

        4. Thou shalt “Save Keys to open doors and treasure chests.”

        5. Thou shalt “Use Magic to kill enemies!”

        6. Thou shalt “Avoid dangerous objects!”

        7. Thou shalt use “Multiple hits [to] destroy secret walls.”

        8. Thou shalt “Use magic to kill death.”

        9. Thou shalt covet thy neighbor’s gold, or thy neighbor’s food, or anything that is thy neighbor’s.

        10. “Thou shalt feel my fury!”

    • NoneCallMeTim says:

      About factories: if I see a factory which produces robots, and I shoot it, the expected outcome for me is that the factory will die and stop producing robots.

      I think that you could have it that it starts releasing robots as a defense, but there needs to be some kind of visual feedback that the factory is taking damage. Also, if it is taking damage, destroying it before it has released all the robots could give some kind of bonus based on how many unreleased robots there are.

      This would reward players for hitting an important part hard.

      Otherwise, it seems counter-intuitive that shooting the factory could result in being a ‘produce more robots’ button.

      • Trix2000 says:

        Yeah, I feel like either shooting factories needs to have some significant benefit (either cutting off respawns, or maybe just money/exp?) or they should just be visually invulnerable.

        Maybe it could be just as simple as making them destructible with no other effects (expect maybe a bit of money or something)? That way players would be incentivized to shoot them to cut off respawns, but they aren’t obligated to and they’d still be fighting similar numbers of enemies anyways.

      • Rick says:

        I like this as the best option… Shooting a factory releases more robots as a defence as the factory visibly takes damage.

        Nice idea with the bonus for destroying the factory before it can release all its robots… Maybe slightly higher XP than from killing those remaining robots normally? Of course this assumes that each robot produces a fixed amount of XP with no bonuses for trick shots. Maybe just the XP from the queued robots plus some from the factory.

    • methermeneus says:

      I like the reflecting idea, both because it’ll be a good cue that the factory can’t be destroyed (unless letting them be destroyed isn’t a problem for your game design ) and because that could lead to some interesting strategies for fighting the spawned robots. Say, you’re using a gun whose projectiles don’t normally bounce, but you’re at a bad angle to hit one of the robots, you could bounce shots off the factory.

    • Zak McKracken says:

      One solution that looks good to me: Yes, make factories destructible but yes, they also spawn robots at increased rate while you shoot them, and they take a fair number of hits.

      That makes it a viable though not always advisable strategy to shoot the factory rather than the robots. But if you manage to destroy it, there will be fewer robots overall to fight because you prevented the production of all the robots left in that factory’s queue.

      … so yeah, that would have to be balanced well…

      • Mistwraithe says:

        You may want to have some visual feedback about how many robots are left to be released too. Eg a bar of light, or all the lights, on the factory could drop as robots are released. Normally the bar might drop by one unit for each robot released while shooting the factory might release one robot but cause the bar to drop by 2 units (or release two robots and drop by 3 units, etc).

    • zookeeper says:

      Assuming that the population limit is in place for balancing reasons and not technical reasons, destroying a factory could just release all the robots it was ever going to spawn, instantaneously, although of course there could also be a cap. As suggested, they could spawn with various degrees of damage or otherwise seemingly in an unfinished state.

      Of course this would need to be balanced so that usually you wouldn’t want to do it (except when you know there’s only a few robots left), so for example there couldn’t be much weapons (say, a bomb) with which you could, if timed well, kill all the released robots as soon as the factory blows up.

      However, it could provide a much faster and satisfying way for an expert player (or one just otherwise feeling bold) to clear a room. Instead of waiting for the robots to spawn one at a time, blow up the factory and you get to fight a huge swarm of them at once.

    • Nidokoenig says:

      The problem could be solved by replacing factories with portals. Maybe the factory and portal mechanism are somewhere in the level so an intrepid explorer can find them and destroy them, or they’re outside the level and the portal just spits out robots, like those purple line portals in Descent 2. Or a delivery chute that the player can dive into to fight a lot of enemies quickly to clear out large areas of the level, so that skilled players can speed up the early game.

      There’s a limit to how far you can go with mitigating the underlying issue that you can destroy every mechanical thing but the factory. It’s infuriating in a shooter when something bleeds when shot but takes no damage, and in this game “If it clanks, we can kill it” is an intuitive rule you should avoid breaking if possible.

    • Corpital says:

      In a game I helped design for a university project a few years back, we made the spawn pool of the spawner its HP and gave it some damage reduction.

      So as it spawned enemies, its HP gradually went down and if you kept doing damage, you could skip several spawns. We went with a standard HP bar, but slowly dimming lights could work nice here.

      • Nidokoenig says:

        There’s a feedback issue there, you want an attentive player to be able to read the damage done either way, so gently dimming lights is going to be a poor fit. A bank of lights that go out, a bit like a HP bar or heart meter, would be good for readability.

    • Lachlan the Mad says:

      Yet another different idea for the spawners; if you want to keep a system where shooting the spawner makes it spit out its enemies, you should add a visual gauge of how full the spawner is. You could put numbers on the yellow side parts which indicate the number of robots remaining, or turn the yellow parts into meters which turn black as the spawner shoots robots out. This way, the player gets visual feedback on the spawn cycle:

      “Hey, when the spawner shoots a robot, that number/gauge goes down. It must be telling me how full the spawner is.”

      “Oh wow, when I shoot the spawner, the number/gauge goes down, but it makes the spawner shoot out another robot. I guess that shooting the spawner makes it drop more robots.”

      I’m not sure about the idea that shooting the spawner makes it launch extra bots — I’d prefer it if the spawner could be outright destroyed without dropping a full load if you concentrated fire on it — but if you do want to go with that idea, this should help to clarify it.

    • John Beltman says:

      If you allow the player to shoot factories the game will be about destroying factories rather than destroying robots. The robots will just be the punishment for not destroying every factory you see fast enough. I like the visible shield idea as well. If shots ricochet off the shields then the player can still interact with the factories and can try some cool bank shots.

      It might be frustrating having something that belongs to the enemy in view and not being able to destroy it. What was your reason for introducing factories in the first place? What do they add? Can you just get rid of them again?

      • Naota says:

        Factories are used as a sort of pressure gauge to allow for longer, bigger fights without overwhelming the player. You can battle, say, a trickle of 20 robots in a tunnel without turning the corner and bumping into all of them all at once – or fight 5 waves of 10 in an arena instead of the room being a single swarm of 50.

    • Naota says:

      What do you guys think about the factories simply turning off for a limited duration when shot – maybe losing most of their lights and visibly self-repairing somehow until they turn back on? Or instead, closing up on themselves and reflecting bullets? As a design dilemma this is a pretty tough one, because:

      -Factories produce the lion’s share of certain rooms’ enemies, so destroying them all could make some rooms dramatically easier by trapping the spawn queue in limbo.

      This isn’t terrible. On the other hand, we don’t want the natural flow of gameplay to involve destroying all of a room’s robot factories if the optimal way is to spawn trap the enemies for their drops. Or if factory-shooting is optimal but not fun/challenging.

      -Robots spawn in three ways: when the level is created, when the player nears a factory and there are ‘bots in the queue, and when certain bots spawn other bots. Spawner bots already fill the role of a renewing, destroyable threat.

      Some rooms have many pre-spawned enemies; others have none (or one specific type, like minefields) but spawn in waves to fight the player. This makes spawn factories a fixture of the level rather than an enemy. Blowing them up is a bit like being able to destroy the cannons in Super Mario, rather than just the Bullet Bills they shoot.

      -Robots are the main source of resources for the player. Fewer enemies faced means less power for them going forward. Since the game difficulty increases with each level, choking off a room’s supply of enemies, even if it is fun, challenging and tactically sound, may leave the player starved for resources in future levels.

      • Supahewok says:

        I think the easiest way to handle it is to make the factories part of the background, in the distance,where they can’t be touched. If they were in the background, you’d just have add some code to show the spawning robots moving from the background to the foreground (provided that the backgrounds are set up to allow moving graphics). Then you just have an invisible spawner at the point you want enemies to come in, and when the background image lines up you spawn the enemy while the background image disappears. Add some visual feedback of a factory starting up, getting halfway down the spawnlist (lights start to fade, or blink, or turn red), then closing down. Maybe make the lights the same color as the enemy type they spawn.

        I dunno, it sounds kind of like a hack, but it saves y’all the trouble of trying to develop new mechanics and testing and balancing them. Providing its feasible in the engine as-is.

        • Felblood says:

          I’m not convinced that this needs to be a binary decision.

          One of the best ways to communicate to players is by allowing them to compare, contrast and sort. So, why not have both types of spawners? You’ll want to test them both, so you might as well use them together.

          This way players can destroy some of the factories and slow the onslaught of foes, but they can never completely block the que from spawning. Small victories can taste sweet.

          With all the variety of bad robots, it wouldn’t be totally crazy to implement a variety of different factories, with different risk/reward paradigms for attacking them. e.g. One could introduce destructible factories with large, inactive turrets. Shooting the factory activates the turrets, adding to the challenge of the encounter.

          Depending on how much you want to invest, you could take factories in all manner of crazy directions. Bosses that have factories on their backs; large robots that you want to kill before they have time to unfold into factories, or even open portals; Factories that are camouflaged as terrain…

      • Da Mage says:

        I don’t feel factories should need to be ‘stopped’ or functionally changed at all, in fact changing their functionality at this point would most likely cause more usability problems (as functionality changes normally do).

        All that is needed is to have visual cues to inform the player that they cannot effect the factories. Either a shield, reflecting attacks, placing them into the background etc. HOWEVER, if the goal in the game is to make everything on the screen intractable with shooting, then the whole factory concept may need reviewing.

        One thing I forgot to mention in my original post is that having more robots spawn when a factory is hit, may make players avoid area of effect or spray weapons in areas with factories for fear or accidentally hitting them and having more enemies appear. I notice in one screenshot there are 5 factories really close, could you imagine firing a bomb and hitting multiple factories at once? Would not be much fun.

      • Nidokoenig says:

        It’s a robot shooting game, so if it clanks, the player should be able to kill it, and a factory clanks like a motherfucker. Ergo, use a different metaphor, like a portal or delivery chute. The fact that you have to put so much thought into how to disabuse the player of the notion they can kill factories makes a pretty good argument for putting a different gloss on the mechanic if you aren’t going to make big, big changes to it.

        Alternatively, make killing factories perfectly valid, give the player the same exp as killing the robots individually, then track how many factories the player destroys and make different endings. The more factories standing at the end, the easier it is for the Good Robot to rebuild, maybe. You lower the skill floor to beat the game and communicate that there is value in mastering the system, like how Metroid games are easy if you get 40+% completion but are a totally different ballgame if you go for sub 10%, and the difference is the victory portrait.

      • Cuthalion says:

        Personal opinion, if you don’t really want destroying factories to feel like the obvious One Best Way to play:

        When you shoot a factory, it goes to red alert. Its windows starts flashing with red lights, and an alarm starts blaring. It starts pumping out its remaining queue rapidly. If you focus on it, you still have good odds of finishing it off before it spawns all of its robots.

        So, you’re taking a risk to get a long-term advantage. The red alert makes it obvious that, by shooting it, you are both damaging it and alerting it to your presence, both progressing and making things harder for yourself.

  5. nerdpride says:

    Spelunky was pretty neat. Interesting that you compare Good Robot to it.

    Are there other neutral robots that don’t attack? I don’t know if that would serve any purpose. Possibly confusing if a player didn’t want to destroy everything.

    Back in the day in Marathon (Bungie’s first shooter game, pretty neat for its time) there were these civilian characters called “BOBs” who were sort of rescue objectives sometimes, otherwise cannon fodder, also often a trap. I don’t know if that would work for you, just an interesting thing this reminded me of.

  6. Abnaxis says:

    Ooh, you should make it a “Good Factory” and adjust the little windows in it so it looks like a factory version of the titular good robot

  7. PeteTimesSix says:

    “Eventually the crowd will be so big you’ll have to stop shooting the machine and pay attention to the robots.”

    You greatly underestimate my stubbornness, good sir.

  8. Re: the spawning factories. I remember seeing portals that spawned enemies in dungeons and raids, and the visual difference was that portals you could shut down had enemies around them visually doing something to it and you’d kill ’em. Perhaps the factories could have a few robot repairers or something along those lines? Factories under attack spawn repairers instead of regular guys who will both attack the player and try to fix or shield the factory?
    Just a thought from someone who loves hearing about this game, but is probably not your target market (I’m sure I’ve played a roguelike or two, but I doubt I got far, I like exploring and story and seeing the worlds, challenge I can take or leave and much prefer it in a group of friends)

  9. Dev Null says:

    I’m wondering if you’re pushing – or planning on pushing – your celebrity-factor in marketing Good Robot. “Good Robot: a game by Shamus, maker of DM of the Rings, and Pyrodactyl, makers of Will Fight for Food”… or something like that.

    You’re going to argue that it’s a fairly limited celebrity – which is probably true, at least by the standards of AAA games – but it still exists. I don’t know how much _forward_ publicity for Good Robot that gets you, since folks on this blog or following your Escapist column are already pretty aware of GR’s existence, but if it takes off to any degree it might generate a little _backwards_ traffic to your other projects? Genuinely not sure either way, which is why I was curious about your plan (assuming you have one…)

    • Supahewok says:

      I don’t think he’s actually brought up Good Robot in its current state of collaboration in his Escapist column, so Escapist readers wouldn’t actually know about it.

      He should be able to make some sort of promotional deal with the Escapist. God knows that they promote anything Yahtzee does, they ought to be able to toss Shamus a bone.

      I also think that Pyrodactyl is most famous for Unrest. I actually saw reviews for Unrest, which is more than I can say for Will Fight for Food.

      But as to your wider point about marketing, yes, now is the time to be thinking about it. Indie games live and die by their exposure. It may be hard to tear yourself away from the finetuning of the final stages of development, because of course you want to make the game the best it can be, but without promoting yourself to the review and news sites, even the best game in the world is going to disappear in the abyss of the internet.

      • NoneCallMeTim says:

        Agreed. Start early. Sound out the Escapist and any other gaming sites that you have contact with. Look at what worked well with Unrest, and any gaming sites which took up on that, and see if they are willing to do a follow up piece for another game.

        • Phill says:

          Use the Escapist connection to see if you can get Yahtzee to slag the game off. There’s (almost) no such thing as bad publicity, and lots of views of Yahtzee being rude about a game is still going to generate a certain number of people saying “that actually looks kind of interesting” or “he didn’t hate on it too much, might be halfway decent and worth checking out”.

          Just don’t expect him to like it.

          Of course I doubt this is actually going to happen, for the same reasons that it is hard to get any prominent youtubers to cover a new game.

  10. Gabriel Mobius says:

    Maybe an idea for the spin up is either particles flowing into the ‘gun’ part of the robot, or having the ‘gun’ glow brighter until it starts firing? I’m thinking something like the charge from a Megaman X game, that’s a pretty good way to show that something is ‘charging’.

  11. Orillion says:

    You could call the checkpoint a “dispenser.” Good balance between clarity of what it does and in-universe cohesion.

    • Jakale says:

      Sounds a bit much like a name for the factories or the shops, things that dispense on a frequent basis. Since the main goal is to get good enough to not die for a long time, dispenser feels like it suggests more frequency than the goal of the game gives it.

      Since we’re trying to avoid it sounding like a repair station and they’ve got a sort of Portal/Borderlands company naming structure going on, maybe something like Warranty Convenience Station to link it to its purpose without suggesting it can help you hold out longer, like Reconstruction/Repair Station or similar might do.

  12. WWWebb says:

    Monster factories make me think of Gauntlet. That reminds me to ask about potions!

    If “the player can only shoot things”, does this mean there are no “specials” to clear a screen?

  13. Wide And Nerdy says:

    In the code I actually called these things “pages” for some stupid reason.

    Don’t feel bad. I used to have to get reports from our ticketing system where we discovered that the tables were all named incorrectly. Interactions were stored in the “Incident” table, Incidents were stored in the “Problem” table, etc, etc. (these terms have specific means in the ITIL standard we were trying to adopt). Not to mention there was needless duplication of tables (my guess is they were using tables in place of data views at first).

    Point is, it can get mad stupid under the surface.

  14. TMC_Sherpa says:

    Obviously Good Robot needs chest high walls. How am I supposed to know I can shoot things without that visual queue?

    No wait! Star Wars tie in! You’re BB-8 and you have to shoot probe droids on Hoth!

    Actually, who wants to be a robot? Vampires is where it’s at. You’ll have a sexy boyfriend hows that for a twist! And you shoot zombies because kids love the zombies am I right? Yeah.

    And you gotta hurry up because the next project is a reboot of Lemmings. It’ll be like that Gears of War. You were the best blocker ever but you got left behind at the end of the level and now you want reven….

  15. acronix says:

    I’d humbly suggest calling the checkpoints ‘reconstruction stations’. That should tell the player immediately that they are not getting healing from them but an actual revival. Though I think players will still try to interact with it because that’s what players do with glowy bits.

  16. RCN says:

    May I suggest calling the “respawn machine” something along the lines of “good retrieval bay”? Or “reconstruction booth”?

  17. Paul Spooner says:

    I would argue that the game has two verbs. “Shoot” and “move to”. You shoot things you don’t like, and you move to things that you do like. Putting these verbs in conflict and teaching the contrast between them is the whole core of the game. Bad robots guarding power-ups?

  18. Zak McKracken says:

    “You can’t go back”

    … right, so I don’t know what the game plays like (and whether there’s a good reason for this) but I bet that sooner or later, I’ll more-or-less accidentally go through the wrong door and become really angry that I can’t just quickly slip back to where I came from, which spoils that really good run I just had …

    • Naota says:

      Having recently played Thiaf, I can totally sympathize. In Good Robot the point of no return happens only when you transition from one zone to another through a door, though. Since all doors are one-way, and placed far enough apart that they can’t accidentally be bumped open, there shouldn’t be any confusion.

      It’s a bit like playing FTL and deciding where to go next at the end of sector, but without the time pressure of the rebel fleet.

      • Zak McKracken says:

        alright, so if I don’t have to decide under pressure, and the labels are clear, I guess it becomes less important.

        That said: I’m the type of person who saves at every junction in the games that would let me, in order to make sure I get to explore what would have happened if I’d picked the other route…

  19. MichaelGC says:

    I do like his expression up at the top there; my ol’ dad would have loved that: he wasn’t an artist himself, but he always appreciated seeing the character talented folk could pour into, say, just a few curves and a couple of straight lines.

    Unrelated quezzo: is the third from last paragraph in the right section? It feels as though it’s gone a-wander from the section below. Although if it is right … then if you shoot the [repair stations], I reckon they should say: “STAHP SHOOTING ME!”

    No idea who you could ask to voice-act that, though. None whatsoever.

  20. @Shamus Maybe rename stuff like this:

    Change LEVEL to AREA
    Change ZONE to SECTION
    Change PAGE to ROOM

    That way you avoid conflict/confusion that occur when name swapping.

    “Snow area, first section, last room.” does not sound that bad if used in a sentence.

  21. @Shamus

    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.

    Call it “Reconstruction Machine” or something similar.
    Also how does the robot spawn from it? Does lights blink and mechanical machine sounds play, clanking, drilling and welding sounds and smoke and shaking? (as if something is being reconstructed) And then a cool light as it opens up and out comes the Good Robot!

    • What happens upon death? Does the camera move to the nearest “Reconstruction Machine” and the lights on it turn on or something?

      Oh and another thought/idea.
      Why not start the game in/from that machine? I.e. the robot it constructed/reconstructed and the robot appear.
      That way the thing the player is exposed to the second before they gain control of the robot is how they “spawn” after they die.
      They’ll hopefully recognize the machine from then on.

      • Syal says:

        Did Shamus say the game started with a super boss, or did I just imagine that? Because if it started with a superboss then the boss could kill you and spawn you at the starting machine.

  22. AdmiralJonB says:

    I got a chance to play this at EGX (was one of only a few games I managed to play due to huge queues and not being that interested in many other games), didn’t get much time with it as I was with friends, but got a good feel for the game I think. Just thought I’d give my thoughts in case anything I say may be useful.

    I fell for the ‘having to click per bullet’ multiple times, even after being told. This may just be because of the lack of sound as you said, but I didn’t see any visual information that told me I was capable to do so. I understand that the weapons are procedurally generated to a certain extent, but some indication of what type of weapon you have may help (unless I missed it due to my short time with the game).

    On first glance, I didn’t notice the doors between rooms existed, I had to be pointed to them. I think it’s because of the dark colour you’ve got for them, it blended in with the terrain a bit.

    I really liked having a line-of-sight mechanic in the game. Made it more than just a mindless shooter. Even if I did hide behind corners, I still had to be thinking to know what would be coming around the corner to a certain extent.

    Don’t have much more to say, other than that it did have a good feel to it. If you can add some more interaction like you were saying in this post, I think it will help add to that little bit of polish.

    My friends enjoyed playing it, and some even said they’d buy it! I asked them again the other day long after the event, and they still thought they would buy on release. You’ve definitely got a sale from me, and not just because I read your blog :P

    Good luck with the rest of the development! I think you’ve really got something good here.

  23. Trix2000 says:

    For some reason, after this article, I can’t help but think you’re actually making Shoot Guy Robot.

  24. Tango says:

    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.

    This is a beautiful summary.

  25. Spammy says:

    You’ve mentioned that the game is somewhat roguelike and is procedurally generated. Have you considered or has anyone on the team ever brought up idea of allowing players to see and enter world seeds and include a timer function? People seem to enjoy doing speedrun challenges for roguelikes such as Crypt of the Necrodancer and Nuclear Throne, and encouraging it might help get an audience and build replayability.

    • Naota says:

      This is an excellent idea – a clock-driven speedrun is a relatively small change for a lot of replay factor, and being a procedural game, Good Robot thrives on the differences between replays.

  26. miroz says:

    In my projects, one of the first chapter in documentation is the glossary: list of every term used to describe the project. That way, new collaborators get their naming straight immediately.

  27. Rick says:

    Do you have a full-size version of that header image? It’s being to be a desktop wallpaper.

  28. Zak McKracken says:

    Speaking of spin-up and guns: Do you have one that you can either fire directly or charge and then unload by holding the fire button? Like this:
    https://youtu.be/uvUDFRhWSLg?t=59
    ‘cos that’s my favourite shoot-em-up eva, so you need this feature, or how would you expect me to touch your game?

  29. Radagast says:

    HAHAHA your last line got me. “React to bullets” …. and that nice Sean Connery line from The Hunt for Red October. You should totally have blow-up-able missile silos :)

  30. Clodpool says:

    It could make sense for rooms to be “pages” if you thought of zones as chapters and levels as books.

  31. Pinkhair says:

    I always assumed ‘brush’ was from the same lineage that gave us Guybrush Threepwood(that is, DeluxePaint brushes).

  32. Gustavo says:

    trading binary is more like a 50-50 chance trade

Leave a Reply

Comments are moderated and may not be posted immediately. Required fields are marked *

*
*

Thanks for joining the discussion. Be nice, don't post angry, and enjoy yourself. This is supposed to be fun.

You can enclose spoilers in <strike> tags like so:
<strike>Darth Vader is Luke's father!</strike>

You can make things italics like this:
Can you imagine having Darth Vader as your <i>father</i>?

You can make things bold like this:
I'm <b>very</b> glad Darth Vader isn't my father.

You can make links like this:
I'm reading about <a href="http://en.wikipedia.org/wiki/Darth_Vader">Darth Vader</a> on Wikipedia!

You can quote someone like this:
Darth Vader said <blockquote>Luke, I am your father.</blockquote>