It is worth planning before jumping in the code?

Question

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 ?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

(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.