For me, it depends on the project. I use a different structure for Nam than I use for my internal projects, and I don't always use the same structure for all of my internal projects.
The game that I am currently working on uses a structure like this:
Code: Select all
Assets/ Sources for asset files (psd, ai, blend, etc).
Binaries/ Serves as the working directory when debugging under
Windows/Linux. On Windows/Linux, the files in this
directory will be installed in the same folder as the
executable. On Mac OS X, the files in this directory
will be copied into the bundle's Resources folder.
Assets/ Final asset files (png, xml, 3ds, etc).
Builds/ Files for building the project.
Visual Studio/ Files for building the project under Visual Studio.
.sln Visual Studio solution file.
.vcxproj Visual Studio project file.
Headers/ Third-party header files.
Libraries/ Third-party library files.
Debug/ Debug versions of third-party libraries.
Release/ Release versions of third-party libraries.
Linux/ Files for building the project under Linux.
Makefile Solution build script.
Headers/ Third-party header files.
Libraries/ Third-party library files.
Xcode/ Files for building the project under Xcode.
.xcworkspace Xcode solution file.
.xcodeproj Xcode project file.
Headers/ Third-party header files.
Libraries/ Third-party library files.
Sources/ Sources for code files (cpp, hpp, etc).
The structure under the Assets/ and Binaries/Assets/ folders is typically mirrored. If there are multiple projects in the solution (maybe an Editor, an Engine, and a Game), there will be more .vcxproj/.xcodeproj files under the Builds/ trees, as well as corresponding folders under the Sources/ tree. I also like to organize my Sources/ folder into multiple logical directories (such as Assets, Game, Interfaces, Managers, Maths, States, and Tools) to avoid the 100-file clusterfuck that most projects degenerate into.