When in the development process should the programming start and what should be programmed first? [closed]

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

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.

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.