Good Robot #46: Game Design Changes

By Arvind Raja Yadav
on Mar 25, 2016
Filed under:
Good Robot

It has been one year since Good Robot went up on Greenlight, and we are due to launch in about a week and a half. The game has evolved an immense amount in the intermediate time.

Top: Early alpha. Bottom: Current build. Click for full view.
Top: Early alpha. Bottom: Current build. Click for full view.

Visual changes are easy to show using videos and screenshots. Game design changes, not so much – this is a process of formulating systems, talking to your team, tweaking your design based on feedback, convincing your team why a certain system is the right fit, and then overruling their complaints with an iron fist.

I thought the best way to show just how much Good Robot’s design has evolved is to talk about some of the bigger changes in its design, from when Pyrodactyl started working on it to now. First, I’ll describe the old system, then the problems with it, and then what we did to fix it. Here goes!

Note: Game design is a collaborative process, which is why I use “we” from here on out, even though I did all the work.

Upgrade System

In the old version, you would get XP from killing robots, and upon reaching a certain XP threshold, get a skill point to put in one of six trees. Points once spent were not refundable. This system is familiar to players and used in many RPGs.

You probably know what this does without me needing to tell you.

You probably know what this does without me needing to tell you.

The Bad

Since the XP threshold for leveling up kept increasing, level ups got rarer as the game progressed. This was intended, as the player is not supposed to acquire enough skill points to fill out all categories. Unfortunately, this meant that the worth of late-game enemies would feel the same or lower than the earlier ones. Sure, they gave you more XP, but the currency of the upgrade system was not XP – it was skill points.

In the early game, you could survive with any skill point distribution, even though you got more skill points here due to the low level up XP threshold. As you progressed, enemies would get deadlier, which provided a nice and steady increase in difficulty IF you had distributed those points optimally. Unfortunately, some of the upgrade categories were more important than others, and if the player made the mistake of putting too many points in the “wrong” skills, they would get demolished in the late game by robots that were too strong for them. Worse, they couldn’t undo or adapt to their “mistake” without starting a new game.

The upgrade system was less of a tool for players to enhance their play style and more of a right/wrong puzzle. Spending points “correctly” in the early game was extremely important, but you would only know if you were right three levels after it was too late to make a difference. Finding the ideal point distribution was trial and error of the worst kind (old adventure game players know what I’m talking about).

Not so funny if you`re the one playing it.

Not so funny if you`re the one playing it.

A minor gripe alongside the bigger problems: Upgrades deeper in the skill tree were more powerful than earlier ones, but all of them had a uniform price (one skill point). This is not inherently a bad thing, but it felt like we were doing it just because that’s the way it was done everywhere else.

The Fix:

We decided to remove the skill points system, and renamed XP to money. Every upgrade in the skill tree now has its own price, and buying a level in any skill increases the cost of all future upgrades by a certain amount.

Since skill points are now priced according to their value, the player can choose to diversify at a lower cost later in the game, and can course correct if a combination of upgrades isn’t working out for them. This also makes it so your options increase or stay the same as you move into later game, because you can choose from a higher level in a skill you’re invested in or multiple upgrades in lower levels of other upgrades.

This also allows the player to fill in their weak spots better – if the player finds that they need just a little more speed to dodge enemy bullets better, they can do that at the next upgrade station for a fairer price compared to the early system.


How energy worked was simple: different weapons needed different amounts of energy to fire. If your energy was low, you had to wait for it to recharge before you could shoot again.

The Bad:

The energy system punished you for firing too many bullets in the worst way possible – by making you wait until you could fire again. In a shoot ‘em up, this problem feels even worse because there are a ton of enemies on screen, and players will not be 100% accurate with their shots.

The upgrade system allowed you to increase your energy reserves, but this made the player choose between spending skill points to make the game more fun, and spending skill points to improve their stats. This was a horrible choice, and the optimal way to play was to engage as few robots as possible, wait for energy to refill, and then engage the next bunch of robots, rinse repeat.

Even if you did upgrade your energy reserves, you would still run out of energy eventually, and the same problems would appear. It was clear that the system was not suited to the game at all.

The Fix:

