Tales of the Rampant Coyote

Adventures in Indie Gaming!

How to Run a Game Company… Into the Ground

Posted by Rampant Coyote on March 21, 2011

I recently re-read the book Masters of Doom: How Two Guys Created an Empire and Transformed Pop Culture by David Kushner. I had to buy a new copy, actually, as I can’t remember who I loaned my previous copy out to. I think it ought to be considered required reading by anybody wishing to leave the “lone wolf” stage of game development and put a company together. Not that I actually have that experience first-hand.

The book principally follows the careers of “the two Johns” of game studio id Software of the 1990s… John Romero, and John Carmack, from their childhood, through their SoftDisk and id days, up through the collapse of Romero’s Ion Storm.

When I first read the book, I was just beginning my experiment with “going indie.” I found the first half of the book – through the release of Doom – to be incredibly inspirational.  The whole experience at the Shreveport lake house while they were making Commander Keen – it felt like what making games should be like.

Unfortunately, as we know, as the company expanded their methodology that worked so well back then didn’t scale too well.  Making games isn’t as much like playing games as we’d like. Hiring some talented fans of his games to make Daikatana didn’t work out so well for Romero, though I’m pretty impressed they managed to get the game out at all.

This second reading, after having spent a bit more time over the last few years involved with indies, seeing  other companies become successful (and “enjoying” the dubious honor of experiencing it first-hand as an employee of another game studio crash & burn), and reading a bit more about running a business, the mistakes and flaws of id Software and Ion Storm are more readily apparent to me. And their problems – which fortunately didn’t destroy id Software, though it did gut the company pretty badly after Quake – seem inevitable.

I can’t help but compare it to my own situation. If by miraculous event  Frayed Knights sells a half-million copies and I’m able to turn Rampant Games into a full-time business with real employees and stuff, would I avoid the same fate?

In all honesty, at this point in time, I’m not sure I would. I think I’d get in trouble pretty quickly. I’m working to address the problems I see with my own process, but the truth is that while I’m a lot more savvy to business and marketing issues than I was when I started, I’m still running Rampant Games  by the seat of my pants. It’s a labor of love – and I hope it always will be – but I still suck as a manager / producer. I don’t have a system in place. If  Frayed Knights – or some other game – manages to have some kind of magical ingredient, I’m not sure what it would be other than “throw all the cool ideas I can afford to throw into it that seems to work together and see what happens.”

You think I’d have figured it out by now. I’ve been a programmer, a designer, and I’ve released games as an indie. I’ve worked with lots of indies, and I’m sure somewhere in my brain I have a bunch of scattered facts about what to do and what not to do to make a tiny game studio successful.  The problem is that sometimes its hard to recognize that you are making classic mistakes. Or you convince yourself that in spite of a history of failure, this time engaging in a particular behavior won’t hurt because you’ll do it the right way. And there are enough famous exceptions out there to convince you that you may be correct.

But to turn things around – if I were to put together something of a top ten list of things to do to make sure your fledgling game studio crashes and burns, it would look something like this:

#1 – Don’t have a schedule or milestones. You’ll only miss them anyway. The game will be done when it’s done. And if you do make the mistake of making a schedule, just acknowledge the missed deadlines and keep going. Don’t waste time trying to figure out why your schedule was wrong in the first place.

#2 – Don’t bother integrating and testing your game frequently. It wastes time, and everybody knows it’ll just come together in the end, right?

#3 – Don’t plan. Just do it. Design docs are for wussies. Marketing and sales plans are for boring guys in suits. Just keep pushing to get that game done that you all have in your head, and everything will take care of itself from there.

#4 – IP rights are of no value to a small studio. Publishers are nice guys, and know that they can’t make the sequel to a hit game without you. Besides, if you do end up making a “hit” series once, it should be easier to do it the second or third time, right?

#5 – Leave your developers to their own devices. They resent meetings, and will think you are uncool and  micromanaging them all the time. Since they are competent, they should of course know exactly when they are doing and are supposed to be doing, don’t really need any kind of guidance, and can coordinate their efforts with their coworkers without your help at any time.  They should already know what everyone else is doing and how that affects them. They don’t even need a sounding board for their ideas. And if you do have a meeting, make sure they are long, drawn out affairs where it’s clear that it’s an emergency necessitated by their own failures and incompetency.

#6 – Don’t pay attention to burn rates.  If you blow that schedule you weren’t supposed to make, and run out of money in the bank halfway through development (or you maybe think it’s halfway through development), don’t worry about it. Banks will be happy to give you a bridge loan in a heartbeat for as much as you think you might need to finish your game, and will be happy to accept “when it’s done” as a deadline.

