70% game done than start everything over
Author
What can you do before programming a game to prevent something like this? What kind of planning should be done? How should you first start?
Decide exactly what you want it to be, and stick to your guns.
And write the code so that there's room for change. It's really yucky to decide after the fact that there should be more than 3 players allowed in a strategy game, and find out not only did you hard code 3 in various places, but you use bitfields that can only contain the number 0-3, etc, etc.
And write the code so that there's room for change. It's really yucky to decide after the fact that there should be more than 3 players allowed in a strategy game, and find out not only did you hard code 3 in various places, but you use bitfields that can only contain the number 0-3, etc, etc.
The best thing to do is to first completely design the game from head to toe, beginning to end. Think about everything that you could possibly want in the game, the more detail the better. Then work it all out and make sure it flows well. Then once you have set the game up as much as possible (in idea form only) start thinking about how to solve the problems you have with good code design. Make your code as flexible as possible. Start with the main game engine and work up from their. The most important thing is to make sure you know everything you want to have your game do down to the smallest detail before you code a single line.
Well, you can decide not to rewrite it and work with what you have. I've found that in 100% of the situations that I've personally considered a rewrite is that I "just didn't like how it was coming together."
Other than that:
Use proven third party tools and libraries everywhere possible.
Bottom-up design - what are the "building blocks" of your program.
How will they fit together.
TEST! TEST! TEST!
Identify problems early.
Code slowly.
Consider at least one other way of doing it.
Other than that:
Use proven third party tools and libraries everywhere possible.
Bottom-up design - what are the "building blocks" of your program.
How will they fit together.
TEST! TEST! TEST!
Identify problems early.
Code slowly.
Consider at least one other way of doing it.
Some idea's/problems with a design only make themselves apparent when your in the middle of development, you never know when one of these problems will stand up and smack you. If you can, you should consider building a Demo Engine to test the dynamics of the design once your done working out every last detail you can. Does your basic design work well with 3 people? or could it handle more? Is the AI sufficent? Does it interact well with the level design?
It may all look good on paper, but a Demo can help punch out holes that may crop up before they become a serious problem down the line.
It may all look good on paper, but a Demo can help punch out holes that may crop up before they become a serious problem down the line.
Quote:Original post by DarkMerchant
The best thing to do is to first completely design the game from head to toe, beginning to end. Think about everything that you could possibly want in the game, the more detail the better.
I have to disagree with this. I know from 5+ years of software industry experience that this amounts to a big waste of time in the end. By all means plan. However, requirements change and so does your knowlege of the project once you get your elbows deep in code. Leave yourself room to be flexible.
And not only for those reasons, but it is also very easy to lose interest when working on a personal project if you don't reward yourself with some results. The best, most detailed game design document never entertained anybody.
You've got bigger issues if you get 70+% done and you realize that nothing that you've done is usable or salvageable.
Gain a little flexibility and assertiveness. You should have been seeing it coming for at least 20% of the development process and heading it off. You should have been more involved and busy finding solutions or alternatives when your ideas or plans weren't working out.
Gain a little flexibility and assertiveness. You should have been seeing it coming for at least 20% of the development process and heading it off. You should have been more involved and busy finding solutions or alternatives when your ideas or plans weren't working out.
I've found that after a half dozen times or so, the "remake" doesn't really remake everything since you've learned from all the previous mistakes, and made things a little more flexible. Then the remakes take far less time, and you get far better results from them. Everything is easier the 2nd time though.
That is true. However, when you've got a deadline to meet it's very difficult to sell the advantages of a rewrite to those who are expecting their software to be delivered on time.
Telastyn: lol - I certaily hope that you haven't rewritten *the same project* a half a dozen times or so! [smile]
Telastyn: lol - I certaily hope that you haven't rewritten *the same project* a half a dozen times or so! [smile]
hi. well, here is how i design a game:
1. think about a theme
2. think about the details (players, maps, all kind of npc's, effects, just imagine that you are playing the game and you'll see a lot of questions come into your mind, how do this, how do that, etc).
3. first diagram, showing the big modules of the game code. here i specify the format of the artworks (texture, sound, model, etc), the main blocks(renderer, soundplayer, etc), not thinking of coding, but how this things interact all toghether(use UML).
4. a more detailed diagram, closer to coding, about the blocks and entities inside them(functions, classes, etc). usually here you'll eliminate all the major problems that may come(again, use UML). don't get too detailed, only to have an idea
5. now get to code. you'll see that it's much easyer to code when you have the plan. no the small pb appear, like how do i implement shadows, etc, etc. when such a pb appears, just get pen and paper, write down an algorithm, very general, just to have an idea, then code it and test it.
the big pb when not planning is that there must be a lot of code until you get to test something. and when you do, you might see that hooops there x and y don't work togheter, must change that, and to do that i must change another thing and so on.
the greatest advice: while coding, take time to comment your code, so to know what you are doing. you can also write your changes or "todo" list, or even use a souce control software, because you can get lost in there :)
1. think about a theme
2. think about the details (players, maps, all kind of npc's, effects, just imagine that you are playing the game and you'll see a lot of questions come into your mind, how do this, how do that, etc).
3. first diagram, showing the big modules of the game code. here i specify the format of the artworks (texture, sound, model, etc), the main blocks(renderer, soundplayer, etc), not thinking of coding, but how this things interact all toghether(use UML).
4. a more detailed diagram, closer to coding, about the blocks and entities inside them(functions, classes, etc). usually here you'll eliminate all the major problems that may come(again, use UML). don't get too detailed, only to have an idea
5. now get to code. you'll see that it's much easyer to code when you have the plan. no the small pb appear, like how do i implement shadows, etc, etc. when such a pb appears, just get pen and paper, write down an algorithm, very general, just to have an idea, then code it and test it.
the big pb when not planning is that there must be a lot of code until you get to test something. and when you do, you might see that hooops there x and y don't work togheter, must change that, and to do that i must change another thing and so on.
the greatest advice: while coding, take time to comment your code, so to know what you are doing. you can also write your changes or "todo" list, or even use a souce control software, because you can get lost in there :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
