Just as the topic says, when you''re working on a new project, how do you typically organize your code? I''m speaking primarily about Visual Studio, where you have a solution space, and then you can have multiple projects contained inside it. Like right now in my GUI project, I have a project for a winform user interface, and then a project for a user control I''ve been working on (which I also use in the winform), and then I have another project for some C++ code I''m making use of. I can imagine justifying a seperate project for almost everything: a project for geometry classes and functions that contains vector, quaternion and matrix classes; a project for actual, rendered elements, including models, meshes and textures; etc. So how do you organize your code? Is it better to forget about the seperate project spaces and just include individual code files when and where you need them into 1 huge project space?

Generally, you want to have one project per compilation result. That is, one project for each tool, library, or executable being generated.

Do this: first identify each executable being built, and break each one out into its own project.

Next, identify components common to two or more executables, and break them out into library projects. Sometimes it''s a good idea to break out a component used by only one project into its own project--I usually only do this when that component is a standalone library developed by a third-party.

Lastly, make judicious use of project folders within the individual projects to organize files. "Source Files" and "Header Files"--like projects are set up by default--is a good start, but adapt it to the organizational needs of each project.

How appropriate. You fight like a cow.

Cool, good advice, thanks.

So since my custom user control and mc++ code are actually being compiled down to DLLs, I''m correct in having them in seperate projects. But if I were to add some C# classes that were only being used in the main project, I should just include them and organize them within a Source->CS folder within that project if needed.

Hmm, unless I bundled the C# classes into an assembly, then that''d go in it''s own project, I guess.

Within a project (I only have one never-to-be-completed game engine, really) I organize each of my "systems" (e.g. sound, audio, video) according to how low-level it is. For example, a couple classes that every other class depends on are the error logging class and memory manager. Then, the next level is the hardware interfacing, such as Direct3D, DirectInput, etc. Here''s where I''ve stopped working: the third level is somewhat more abstract, and has a class called View, which is supposed to be a wrapper between the Model data and the API-dependent Graphics class.

project files| - utilities|   | - error log|   | - memory manager| - systems|   | - graphics| - ???|   | - view