Restarting Projects
Miscellaneous Forums/General Discussion/Restarting Projects
I've just restarted a game that I worked on for 3 months strait. I felt that the code was too sloppy and that I could have done a much much better job on it. Does anyone have any good tips or ideas to keep in mind when restarting a project?
I want to do it right this time.
Don't do it. It's a vicious circle. Refactor the code you have now instead.
Otherwise in 3 months time, you'll be in the same situation.
I restarted a project too. FMC now called Mashup.
First thing is probably to organise any assets your reusing. If your starting from scratch, decide on key areas that you need in your framework. A bit of planning goes a long way, particularly if this is your second attempt. THere's bound to be a ton of things to do different.
make a plan
Don't do it. It's a vicious circle. Refactor the code you have now instead.
Have to agree to an extent there.
I find that when I code, originally my goal is to get it working. Then I go back and rewrite to compact similar things into one thing, clean up the naming conventions, and comment important items of interest.
Usually I am finished after the 3rd rewrite (as in I am happy with the results).
So long as you keep the old code on screen or printed out next to you as you re-code, you shouldn't go wrong.
This effectively will re-factor the code you already wrote but should train you into writing clean code at a first sitting. If you can see the old code and think "duh, should have done..." whilst you're sat in front of Blitz, it should turn out OK.
I break my projects up into multiple includes. For instance, my Spheres project has sound, graphics, particles, meanies and menu source files which are all separate and just get Included in spheres.bb (which then handles the main loops).
I recently scrapped the particle system and I will be rewriting it in a much better way (objects, types, 3D sprites). I will have old code and new code side by side on the monitor when I do it though.
Sloppy code is easily refactored.
Sloppy architecture should be refactored - or if it's really flawed, rewritten. Keep in mind that there's no point in starting a rewrite until you know exactly what you're going to fix. Play around with psuedocode examples of interactions between the parts of your program until you're happy with the design.
Rewrites aren't always scorned: a prominent book on software development I read (sorry, don't remember the name) suggested that you "build one to throw away" when prototyping. The idea being that you can find out where all the challenges will be before worrying about architecture.
vinylpusher: you don't want to use Blitz's Sprites for particles, or much of anything. They each get their own surface. Surface counts will kill you much faster than triangle counts.
Write Better Code Now!
It's up for debate as to whether using "Object Keys" is "Better".
I can't count how many times I've started a large project
only to discover a better way to do some fundamental
thing. In qBasic, I always started again from scratch.
Now with BlitzMax and it's lovely OOP I will take
advantage of modularity, and I'd suggest you take full
advantage of it too.
And octothorpe:
you don't want to use Blitz's Sprites for particles, or much of anything.
I was wondering about that. I knew about the multiple-surfaces thing, but what alternative does someone like me have?
I was wondering about that. I knew about the multiple-surfaces thing, but what alternative does someone like me have?
Here's a few options:
1. Email Noodle Cower and ask if you can have a download of his Lotus Particle system
2. Pop into the code archives and get one of the many single surface particle systems.
3. Buy Sswifts particle system
4. Buy Particle Candy
5. Write your own single surface particle system
And back on topic:
I've rewritten many of my projects many times. Usually I rewrite due to coming up with a better idea as I'm going. Or I learn how to do something much better that's pretty fundamental so it requires rewriting... of course this is why I have bugger all output.
Write out a description of how everything in the game works. Decide now. Don't leave any routines "unknown".
Octo: I kinda guessed there would be a better way of doing things. I'm still relatively new to B3D. I'm still at the stage where everything I learn just makes me realise how much I do not yet know.
Anyhoo, the Spheres project stays firmly 2D until I really get my [rhymes with spit] together.
YOU'LL WIND UP LIKE RED OCTOBER AND HIS SUB GAME!!!! :)
Ask god for some IQ.
Write out a description of how everything in the game works. Decide now. Don't leave any routines "unknown".
I did this with PLASMA and it never saw the light of day. If its a really big Project get help.
I'm in the habit or restarting website designs, I've been doing since I was 16 and I'm now 23. It is a bad habit, and my website still isn't online. It is a bad habit to get into and a vicious circle. You do need to break away from it and learn to leave finish projects behind. The best thing to do to boost your confidence in what you make is the only show the good projects you make, and delete the bad ideas.
It's how good programmers look good. :D
Rewrites aren't always scorned: a prominent book on software development I read (sorry, don't remember the name) suggested that you "build one to throw away" when prototyping.
While it's true that you shouldn't be affraid to make even radical changes to code, writting something to throw away seems like a particularly bad way to spend time, even if it does help you find the challening parts. If it isn't broken, don't fix it.
You probably won't do it `right` this time around either. There is no `right` way. There's only the way that you're doing it right now. In the future you will look back on your second version and see things you could've done better. Such is your growth.
AngelDaniel has a good point. Also, the only good reason to restart a project that has gone a long ways already, is if the current version is simply not cutting it. If major bugs or slow program speeds are killing your project, or if the architecture isn't able to add certain needed features, a re-write would definately be in one's best interest. Otherwise, don't worry about it. If the deficiencies in your program will never be noticed, nobody will ever know how sloppy your source code really was, and restarting a project would be a big waste of time. Get the project done and available, and then you can worry about better versions.