Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I always thought that planning is important for a game. But i don't know at which point. Some are telling me to code instead of planning but i feel like its still important because when you will be in the code you will know what to do next more easily. I am currently working on a game that will have lots of content so i decided to start a design document introducing thoses content and at a side-level i am doing proofs of concept to check if it can be done. Parts of each proofs of concept then could be used later in the real game.

EDIT: I am working alone on this project.

So my question is : It is worth planning before jumping in the code ? Im still interested to know what others have to say about this. Cause i still get some poeple saying i should code instead of thinking.. so what your opinion on this ?

share|improve this question
    
Are you working alone or as a team? –  nathan Sep 28 '12 at 13:03
6  
-1 I don't believe this question has a correct answer. It depends on the person's skills and the project. It's too localized to try to answer it just for you. –  Byte56 Sep 28 '12 at 14:47
3  
Just an advice: I never plan my games before coding. Also, I have started many game projects and never finished one. –  lvella Sep 28 '12 at 17:38
1  
@MarkusvonBroady I can't really answer. If it's "worth" doing something or not is really up to the individual. It would depend on the individual, the project and the moment in time. I wouldn't know if it was worth it for the OP to do it or not. –  Byte56 Sep 28 '12 at 18:08
3  
This really is off-topic, sorry. Try programmers.stackexchange.com instead. –  Cyclops Sep 29 '12 at 19:18
show 4 more comments

7 Answers

up vote 33 down vote accepted

You said two smart things in your question:

  1. "code instead of thinking" - there's a whole philosophy describing this: http://gettingreal.37signals.com/toc.php
  2. "proofs of concept to check if it can be done" - I've seen and had many ideas that turned to be impossible or extremely hard to make when they were almost finished. Sometimes you just can't predict it, because it's your programming environment (language, libraries, hardware performance) limiting you.

That's why I say:

  • design, but don't make a huge design-doc if you're not looking for collaborators or investors, unless it's fun to you and you take it as a break from programming;
  • always have in mind what you want to achieve; every module should have a designed input and output; that way you can easily test the module, and have no feeling of wandering in the fog;
  • remember that you design most of the time anyway, as typing code takes only about 5% of your time (at least typing the final code);
  • programming is not a theoretical science, instead of checking if something will work on a piece of paper, you can just code it and try; final product is mostly about making user input foolproof, GUI looking nice and dealing with special cases - a dirty test of an idea can be made straightaway;
  • create a todo list if you're afraid of forgetting your ideas
  • talk with your friends about your ideas, as they will be less enthusiastic and may have more experience in a field; once I had an idea of keeping unit parameters (in a strategical game) secret, but my friend told me it's a bad idea, as he played a game like this and it was a terrible user experience.
share|improve this answer
    
Interesting points. –  Rushino Sep 28 '12 at 13:46
    
This is a really good well thought answer. +1 –  Arthur Wulf White Sep 28 '12 at 14:25
5  
+1 to the todo-list –  labotsirc Sep 28 '12 at 14:42
    
+1. I especially like your point about a dirty test can be made straightaway. Prototypes are very cheap in comparison to a design that just won't work. –  Earlz Sep 28 '12 at 15:26
    
+1 for todo list as well, and as a tip I use GraphViz to make my todo lists visual, since I tend to have ideas that can only be done after finishing other ideas. It helps me to focus on which things I need to do first, so I don't get all mixed up. –  Izkata Sep 28 '12 at 21:50
add comment

You have to know where you are going before writing code and writing/drawing can be a good way to materialize what you want to achieve. I say drawing because drawing diagrams, sketches etc. may also help you a lot. You don't need to make a wonderful document made with Word or anything, just take a pencil and a piece of paper (lot of pieces of paper?) and draw, write everything you may think about.

To me, it's a good practice to use pencil and papers, it helps materializing your ideas and also set where you want to go to prevent going anywhere, fix your goal. It works for everything that needs reflexion. And it's obvious in a lot of domains to write things down before doing the actual work.

share|improve this answer
add comment

