Tales of the Rampant Coyote

Adventures in Indie Gaming!

Making Games: Lubricating with a GIMLET

Posted by Rampant Coyote on November 3, 2010

Not too long ago, I read The E-Myth Revisited. While not the final word on why businesses survive or fail, it was packed with a lot of ideas. And I immediately used it as a yardstick to measure every video game studio I have familiarity with. And explains why so many fail. Unfortunately, the principles in the book are better applied to a service or manufacturing company, and are more difficult to apply to creative or entertainment businesses.

I get an automatic resentment towards any management philosophy that tries to treat creative production like a widget factory. Which is, I think, ANOTHER major reason game companies fail as they expand and get new, more professional management.

This was brought back to mind when I re-read Allen Varney’s article, “The Conquest of Origin” last week as I was working on my post on Origin Systems. The quote that struck me was from Stephen Beeman: “You’d like to think a marriage of EA and Origin would result in a merger of their strengths. But instead of combining EA’s execution with Origin’s creativity, the end result was more like Origin’s execution with EA’s creativity.

As a dude sinking an insane amount of my “free” time and a not-inconsiderable amount of out-of-pocket money that could go to my kids’ education into making games and running this website, this is sobering stuff. I mean, sure, I am doing this ‘cuz I love it – I seriously do enjoy making games more than playing them (well, most of the time…)  And as a part-timer (so far), it’s not like a failed game will likely mean not being able to pay the mortgage or put food on the table. But it does make me realize how far I am from making a go at this as a full-time job, and brings up some issues from the book that I’m trying to reconcile in my head and development style (such as it is).

What it comes down to, I think, is that some parts of game development do need to work like a widget factory. Yes, I am horrified to admit it. But if you run a game development business, like all software development, it needs to run as a business. This means predictability and consistency. It means some level of repeatable process. At the very least, it means being able to come up with a somewhat accurate estimate of the time and resources needed to complete a product, and some concept of what kind of return can be anticipated to make it worthwhile. That’s the business side of things.

And maybe it doesn’t need to suck all the fun out of making games.

Sadly, in spite of years of professional experience making games, I fail here. I guess Rampant Games is not yet ready to become a full-time endeavor. My development process is still pretty haphazard. How do I measure project velocity? How do I make sure it’s heading in the right direction? And how do I gauge quality? And once I am able to measure these elements, what can I do to improve? Obviously, if I don’t have a process in place, it’s hard to improve upon it, or build the tools necessary to do so.

I think one of the failings in the software industry is that it keeps searching for a “one size fits all” solution.  Games are different from customer management software. Downloadable games are different from web-based social games. RPGs are different from action games. I probably work differently from Thomas Riegsecker. A single, supposedly objective uniform process isn’t going to work best for all of us.

So I’m working on that. Making a process, a methodology for doing some things that will hopefully allow me to be more consistent, automate some parts, maybe even offload some responsibilities at a later date, and most importantly allow me to concentrate more time on the fun stuff.

Then there’s the quality aspect. One thing I’ve found in all game projects is that its easy to lose sight of quality while neck-deep in production. When I do that in Frayed Knights development, I sometimes go back and discover that I’ve gone and set up three almost identical combat encounters one right after another, or some other stupid thing like that. Or – just as bad – I’ve put hours and hours into working on something that going to make very little difference in the game (AKA “Gold-Plating”). Having some kind of pattern in place to help me make sure I’m working on the things that *I* consider important for game quality would be helpful, especially on those nights the creative part of my brain has gone into autopilot.

I’ve a sneaking suspicion that a gimlet might help. Or rather, GIMLET.

I’ve been delighted reading The CRPG Addict’s Blog, and Kevin made me a more readable / printable PDF of the GIMLET RPG Rating / Ranking System that the CRPG Addict came up with to try and find a common system for evaluating RPGs with extreme differences in technology and style. I printed it up and hung it in my office, near my framed cloth map from Ultima V. It’s a subjective system, which is actually just fine by me.

I’m mentally tinkering with the system, considering how I might personally use something similar as a yardstick for not only measuring my games, but actually as something of a template for design. Not to “game the system” or just check boxes. That would be silly, as it will be an unrecognizably modded-up system vaguely based on something only used by one guy on a blog somewhere who will never review my games. But the point is to provide focus and structure as I move forward – a system for evaluating the design and results. To turn it into a recipe for my “secret sauce.” Or something.

I’m still in mulling / experimentation mode here. We’ll see how it turns out. But if any other indie devs are reading this and have insight into this, please speak up! Hopefully this will help. I’d love to share anything that helps other indie devs improve their chances of success in a field where failure is, unfortunately, the norm.

Oh, and to The CRPG Addict: Thanks for the GIMLET! We’ll see if it helps Frayed Knights 2

