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



top