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.

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

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.

Start from the bottom up.

Write out small things, classes etc that are completely flexible. Then build classes that use those classes, etc.

i think you should have a shell of the game, a very basic structure, eg main classes and relationships, then build lots of flexible classes for each of the main sub systems

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.