Aborted game autopsy 1: Lessons learned

One day during my junior year of college I decided to design an RPG. I was surrounded by friends when I announced this and they all responded with enthusiasm. It’s now about four years later and I have little to show for my effort. Luckily, working on my game led me to some truths about game design, most of which are obvious or irrelevant. So, here they are.

Lessons Learned:

Seizure Soft
The most important part of designing a game is making a cool company logo.

There is a positive correlation between dedication and salary. Finding a team of people who are willing to put in the long hours to make a game is a significantly harder undertaking if you cannot afford to pay them. As Pat explained to me, sticks work best when there are carrots hanging from them.

My development team was comprised mostly of my friends. I figured we are all intelligent college graduates or near graduates, not 12 year olds who have their heads up their asses. It turns out teams of 12 year olds don’t accomplish much less than unmotivated teams of 22 year olds. After constant attempts to make team members excited about the game again, I eventually became unenthused. My new plan is to become independently wealthy then just hire a team to do what I say, as well as pay for an At the Gates reunion tour.

Plots should be under 150 pages long. The bulk of my time went into writing an enormous plot that is still only about 3/5ths done. Having a finished plot early on in development could have enabled me to spend my time working with the tech guy and art girl more closely, or at least given the team confidence that progress was being made.

Instead, a friend and I spent countless hours working out each character’s motivation for taking a crap in the left stall instead of the right. Maybe Square writes plots that are 200 pages long, but I wouldn’t recommend it for a first game (an RPG for a first game is also a bad idea). I’d convert my game’s plot into a book if I knew how to write.

Don’t involve significant others. This can also be called the Spinal Tap rule. Though in my case, the significant other didn’t cause stress in the team or book us at a military base. She was actually quite helpful, too helpful in fact. What started as my game became our game. Like most dumb things, it seemed like a good idea at the time. She kept me motivated and had a lot to contribute. But then, of course, we broke up.

I didn’t want to even think about my game for months. When you share something that means something to you with someone else then things go awry, it can be difficult to reclaim that song/book/show/play/painting/candy. If it’s something the other person helped you create it can be extremely difficult to not just turn your back on it. Fortunately, I had made the vast majority of progress on the game by myself or with another close friend. I realized that allowing someone to ruin my hard work would be stupid, but also that I was already stupid for allowing her to have such a large role in it to begin with.

Elrelis Bled
The next most important part of designing a game is making a cool logo for the game.

A test build is mandatory. Everything I read on designing games said this but I assumed it was something a tiny unfunded development team could ignore. Turns out any and every game needs a running version very early on. I have finished most of the gameplay design on paper but there are still key elements where I’ve only narrowed the gameplay down to a few possibilities, instead of a concrete “this is how the game works.”

I think I like the idea of weapon durability because the game tends to be realistic, but then that mechanic is often annoying in other games. Let’s test it! Wait, we can’t because we have no test build. So I have a design document that has multiple versions of the weapon systems and a handful of features with question marks by them. Without a test build I can’t screw around with the battle system and see what’s fun and what sucks.

Pull the plug after four years. A lot of releases by real developers that come out after huge design cycles are crappy or just broken. Too much time is usually indicative of a core problem in the design. For my design, it was that it didn’t have a team to make it. I’ve recently had the will power to push the game aside and start working on design documents for other, easier to pull off ideas. These ideas are still all for games I will probably never be able to make, but each one seems more plausible in my mind than the original enormous RPG.

Even so, now and then I still think about my main character Voland and his crazy antics in the land of Elrelis and I can’t help but smile. Smile, then begin working on the skills list again.

Notify of

1 Comment
Inline Feedbacks
View all comments

[…] Strategy employs a design technique I named “branching linearity” when I was pretending I was a game designer in the halcyon days of college. Instead of many choices with usually subtle or no effects on game […]