Preamble:

I have attempted to make 2 little indie games and each of them have failed for one reason, planning. For both of the projects I started off only planning to have a few parts to the game. As I started to code those parts I would realized that each of these parts needed a lot more code and classes and such than I originally thought. The problem is I would have already coded the majority of the game before I realized this. Thus leaving me with two options, 1) Rewriting the whole game, and throwing out countless hours of time. 2) Giving up . After thinking about where I went wrong it would always come down to the fact that when I started writing the game I didn't fully understand what I needed and thus didn't design it properly. I figure that this might happen a lot in many games(Realizing that a major change needs to be done) and I imagine that they don't all restart or quit. Which leads me to the conclusion that my planning might not be sufficient but the main structure of my code might be the problem. When I looked over my first game I found that a lot of my code was very specific and could not be easily rewritten without affecting other parts.

The question:

1) How do you go about properly planning a game and allowing major changes to be made without a re-write?

2)To avoid problems with having to rewrite everything should I try and write everything as a module that can be used in a main game loop?

If anyone has any good ways of organizing a game that you could point me to that would be awesome(Currently I am using the Model, View, Screen system)

This is a problem I am kind of facing as well =/. I've had to resign to starting over due to not knowing an efficient way to continue my code and seeing that I was headed towards coding myself into a corner.

Any insight on dealing with this or avoiding this in the future would be greatly appreciated.

1) How do you go about properly planning a game and allowing major changes to be made without a re-write?

Paper and pencil is really the way to go. Sketching things out is a great way to work out ideas. Use of formal tools, like UML, is entirely optional -- if you think that they help, go for it!

2)To avoid problems with having to rewrite everything should I try and write everything as a module that can be used in a main game loop?

Do it, if it makes sense. But avoid over-generalization -- YAGNE!

Happy hacking!

Code wise, not sure. As for gameplay, keep wrting each idea on a book (books for me), when you've reached a point where you think it's alright, read through the whole thing and make sure it flows naturally, removing and adding ideas till you feel it's good. It could help you guess what the code will be like.

How do you go about properly planning a game and allowing major changes to be made without a re-write?

Keep making games, keeping making mistakes, and learn from them.

To avoid problems with having to rewrite everything should I try and write everything as a module that can be used in a main game loop?

If you have a good idea about how to do it. Getting a good handle on how to properly do that tends to be the product of learning from past mistakes.

If anyone has any good ways of organizing a game that you could point me to that would be awesome

General Game/Engine Structure

You are basically asking, “How do I learn from experience without going through the ‘experience‘ part?”.

No matter what strategy you use, at the end of the day you will still need to be sitting down programming, and you will still be making mistakes. Throwing away code, writing tightly coupled code, and wasting hours of coding time is how we all start. It is a natural part of the learning process.

And I wouldn’t advise using any strategy that you yourself did not create specifically for yourself. When you create your own strategy it is based off what works best for you.

If someone told me to draw it out and I followed that advice, it naturally goes against my grain and would only slow me down. I have a mental image that has no naturalistic translation to an actual image; an image I see on paper does not translate into anything useful related to code for me, so trying to work that way is like trying to sew a shape into cloth just by looking at numbers representing angles and distances.

You can create any strategy you want. The point is that it won’t naturally flow for you unless it comes from you.

L. Spiro

L. Spiro has pretty much nailed it in the head. I would like to add a slight bit of advice though that I've read a long time ago and I can't remember where it's from: Always try to refactor your code before throwing it away. I find this is a better approach when it comes to learning because by fixing the code that you know is broken, it forces you to think about why it's broken and what the correct solution is. When you just start over and toss the other code aside, you're just making another shot in the dark. That's really just the way your memory works too. If you don't think about something extensively, you decrease your chances of remembering it.

Initially, this process will take a mighty long time, but the more you do it, the better code you'll write in the first place. As an example, I program my UI's by hand, and, at first, the UI code alone would give me so much trouble that I would rather do just about anything else than have to modify it, but once I started refactoring it, I find much better techniques for separating all the parts of it. Now I actually got myself a little library that handles building intricate menus :D

Preamble:

I have attempted to make 2 little indie games and each of them have failed for one reason, planning. For both of the projects I started off only planning to have a few parts to the game. As I started to code those parts I would realized that each of these parts needed a lot more code and classes and such than I originally thought. The problem is I would have already coded the majority of the game before I realized this. Thus leaving me with two options, 1) Rewriting the whole game, and throwing out countless hours of time. 2) Giving up . After thinking about where I went wrong it would always come down to the fact that when I started writing the game I didn't fully understand what I needed and thus didn't design it properly. I figure that this might happen a lot in many games(Realizing that a major change needs to be done) and I imagine that they don't all restart or quit. Which leads me to the conclusion that my planning might not be sufficient but the main structure of my code might be the problem. When I looked over my first game I found that a lot of my code was very specific and could not be easily rewritten without affecting other parts.

The question:

1) How do you go about properly planning a game and allowing major changes to be made without a re-write?

2)To avoid problems with having to rewrite everything should I try and write everything as a module that can be used in a main game loop?

If anyone has any good ways of organizing a game that you could point me to that would be awesome(Currently I am using the Model, View, Screen system)

Start using a source code revision tool as it allows you to code a lot more fearlessly of losing old work, make sure you checking in often. If something doesn't pan out just revert to the last working version and start afresh, if something pans out to work check it in so you have a backup.

You are basically asking, “How do I learn from experience without going through the ‘experience‘ part?”.

I wouldn't exactly say that. I understand how valuable experience is and learning from my mistakes. Getting experience helped me learn another fieldset(Web dev. php, js, ruby, ect). Like writing an essay, there are certain structures that are generally accepted as at least a good outline on how to do it,

Preamble:

I have attempted to make 2 little indie games and each of them have failed for one reason, planning. For both of the projects I started off only planning to have a few parts to the game. As I started to code those parts I would realized that each of these parts needed a lot more code and classes and such than I originally thought. The problem is I would have already coded the majority of the game before I realized this. Thus leaving me with two options, 1) Rewriting the whole game, and throwing out countless hours of time. 2) Giving up . After thinking about where I went wrong it would always come down to the fact that when I started writing the game I didn't fully understand what I needed and thus didn't design it properly. I figure that this might happen a lot in many games(Realizing that a major change needs to be done) and I imagine that they don't all restart or quit. Which leads me to the conclusion that my planning might not be sufficient but the main structure of my code might be the problem. When I looked over my first game I found that a lot of my code was very specific and could not be easily rewritten without affecting other parts.

The question:

1) How do you go about properly planning a game and allowing major changes to be made without a re-write?

2)To avoid problems with having to rewrite everything should I try and write everything as a module that can be used in a main game loop?

If anyone has any good ways of organizing a game that you could point me to that would be awesome(Currently I am using the Model, View, Screen system)

Start using a source code revision tool as it allows you to code a lot more fearlessly of losing old work, make sure you checking in often. If something doesn't pan out just revert to the last working version and start afresh, if something pans out to work check it in so you have a backup.

I am pushing to a private git repo every night after I finish. Is this sufficient for version control?

I am pushing to a private git repo every night after I finish. Is this sufficient for version control?

You really want to be making commits of each feature and/or refactor, so that you can step through the history change-by-change to analyse when bugs were introduced.