Some say you should code instead of thinking? Well to code you need to know what you want to create, to know what you want to create you first need to think what you want to have, ergo you need to think before you code ;).

And seriously, you probably don't need a detailed plan right at the beginning, but having an outline and/or milestones is always benefical - also for your atitude, when you cross out things as done, you will be more encouraged to do more work.

share|improve this answer
add comment

Do whatever works for you. Personally, I plan out things to a small extent, but don't have design documents are extremely detailed plans before I start coding anything. Do whatever is the most productive for you, especially since you're working alone.

share|improve this answer
add comment

Both coding and planning is needed. First plan, then code, but don't plan everything at once. Plan a core, code it, updating your plan as needed, then plan features that add up to playability, graphics, sounds, sprites etc etc, this will make the game you are creating look better and overall feel better. You can run such a cycle more than once, obviously, and I advise you making decisions that will support upscaling should the need arise.

share|improve this answer
add comment

Yes, but only a bit.

For game programming, especially gameplay programming, it's essential to have a good use case before writing any code. E.g. what is the player supposed to do, where is he supposed to go and how, how does he interacts with the world, etc. This can be a storyboard sketched on paper, or come out from a discussion with a peer... This is part of game design, and it'll be foolish to start coding without even a rough idea of how the game is supposed to be played.

But games have to be created iteratively. You can't create a huge spec for your game and hope it's going to be fun to play. You need regular playtesting to find out what works, and what doesn't, and keep iterating. The quickest the executable runs, the quickest the game design can be tested, the best the game gets at the end. So it's always better to start coding ASAP, from a very non-formal game design, see what gets out, and keep going.

One thing for sure, as you're coding alone, you don't need any fancy software design document or methodology, the source code is the design.

share|improve this answer
    
^ What should have been marked as the correct answer. "Yes. A bit." Exactly. –  Nick Wiggill Sep 29 '12 at 0:03
add comment

(I assume the question is made from the code-design/architecture point of view, not game-design one, though the answer at least to some degree applies to both.)

As already said, you need both, and you need to balance it. Both overdesigning and underdesigning your code flow/structure can cause problems. It is hard to say what the right balance is, but generally I find that I need to have at least a vague idea how the rest of the code will join up with what I'm programming at the moment, and think about possible issues, otherwise I tend to "code myself into dead end" - get into a situation where I realize "okay, now thanks to how I solved this problem, I created a new problem which rendered my whole previous solution (or even more, in worst cases) futile".

Generally, in my opinion, you can roughly judge whether you have the right balance by thinking about "what if" scenarios as in "what if I later (when everything is fully implemented in the similar paradigm as I'm using now) find out that part A needs to work slightly differently which will mean I have to completely rework part B that connects to it accomodate the changes?". If architectural change in one part doesn't require you to change more than one or two other parts, and the changes do not cascade (meaning that in turn you have to change also next parts connecting to the part B, and then parts connecting to them, etc.), the code is compartmentalized in a relatively good way.

But really, this is something you'll get a feel for after gaining some experience. This is partially why everyone gives the beginning gamedevs advice to first code something known and easy (Breakout/Tetris/Snake) and to do it completely, with all the menus, sounds, effects, everything to make it fully finished game - it is better to screw up smaller project, and doing it (whether in a good or bad way) will exactly help you to get a feel how far effects of various architectural decisions span.

share|improve this answer
    
For future reference: Anecdotal evidence is frowned upon on the SE sites. Just reframing your answer (avoiding words and phrases like "I find" and "my opinion is") will serve you better for getting upvotes and avoiding downvotes. This is no reflection on how valid your experience may be, just that objectivity is crucial here. –  Nick Wiggill Sep 29 '12 at 0:05
    
Thank you, but I guess you'd agree with me if I said that there are questions where there is no objective answer and all of them will be based more or less either on opinion, or experience (whether it be personal, or someone else's), and this is one of them. I was aware of that suggestion/rule, and I am and will be trying to adhere to it whenever possible. But thank you anyway for reminder. –  sh code Oct 3 '12 at 9:30
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.