#10181 - nazuraku - Fri Aug 29, 2003 2:12 am
This is a simple question I am sure I could find answers for on the web, but I would like to see what people here are doing. In C, I know C++ would be much clearner, how do you go about organizing your code for large projects? Lets say if you were making an adventure game or an RPG... it certainly seems that code could quickly become unmanageable if not properly maintained. Is there any large scale projects available that anyone feels is well organized? If so could someone please point me in the right direction. One thing I dont want to start is bad coding habits...
Let me know if anything pops into your mind.
Naz
#10183 - Cyberman - Fri Aug 29, 2003 4:02 am
Well all projects should begin with pencil and paper.
It's not a joke, before you write one line of code you need to write down what you plan on doing and what your goals are.
For an RPG you should get everything laid out in terms of events conversations etc.
an RPG is really an interactive story. So think in those terms. Story line must be complete for example. The story is what DRIVES what you do.
Then after you have a complete story you go to doing story boads (like a comic book).
Basically you need to be very organized and disciplined.. have you noticed anything yet? I haven't mentioned one THING ABOUT CODE YET. That's important. Coding is very expensive and difficult. You should never begin writting code for something until you have an idea what you need to achieve. So consider that.
This is really something that should be in coding not in C/C++ forum really.
Cyb
#10192 - Sweex - Fri Aug 29, 2003 9:33 am
A couple of tips for organizing your source files. It pretty much goes for C and C++...
- Have every block of functionality (class) in a seperate .c and .h file.
- Prefix all your functions and structs. Usually with a 3 letter code indicating what it is used for. Best is to name your libraries and gamecode, ie. NGL (nazuraku Game Library). So if you have an initialise function of some kind, you should call it NglInitialise instead of Initialise
- Seperate code into smaller packages. Create a project for your video routines, sound routines, game logic, etc.
Hope this helps...
_________________
If everything fails, read the manual: If even that fails, post on forum!
#10209 - nazuraku - Fri Aug 29, 2003 6:41 pm
Yah thats a start, over all I am relatively new to game design in general. Cyberman, I appreciate your input as far as general game design is concerned. That is certainly a big portion of development. Sweex is right on with what I was trying to get at, Is there some type of standards that exisit or somewhere where I could find some? Or better yet well laid out open source projects?
#10215 - Cyberman - Fri Aug 29, 2003 8:31 pm
| nazuraku wrote: |
| Yah thats a start, over all I am relatively new to game design in general. Cyberman, I appreciate your input as far as general game design is concerned. That is certainly a big portion of development. Sweex is right on with what I was trying to get at, Is there some type of standards that exisit or somewhere where I could find some? Or better yet well laid out open source projects? |
Ahh you should look at the GNU coding standards then.
These are QUITE helpful standards for maintaining code, standards for developing code. Some of the information is not applicable but most is. It will improve your project readability and maintainability (IE bug fixing).
Ciao!
Cyb
#10219 - sajiimori - Sat Aug 30, 2003 12:04 am
I do things pretty differently depending on whether I'm using C or C++.
In C++, I tend to do things the "right" way, seperating each class into a .cpp and .h file. To be honest, I find header management really annoying, so I've pretty much abandoned C++ in favor of C# in cases where speed is not so crucial. When speed *is* crucial (on gba for instance), I just use C.
In C, I actually do a lot of things that are considered bad habits, such as using "main()" instead of "int main(int argc, char** argv)". Simple, readable, and terse code are very high priorities, and extra punctuation and verbose declarations are avoided when possible.
I keep one common.h file that is included in all modules. It includes all structs, constants, enums, macros, and global data declarations (always declared extern). I don't add anything here unless I absolutely have to.
Most global functions are *not* declared here, as that becomes a maintenence issue. I occasionally declare a function if it has a return type other than int, or if I need to get it's address.
In each module, everything is declared "static" unless it absolutely has to be accessed from a different module.
Global function and data names generally have prefixes. (In very large projects, generally = always.)
My general philosophy is to have as little text as possible that doesn't directly contribute to what I want to do. As such, "void foo(void)" is too verbose when foo's use does not involve arguments or return values. The only relevant bit of information about foo is that it's a function: "foo()".
And no, I've never had a hard-to-find bug related to passing the wrong thing to a function. I attribute this fact to my habit of testing my code every time I write a few lines.
Lastly, if a project gets too difficult to maintain (usually when common.h passes 10k or there are more than 30 modules), I try to find a large set of related modules and seperate them into a seperately compiled library that exports a minimal interface.
YMMV. If you're working alone, do what is most comfortable for you.