Source Control is not a delivery mechanism

How do you get your tools out to the team?

If your preferred method is to shout over to the artists: "New tools are ready, sync to Perforce now!", then you're a bad dog, no biscuit for you.

This is exactly what we used to do, but no longer. Here's why:

50% of our support questions went like this.

ARTIST: "Help! My tools are broken"

    "Have you tried syncing to the latest" :ME

ARTIST: No.

    "Let's try that first" :ME

[Sync, try again]

    "There you go, all fixed" :ME

ARTIST: "You're the greatest."

The other 50% went something like this.

ARTIST: "Help! My tools are broken"

    "Have you tried syncing to the latest" :ME

ARTIST: "No"

    "Let's try that first" :ME

[Sync, try again]

    "Hmmm, yeah, er, that's bust, I'll go and fix that" :ME

ARTIST: "I hate you!"

When we switched to giving out installers we literally cut our support queries in half. Not only that but it also allowed us to properly version our releases, which makes tracking bugs much easier too.

Other things

Once you start with the installer, other advantages become clear. The process of building an installer is a natural fit for continuous integration, every evening you can build a new installer which can be given out to the team in the morning. This can lead to problems though, because if you are building an installer every night then it is by definition work in progress code. WIP code can have instabilities and bugs, and that can mean your team losing faith in the tools, and once that happens it takes a long time to earn it back.

So ideally, you do a nightly build of your latest code. A small section of the team, perhaps the technical artists or one of the more friendly designers can take the installer and upgrade every morning, after few hours or days of testing the installer can be approved and then you can offer it out to the rest of the team.

To force or not

In my opinion the jury's still out on whether to force an update out or whether to allow users the options. I guess ideally you'd support both, but in general I think that unless you have a very robust testing framework or team, forcing updates onto people will only generate bad blood when you break someones tools hours before their art review or something.

To be honest it seems pretty silly saying all this, because it is so obvious and once you've made the switch you can't understand why anyone wouldn't set their tools up to be installed atomically straight away. However, I remember the old days when Perforce seemed like the obvious way to distribute the tools, but no more.

Notes

• Deliver your tools atomically
• An installer is a good way to do this
• Automate installer creation overnight for a daily build
• Make sure you test the installer before distribution

Some installer software you could try:

• InnoSetup - we've used this for a while now, it's pretty good. Nice and straightforward to get a typical installer set up. Main downside is any scripting you want to do has to be in Pascal!
• Wix Toolset - we're looking into using this in the future. Integrates nicely with Visual Studio, can be scripted in C#
• NSIS - the other one of the big three. I've no experience with this, but it's by the makers of WinAmp.

I came across this interesting piece from Paul Bakaus called Why I would hire game developers for my startup and I thought I'd try my hand at the opposite view point to stop all those web developers feeling put out.

Rapid Iteration

With multiple releases a week ( or even a day ) web developers have really been able to run with the deploy, measure, iterate, mind set. Put that in context with game development teams who create monolithic C++ monsters that require days to change even the most basic features, for example front-end menus that require a full-time C++ programmer to implement any changes that the designers require.

High level languages

To the metal C/C++ coding is going to be around for along to time to come yet in the games industry and rightly so. However, look to the web developers and their complete frameworks built in high level languages like Ruby and Python. Why is the gameplay written in a language that excels at talking talking the hardware. Why can't the designers have their own framework in Lua, or Python or Ruby, which allows them to create complete levels without any intervention from a coder?

Openness

Search Google for a blog on coding techniques for web development and then try the same with game development techniques. My quick google search reckons the numbers are about half, but to be honest, I doubt the relevance of many of the game development results. Where are the blogs from senior developers in big name game devs? I'd love to see coding techniques from Uncharted or the way the cover system was implemented by the Gears of War team. I'm not sure whether this is shyness on the part of the developers or it's the publishers keeping them locked up. Either way, I think it is a shame and only holds back the industry.

Disclaimer

I know that high level languages are making in-roads into game engines, but there use is usually very limited. And I know that a lot of teams are trying very hard to get rapid iteration working with in their team, but this is the exception rather than the norm.

So there you go web devs, it's not all bad, I think coders in the games industry could learn a lot from you guys.