Building Awesome RPG Levels Blazingly Fast By Embracing Feature Creep

Posted by Rampant Coyote on June 16, 2014

“Create as if nobody will ever see it; then polish as if millions will.”

I saw this advice for writing, and wondered how applicable it would be for games. The first part – creating as if nobody will see it – gives the writer two benefits. The first is a freedom to write whatever kind of story he or she wants to write, regardless of genre, market trends, and so forth. The second is speed. I’ve read (and found first-hand) that if you edit as you write, you will get bogged down to a snail’s pace. It is much faster to go back and revise once everything is down on paper than it is to edit as you go, and the results are usually better.

The main difference is that there’s a higher cost for revision in game development than there is for writing. Or is there?

That’s why prototyping is so important. This includes writing up the game design document, which I consider the “paper prototype” (and I don’t usually worry about it falling out of date). I’ve been obsessing lately about my (lack of) development speed, and how to improve that. I think improving my prototyping methodology is a great start, from paper to gray-box to final product.

It seems my best ideas come from very simple concepts that I iterate on. I keep having to re-learn this lesson. I know it works. I’ve seen it work many times, every time. Creativity seems to flow best while you are in the process of creating.  It’s totally dumb, I know. It feels like jumping out of a plane and then trying to build a parachute on your way down, but that’s how it works.

It’s that same creative force that will work against you if you edit and revise *AS* you are creating. The process of creating causes a ton of creative ideas to flow, and allows you to see things far more clearly than when you were second-guessing yourself at the starting point. The trick is that instead of constantly revising as you go, you are able to get ideas onto the screen as quickly as possible, and then review, improve, and repeat.  This means a rapid (and cheap!) iteration cycle.

As I said, I’m bad at it. I am one of those guys who tends to edit as he goes, get stuck in analysis paralysis, etc. When I *do* it, things go great. I have the same problem when I’m writing – I have to fight the urge to edit and revise as I’m creating. You’d think I’d learn…

I’ve even gone on record a few times against design documents – even though I sometimes use them myself. That’s mainly because I think that the industry has used them incorrectly. But done right, they can be an incredibly useful prototyping tool. You can’t design fun on paper, but sometimes putting it all on paper and drawing quick sketches can show you where the sucky parts are. And even if you know you are going to be chucking the blueprint at some point to go off in your own direction, it’s extremely useful to actually have that starting point.  Again, it’s that creative process at work — the ideas tend to flow better while you are building on something that’s already there, rather than trying to summon them from the clear blue sky.

So – with all this aforementioned obsessing over development speed (which sucks) and my tendency to get mired down by analysis paralysis, and the likelihood of “feature creep” raising its ugly head after it’s too costly to make serious changes. I think it’s all about prototyping and getting that rapid iteration process down. Taking that same idea, it’s better to start with a flawed process that I can improve on than having no process at all, so I’m working out something semi-formal to use as a crutch or guide.

Note that this is for content, not code. While code is in no way ‘complete’ at this point, the key features for a playable game are all there, and I’m now transitioning to hardcore content development mode. It’s time to go from basic outlines to detailed gameplay. Some stages are merely on paper (write-ups), others are actual in-game prototypes.

Here’s what I’m currently trying – the stages of the process:

#0 – Brainstorm (write-up): Given the needs of the level / area / quest, I just write down ideas. A mess of them. Ideally, I should keep this is a standing, living document, because ideas that don’t make it into the current level can be used elsewhere. This doesn’t need to be done every time for every level. At least for me, I already had an outline and basics planned (for years) for the main areas. But it’s still a good place to go back to for ideas.

#1 – Simple Overview (write-up): This can be in paragraph or bullet-list form. Taking the ideas that best fit from the brainstorm stage. But this is describing the key concepts for the level / area / quest.  I describe my key elements (location / backstory / story progression / quests / main challenges ) in a sentence or two, and come up with something that might be two or three paragraphs in length. Then I’m working with something concrete.

#2 – Detailed outline (write-up): This is where I draw up the map (at least mentally, if it’s a tiny area), and expand each of those one-or-two-sentence elements into one or two paragraphs. I also break out all of the key encounters and features. This isn’t every single detail. This is “everything important about this level.”

#3 – Gray-box walkthrough (game): I finally get things on the screen. This is where I create a rough level capable of being walked through, with all the key features placed in non-interactive or semi-interactive form, but without the full gameplay. The levels at this point are “gray-boxed” – simple, ugly geometry with a stand-in texture. By walking through the level and seeing where everything will go, I can see what needs to be tweaked and added. This can also give me some cool ideas that may or may not fit.

#4 – Playable Gray-Box Level (game): Attempt to add at least a simplified version of most interactive elements. At this point, it may look ugly, nothing is properly balanced, but if you squint REALLY hard, you can see the final game from here.

#5 – Beta-level (game): This is the “final” version of the level. At this point, the changes are either going to be small and often bug-related, or they are likely to be costly to make.

One amusing note here is that, in a way, I’m actually embracing feature creep. At each stage, I’m actively inviting really cool ideas for new features and changes to the game. At each stage, the range of allowable changes grows a little smaller, but there’s plenty of room for big changes all the way up to the final stage. But if it’s an inevitable part of development, why not take advantage of it?

How much time should each of these take? Each stage does take a progressively longer period of time (not including the brainstorm session). Stages 1-3 can all be done in a single evening, with the first stage only taking a few minutes, the second stage taking a half-hour to an hour, and the third stage probably taking well over an hour.  After that… it really depends on the size of the level.

Anyway, this is actually a new process for me, although it has evolved from what has worked for me in the past.  I’m going to try and stick with it, to defeat some bad habits of mine, and see how things go. Things are starting to hit an acceleration phase, and we have a hard deadline of the first of September facing us for a fully playable, awesome, show-worthy level.

Filed Under: Books, Frayed Knights, Production - Comments: 2 Comments to Read



top