Sign in to follow this  

70% game done than start everything over

This topic is 4756 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

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
Quote:
Original post by smr
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]


Hah, no; or at least sort of no. I mean a while back I didn't even do the rewrite, I just stopped. I have done perhaps 5 re-writes on my current project, but they weren't full re-writes. It's a multiplayer turn based strategy game, so I started with the server, got a little ways; blew it up, tried again, got farther, blew it up, tried again... got it good enough, then worked on a client, blew that up, and so on.

I've gone through that cycle basically taking 2-3 months to write about 10,000 lines of something for the first time, then blow it up. Then it takes about a week to rewrite it into about 2,000 lines. Not only is it shorter, but the 2nd attempt code is much cleaner, a little faster, far easier to deal with, and it tends to be more bug free.

Share this post


Link to post
Share on other sites
It honestly sounds like you're doing something inherently wrong in your design and programming scheme.

Maybe you need to build modules for your application, so that you can edit one piece at a time. Example:

Networking module (communications and chat)
Graphics module (UI, game display)
AI module (pathing, decision making, etc...)
Storage module (dynamic data used in game)
Combat module (It's a strategy game, let's hope there's some combat)

You can add more as you see fit, but this would be a good place to start. If you have a networking problem (using too much bandwidth, bad lag, etc...), then you can just rewrite your Networking module. If you are having a problem with the graphics, you don't need to rewrite 5000 lines of networking code or 17000 lines of AI code, just rebuild/fix your graphic module.

Think of this as it's not just you doing it all and you have to break it up for a dozen other people to work on. Some portions are going to be big enough to require 2 people to work on (graphics, AI) while others are going to be less intense and would only require 1 person (networking, storage). So you break them up to those portions and then build the code so that you can simply fix portions and any one 'person' can't tank the whole project. Sure, you're doing it all, but if it's built with modularity, then you can't tank the whole project because of a poorly built network module.

Share this post


Link to post
Share on other sites
subflood: Use an existing engine and concentrate on writing the game itself. Often enough you'll be saving yourself the work (and time!) to write and test code for resource management, storage, networking, basic AI groundwork (e.g. pathfinding), graphics and more. Furthermore you often get lots of tools, too (exporters, editors, ...). Why not spend the time on the game you want to make? ;)

-codeandroid

Share this post


Link to post
Share on other sites
Quote:
Original post by smr
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.


I understand that, but from a design standpoint this is often a good way to get things started. Make sure you know your game as well as possible before you try to code it. I actually do enjoy my game docs (maybe i'm just strange!) I even find that to be a large part of the fun behind making games personally. Obviously there are lots of different approaches to the matter, so do what works best for you, this is just how i approach the matter.

Share this post


Link to post
Share on other sites
Yeah... lots of devs that do their own projects suffer from this... it's because the motavation goes if momentum is lost. If you're not doing it for money or to live, and just for the fun of it... and it's not fun anymore... what's the point?

It's about discipline, which I guess is a state of mind more then a skill.

I'd say the best way of avoiding this is not going it alone... as long as at least one other person is still pushing it forward then even if you loose your momentum the project keeps going and you can get back into it.

The thing to keep morale up is to always set yourself small attainable goals and try and regularly get the project into a state where you can see something positive happening. Even if it's just successful unit tests, at least you can feel like you moved forward.

It's all easier said then done though.

Share this post


Link to post
Share on other sites
It's really hard to design a game 100% before-hand and then go and make that game exactly to the plan. Things change, and sometimes the only way to see if something works is to actually play it. I'd suggest making a prototype of the game with all the main features you want, but make it easily changeable (through scripting or something), so you can change things around easily.

Share this post


Link to post
Share on other sites
Quote:
Original post by smr
Telastyn: lol - I certaily hope that you haven't rewritten *the same project* a half a dozen times or so! [smile]


I've actually been faced with this for Manta-X, my 'main' project. This is the 4th rewrite (from scratch). The reasons are simple; I was initially trying to make an 'engine' that would do everything I needed for every game - mainly because I got caught up in hype and convinced myself that I had to do it. The result was three different 'engines' following three different styles of operation - but they all had one common trait, they were too restrictive. The most successful of the failures resulted in some nice effects on show, but the task of adding new features to the game became unbearable because of my spaghetti heirarchy.

I realised I was wrong and after that way I went back to basics, how I've always coded and perhaps how I will always code in the future. I kept it simple, but kept the common functions and utilities that emerged from the failures before and used them as a basic for a library, not an engine. The library of code was a refactored bunch of utility functions that had little or no linkage with each other, my game then became the glue to bind them.

So my advice here is that even if you do need to rewrite, make sure you realise why you are doing the rewrite and salvage any code that will be useful for other projects. If you liked the way you did xyz, then keep the code - bundle it into a library with a generic interface and reuse it! I also echo smr's suggestions of using as many avaliable libraries as you can. I no longer try and get dirty with window management and input, I let SDL handle all that.

I started a thread a while ago about this subject - it ended up being filled with useful tips from people - it might be worth a read.

Share this post


Link to post
Share on other sites
The secret to good rewrites is Ctrl-C, Ctrl-V. Don't rewrite the hard nitty gritty code, just refactor, or convert routines over to use some new library or whatever is motivating the change. Ignore the people who claim that planning it all out is important. A goal is important, but you don't get the rich wild joy ride of a learning experience if you try and restrict yourself to a plan that you could think up all at one time, or you will produce a just as stuffy game.

The key to fast development is this: Code for only the immediate problem at hand and nothing more. When you write code 3 or more times, factor it out into one of your libaries. Ive had great results at work and in my own projects doing things this way, I have a custom library tailored to my needs, and they are real needs not some blind searching for percieved needs, when actually its very difficult if possible at all to know such things.

If you try to code bottom up, you will only get tired of seeing nothing for results.

Share this post


Link to post
Share on other sites

This topic is 4756 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this