This was one situation where simply removing a bad system did 90% of the job. We already had weapon specific fire rate options, which were brought to the forefront. Later on, we divided the weapons into primary (high rate of fire, low power) and secondary (low rate of fire, high power) to give the player more variety.

More importantly though, we made it so you could shoot as many bullets as you wanted. Because our founding fathers would have wanted it this way.

Click for larger image.

Click for larger image.


In the old version, if you died, you just respawned at the start of the level. The enemy bots you had killed stayed dead, and the ones who were hurt-but-not-dead stayed at the same health.

The Bad:

This was not really a system, rather a lack of system to handle death, and resulted in tougher levels becoming a tiresome grind where you chipped away at the enemy over the course of multiple lives. Bioshock suffered from a similar problem. It was clear we needed a better way to handle player death.

The Fix:

Since the levels in Good Robot are procedurally generated and different every time, roguelike-style permadeath was a natural fit for the game. However, we were not opposed to giving the player a way to recover if they messed up – bonus points if it fit the gameplay/story aesthetic we were going for. To that end, we introduced the warranty.

The player can buy a warranty, which is one extra life. If the player dies while they have a warranty, they respawn at the start of the current zoneA sub-segment of a level.. The warranty gets more expensive for each upgrade your robot has, and for each time you buy it. After a lot of playtesting, we found this to be a good balance of difficulty and convenience.

The ✓ sign at the top left indicates that you own a warranty.
The ✓ sign at the top left indicates that you own a warranty.


A few weeks ago, our team meeting was wrapping up as we had finished discussing the important stuff. Then this conversation happened (paraphrased):

Arvind: We’ve been making Good Robot for almost as long as TF2!

(A series of hilarious and original hat jokes ensue)

Shamus: I think I can actually add hats to our game.

Arvind: This confirms my theory that any game in development long enough will end up with hats in it.

Shamus: Who said that?

Arvind: I came up with it. Just now.

Ross: I wouldn’t have guessed, that was almost sort of clever.

Arvind: Meeting over! Bye everyone

Thus, we ended up with hats in the game. Hats were purely cosmetic, which meant that they didn’t integrate with the core systems of the game. Purely cosmetic hats are fine, but could we do something more with them?

This is samurai helmet, that will be a different color in the final game.
This is samurai helmet, that will be a different color in the final game.

We made a hat vending machine that shows up at the start of every zone. Hats are dirt-cheap and absorb the first shot that hits you, after which they fall to the ground. This gave them a small amount of utility. Then we realized that this could potentially add an entirely new layer of challenge to the game.

A normal player will probably find hats funny and buy them once or twice when even one shot saved could make a difference. However, if we added achievements for completing a zone, a level, multiple levels and the ENTIRE GAME while wearing a single hat – they become an entirely different game mode for an experienced player, where they have to avoid being hit at all while completing a section of the game.

Which means that now, if you want to get 100% achievements in Good Robot, you have to be very good at the game. We ended up with this hidden high-difficulty mode in the game, and all because of hats. All hail hats.

Good Robot comes out on Steam on April 5. Mark your calendars!

Enjoyed this post? Please share!


[1] A sub-segment of a level.

20201050 comments. It's getting crowded in here.