#7 – Double your scope and budget for your second game. Because these kinds of things scale linearly, and there’s no reason to expect new hires to be any less productive than your experienced, motivated core team right out of the gate. Just remember that you are going to at least double every penny that you put into your game.

#8 – Screw over your employees. That shows them who’s boss, and makes them more motivated to work harder for you – they’ll want to get into your good graces so you’ll be less inclined to screw them over in the future.

#9 – Make your work environment either a wild and crazy frat house full of distractions, or an austere gulag. Don’t settle for anything less than those extremes. And even if you don’t go for the full-on gulag approach, mandating professional attire is also important, because your end product is professional-looking employees, right?

#10 – Downtime is for chumps. If your employees work twice as many hours, they should get all their work done twice as fast, right? Don’t worry about morale – spending three months twiddling their thumbs and surfing the web with nothing to do at the beginning of the project should totally balance out the nine months of mandatory overtime at the end of the project.

So there you go. If you were looking for advice on how to run a game company. Follow even a just a few of these ideas, and I can guarantee you’ll do a great job running a game company… into the ground.



Filed Under: Biz, Books - Comments: 6 Comments to Read

  • WhineAboutGames said,

    Don’t have a schedule or milestones. You’ll only miss them anyway. The game will be done when it’s done. And if you do make the mistake of making a schedule, just acknowledge the missed deadlines and keep going. Don’t waste time trying to figure out why your schedule was wrong in the first place.

    So, what are Frayed Knights’ schedule + milestones like? 🙂

    I am still crap at estimating development time. People ask me and I have no idea. I can usually only say ‘soon’ or ‘not soon’. When I first started talking about Magical Diary and people asked when it would be out, I could only look baffled and eventually say “Definitely not before Christmas (2010).” Which got some people to say “Aww, we can’t play it until Christmas?” and me to sweatdrop. I didn’t say it would be done then!

    And of course it wasn’t, not anywhere near, but there was a good playable chunk by then, and considering the time that had gone on and that some people were hoping for progress by that point, Christmas is about when I started the transition into the alphatest.

    My answer on release dates is still a vague shrug and “Couple of months?” But I suppose even a vague guess is helpful for providing focus… just don’t expect me to necessarily stick to it.

  • Rampant Coyote said,

    The part about missing them anyway was no joke. I have a tough enough time just projecting when the next build will be done for the testers. I don’t think anybody is “good” at it, but I do believe you can get better at it.

    Spiderweb manages to get RPGs out on a regular basis, but I’m not sure how much of that is really good time estimation due to similar games (this long at it, you’d think they’d be pretty good at it), or a case of fitting the game to meet the schedule rather than the other way around.

    Still – it’s better to have something to shoot for, IMO. Even if you miss it.

  • Felix Pleșoianu said,

    Hahaha, delightful. I recognize #5 from my last 9-to-5 job, and we weren’t even doing games.

    That said, #4 seems superfluous nowadays. Publishers? In the 21st century? What are they good for?

    As for schedules, you’re right on both accounts: with time you get better at estimating, and fitting the game to the schedule (to a degree) can help a lot in mitigating delays.

  • Bad Sector said,

    Regarding “#3”, Doom 3 was id Software’s first game to use a design document and we all saw how unpopular (relatively to their other games) it was :-P. On the other hand, the design document didn’t save Daikatana.

    Of course the design document is more a tool of communication than planning.

    In my opinion things should be somewhere in middle. For example while #1 sounds bad, it is also bad to strictly and mercilessly follow a schedule. This kind of thinking has produced so many awful games because the development team didn’t had more time to fix them.

    Publishers tend to have the money and marketing muscle necessary to make a triple-A game these days 😛

  • Rampant Coyote said,

    I actually had an entire point about design docs, but I wanted to keep it down to 10 items. It was that you should either have two-page design docs, or 800+ page monstrosities.

    I’ve never been a fan of big design docs. I’ve said as much. However, especially working on an RPG and needing other people to be involved in the process, I’ve found that more is needed for something like that. If you are a lone wolf or a partnership, though, working on an action game, then it’s still probably optional.

    I also believe that the idea of a design “doc” as a monolithic piece is outmoded. A design wiki or collection of documents makes far more sense.

  • Bad Sector said,

    Yes I agree with the last one, i call them “design notes” :-). I’m more against to the original “monolithic” design doc.