Terminal_ is a game that Evan Conway , Max Feldkamp, Mike Gold, Julian Delfino, and myself worked on during the winter of 2012-2013. I’ve since left the project, but I believe that Evan and Max are carrying it forward despite having day jobs. That winter, I had the role of Product Manager, and came up with the following “helpful suggestions” to guide our development. I was chatting about game design with my friend Matt Davis, and decided to write up these rules so that they might be helpful to others.

The rules:

1. This is not a workstation
2. This is not a sim game
3. Playtest Playtest Playtest
4. Our drill is the drill that will pierce the heavens!
5. Early optimization = death
6. What is it really about?

1. This is not a workstation

Our early ideas for Terminal_ revolved around the player interacting with the game solely through a computer terminal. The problem with this is that we kept having ideas about implementing existing *nix tools and commands (like top, grep, etc.) in our game. I wrote rule #1 to remind us that the game was not a workstation, and that anything that didn’t contribute to the player having fun was just a distraction.

Takeaway: Focus on fun, not functionality.

2. This is not a Sim Game

We were constantly skirting Bottom-Up Game Design, basing the fun on the idea that the player was interacting with a terminal, instead of focusing on the challenges of level and puzzle design. Retrospectively, this is probably the biggest problem that we had. Our game was cool, it had a great atmosphere, but it didn’t have anything that was actually fun and engaging for the user.

Some games *are* sim games, in which case you can totally ignore this rule. But remember that sim games are only fun because they’re not exactly the thing that they’re trying to simulate. Otherwise they would be just as boring as that actual thing. If that makes sense.

Takeaway: Focus on fun puzzles and levels, not accurate simulation

3. Playtest Playtest Playtest

The Terminal_ team would get bogged down by arguments over the best way to implement a feature. When this happened – and I was usually one of the offenders – I would bring down the force of rule #3. Implement it one way, then playtest it. If it doesn’t work, try the other.

There’s A/B testing on websites, and really, data is an amazing way to make sure that your game is fun and playable. Valve knows this. They playtest each level over and over and over, making radical changes to the puzzle design until they get something that is fun and challenging, not frustrating or obvious. Portal 1 is a great example of this – listen to the developer commentary especially to see how many times they reference changing something because of playtests.

Takeaway: Data trumps opinion 99% of the time.

4. Our Drill is the Drill that will Pierce the Heavens!

If you don’t recognize this quote, you need more galaxy-sized robots in your life.

#4 was a reminder to not give up on the game, even when things were tough. We watched Gurren Lagann together as (mostly) a team at college, so whenever we were feeling down about the slow progress of our game, we would shout this at each other to remember that this game was achievable through hard work.

We obviously didn’t end up making the game, but I attribute that mainly to the fact that we only had 5 weeks to work, an ambitious schedule, and no clear person in charge to make final decisions about what went in the game.

Remember – you’re making something new, and even if the idea has been done before, you can do it better, or different in ways that are fun. Flappy bird is an idea that has been around forever, but Nguyen did things just right to make a worldwide sensation.

Another thought on this: Pare your game down to the minimum viable product. Get that done. Then expand on it until you have all the functionality you want. Whether you have a public beta is up to you, but despite your ability to pierce the heavens, you need to set realistic goals for the size and experience of your team. Once you’ve created something fully, you’ll be better prepared to embark on a larger project next time.

If you do fail, focus on the ways in which you’ve grown throughout the project, and the lessons learned for your next project. Then pierce the heavens next time.

Takeaway: Don’t give up on a game. If you run into trouble, see what you can cut. If you do fail, focus on the things you learned so that you can succeed with your next project.

5. Early Optimization = Death

I was chatting with Evan about one of his games recently – a dungeon crawler with a very innovative “sense” system. What you see, hear, smell, etc. in each room is passed through messages, and these messages also affect the wandering monsters. Nobody likes a room that reeks.

Evan was worried about the performance of iterating through all of the monsters and messages on each frame. He was beginning to consider alternate data structures and optimizations for the problem.

I fall prey to this all the time. The problem with this kind of thinking is that it quickly leads to spending more time working on the code than it does working on making the game fun. And really, there were no performance problems here, or in the similar problems we faced making Terminal_. This ties in to rule #3 – once playtesting has determined that something isn’t optimized enough is when it’s time to go back and rewrite it to be more efficient.

Or, if you have extra time and hands at the end of the project to make sure that your program will run on older PCs. Otherwise, just ship it, and work in the performance tweaks through patches later.

Takeaway: If you’re worried about performance, you’re probably wrong unless something actually isn’t performant.

6. What is it really about?

Especially in strongly-aesthetic games like Terminal_, knowing what your game is actually about is an important step toward putting reason behind your choices.

Even Flappy Bird has a “really about”: it’s about minimalist, fast gameplay. Nethack is really about exploring complex, programmatically generated dungeons. Amnesia: The Dark Descent is about atmosphere, memory, horror, and helplessness. Portal is about an insane AI testing you on puzzles which require you to think in a different topology.

What was Terminal_ about? I’m not sure. We kinda failed at this one because I think everyone on our team had a different idea.

Know the central themes of your game, whether you can describe that in a few words, a few sentences, or even an essay. Then, when someone proposes a new feature, you can really ask yourself and your team: does this fit into the theme?

Feel free to edit this theme as you go along, but when you do, check to make sure everything in your game still works toward creating something whole.

Takeaway: Have one idea about the themes of your game.