Tales of the Rampant Coyote

Adventures in Indie Gaming!

Game Development. Cheaper.

Posted by Rampant Coyote on January 6, 2012

I was going to write this longish piece about lessons learned from working on Frayed Knights: The Skull of S’makh-Daon. I still plan on it, but then prolific game-design thinker Raph Koster went and did a write-up about making games “more cheaply” (which can also be interpreted as, “more quickly,” as the major cost in software development is time). While I can pick nits over it, I’d consider it a “must read” for anybody involved in game software development – mainstream or indie.

Raph’s Website: Making Games More Cheaply

My thoughts…

#1 – Re-use engines. I’d also suggest: Consider off-the-shelf engines. I didn’t always subscribe to this philosophy (and if you recall, Void War was a totally home-brewed game engine).  But over the years, game engines have gotten a lot more sophisticated, a lot more price-friendly, and customer expectations have gone up a lot. But I will suggest that an off-the-shelf game engine can be a lot more trouble than it sounds.  I am honestly not sure if Frayed Knights would have taken less time if I’d written the game engine myself.  Or at least used a different engine. Every engine has its limitations, problems, bugs, and a learning curve.

There’s another factor as well, which Koster implies here… do you want to write game engines, or write games? While I love solving the technical problems (the higher-level architectural and optimization problems, not the “this game won’t run on this video card” problems) that come with engine design, I realized that my real love was making games. Back in the day the classic game developers had to create worlds that could be envisioned by players at 256 (or 16, or worse) colors at 320 x 200 resolution (or worse). They made do. Game design is all about creating entertainment within constaints.

#2 – Aesthetics, not bleeding-edge graphics: Sadly, the average gamer tends to associate the worth of a game with the “awesomeness” of the graphics. I wish this was not so, but considering how many players are dinging a game like Skyrim for its graphics (which for me are still in the mind-bogglingly cool realm – I don’t care if there are some tightly constrained games with marginally better-looking visuals), it’s definitely an issue. This is especially frustrating for programmers like me who aren’t great at art. 🙂 But Koster’s point is that you don’t need to be bleeding-edge to look good. The graphics and style of Bastion really impressed me this year.  Frankly, we passed the point of diminishing returns several years ago, IMO, which means it costs an increasingly greater amount of time and effort to produce a marginal improvement in graphical fidelity (or “awesomeness”). The biggest publishers can still ride that train, but I think for most developers it’s more a question of what the artists can do within a limited amount of time rather than what the next-gen consoles or highest-end computers can do.

#3 – Embrace Tools. Abraham Lincoln is famously quoted as saying, “Give me six hours to chop down a tree, and I will spend the first four sharpening the axe.”  Meaning spend the time in preparation and making sure your tools are up to the task. This was something that bit me repeatedly in Frayed Knights. When I finally broke down and spent time building even the simplest of tools to help me through some bottlenecks, things improved substantially. And I was constantly fighting tool limitations (and bugs). The simplest example I can make is the plethora of RPG Maker titles now available – both free and commercial.  Yes, making a good, quality RPG is still a major effort even with that powerful toolkit.  But the tools (and, obviously, the engine) make it several times easier. Or, to put it in more practical terms – it frees up the time and effort to be put towards quality, rather than just getting the game to work.

#4 – Embrace Procedural Content, but don’t over-rely on it. This was another huge lesson I learned with Frayed Knights (which had very little procedural content, aside from some randomized encounters and loot) which I am really trying to apply to the sequel. I’m going to have a larger post about this in the future, but it really goes hand-in-hand with tools creation. The bottom line is to make it so that the designers only have to focus on custom-building the parts that are important to them. Let automation handle the rest.

#5 – Systemic Game Design vs. Content-Driven Design: This is a toughie with RPGs and adventure games (which he acknowledges), but an emphasis on repeatable systems and mechanics can really save the day. This also goes hand-in-hand with the procedural content and tools points, too. I mean, a big aspect of RPGs (for me) is exploration, which can be loosely interpreted as “devouring content.” At a voracious rate.  But at it’s heart, an RPG has a few core systems – particularly combat (usually) which can be emphasized without necessarily turning into repetitive grinding.

