Project Structure for Your Maps
When the time comes to use version control and share your project with others, it becomes important to have a well defined project structure. A good structure will ensure that everything is where it is supposed to be and all packaged nicely. Here, I'll be focusing on the structure that Valve uses internally. Matching their project structure will have the benefit of making things as straight-forward as can be when the time comes to exchange files with them.
Valve's structure
For each project/map, you should have a separate folder inside your mapsrc folder. To follow Valve's folder structure, you should lay out each project like this:
Code:
yourmap/
├ content/
│ └ maps/
│ └ yourmap.vmf
├ tf/
│ ├ maps/
│ │ └ yourmap.bsp
│ ├ materials/
│ ├ models/
│ └ ...Essentially you want your work files inside content/maps/. Next you want all the content required for your level in the usual tf/directory/ structure. Note the tf/maps/ folder, having your map in there is probably not useful in your workflow so it is definitely optional for development but Valve will require you to have it in there if you end up shipping.
Now with manifests!
If you're using manifests and/or instances, your content folder will be slightly different. Content/maps/ should be structured as follows:
Code:
yourmap/
├ content/
│ └ maps/
│ ├ yourmap/
│ │ ├ submap1.vmf
│ │ ├ submap2.vmf
│ │ ├ instance1.vmf
│ │ └ ...
│ ├ yourmap.vmm
│ └ yourmap.vmf
├ tf/
├ Extras......Now what are extra files that you might want to have around? Well there's a few useful ones to have at the root of your project. These are suggestions:
Readme.txt - Have a readme in there! explain what your project is about, how it is structured, who are its authors etc.
paklist.txt - This is the text file that is meant to be used with bspzip.exe, it is essentially the list of assets to be added to the map which is nice to have in there (If you use CompilePal, this file is generated for you).
contributors.csv - Why not have a spreadsheet that lists the authors of each custom assets? This will be useful in keeping track of where assets are from. Csv is my go to format for universal spreadsheet files.
Version control configuration files - Of course you will want these files at the root of your project (for example, .gitignore if you are using git).
license.txt - Is your project open source? If so you might want to include a software license to explain what people can and can't do with your project.
This should give you a good idea of how to structure your project. Feel free to tweak these to match your workflow and needs, maybe have your source files for models in there as well, have fun. You can use one of my projects, Cp Vanguard, as a reference if needed.
