I’ve recently been moved across to a new project, one which I’m enjoying immensely. It has two properties which make its development particularly interesting: it is massively data-driven, and it is being developed across a multitude of platforms (five at last count). In order to accomplish this feat we are using make.
make, and the UNIX-style command line environment it typically utilises, is often forgotten or even scorned by programmers studying games-specific courses, or even some of those I’ve met in the industry itself. We’ve become used to IDEs which enable us to drag and drop files, edit them, compile, run and debug all in the same window. These have their advantages: the initial learning curve is much shallower, and they can deliver a tightly integrated experience (which is rather the point). They have their disadvantages too, however, and console-driven build management tools like make shouldn’t be discarded out of hand.
Each of the platforms we’re working with at the moment has an IDE associated with it: Microsoft platforms use Visual Studio .NET, while Sony and Nintendo both have CodeWarrior compilers set up, as well as their own alternatives. It’s quite easy to build and maintain a project / environment / solution for each individual platform, but running five concurrently is a different matter entirely. You know the story: somebody creates a new file and forgets to add it to all the different project files, or they write some code and check it in after compiling for one platform, not realising that it breaks the build on some of the other platforms… and so on. We’ve all experienced it in one way or another; most of us have been guilty of it at least once or twice. And with five different IDEs to load up and hit “compile”, who can blame us? Every check-in becomes a chore, which leads to fewer check-ins overall, which leads to difficult merges and difficult-to-track revisions.
One problem with using IDEs for cross-platform development is that they force you into a certain way of setting up your build. Sure, they try to add some flexibility with pre- and post- build steps, but if you want to do anything other than a simple compile it all gets a bit voodoo. make simply lets you run shell commands, meaning that it is not restricted to doing things in a particular order, to using a particular compiler, or even to compiling a particular language! The same makefile could compile C/C++ source files, link them into an executable, and run LaTeX over any .tex files it comes across, generating beautifully formatted documentation.
Indeed, this flexibility means make need not be limited to building the application executable. It can also process asset data ready for transferral to disc. Each platform will typically have its own texture format which is optimised for that platform specifically, and may have native formats for other media such as mesh data, videos, and audio streams. It pays to use these formats if possible, and make makes this pretty easy. It can be set up to handle all conversion, and move the new native-format files to the correct location in the directory structure.
Often this sort of asset processing is done using a custom tool written to do the job; typically a GUI tool written in C# or Python. Consider coding such a tool in C#, for example. It’s not difficult, but it would involve an unnecessary amount of work to accomplish something really quite simple. Python may be better — indeed, another build system, scons, is built upon it — but writing a full GUI tool from scratch seems like a waste of effort when what we’re trying to achieve is an automatic tool; one which requires as little user interaction as possible.
make allows us to set up dependencies to automate the conversion of asset files and move them into the correct place with ease. In addition to that, it will only perform these conversions if the source file has changed, which is a massive boon when you consider the length of time it takes to convert, say, video assets.
There are plenty of places to learn make, so I won’t go into the details of how to use it here, but for those reading who’ve never coded outside of Visual Studio, I urge you to take a look at make and see what it can do for you. Indeed, get ahold of Cygwin and familiarise yourself with it. The command line is far from dead, and as you learn how to take advantage of its many powerful features, you’ll likely find it changes the way you work.