From the Archives:

  1. Steven Rodney says:

    I Apologise if this question has already been asked and answered, but what tools did you use to create the game. For instance did you use a libraries such as SDL or was it pure C++? and OpenGL. Any specialist tools used to create the games graphics style?

    • Ilseroth says:

      Well I know some libraries were used from some of the earlier robot posts (like, years ago) as for the graphical tools, I am pretty sure Shamus was saying he built some tools for the artists if I am remembering correctly.

    • Da Mage says:

      From the previous programming posts (and comments with them) I’m pretty sure Shamus has said he was using SDL 1, opengl 2 and written in C++ using visual studio.

      For the designers most of the core game elements are defined by xml documents, so I doubt there was any advanced dev tools….that seems like something that would have been discussed.

      Again, this is going from my memory of the posts Shamus has made, so I might be wrong.

      • Bropocalypse says:

        This sort of makes me wonder whether there’s a divide in the game development world between those who make games from scratch and those who use various libraries, and if this also extends from those groups to developers who use tools such as Unity or Unreal.
        I know Shamus is unlikely to do so, but it feels like that would be a thing: Devs looking down their nose at those who didn’t “have” to work so hard to make their game.

        • That’s an interesting question. I would guess that there isn’t much of that in the AAA development space because so many devs use Unreal, and maybe that’s just accepted as The Way Things Are Done. However, there does seem to be some feeling among indie game fans that games made with Unity are sometimes lazy, same-y, and crudely made. It would be tough to say if there’s actually a stigma against Unity or the devs who use it.

          • Chris says:

            Building an engine from scratch is expensive and difficult, especially in the AAA space. Everybody uses Unreal because it’s reliable, pretty, well-documented, well-known, and much cheaper to license than the cost to build a comparable engine from scratch. CryEngine and idTech (and I’m sure several others) tick most of the same boxes, but Unreal has network effects on its side; any new hires are more likely to have experience with Unreal than with other engines, so it keeps training and ramp-up costs down.

            A big part of Unity’s negative reputation stems from shady actors pumping out simple asset flips (buying cheap, generic assets from the Unity store, half-assedly slapping them together into something buggy and barely interactive, and selling it as a game). Jim Sterling has ranted about that ad infinitum. The “samey” look is likely a combination of asset reuse and the fact that the free version of Unity doesn’t (last I was aware) allow custom shaders.

            • DivFord says:

              Unity (even the free version) does allow custom shaders, they just aren’t documented very well. It’s sort of assumed that you go into it familiar with OpenGL shaders or something similar.

              • Chris says:

                I stand corrected. I could have sworn I remembered that being one of the distinctions between the free and professional licenses. Perhaps I’m thinking of access to the underlying renderer source.

              • Naota says:

                In fairness, the presence of custom shaders doesn’t really impact how frequently they’re used in low-effort or first-time Unity games. It’s likely that whatever the default look, it’ll be replicated in these projects because the creators don’t know or care enough to find alternatives.

                Unity allows a single programmer with a modest budget to essentially make a game that functions (as in, it runs) without the need for an art team or a thorough understanding of how to create art assets, where Unreal is mostly a framework for plugging in content you’ve made yourself. For example: Unreal 3’s package system is the hardest one to source assets from of any SDK I’ve used – even HL2’s Source engine allows you to search through all of the game’s default models and textures (something only third-party developers need to do) without explicitly loading their containers to see what’s there.

                I think this is the biggest reason Unity has the stigma it does, more than a divide in triple-A/indie culture – it’s made creating a 3D game so cheap and so easy that the lower limit for quality has never been worse.

    • Decius says:

      Like all great programmers, just adjust the boundary conditions of the universe such that the program you want results.

  2. Daemian Lucifer says:

    So what you are saying is that Shamoose messed up a bunch of things,and you had to do all the work trying to fix it.

    • Fists says:

      Didn’t realise this was from Arvind until I read your comment, writing and structure is surprisingly similar to Shamus’.

    • I know this is a joke, but when I took over the project, Shamus was focused on the tech side of things and wasn’t paying much attention to the systems. He knew the design had a bunch of holes in it, and he would probably have fixed them given enough time (even if the way of fixing them wasn’t the same as how I did it).

      Even as a joke, I do not find statements like “this guy did something wrong” helpful in development. I always try to say “this thing/system/bug is what is wrong” and then work to fix that. Ultimately, we’re releasing this game as a team, and we’re responsible for the game as a collective. If I want to take credit for the good things, then I also have to take responsibility for the bad things.

      • MadTinkerer says:

        “Even as a joke, I do not find statements like “this guy did something wrong” helpful in development.”

        Yep, because then in my experience that eventually leads to everyone blaming a single guy for:

        1) Systematic issues that can only be fixed by completely throwing everything away.

        2) Systematic issues that could totally be fixed without throwing everything away if we were thinking about them as systematic issues instead of blaming someone for them and demanding that he be less lazy and then getting angry when the problems don’t become fixed.

        3) Not implementing everything in the design doc exactly as written. Because doing anything other than implementing everything exactly as written is laziness.

        4) Things that the guy doesn’t even know is happening, because it’s presumed that he’s the cause of them and is doing it on purpose without any discussion of what’s happening.

        5) Problems that arise from trying to get things to work with other things, even though no one is telling the guy how those things work because he’s being deliberately “cut off” from communication. (as he’s told later)

        6) Blaming the guy for things that went right as if they were wrong things.

        7) Completing a seriously flawed game without learning the real reasons for the flaws even though… wait… This is supposed to be a COLLEGE CLASS NOT A GAME STUDIO, LEARNING FROM MISTAKES IS THE ENTIRE POINT OF WHAT WE’RE DOING, YOU JACKASSES.

        And that’s why I dropped out of college.

        (Actually, to be fair, none of the things the students did were directly the reason why I dropped out. It was the part where the teacher told me that I was being deliberately “cut off” from communication and that I “deserved it” because of my behavior. That was the last straw. I really couldn’t take the classes needed to graduate after that, because I couldn’t take them without him being the teacher.

        I got a C, by the way. He tried to pass it off as being “generous” to an inexperienced student, but the real reason is that he’s a lying coward who doesn’t want the administration to realize they hired The Music Man to teach game design. If he was honest, I would have been given an F for my efforts, but his scheme would be exposed.)

        So, yeah, don’t blame other people for design issues. At best, you’ll keep yourself from understanding what’s really going on. At worst, you’ll ruin someone’s career, and they’ll never work with you again even if you learn your lesson after the fact.

  3. Ilseroth says:

    I think a lot of this comes down to why it is important to work with others on games.While plenty of solo developers have made good games, far far more of them have put out interesting but inherently flawed games because they view things from their point of view and after you spent literally hundreds (if not thousands) of hours playing a game, determining what is fun and what isn’t can be… challenging.

  4. lethal_guitar says:

    The link to the large version of the screenshot comparison just comes up empty for me..

  5. droid says:

    How many hats can one wear at a time?

    And in the game.

  6. Merlin says:

    Because our founding fathers would have wanted it this way.

    It comforts me to know that America has reached sufficient peaks of blustery self-parody that we’ve managed to export this saying to the rest of the world.

    • Sabrdance (MatthewH) says:

      I’m curious which founding fathers he means:

      Marquis d’ “I think it’s very important that American soldiers pick a redcoat they intend to kill and plug him solidly right in the X where the belts cross over the heart, don’t you, Freddie?” Lafayette


      Jawaharlal “Jinnah, can’t we all agree that it is much better for us to shoot the British than each other?” Nehru.

      And suddenly I feel a much deeper kinship with India…

    • 4th Dimension says:

      I’m quite certain he isn’t honestly refering to his founding fathers, but us using that sentence as a meme/joke.

  7. Dragmire says:

    So, is Rutskarn allowed to play Mount and Blade again?

    I really enjoy reading about the design process, thanks to everyone for being so open about it.

  8. Incunabulum says:

    “Which means that now, if you want to get 100% achievements in Good Robot, you have to be very good at the game. We ended up with this hidden high-difficulty mode in the game, and all because of hats. ”

    Hahahaha! I like it – its not as good as an achievement for pre-ordering/EA purchase but its a nice FU (=>though I know you don’t *mean* it as such<=) to cheevo hunters while being the rare type of cheevo that actually could be *considered and achievement*!

    You are going to get crucified for making those guys actually have to be good at the game to get their Ding! and 100% (which is more important than *enjoying* the game, being challenged, learning something, etc).

    • Naota says:

      No joke: a non-insignificant part of my job at Pyrodactyl involves diving into the scripts of our old games that I haven’t touched for more than a year, to find out the precise conditions for earning achievements at the behest of completionists on our Steam forums.

      While it’s always nice to know people are still playing our games, instead of my usual paragraph-long explanation I would love to respond to one of these threads with “This one’s dead simple: buy a hat, play the entire game, and don’t get hit by anything.”

  9. krellen says:

    As an early playtester of the game (before Pyrodactyl came on), I disagree that the original upgrade system was a “puzzle” with any sort of correct solution. I tried out many different combinations of builds and all were able to get through as much of the game that existed.

    I also really, really don’t like this idea of “achievements” that require never being hit at all in what amounts to a bullet-hell game. That’s basically saying “fuck you” to customers.

    I dunno. Overall, I think this post has made me less likely to buy the game. It might be language barrier, cultural barrier, or simple personality clash, but the “problems” addressed and the way they are addressed kind of repel me.

    • Tewi says:

      How is rewarding an achievement for an extremely difficult feat an insult to the consumer?
      Also, without even playing the game it’s obvious that half of the original upgrade options have literally one correct solution amongst them(or else their names are extremely misleading).

    • Nidokoenig says:

      Having that achievement exist, carries with it an assumption that it should be achievable by an about average person trying really hard, and thus enforces a skill ceiling on the game, forces the devs to make bullet spreads dodgeable with sufficient skill, not setting gotcha traps and the like. It’s an implicit promise of fairness, similar to Platinum Games having the platinum medal for damage taken always being zero in many games, or the Kick Me sign in God Hand promising that the basic, non-special moves are sufficient to overcome anything. It’s a huge problem if the game doesn’t deliver, obviously, but the proof of the pudding is in the eating. If you’re worried, wait for feedback.

      Bullet hells have had the concept of the 1cc pretty much forever, if anything the problem comes from the proc gen system, since it’s far harder to guarantee that a given arrangement is both winnable and challenging enough to warrant the cheevo, like how Solitaire can be trivial or just flat out impossible and you have to waste your time finding that out. That worries me slightly, but it’s only really an issue if the basic gameplay isn’t fun.

    • Blue_Pie_Ninja says:

      I guess you could always “hack” the game seeing as most of the game is xml code, so you could literally make all the enemy robots not fire as fast, or not at all to easily get that achievement.

      I really hope they allow that kind of “modding” with achievements :P

    • We’re using this achievement as an experiment to see just how difficult achievements can be. If it turns out that a lot of people are having a problem with this one, we can just remove it or tweak it to make it easier. Even if we don’t change it, you can mod the game’s XML files to remove all enemies from the game and make the game 1 level big.

      • Daemian Lucifer says:

        No!Dont do that!If its too hard for some,then tough luck,they dont get an achievement.Those who can do it deserve a reward precisely because its hard.Achievements arent supposed to be for everyone.

    • Naota says:

      It’s worth noting that the game has changed so much since then in terms of the core gameplay loop that the two experiences are hard to compare.

      My opinion is that the earliest upgrade system actually had no wrong answers because the game around it contained a half-dozen enemies that fired one of four projectiles, and the player had a single, uniform weapon tied to it from start to finish. There were no dramatically wrong or right strategies because the most it did was nudge the experience in your preferred direction without changing the core, and so as long as the core was balanced everything worked out. It was simple, but very resistant to imbalance.

      When we expanded the variety of bots into a half-dozen per level and varied their attack patterns in new ways, it became harder to justify making certain build choices because there were now situations like minefields where builds without speed or fire rate upgrades found themselves at an intense disadvantage. The same applies for weapons – not all upgrades achieve the same effect on all guns. You can make a railgun less slow with an RoF build, but the effect on gameplay is dramatically different from using a machine gun with the same setup.

      The result is that there are now optimal and sub-optimal builds where there weren’t before, more in line with an RPG. Some combinations of the new mechanics and gameplay elements are extremely effective; others may not be viable. Using the old upgrade system it would be possible to trap yourself in the latter case through early-game choices without much recourse later on.

  10. Steve C says:

    What’s the money called? Hopefully you’ve named it Bit-dollars. Anything else feels wrong.

  11. Stu Friedberg says:

    I’ll be buying Good Robot when it comes out, just because 20-sided. But bullet-hell games (also two-stick arcade shooters) are really not my preference. In fact, looking at the animated GIFs in the last several posts about Good Robot, I suspect I am going to be confused, dazzled and really really uncomfortable playing it.

    Fortunately, Unrest and Good Robot have established a hugely broad spectrum which Shamus and Pyrodactyl can populate with a wide variety of small gems. I await their procedurally generated racing game eagerly. :-)

  12. WJS says:

    It would be interesting to see some of the earlier builds, if that would be possible.

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="">Darth Vader</a> on Wikipedia!

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