Filed Under: Biz - Comments: 8 Comments to Read

  • Adamantyr said,

    It’s easy to lose perspective when you’re knee-deep in code and design. That’s why it’s also important to have a test team. They can act as not only code testers but also quality control. If you don’t already, you should have some close associates “test” out your builds on semi-regular basis and provide feedback.

    And the #1 rule of any game is “Is it fun?” I’m pretty sure a lot of mainstream designers for the big companies never ask themselves this personally. “Well, marketing shows this type of game is popular…”

    As far as a yardstick, I think an important aspect of any game is the measure of how often the player determines the next course of action. Linearity is the bane of any game… if we wanted linear, we’d watch a movie.

  • Rampant Coyote said,

    True, but you can’t just throw the game together and not find out whether it’s fun or not until its ready for external testing. And frankly, even the best games aren’t a whole lot of fun during much of development (though that could also be a procedural thing – early integration of testable features…)

    The non-linearity thing is also a big deal that I’m hoping to address with this. Going too far without an Event or Decision is a bad thing. Long, straight hallways are Bad. And no, they aren’t spiced up much with generic combat encounters. I *think* I’ve done a pretty good job of it in Frayed Knights, but there remain some outdoor areas that need to be broken up with more Stuff To Mess With.

    I want to turn that into kind of a checklist-style item so I can find problem areas earlier.

  • Silemess said,

    If it is any consolation, your posts on here help to give some insight on the game development process to those of us on the outside. I don’t work professionally as a programmer, and my hobby projects you could code in an afternoon (maybe two if I’m generous to myself).

    So I appreciate being given these glimpses into the trials and tribulations. I also revel in the triumphs and glories, but hey… who doesn’t enjoy success even if its vicarious?

  • McTeddy said,

    I second the notion of a test team. I’ve got a couple dozen people that I usually have test my projects. The key here is that I’ve got 2 stages of “Testers”, Devs and Players.

    Early in my testing I rely on letting Developers test the functionality. They understand that it is a work in progress and can take into account “This will be added eventually”. But they can also tell me if something isn’t working for them. Early warning makes if far easy to redo systems.

    When I get to player testing, it’s usually past the point that I can make major changes. I’ve built a functional game engine, but still need to complete the game. At this point I can see how fast normal people can pick up on it and what they enjoy. If I find out that they enjoy the combat, I can simply add more… if they dislike the lockpick system I can cut back on how much lockpicking there is. While it’s not perfect, it lets me try and make it good enough that people will enjoy it.

    As for the procedure, I usually focus on order of importance. Anything that is very important to the game such as Combat, will be in the first few steps of development. Having it done early means that I have longer to test and tweak it, and if I am short on time, I can cut the less important features that weren’t implemented until later.

    As for Linearity, I whole-heartedly disagree. Whether a game is linear or not depends on many different things. Puzzle games, side-scrollers, shooters, and even RPGs can be amazing despite being linear.

    Most oldschool RPGs had fake freedom, but in reality were very linear. You can go anywhere… but you can only win by taking these steps in this order. This straight forward sequence of events made the experience streamlined… fast paced… and focused the story into a specific sequence of events. It’s hard to believe, but in some situations focusing the game-play can enhance the experience.

    Saying that linear is the bane of any game is nothing more than fitting all games into the universal formula. It should do what it is intended to do in whatever way works… entertain the player.

  • Felix Pleșoianu said,

    You know, people like to compare software development with the construction business, as if the latter is a smooth, predictable process. And it’s not! Construction projects are fraught with uncertainty. Even building an ordinary house can run into all kinds of unplanned-for difficulties. Why do we expect the far more complex process of software development to be any better?

    Business is risk. Life is risk. Maybe we should all grow up and get used to it.

  • Rampant Coyote said,

    Well, I’d caution that successful businesses *manage* risk. Sure, there’s always cost overruns, surprises, changes, etc. But a good, well-managed business should be able to deal with most of these situations so it will come out within a predictable window.

    I think the problem with games (and other labors of love) is that there’s a tendency for the developers to be unsatisfied with producing something that’s merely “satisfactory.” There’s always the push to go the extra mile. Unfortunately, when combined with crappy management and prediction of the effort required to make a game, you end up with the devs NEEDING to go the extra mile just to get the game out the door not too far behind schedule.

  • Felix Pleșoianu said,

    “there’s a tendency for the developers to be unsatisfied with producing something that’s merely “satisfactory.””

    Ah, you’ve touched a sensitive string. As I like to say, people tend to want all or nothing, and they want it now. And of course “all” can mean a lot of stuff. I went into more detail about it here: http://notimetoplay.org/2010/11/02/secrets-of-a-successful-programmer/

    Also, you’re absolutely right that risk should be managed. But in my experience, many people refuse to accept risk as a reality in the first place.

  • Making Games: Adding Role-Playing to Computer Role-Playing Games said,

    […] Comments Felix Pleșoianu on Making Games: Lubricating with a GIMLETRampant Coyote on Making Games: Lubricating with a GIMLETFelix Pleșoianu on Making Games: […]