The Game Design Rough Sketch
Posted by Rampant Coyote on December 30, 2013
I heard a joke the other day: “Weeks of programming can save you hours of planning.”
It’s pretty true, although for certain familiar tasks for veteran programmers, the planning can take a lot more time than just jumping into code. I think in code. But of course, that’s the kind of thing that gets me into trouble, too. Because I can get away with it sometimes, I start thinking I can get away with it most times.
Being a game developer, I have the desire to create far more games than I actually have time to work on. Probably until I die. These are great possibilities for game jam prototypes, if I would quit being lame and actually do another one. I don’t think I’ve participated even once this year. Shame on me. Anyway, I get more exciting ideas than I could ever hope to do, let alone keep track of in my head, so I write them down. I keep a document of all of my game ideas, every single one of which would probably make you say, “Meh,” but at one point I thought it was the Coolest Game Idea Ever.
When I’m really bored or in need of distraction, I’ll actually go so far as to start a short write-up on the design, which rarely exceeds three pages. I just throw around all these ideas about how I’d actually make it all work if I should take it to code. There’s this optimistic, egocentric part of me that looks at the game idea from 30,000 feet above it and says, “That would be easy! I’ll be you could just take a week off and whip out an awesome prototype.” Of course, I’m only thinking of coding, not the 10,000 other tasks that go with making even a prototype game.
Instead, I create the prototype on paper. More of a rough sketch. Yes, that part is faster than coding. I take maybe an hour out. It’s a nice change of pace. This is a “brief game design document” or a “design brief.” Some folks might call it an outline, but I don’t structure it that much. I just think of it as a thumbnail sketch. I write a short explanation of what the game is about, plus some kind of “pitch” that captures my enthusiasm for the game. I write out some of the systems that are whirring in my head that would make the game “tick.” And I write out some examples of interactions or units or characters or whatever that would end up being major content elements. I usually do all this in a page or two.
One night, I woke up in the middle of the night and couldn’t get back to sleep until I did a brain dump of a game idea. That one is still up near the top of my “short list.”
The best thing about doing this is that it prevents me from getting distracted for too long with all the fun potential game projects out there. Creating that rough draft of a paper prototype allows me to feed whatever demons are demanding my attention, and record it so that the effort is not wasted.
One of three things happens.
#1 – I discover that yes, indeed, this is an Awesome Game Idea and put it on the short list for future projects. Some evenings, when I’m sick of working on my main project but want to fiddle with game development, I take a few hours to tinker with it. The cool thing is that I can go to my design brief for the game idea, remember why I was so enthusiastic about it, and get my head back into the same place where I was when I wrote the document. Maybe I add some new ideas. Whatever the case is, it’s a cool idea, and it really does become a “back-burner” project. I keep it simmering.
#2 – I discover that my super-fantastic game idea actually kinda sucks. If I go back to the document I can see later where I discovered it sucks. It may happen in mid-paragraph. The core idea might still be feasible, but at some point while I was developing a rough sketch I realize I had gone off the rails somewhere, and what I had was either no longer interesting or no longer reasonable for an indie developer to mess with. This is just as valuable of a result as #1, because it helps me fall out of love with a distracting idea.
#3 – None of the above. The game concept just isn’t coming together, and it needs more time to gel. I may or may not get back to it another day. I might combine it with another Awesome Game Idea.
Anyway, if I was a lot better at what I do (I keep trying!), this would be an awesome place to draw from for game jam ideas and whatnot. And when the Frayed Knights series is done, I have three pretty clear candidates for what I will do next. Maybe they’ll change by the time I get there. But the nice thing is I’ve got the information recorded and filed away, I feel like I’ve done enough work on them to keep them from gnawing at me, and now I can almost forget about them to get the work done that I really need to do.
Filed Under: Design, Production - Comments: 2 Comments to Read
Copyright © 2024 Rampant Games | Privacy Policy
Powered by WordPress.
McTeddy said,
I do a similar thing. In fact, my process for designing my board games and video games is nearly the same in the beginning.
But, instead of just writing down the brief, I’ll run a number of tests on a paper prototype.
I tend to make an abstracted game that covers the “Great Mechanics” to see if they actually work in practice. Even if you don’t directly mimic the experience, you can test the decision-making and flow of the game.
After testing the prototype, I’ll add any thoughts from the testing such as “Mechanic A shows promise… Test it more” or “This power seemed useless… cut it?”. If I ever return to this project… I’ll have an idea of what to focus on.
This entire process takes an hour or two and can show a number of core design problems. If a game passes this test, It’s worth a computer prototype. If it fails… I’ll store it in case this data will help with a future project*.
* There are times where I create a computer test despite failure… because the approbation isn’t always perfect.
– – –
I actually learned this technique by reading a post-mortem of an early death-match shooter. Developing the net-code would take them a while… so the designers made a board game to test their First Person Shooter.
They mimicked the game Robo Rally, which allowed for simultaneous action. Because the game was still about choosing your own movements and guessing your opponents… it allowed them to mimic their core game and balance the weapons before the game was even playable.
Obviously, when the code was ready they needed to do more balancing to actual real time standards… but the numbers were far closer than the original design document estimates.
Andrew said,
My game-idea-that-will-never-be is a Metroidvania type where Modest and Jake from the webcomic Modest Medusa explore an abandoned Dwarf Fortress, trying to find some way back to their own world. The player would control one character and the other would follow along under AI control (if they can… Modest is absolute rubbish at combat but her light weight and slinky build allow her to climb engraved walls and slip through fortifications, which Jake cannot hope to do).
As they explore the fortress they gain access to resources and workshops (not much good finding a pile of more iron ore than they could ever need without also having found a furnace to render it down to ingots and a metalsmith’s forge to turn the ingots into usable gear). Modest can use some of the workshops, such as a loom to spin thread into cloth and a clothier’s shop to make cloth goods, but only Jake can handle the heavier tasks such as forging weapons and armor.
And of course, when I describe the fortress as ‘abandoned’, that only means there’s no _Dwarves_ present…