To add to that:
-Don't leap straight from design to code. Your design document is great for making sure you know what has to be done, what'll be in the game, and all that, but it does nothing except give you a list of things wot need coding. The next step is program logic and pseudocode. If you go from "These are the things that need to be coded", to "To do this, I need to program these tasks", to "The code to do this task is...", you'll have a better grasp of what you're doing, why you're doing it, and what its place in the bigger picture is.
-Don't feel you have to finish everything in order. If you feel like doing the logic for the enemy movement function one day, and the pseudocode for the menu screen the next, do that. Anything that helps you keep moving forward and avoid burnout is good- just keep track of what you've done (and, more importantly, what still needs doing!)
-To add to Sirrocco's third point, start small, and build up. With my 4X project, I'm starting by creating a ship designer... well, part of one. The first version is just the interface, and the most basic functions. The end of the project will be the full design spec for the game's ship designer. I figure that, by the time I reach that point, I'll have learned a good bit more about coding, data storage, and, more crucially, what all that part of my game actually has be. That'll give me a better idea what the full spec for other, related bits actually is. It might get used, in whole or in part, but the important part is what I learn writing the code.
My Unitarian Jihad Name is: Brother Atom Bomb of Courteous Debate. Get yours.
I've been writing a bit.
-Don't leap straight from design to code. Your design document is great for making sure you know what has to be done, what'll be in the game, and all that, but it does nothing except give you a list of things wot need coding. The next step is program logic and pseudocode. If you go from "These are the things that need to be coded", to "To do this, I need to program these tasks", to "The code to do this task is...", you'll have a better grasp of what you're doing, why you're doing it, and what its place in the bigger picture is.
-Don't feel you have to finish everything in order. If you feel like doing the logic for the enemy movement function one day, and the pseudocode for the menu screen the next, do that. Anything that helps you keep moving forward and avoid burnout is good- just keep track of what you've done (and, more importantly, what still needs doing!)
-To add to Sirrocco's third point, start small, and build up. With my 4X project, I'm starting by creating a ship designer... well, part of one. The first version is just the interface, and the most basic functions. The end of the project will be the full design spec for the game's ship designer. I figure that, by the time I reach that point, I'll have learned a good bit more about coding, data storage, and, more crucially, what all that part of my game actually has be. That'll give me a better idea what the full spec for other, related bits actually is. It might get used, in whole or in part, but the important part is what I learn writing the code.
My Unitarian Jihad Name is: Brother Atom Bomb of Courteous Debate. Get yours.
I've been writing a bit.