-1
\$\begingroup\$

I think the title really says it all.

Should I start programming after designing the basic outline of the game or should I have the whole thing written out?

If I write the whole thing out isn't that waterfall development and isn't that bad?

What principles should I follow or steps should I take in order to keep my code up to date with the design and vice versa?

\$\endgroup\$
  • 1
    \$\begingroup\$ It seems like this question is ultimately opinion based. Can there be an objectively best answer? \$\endgroup\$ – ssb Sep 2 '13 at 6:31
  • 3
    \$\begingroup\$ The answers for this question will be opinion based, since it's impossible to give one right answer for all situations. The general answer would be 'when you feel it's right time'. \$\endgroup\$ – Petr Abdulin Sep 2 '13 at 6:32
  • \$\begingroup\$ It's hard to tell if a game concept is fun or not when you just read the design document. You need to actually play it to know if it works out or not. For that reason game development is quite suitable for an agile approach. Make it playable as fast as possible, test how fun it is to play, and adjust the development goals accordingly. \$\endgroup\$ – Philipp Sep 2 '13 at 7:40
2
\$\begingroup\$

Depends on development methodology the fast answer is "When you have enough information to begin writing code".

My thinking on what "enough" should be is something like ...

  1. I wont be rewriting large portions later.
  2. What i'm writing is a small enough chunk that i can handle it as a "task".

I see so many people taking on tasks like "build the terrain" ... that's such a wide scoped task that it could take weeks and you have no idea of weather you are wasting your time or not. I would go with smaller tasks like ...

  1. investigate potential options for terrain generation.
  2. implement a proof of concept.
  3. design the solution.
  4. Begin development on terrain component (basic form only).
  5. Add trees, buildings ect to terrain.

This works for me because I take an agile approach to my design, I pick up a small chunk of my project at a time and build it, then move on to the next.

Waterfall based development means you must have the full details of your project from start to finish before you begin. My experience is that this is falling out of favour in all but the most elongated dev processes because of the time taken to plan such a project. Typically waterfall based dev process involves just as pmuch planning time up front as the dev time that follows.

Simply put ... Waterfall: Planning time - 1 year Dev time - 1 year

Scrum / agile: Planning time - 1 week dev time - 2 weeks

You also have to factor in testing time and other process based time allocations (proof of concepts, meetings, design time, delays).

My advice (best i can give) ... Build a plan for a unit of work, then build to that plan. If the plan needs to change you should stop all development work and consider the impact of the change, update your plan then begin again.

Once the unit of work is developed ensure it gets thoroughly tested then repeat.

The agile approach (it works well for me).

| improve this answer | |
\$\endgroup\$
0
\$\begingroup\$

It's a judgement call.

Advantages of starting coding early:

  • You get stuff done on the coding front
  • You create energy, enthusiasm and momentum in your team
  • You can prototype to help you learn and solve technical / implementation issues
  • Game design can benefit from frequent iteration. You need to build something to get that iterative loop going.

Advantages of waiting (i.e. doing other stuff first):

  • You reduce the risk of producing a really badly designed monstrosity that ultimately needs to be thrown away.
  • You might need to take important decisions (which game engine to use? is it multiplayer or not?) that fundamentally change how you build the game. No point starting until you've made these decisions.
  • You reduce the risk of wasting time working on something that ultimately isn't needed

Overall, my recommendation would be to start coding pretty early, but only for things that are properly designed (which includes understanding the design, especially if you are part of a big team). If you're coding blindly on aspects of the game that haven't yet been properly designed, you will definitely get into trouble.

| improve this answer | |
\$\endgroup\$
0
\$\begingroup\$

I'd say as soon as possible, simply because that is when you discover if you're cut out to program a game all by yourself (or in a group or whatever).

I've known so many people that were to create a game, that made super convoluted design documents and "concept art" (for characters that were supposed to be rendered in skin shaders, meaning that they had be rigged and modeled, something they thought was as easy as drawing an picture). None of them ever got past coding a single line of code.

Thinking about what cool game you want to do is easy, implementing it is hard, and that is when you discover if you're cut out of it.

I've made several games, all of them are shit, but at least I've implemented an idea I had from the start, making my own game art and stuff, and I had really fun doing it. That's more than can be said about my douchebag friends that were to make revolutionizing games that were supposed to turn the whole game community upside down. I don't want to sound like a downer, but don't underestimate how much time it takes to make a game, and it's not the design part that takes time.

| improve this answer | |
\$\endgroup\$

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