I've been looking through the SCons build script for Doom3 and researching different approaches to build processes used by professional game developers/studios (C/C++) and I've come across a few questions:

  1. When creating a build script (scons/make file etc.) is it used every build when coding within an IDE like say Visual Studio? In other words do you tend to just use the tools in Visual Studio (Project files etc.) when you want to test a small code change? Or do you step outside VS and run the scripts to get the project to a point that it can be run?
  2. An extension of question 1, if you use VS entirely for these kinds of builds, how far do you take it? i.e. do you have it copy the game into a folder with all the assets or run any kind of install scripts?
  3. If your feeling generous could anybody give me a quick overview of the kind of things you're including in your build steps? Asset creation/install scripts/folder structure creation etc.

Many thanks all.

  • 1
    \$\begingroup\$ If you can snag a copy, "Gaming Code Complete" has a really well written section on on this, written by a guy with tons of game industry experience. He's very informative and goes into a lot of detail. Check it out! \$\endgroup\$ Aug 9, 2012 at 13:25

2 Answers 2


I'll try to answer to the best of my knowledge, even if I'm far from a build process expert.

  1. Typically, when changing code:

    • Most of the time, just running the compiler + linker is enough
    • When adding/removing/renaming source files, it's necessary to close the IDE and run CMake, Premake or similar to recreate your projects/makefile/etc. (if such a tool is in use)
    • And that's only when doing a code change that isn't compatible with current data that the data needs to be binarized again
  2. If you're talking about a whole build process, including binarizing data, creating installation script, etc., then no that's usually not something that's done from an IDE. It's usually managed by some continuous integration software, or just a bunch of custom scripts, run automatically overnight for big projects.

  3. I won't go into folder structure, as there is no standard for that, just follow your instinct on what you feel is best. Just make sure you have a clear distinction between source code/assets and generated stuff, this helps keeping version control clean. What a build process does usually is as follows:

    • Generate the projects for all platforms & configurations
    • Build the code for each project
    • Binarize all data
    • Package: create disc images, installation scripts...
    • Run automated tests
    • In case of failure, report errors
    • In case of success, archive the build somewhere
  • \$\begingroup\$ SCons actually performs the building. It directly invokes external tools: SVC, compiler, linker, whathaveyou; to produce the final product. Maybe you were thinking of CMake and Premake, which are build systems that generate projects or makefiles or whatnot? \$\endgroup\$ Aug 10, 2012 at 11:42
  • \$\begingroup\$ Yeah I thought SCons was similar to those. Looks like it's doing much more! Thus the disclaimer, I'm not a build process expert ;) \$\endgroup\$ Aug 10, 2012 at 14:48
  • \$\begingroup\$ Answer edited, should be a bit more correct now... \$\endgroup\$ Aug 10, 2012 at 15:11
  • \$\begingroup\$ Upvoted as appropriate. :) \$\endgroup\$ Aug 10, 2012 at 19:29

There could be multiple things being discussed here. Generally you have one and precisely one build method, where this is how you produce the executable. If you had more than one, then they risk getting out of sync, and it's another variable you have to consider when troubleshooting. You don't want your IDE's Build command using different settings to the one that a proper build does (except for Debug/Release distinctions, etc.)

But often what we call a build script includes building assets, deploying to test servers, etc etc, and you obviously wouldn't do that on your own machine every time.

With scons, makefiles, and similar, you can set up different targets so that one tool can perform both roles. You'd probably set up Visual Studio to run the basic executable-only build, and if you needed a full build exe/process assets/package/test/deploy system, you might do that outside the IDE.

Generally I wouldn't go too far with putting the whole process in Visual Studio - it's likely to be something that non-programmers are going to want to be able to do, providing there is an up-to-date executable available. It's also commonly automated, for example to have a system that automatically continually performs full builds to see if anything has broken.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .