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.

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.

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.

Start from the bottom up.

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

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.

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.

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.