It takes a boatload of classes and structures to assemble a decent base game engine. Then you have to contend with all the classes and structs that make up the game you are laying on top of the engine. If you put it all down for a while and come back to it some time later, it might be hard to remember what everything does. How do you organize all of it? Is there anything in Visual Studio that helps present them in an easier fashion, other than creating folders in the structure listing? Do you use naming conventions that assist with the organization? Or do you complement it with an external document so you can come back to it later and say, "Oh, that''s what those classes are for"? How about a visual class diagramming tool so you can tell how classes are laid out from an inheritance and access standpoint, like you see in the MFC documentation? What do all of you use to help keep those gigantic projects organized, showing a clear separation between the base engine classes and the game specific classes? Or the classes that are involved in inheritance with each other? I''m currently using version 6.0. Does 7.0 offer something in this area? Thanks for any insight. This is one area of C++ programming I never really developed for myself. Any links to tools, articles or books along these lines would be appreciated! I also just wanted to find out what works well for you.

I simply give the classes an obvious name. CCamera is the camera, Vector3D is a 3D vector, CTerrain is the top Terrain class and CTerrainLeaf is a leaf in the terrain. Don''t become too cryptic when it comes to class names. You won''t be typing these names all the time anyway.
I also tend to comment the *.h files a lot to explain the member functions and variables, although usually the cpp files are commented with a comment block preceding the function, but this way actually saves me a lot of scrolling, since the cpp files are often quite big (if you have complex algorithms).

Having multiple header files also helps. For example I have all of my terrain classes in the terrain.h file (CTerrain, CTerrainNode, CTerrainLeaf) and all functions that are part of the terrainclasses in Terrain.cpp.
This also helps when I want to use my class in another game/project.

At school we also learned to make class diagrams, on PAPER (yes, the stuff they used in the dark ages and so). When you design your game you usually have an idea of the structure in the back of your mind, so you write it down and prolly make a treeview of it. Keep it on paper because it''s easier to modify and easier to have as a reference.

Those are my two cents, although I still have a lot to learn in this particular area too (thanks for the submapping in the project idea BTW )

Hmm... so I could prefix all the sound, graphics and menu classes with Snd, Grp and Mnu, as an example. That might help.

I''ll experiment with splitting the code into separate LIBs or DLLS, too.

And I''ll look up the software suggestions. Thanks!

I''ve found prefixing names with letters describing the subsystem works well for globals. For classes, I just give things an obvious name, and sometimes stick to general naming conventions.

I also use the File View in VC++/VS.NET more than the Class View. Organizing the files within folders seems to help a lot. In VC++ at least, the folder structure disappears in the Class View sometimes, which is why I don''t normally use it.