Ten Ways to Improve Developer Efficiency

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  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 )
  7. 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.
  8. 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.
  9. 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.
  10. 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?


9 Responses to “Ten Ways to Improve Developer Efficiency”

  1. Jeff Freeman replied on :

    Use text files for your data files

    So… I like to fiddle with numbers in a spreadsheet. Saving it out as a tabbed text file makes it text, but loses all the forumulas. Simple CELL+CELL sorts, mind.

    Do you know if there’s a spreadsheet-lite program that could save the forumas even when the file is saved in a text format?

    And doesn’t convert dates to some kind of countdown from the Martian-invasion?

    If we went back to VisiCalc on an Apple ][, say?

  2. Joe wrote on :

    Heh, I don’t think VisiCalc is necessarily the answer. :)

    We are using Excel for some of our tuning. The designers love it (for obvious reasons). Unfortunately we have no way to get data out of Excel and into files the game can actually read. We could probably come up with something that dumped out the cells into an XML or CSV file and then check both things into source control. Revision histories on Excel files would have been handy on more than one occasion on Pirates. The need for revision histories has never outweighed the benefit of using such a powerful tool, though.

  3. Sara Jensen replied on :

    Yeah, I’d put the spreadsheets in source control, then write an exporter to turn the spreadsheet’s values into whatever the game needs.

    I’ve longed for source-controlled spreadsheets and Excel exporters more than once. :)

  4. Joe said on :

    Have either of you looked into the OpenOffice spreadsheets? They might not have all the functionality of Excel, but maybe they can save and read complex spreadsheets in XML.

  5. Richard wrote on :

    I am not sold on saving data as text files. Let’s say we are talking about game design data, a better method would be to store it versioned in the database. In fact that directly relates to what I consider a big missing entry, the need for a web server built into the game server.

    Pretty much everything can be done, and is done, for EVE Online in the web pages its servers provide. Game mastering, game design, administration, introspection, statistics, graphs.. etc.

    #10: A friend and I reimplemented how EVE does its modified script reloading and released the code. It can be found here if anyone else is using Python and hasn’t written the same functionality themselves:

  6. Joe wrote on :

    As long as your art assets and code are versioned in the SAME database, that’s just fine. Not being able to associate our static data with a particular build bit us often when we were still storing the static data in the database.

  7. Neumann said on :

    Excel can natively save worksheets as XML files.( ->Save as -> XML document) However, you would need an xsl-t document to put the data in a useful format as the XML spit out by excel has a lot of data that isnt useful except to excel. (It stores the width of the columns and which column was highlighted!)

    Another option is using Excel spreadsheets as ODBC datasources.

  8. Ryan Shwayder said on :

    Great post. I’d personally suggest a combination of database and text files, but I’ve seen it done every way you can imagine.

    The nice thing about using text files is that it’s really easy to get at for a designer. You can have all the data on your machine locally and skim through it a lot easier without necessarily knowing what you’re looking for.

    It makes searches for data using Textpad (my personal favorite) extremely easy and often faster than databases (as long as you know the general area you’re searching in), not to mention it reads a lot more naturally when you get results.

    It also tends to be easier to drop in more Live data without rebooting servers if you’re using text files.

    I think the same things can be achieved with databases or text files, but there are advantages and disadvantages to each, so if possible I would combine the two forces for maximum efficiency.

  9. Richard Slater thought on :

    Both OpenOffice.org 2.0 and Excel 2007 save natively as Zipped XML files. You can see it yourself by renaming the .ods or .xlsx (for OpenOffice.org 2.0 and Excel 2007 respectivly). With any luck we will see plugins and extentions for our favorites SCM soloutions becomming available soon.