Jump to content
  • Advertisement
Sign in to follow this  
subflood

70% game done than start everything over

This topic is 4946 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!