(quote) PS. REMEMBER: *NEVER* End a programming session with Errors or Warnings! Make sure that it's all compiled and ready to go when you turn in for the night! (end quote)
Was that a joke?
Sleep on it, look at the code the next day - your error will be apparent to you.
Actually, I agree with that. Whenever I finish a session, I try to make sure I can at least build the game without compile-time errors.. Sleeping on runtime problems is a good idea, but most compile-time errors are easy to figure out and fix.
Oh, and in regards to Julio's post: "Isn't borland a slower compiler" Everything I've ever read has suggested that Borland's compilers have always been some of the fastest.
Well, I know this has been answered already a couple of times, but it now seems like a ''How do you program/test?'' thread so I''ll give my approach and my idea of the ideal approach.
Ideal approach: Write down all features you want. Be cynical. Determine what interfaces you will need for the simplest, smallest feature set that would be needed and would run. do spec out next class interface. write all-inclusive tests for the current system once the next class has been integrated. write all-inclusive tests for the next class you will write (to test it by itself, without the system). do write the simplest class that will work for the current feature. review source code by hand before compiling it. fix any mistakes found. run tests. until all current tests pass. integrate class into current system. test system. if system fails test, fix class, test class seperately, test class integrated, and repeat until it works. until smallest feature set version is done. Then for each subsequent feature, repeat the above.
Of course, for this to work it would require dedication and patience. I haven''t actually done this myself, but one day I probably will. This is based off the idea of XP, so if you know XP the above should look somewhat familiar.
What I actually do: Spec out a feature, dividing it into small components. Write each component, refactoring the system if necessary. Test the component within the system until it works. Until the project is done.
The biggest reason that I keep such disparity between the two is the amount of effort it takes me to make small, quick test cases. If I had a tool to automate the testing, I probably would switch to the ideal method.
The most important thing, which a lot of people have previously emphasized, is that you should always be testing. The only testing that you can even consider to defer to the end of the project is ''game balancing.'' This is because the numbers your designer writes down in the beginning need to be tweaked once they are all implemented, and unless the designer(s) are very good at guessing, they won''t know how well it actually works.
I use lots of classes, seperate different stuff into different source files, and do a lot of technical design. For instance, I''m making a game this summer that I started designing around January. Now THAT''s a long design time.
- DarkMage139 "Real game developers don't change the rules. Real game developers don't break the rules. Real game developers make the rules!" "Originality (in games) is the spice of life!"
Dark Star, definately test each module seperately and then once you integrate them test them again. ( Clear box testing ) Then if you can write up a list of test you want performed, and hand over your code to someone. They shouldn''t know how your block/module works internally though. ( Black box testing )
GXD: What the hells your problem, is it ok to learn about the speed of different compilers, and why someones code might compile longer, didnt look like anyone else had a problem with it, Or maybe your just jealous cause your on a peice of crap.
PS: My other post wasnt meant to hurt feeling GXD(hehe), just to give background on a question, so I dont think you needed to say anything.(also, that wasnt much of a quick example, more like a novel)
)