I think this is more important than many RPG fans & designers might credit it. What constitutes a “grind?” For me, it’s repetitive gameplay. What makes combat repetitive? It’s when I have little variation on my actions or tactics. It doesn’t matter if the graphics for whatever monster I’m fighting have gone through a dozen different changes – if they are all acting the same but getting tougher, I’m grinding. I’m getting bored. It’s the variations of actual gameplay that keep me interested – from interesting tactical & terrain-based challenges or unusual new powers that force me to cope and vary my tactics. Or – better yet – more interesting AI approaches. Or multiple competing goals (like, “don’t let the hostages get killed”). Think about how well X-Com worked back in the day with essentially random battlefields and challenges. Build upon a solid foundation, and all of this can come pretty easily and new content becomes icing on the cake.

#6 – Embrace Prototyping: I can’t agree with this one more. I have an issue with giant design documents. And there is an overwhelming abundance of evidence that getting a playable “demo” working internally as early as possible is a major factor in the success of a game.  The prototype doesn’t even have to be playable on the computer. RPG designers – ever consider running your concepts as a pen-and-paper D&D game first before committing them to code & data?




Filed Under: Game Development - Comments: 6 Comments to Read

  • McTeddy said,

    Learning those 6 rules really would cut countless wasted hours from dev time.

    It does make back to my mainstream days. I remember that we were making a board game and we had a board that was used for marketing. Yet when I suggested we try playing it on a tabletop before putting two weeks into coding untested rules… I was told that it is silly to think playing a board game could help us make a video game.

    Rule #3 on the other hand was even worse. Our lead designer would break the build NIGHTLY while working in the XML… yet I was silly when I offered to build a graphical interface so he couldn’t break it anymore. “We don’t need tools if we can do it by hand! You’d be wasting all of our time.”

    On the other hand… we never did fix the half tested and broken rules even after they were coded. So maybe prototyping would have been waste in that case.

  • True to Design: What I’m Reading « Managing the Game said,

    […] Game Development. Cheaper.: http://rampantgames.com/blog/?p=3750 […]

  • Want cheaper games? Work less! « No Time To Play said,

    […] game developer Raph Koster starts 2012 with a 6-point guide to making cheaper games, to which the Rampant Coyote responds thoughtfully as ever. Here at No Time To Play, we are definitely interested in this particular […]

  • Ahtchu said,

    What if the true issue isn’t the cost? I maintain that I couldn’t care less at the cost of a game, I care about its QUALITY. There are more than a plethora of titles for any conceivable budget, ranging from $1 to $80, but the titles that can be called ‘quality’ work I could count on one hand.
    I agree with most all of the points made in the OP, and it’s absolutely great to nitpick the business side of things, but is it not the cart to the game’s horse?

  • Rampant Coyote said,

    You may not care about the cost of the game, but it may mean the difference between the developer releasing the game or going bankrupt (too often they play it too close and end up doing both). I wish I could say the recouped costs from making the game cheaper could go into polishing – and some of it probably will – but that’s not a given. But I *CAN* say that when a game is over budget (in time and money, which are pretty much the same thing), there’s very LITTLE attention left over to be spent on quality.

  • Les said,

    My few cents:

    #1 – Re-use engines. I would say it depends of what are you creating. If puzzle game – no engine is neccessary (maybe some graphical libraries and some custom effects) However, if you are planning for 3D I would think that Unity or UDK will solve much more more problems, than it creates.

    #2 – Aesthetics, not bleeding-edge graphics. Unfortunately, like Coyote mentioned – market already decided, that awesome looking games are awesome.
    I just wonder when it will crash 🙂

    #3 – Embrace Tools. Agree, good tools are the base. However, we sometimes can use shortcuts (graphical program with some bmp-to-level convertor).

    #4 – Embrace Procedural Content. Not much experience here.

    #5 – Systemic Game Design vs. Content-Driven Design. Depends on your philosophy, IMO both ways have their uses.

    #6 – Embrace Prototyping. Yeah, prototyping is good and saves much time later (when you are finishing application). However, never let prototype become base for your game. Prototype is for what it is – scratch it and start anew.