This is a repost of Shamus’ devlog on Twenty Sided. Read the original post here.
When I was working on this project all by my lonesome, things were pretty simple. The feature list was “whatever I felt like putting in” and the release date was “whenever it gets done”. That’s great when you’re programming to entertain yourself and turning it into blog posts to entertain others. But when Pyrodactyl joined, I think the team had some kind of (perfectly reasonable) expectation that we should have a plan, and that plan should include shipping the game in our lifetime.
So the first few weeks of serious work on Good Robot have been a transition from a one-man-hobby project to a six-person commercial enterprise.
Arvind is the other dedicated programmer on the project, and he’s taken over working on the interface and managing the people.
Imagine you get a new job. There are two parts to the job. The first part is that you need to hang around on the beach, stroll the boardwalk, and maybe take a swim in the ocean once in a while. The other half of the job requires you to be locked in a room with an angry Gilbert Gottfried while he rants about conspiracy theories and pelts you with pinecones. Granted: This is a strange job. But I think the vast majority of people would agree that one half of this job is a lot nicer than the other. And your enjoyment of being on the beach is tempered by the knowledge that every hour you spend on the boardwalk is another hour in a small room with Gilbert Gottfried.
Then a new guy joins up to help, and the two of you can divide up the labor any way you like. It turns out he hates the beach, doesn’t want to go anywhere near a boardwalk, and he’s not a fan of the ocean in general. On the other hand, he loves Gilbert Gottfried’s voice, he finds conspiracy theories just fascinating, and he actually enjoys a good pinecone-to-the-face now and again.
An early version of the Good Robot interface
That’s pretty much what it was like for me when Arvind took over the drudgery of working on the interface. Arvind likes working on interfaces, and I’d rather be hit with pinecones.
The other big shift is with the art style. Previously, I sort of locked everything down to make it idiot-proof. Color B would be be a darker version of color A, several of the various light sources all drew from the same color value, and everything was blocky and pixelated to hide my artistic sins. That was really handy when I was doing a one-man-band approach to game development, since I’d made it so that basically any input would generate something tolerable. But then Mikk wanted to upgrade things from “passable” to “nice” and found everything was interconnected. It’s like the face sliders in the Fallout: New Vegas character creator, where moving one slider would change the values of three other sliders. That’s actually really annoying if you know what you’re doing.
So we’ve gone back and forth, with Mikk gradually asking for more and more freedom as he runs into various dependencies and limits.
In the early stages of the project, I designed several different weapons for the robots, several different types of AI behavior, several different types of animated bodies, and a bunch of different ways to control the frequency, duration, timing, and intensity of their firing patterns. The result is that nobody really knows what sort of robots you can make, what they can do, or which combinations of behaviors will be fun and interesting. So Ross has been experimenting with different enemy types and seeing what works.
We’re also experimenting with different color schemes
The team agreed with my assessment that the game just wasn’t interesting enough. The problem was that everyone had a different idea on the best way to fix that. Get rid of the leveling system. Make the leveling system deeper. Get rid of the story. Add more story. Add more different kinds of weapons. Simplify the weapons. Permadeath. Add scoring, with combo meters and score multipliers. Give the player the ability to select different characters, like in Spelunky. Make levels non-linear. Borderlands-style “goal coaches” who suggest things to do via voice messages. Get rid of the energy system.
All of these ideas can lead to a good game, but a lot of them suggest different types of game and many of them are mutually exclusive. It’s not that we don’t know how to make the game better, it’s that the possibility space is too enormous and we don’t have a great way of narrowing it down.
The good news is that the core mechanics work. This game is about flying around, blasting robots, and watching them tumble to the ground and explode, and that much feels good. So the process is roughly:
- Haggle over what features we think will be good.
- Over the course of a few weeks, the feature takes shape in our heads and winds up in the design document.
- Lock the feature down and code it.
It’s kind of multi-layered, so that while we’re coding feature C, we’re putting B in the design document and haggling over A.
The aim is to have the game roughly feature-complete by September. Is that reasonable? I have no idea. I’ve never worked on a project like this. Just looking at my current job list, September looks easy. But this is a videogame, not productivity software, and making a game is more than just ticking off a list of features.
It’s not that I can point to any single job and say, “That one is going to take ages!” It’s that there are lots of nebulously defined question marks, and through the years I’ve learned that question marks usually have really big challenges lurking behind them. Not always, mind you. But often enough that I’m afraid of them.
My next big challenge is changing the way levels are generated. I’ll cover that in the next post.
– Shamus
If you want to know how games are made, the Good Robot Devlog is for you! Read it here.
Posted In: Games, Good Robot
Tagged: game development, indie, video games