Thinking more about build systems, I figured the gaming industry must have some pretty complex problems to solve there as well. Indeed they do, and there’s quite a bit of info about it readily found on the web. Performance is key, and no-one seems to care much about “open development”. But with microsoft XNA on the horizon, that might change.
(This article is part of a series on build tools.)
Where gaming industry engineers hang out
Noel Llopis provides “an engineering look at the game development process” on his blog, and has written a bunch about build systems. He refers to the sweng-gamedev mailing list, which is a true gem of insight into what goes on in the game engineering world. Its a place where people from actual game development houses interact directly with the microsoft developer teams.
I’m going to equate the gamedev community to the gaming industry for a bit. That’s probably not all that accurate, but it helps the thought process.
The gamedev list has build systems as a recurring theme. For example, Dec 2004 has several long threads about build systems, and then June 2005 rehashes some of those, after which Noel wrote some of the entries referenced above, after which these guys spend a lot of time on a Quest for the (More) Perfect Build Tool.
The gaming industry likes perforce and jam
The mailing list policies for the gamedev list discourage quoting from it or “publishing” from it, so I shouldn’t. I’ll sum up some things I thought were very interesting:
- Games are developed in C++ and mostly on windows, secondly on linux (I presume especially for the servers), meaning Visual Studio is pretty much the default (and only) option. Those that used CodeWarrior still long for it. Poor bastards. Us java people have eclipse, intellij, and more, with integrated support for our favorite tools (Ant, and up and coming, maven). They tend to generate visual studio project files.
- Microsoft seems to listen well to concerns and complaints and has a team in place to get their act together
- Most of them currently seem to use MS tools with various extensions, with Jam being a favorite (because of speed)
- They seem to like scons (except of course the people that don’t like python its syntax, these are C++ people after all), but it is too slow for their big builds
- They use perforce (again, main argument seems speed) a whole lot (hence Jam makes a lot of sense)
- Relatively speaking, they don’t need a whole lot of “SCM” for code at all. Most of their code is “just C++”. They need a whole lot of management of “resource management”, with resources (or “assets” or “data”) being things like textures and 3D models and all the other stuff the non-programmers make for games.
The gaming industry doesn’t do much open development (yet)
In many ways the gaming industry seems to be at about the stage where the “content management” and “middleware” industries were 10 years ago as far as “getting” open source is concerned. They use some open source tools, yet don’t contribute a whole lot back (given the size of the industry!), and don’t seem to have all that much of a clue when it comes to licensing. Sharing takes the form of posting code and/or patches to the perforce public depot.
With all the stories of big losses made on games and game studies going bankrupt, I’m guessing they’ll be playing catch-up much faster — they have to. There are quite a few open source game engines already. I wonder if other parts of their workflow systems are going to become open source soon(ish) too.
I think there is not a lot of open development in gaming yet is because the gaming industry hasn’t been feeling the commoditization of software very much just yet. Game publishers do a lot more than just write software, and have business models that go way beyond being about “just” software.
This probably is one reason why efforts to collaborate together on things like an improved Jam don’t seem to work out — the decision makers don’t see the incentive clearly enough.
It’s either going to be open or “completely microsoft”
Doing a good analysis of the requirements for build systems that the big gaming studios have and then pitching an open source solution to them doesn’t sound undoable at all. Apparently sony seems to like the open standards thing here (how ironic given all their DRM slip-ups), and it seems they’ll be churning out some nice tools for the PS3, but they’re doing a stellarly bad job of talking about it.
Microsoft has a strong XNA team who are building on top of the horrible product (yes yes, in many ways its rather cool too) that is Visual Studio 2005. With all these developers already working on windows, and all of them using C++ as the main environment, it seems visual studio is firmly posed to remain the standard baseline environment for these people, and this puts XNA in a rather strong position. Gotta love monolopies!
Paraphrased from this presentation on XNA (its a good presentation, bit slow though):
Why should each studio have to uniquely solve the same sets of problems faced across the industry? (…) Without tools vendors devoted to support the unique needs of the gaming industry, studios are left with no other choice but to continue to invest into building and maintaining these technologies.
And then, of course, microsoft is posed as the ideal partner and the only real tool vendor. Yeah right. Uhm, hello, gaming studios? Don’t listen to this crap please. There is this other choice, called Commons-based peer production, or more briefly, open source, which is the direction your tool and build teams have been pursuing for many many years, with arguably stellar success — you’ve been shipping some very complex pieces of software on insane schedules for years now. How much of your pipeline do you think is built around visual studio today? Not much. Why do you think that is?
Whose judgement do you trust best? That of your own experts, or that of the people who want to go and store all your gargantuan asset files in a rather crappy relational database?
LSD::RELOAD 