How many people plan their games out on paper?

#1 I use paper to plan things out. I write down basic info such as a backstory of the game , characters, things that will happen. For artwork and storyboards, I draw them down in my sketchbook. I also use storyboards to plan out cutscenes. I like to type up the document in word. nothing special.

#2 I usually just have several notebooks that I jot various things down on (story, programming, art, etc). I've generally got a good plan always going in my head, but the notebooks help me out a good deal when it comes to planning something far ahead or something currently requiring a good amount of detail.

#3 I've always found a text editor to be the best sort of thing to plan out a program in general (I'm not much of a game developer -- yet :P).

When planning GUIs, I sometimes draw them out, but it's better to just dive in and use the GUI editor (or in my case, the Windows.Forms designer in VS) and just draw your interface.

The major thing is -- always always always plan out the following:

- The ultimate purpose of your program (or in this case, your game);

- The intended audience of the program (for games, the genre type and the age of players involved. You'd have to tailor your design to suit the specific genre and age group. For programs in general, the type of users who are using it is important to know; i.e. - in TorqueDev/Codeweaver, I know that programmers will be using it, so I don't have to explain every small feature. Most of the users are familiar with traditional IDEs, therefore I can stick things where they'll be found).

- Chart out milestones for your project. Base these milestones on your known skills. If you're delving into new territory, always make time for research and learning. It's always best to allocate more time than less.

- Don't be overly abitious. Stay within your known talents and skills. If you know you won't have the capacity to learn differential calculus, stay away from the area or anything that may require it, or make plans to do some extensive study before continuing. It's a good idea to seek help from people in the specific field that you're studying, too, to make this process go easier.

- Develop regularly and don't burn yourself out. Set a schedule up for yourself. Tell yourself you're going to only go for x hours before calling it a day. Take regular breaks, too. If you get stressed out by a problem, leave it until the next day. Your mind will mull over solutions and it's usually easier to approach after some rest.

- Conversely, don't procrastinate either. Many a project was never completed because either: interest was lost; the programmer became disillusioned and stopped; or so much was planned that it was difficult to wrap the idea around reality. It's always best to start small, work regularly, and complete a project before increasing your goals.

- If you're working with multiple developers, setting up a CVS to avoid concurrent-development problems is always a good idea. There are lots of good resources on the 'net for how such "groupware" programs can make life easier for you and your team.

- If you don't meet your deadline, don't be disillusioned. Just set a new one, allocating enough time for the remaining work that has to be done, and press on. Eventually, you'll get there.

I know this kind of went beyond the scope of "planning games out on paper", but I've always felt it important to advise newcomers on the proper steps that should be taken.

I'm sure many more items can be added to my list above. These are just the ones that came to mind briefly.

Good luck!

#4 I do.

I tend to map the basic desing out in an outline format.

More specific mathematicl systems I will often set up in a spreadsheet in excel so I can run "worst case" scenarios to better know what I'm dealing with or what abuses such a system might be vulnerable to.

As far as advice, I'd say always ask yourself "why".

You want to include ub3r gun # 2335, why? Who will use it? When should it be used? Would rampant use unbalance the game? How will you restric it's uses to discourage abuse of it? ect. etc... just as an example. (C;

#5 I wrote out a concept doc, and then we teaked that, and then wrote a complete design doc, from chris taylors template.

#6 Most of the work that we have done on Realm Wars 2 is on paper. From the rough notes for the design doc, to mission templates and of course model concepts that we have. Its been highly beneficial towards keeping the project focused and in the realm of reality IMHO.

#7 Good info Sam Bacsa! :D

#8 Sam's information is excellent.

I use my Tablet PC, Photoshop, Sketchpad, and Word.

#9 For this project I didn't.

That said, "This Project" is my Senior Project and I specifically decided to "Re-implement a classic NES Game in Torque)" so that I could 'skip' the design step as much as possible. I'm one guy, I can't do EVERYTHING in a semester :-P

I should also point out I'm on my 2nd yellow pad since this journey began, I usually work out the specifics of stuff on paper before programming it. This has been usefull when I don't get around to programming it, and have to look back later.

I DID write out a "Master-To-Do" list at the beginning which ended up being a 12-page outline of every step of every major and minor milestone I could think of. That in it'self was a small achievement, but my professor liked it.

--

I've seen advice from alot of people that says it's better to complete a small project, than not-complete a big project, especially if you are inexperienced. Don't try to build you Masterpiece on your first, or even second or third project! Start small and work up!

Also expect things to go slow as you mount the learning curve but don't think you have to "know everything" to start. The best way to learn torque is by using, changing and breaking it - once resource at a time!

#10 I'll second Sam's words and add my on $0.02.

Something to keep in mind is that plotting your course is not necessarily writing a bible. A lot of people get cuaght up in this idea of writing a design document that has absolutely everything laid out, which IMHO is a great way to frustrate and overwhelm yourself.

Work in small bites and braid strokes. Though this might seem a contradiction it really isn't. One of the rules we follow over at wideload is trying to say things in one page or less. This makes you shoot for the core of what things are. Do this for your game types, your levels, your game play, your metagame, and your main characters (if any) and you'll have a basic document to expand upon as things progress. This is what I mean by small bites and broad strokes.

Our first document for Stubbs the Zombie wasn't more than a handful of pages. What was important about it was that is capsulized the vision of the project more than the specifics. The version of the doc we used when shopping the game around didn't even have level descriptions. Anyone looking at it, however, knew right away what we were going for, what it would look like, and what technology we would require.

Try to avoid doing anything without writing it down, especially if there's more than yourself working on it. A great way to make sure that everyone is on the same page (aside from having regular meetings) is having said page for everyone to read and discuss.

Refine as necessary.

We didn't start out with any real formats but we did eventually standardize things. We had one page templates for level ideas, and larger ones for refining the fine details.

Keep a notebook with you. My buddy is my Moleskine. I take it every where with me and jot down thoughts as they come to me.

As for starting out, trythe following:

* Write a 1 page treatment that describes the game.

* Show it to someone whose jugment youtrust and ask them to point out the things that stand out to them and the things that feel lackluster. Take notes (mind you that for me take notes often means store this in your noggin).

* Show it to someone who doesn't necessarily like the same things you like and ask them to tell you what jumps out at them as well. Take notes.

* Rewrite the document. Put it away. Go do something else for a bit to distance your mind from the idea. Play a game, watch a movie, lay down a wood floor, whatever it takes to relax your mind.

* Go back to your docement and read it. Do Try rewriting it reflecting different play genres (puzzle game, action game, FPS, etc.).

* When you think you've found the angle you want, try expanding to the treatment to a 2 to 3 page doc. In this document expand on the game play, style, technology and the things that will make the game stand out in the genre it falls in. Keep in mind the kinds of people who you think will find your game attractive, as that will help you find good language. When you are done with this you will have your skeleton. You might then want to break it apart into sections. You might even consider making a private wiki to help organize your thoughts. The nice thing about a wiki is that it grows with the game very well by allowing you to easily section your document up and scope down on the areas you are currently dealing with.

You will eventually have focus, morale issues as you work on your game and having this ready at hand will help you overcome these hard times because you will have that defined vision on paper.

One other thing I should mention is that you shouldn't feel obliged to make a game out of the first good idea you get. Prototype early with your core mechanics (the thing that the player will eb doing most of the time). If you can't find fun here it's time to rethink and redefine your approach or scrap it and move on to something else. It is not a failure to not find fun, it is a success. You now know what doesn't work, that get's you one step closer to figuring out what does.

-Allen

#11 I don't make myself require it, but the few games I've completed have always eventually had some sketches and brief paragraphs describing key pieces of gameplay.

The programming work tends to have more detail to it than the game design, because the design always seems to need some more feedback to be properly evaluated - unless you somehow figured out beforehand every concievable property of every item from the dimensions of collision to the speed of every animation. It's much easier to just guess and check those things than it is to guess at programming tasks and leave them unclear.

Usually my design ideas only work out if I'm bouncing off the walls at the thought of it. The one or two where it's like "this might be kind of interesting to play" are exactly that - kind of interesting. And I have to work at their designs more, too, usually. The good ones are envisioned well enough from the beginning that I'm writing down stuff just because I'm going crazy trying to get it out of my head.

#12 I've found that my best designs come from games where I wrote a complete document at the beginning, including the gameplay, the target market (even for freeware, I treat it as if I were selling it), the UI, and all systems needed to make the game "go". For Rumble Box this was 44 pages long! This approach is definitely not for every indie, but I feel that it forces me to think out everything before I start.

Of course, in many cases the document is only a jumping off point. For example, the chain combo and scoring systems for Rumble Box were designed, tested, and then thrown out and redesigned. Then thrown out again and turned into the system we have now. The level progression also changed heavily, because players were getting bored in level one (which took eight minutes to get out of, originally). Finally, two enemies were combined to create one more interesting enemy (the Bug and Zombie merged and became the Wildman). But without the document, who knows how many iterations these systems would have gone through before fitting our original vision.

In my current project, Lemmon's Workbench, we figured "it's a simple puzzle game, we don't need a big complex document". We pay for that every day... after having not thought out everything in the beginning, we have redesigned every system in the game multiple times. The game is coming along nicely, but it would have been much smoother had we just written a document beforehand.

Like I said, though, it depends entirely on your personal preference. The way I look at it, though, is "it can't hurt, can it?".

#13 I have gone thru ton's of documented ideas but nothing has stuck yet as "the plan". I use IC dictator (tapeless) when out an about
to take notes then transcribe any game concept and plans in text. All that and other stuff get's backed up offsite as well once a month.

#14 I find that if I work out things that are going to be complex on paper, it helps keep me organized. It is just too easy to forget where you are, or some sort of detail when you are typing away.

#15 I almost always use paper for the initial brainstorm. Usually only take about 30 minutes to an hour to plan out the core of the game. I prefer paper initially probably because it's quicker and easier to diagram the key concepts with pencil than to break out MSPaint or whatever. Once I have a solid conceptual core down, I move everything to a modular Wordpad document, and translate the key pencil diagrams to MSPaint objects which are inserted into the Wordpad document where relevant.

Works great.

#16 Often you come up with so many good ideas, some are meaningless yet so important, that you just gotta write it down.

I make a game folder, and make level folders, and pull all my notepads and photos and notes in there. Then when I work on a level, I open up that folder and check out what I kept on file.

E-Filing, it's helpful

#17 I do some writing... but really at the most critical element 'writing down in a scratch pad' I do little.

I do write these massively detailed project proposals before each project that no one on my team ever looks at, largely because they just ask me, but I don't really count that in terms of worthwhile time spent (the graders love it though =P)

Dracos

#18 I write down a one-pager of the game concept... the core elements. Then once I'm getting started on the project I write down a to-do list for stuff I need to do. I don't try to think of everything at once... I have tried that in the past and the projects ended up being pointless and not fun. I just write down what needs to happen in the near future, or if it must be distant, it's very general.

I try to work on things for the whole game prototype first. So I don't write much down on what artwork is needed, what kind of music, etc. in the first stages of development. Once the prototype looks good, I start filling in what needs done with the other assets in the game.

Like others, when I approach a complex problem, writing it down makes it easier to solve and keeps me organized for when I go to implement it. I also write down quick notes about characters, levels, and all that.

I am a one-man team, so all of this may not work so well on larger teams.

#19 Like J. Alan, I'm also a one-man team and I find having a notebook to be quite helpful in organizing numerous things, like characters, levels, plotline, abilities, weapons and the like. If you have to leave a particular concept alone for a long while, it makes for a great way to recall it all later. I use the notebook also to organize what order I should do things in, as well.

I don't think there's really too much more I can add to the need of a notebook. J. Alan's pretty much covered everything I would've said. =P

EDIT: I should've added, that like some of the other above posters, I use it for GUI planning and storyboards, as well. =P

EDIT AGAIN: Whoops, I must've been pretty tired. I didn't realise I already posted in this thread a couple months ago. =P

#20 I think its good to have a brief outline of the project, sit with your team and narrow the focus down so everyone understands the core of the game and what absolutely must be in there. I think its hard to write a game down and stick to it as so much of of the game is very touchy feely. And often what looks good on paper doesn't work out as well as intended, particularly in gameplay.

It is important that the core team knows what they are working on, and what is needed to achieve those goals. Much of it is going to be experimentation though.