As I see it, improving developer efficiency is the most important thing you can do to increase your game’s chance of being a success. Game development is a very iterative process, where each iteration results in a game that is better than it was in the previous iteration. Every second that you can pull out of the iteration time of each of the members of your team is going to buy you many additional iteration cycles over the course of the project and have a big impact.
Here are ten things you can do to improve productivity for your developers:
- Never, ever require anybody to wait for a build to see their changes working in-game – I can scarcely believe it when I hear it, but over and over I hear tales of artists and mission designers waiting for a build to test their new art or missions in the game. Even if your builds happen every day, this is still ridiculous. Iteration times should be measured in seconds or minutes, not hours or days.
- Drive as much of your game as you possibly can from data files – Data-driven development has plenty of its own virtues (not the least of which is that it helps a lot with number 1.) The biggest thing it does is remove the need to talk to a programmer when you need to make a change.
- Allow everyone in the company to run their own copy of the server cluster – This will vary in difficulty based on your server architecture, but it’s crucial. If there are any data files loaded by the server, (and your game is data-driven so of course there are) many people will need to be able to restart a cluster when they make a change. And as part of making it easy to bring up a new cluster for Random Artist A, you’ve also made the job easier for Random Operations Guy K.
- Use text files for your data files – Text files can be read by a human (or at least a human of the “programmer” sub-species.) They can also go into source control tools and show diffs. Depending on the format, they can probably also be merged in source control tools. Most game data (textures, meshes, and animations being huge exceptions) is small enough to begin with that the extra bloat from a text-based file format isn’t that big a deal. If you’re worried about the performance of text files, feel free to have a binary version that you compile from the text files as part of the build process.
- Run builds often – I was on the Middle-Earth project at Sierra for 9 months (up until it was cancelled) and I think we ran exactly two builds. On Rails Across America we ran builds once a week. On PotBS we run them (at least) once a day. If builds are running constantly, and build breakers are hassled appropriately, you can never get very far from having a playable game. At least not as long as you also do #6. When your build finishes, it should notify several people automatically and let them either fix it (if it failed) or start the manual part #6.
- Run Build Verification Tests daily – BVTs are intended to tell you if a given build is worth the electrons it’s written on. If you run them every day you will have a much greater chance to detect integration problems and build breakers as close to the source as possible and get them fixed just as quickly. There is likely to be some kind of human component to these tests, but much of them can be automated. We automatically test to make sure that every environment can be loaded, and every ship type can be created at the end of every official build. These tests fail in some significant way about once every three weeks and usually the fix is made and a new build is underway by noon the next day. (We run our builds at night, so nobody is around when the tests fail. Fixing the build is )
- Write unit tests religiously – I think the central tenet of Test Driven Development (that you should write your unit tests before the code and then run them to watch them fail) is a bunch of hooey. Testing your code with unit tests, however, is much faster in many cases than testing it by bringing up the server cluster and client and testing it in-system. And once you have them in the build you have a perfect way to test that your basic assumptions about the code aren’t being violated when you make future code changes.
- Review all checkins – Programmers will get the most benefit from this one, but other developers will also benefit. Thanks to #4 you have all your source data in text files, so a quick diff will show you what the developer changed. If the changes don’t look quite right the developer can fix it before it breaks the build. The reviewer is also granted some knowledge of the checkin so they are better able to fill in for the developer in a pinch. Everyone on the team should act as reviewer for other developers so that leads don’t become a bottleneck. This is also a great place to enforce coding standards and naming conventions.
- Keep your startup time as low as possible – Normally your whole-system optimization happens toward the end of the project. If you can spend some time optimizing startup times as you go, you will save many hours of developer’s time over the course of the project. Don’t forget to pay attention to the startup times in your tools and servers too. Chances are that developers will be launching those just as often as they launch the client.
- Prevent developers from having to restart – For programmers, this might mean using a scripting language and setting things up so you can reload scripts on the fly. If programmers can shut down pieces of the server cluster, recompile them, and then relaunch them without ever closing the client, they can get some benefit there too. For other developers, this means being able to re-read data and configuration files instead of requiring a restart of the client, server, or tool in order to see your change. Anything you can do to make this reload of data faster is a big help, possibly including doing it automatically by scanning file times.
These are all ways that you can improve developer efficiency (and therefore productivity.) There are only ten on this list, though, and I’m sure there are many others out there. What are some ways you have improved the efficiency of your teams?