AAA game publishers love to muzzle their developers and send out their marketing robots to tell us EVERYTHING IS FINE. SALES ARE ALWAYS UP. WE BELIEVE IN OUR TEAM. SADLY, ECONOMICS BEYOND OUR CONTROL MEANS WE HAVE TO LAY OFF THIS TEAM. EVERYTHING CONTINUES TO BE FINE. WE ARE PROUD OF THIS GAME. WE ARE DISAPPOINTED IN ITS RECEPTION. SALES ARE UP. WE VALUE YOUR FEEDBACK.
We’re trying to invent a new industry and a new medium, and instead of learning from each other’s mistakes, everyone pretends they don’t make mistakes. I think that’s bad for everyone. On the other hand, documenting your mistakes in public is no fun, and publicly saying, “Here is how we wasted some of your investment money” might make it less likely that people will entrust you with money in the future. And writing stuff like this takes time away from stuff like patching your game or starting on the next one.
So I understand why only a small percent of games get a postmortem. And given the odd, meandering path this game took to release, I’m not sure how valuable this postmortem will be to other devs. But in an effort to Do The Right Thing, here is our story.
Who Did What
Shamus: Engine programming, music, game design, “writing”.
Rutskarn: Actual writing.
Arvind: Game Programming, Game Design, UI, Level Generation, Business & Promotion
Ross: Game Design, Scripting, Misc. Art
Mikk and Rashi: Art
Over the next few entries, Arvind, Ross, Rutskarn and myself (Shamus) will take turns talking about the development of this game. Arvind’s text will be in green and Ross will be in blue. Rutskarn will be in red.
Good Robot began in the summer of 2013 as a personal hobby project. I observed that there was a lack of Descent-style gameplay where the player would fly through caves, shooting robots. This was an interesting gap, since this seems like a really attractive target from a development standpoint.
Blocky robots are easier to model and animate than (say) ambulatory bipeds. Making AI float around is easier than making AI that needs to navigate terrain. Indoor spaces are easier to build than outdoor ones. They’re also easier to render. (Which is way so many 90’s games took place inside of buildings.) And the indoor, corridor-based design automatically provides a way to keep the player focused on their immediate goals and not wandering around bored and aimless, which is a danger for open environments. Industrial / organic caves and tunnels are easier to build than (say) residential, urban, or retail locations because you can take more artistic license. Aside from market size, everything about the Descent design and gameplay screams out “This is an ideal target for indies!”
Apparently I’m not the only person who saw this opportunity. Since I began Good Robot, at least three other supposed “Descent successors” have begun or completed development: Overload, Sublevel Zero, and Descent Underground.
But I knew that making a full 3D game was probably still too much for me to take on all on my lonesome. I wanted to play around with gameplay concepts, but when you’re working in 3D, a lot of time goes into fussing with technology. So I decided to see how far I could get with just 2D.
Six months later, I’d finished the core technology: AI, level generation, a particle system, flying bullets, a stat-based level-up system, per-pixel hit detection on 2D sprites. I had a procedurally generated world where the player flew through caves and shot robots. Unfortunately, it was basically a mild diversion of a game. It just wasn’t interesting. Also, the interface was a horrible mess. I hate writing GUI interface code, and it really showed.
In January 2015 I teamed up with Pyrodactyl games. The goal was to fix the above problems and bring the game the rest of the way to market. In April 2016, after a year of steady part-time development, we released the game on Steam. The reception was very positive.
When I got my hands on the game, the individual segments of the caverns were procedurally generated but the eventual path the player took was always the same. If you were to draw a diagram of the levels, it would always look like this:
The boxes are the individual rooms which were procedurally generated, while the line in the middle is the path the player takes. The change in color indicates different levels.
The problem here was that the arrangement of the rooms was undermining the entire idea of procedurally generating your game. If the overarching arrangement stays the same every time, then the rooms themselves being different is similar to changing the building textures in GTA every time you load the game, but keeping the street layout the same.
As soon as we made it so that the rooms now could have exits in any direction and the path was different each time, the game became a lot more enjoyable to play. Now, the player had to actually explore and find the path to the next level, instead of figuring out the path once and then just following that for every playthrough.
I also entirely remade the way the rooms themselves were generated, which is explained in the guide inside the game files (look for it in
After that, we made a system to put together these rooms in a fashion similar to a music playlist set to play X random songs out of Y. This led to the random caverns you see in Good Robot today.
Overall Design Philosophy
If I had to distill my key design goals for Good Robot, they would be:
- Present the player with interesting decisions at every turn.
- Alternate between action segments and quiet segments.
- The player should learn more about the game and be able to apply that knowledge in subsequent playthroughs.
Once you list it out like that, you can piece together why:
- Each level is divided into multiple zones, and you have to choose from one of 3 doors.
- Door symbol meanings become apparent after a couple of times you choose that door.
- The vending machines are always at the end of a zone, so you can enjoy a little bit of downtime while making a strategic decision about your upgrade/weapon/warranty/etc purchases.
If any of you fancy becoming game designers, feel free to dissect the game's design and see if you can identify some other pillars of Good Robot's structure.
What Does a Robot Want?
No, self-aware robots aren't going to turn on us, Skynet-style. Not unless we designed them to.
A look back at Star Trek, from the Original Series to the Abrams Reboot.
So what happens when a SOFTWARE engineer tries to review hardware? This. This happens.
Trashing the Heap
What does it mean when a program crashes, and why does it happen?
Quakecon 2012 Annotated
An interesting but technically dense talk about gaming technology. I translate it for the non-coders.