I attended Brian Sharp’s roundtable on sharing code on its third day, which was Friday, 22 February 2008, at the Game Developer’s Conference 2008. The intent of this roundtable was to discuss code re-use between programmers, and there was no discussion on things such as open source issues.
A key question raised at the start was: what actually works? Consensus was that the key features of a code set that shares well is that there must be well-defined packages that build properly and easily. Well, for myself, the latter feature, making shared code build easily, is simply crucial. I have, far too many times, attempted to reuse someone else’s code that had undocumented prerequisites, didn’t have a build script updated for the latest compiler, or that simply required too many operations and manual file copies and reconfigurations of include and link paths for comfort. I think the audience nailed these two requirements!
Some studios (and I add my own company to that list) have complex automated build servers and a myriad of processes that semi-guarantee the ease with which code can be shared. But maintaining these build processes is expensive, and might not be possible for small teams. Another consensus point was that it may be impossible to create a system for code reuse all at once. (For example, my company’s process set, which includes automated builds, standardized code and functionality reviews and deliveries including a requirement to keep documentation fresh, and supports multiple dev teams and over a hundred people in total, has evolved, literally, over several years with multiple people spending months of dedicated time for each iteration of the processes.) Whatever the size of your teams, start small, and develop your system in stages!
A few people are using Wiki technology to document ways in which code can be reused. Wiki’s provide easy ways for developers to just produce snippets of code, without going through a formal documentation process. I have found that they work really well.
A classical problem in software development, and the game industry is no different, is the continuous recreation of common functionality such as vector and string libraries. It is possible that a game may eventually have dependencies on three different string libraries as a side effect to using different shared modules that were built around the different dependencies. Someone in the audience made a point that sometimes, sometimes this is just a cost that will have to be accepted. It can be more cost effective for a particular project (get this game done on time and on budget) to just leave the multiple dependencies. A long term goal, in general, would be to reduce redundancy.
An audience member raised the issue of keeping morale up while refactoring code to enable reuse. Some people will like enjoy this activity, its rhythm, and may find it meditative. (I sometimes do, myself.) But others may not find it as agreeable. A few points were made, that can make the refactor task go smoother. The programmer that produced the code originally will likely be very happy to see the code reused elsewhere, and so the team lead may decide to have the programmer refactor the code. This secures the code ownership and encourage the reuse that will add that satisfaction of having a larger impact within the company. Another idea was to rotate staff through a core technology/shared technology team, so that everyone has a chance to work on cool stuff (new fancy game) but also everyone shares in what some find monotonous. The idea of rewards also was discussed, e.g., if you work on refactor for a month, the next month you get to work on a cool feature of the next big game.
The issue of trust was raised. For example, some developers don’t trust code that is offered for reuse. Redundant code often results from this distrust, and the Q/A and maintenance costs grow as a result. Consensus was that reuse needs to be advocated by someone on the team who is generally respected and outspoken. This person can encourage team buy in to the idea of reuse. It works, believe me.
There was some discussion of how to pay for the cost of sharing code. For example, if you have a shared technology team, whether with permanent or rolling staff, where does the money come from to pay for the salaries and hardware/severs of that team? A simple idea presented was to simply have the game teams pay a weighted percentage of the shared tech cost. A question that can arise, in the customer’s (publisher’s) mind might be one of return on investment (ROI), and if you have a shared technology team that is not working directly on a game, be prepared to provide a way to measure the ROI for the publisher. Of course, the idea here would be that the cost to implement the code rather than reusing would be greater.
The session concluded, having produce quite a few good ideas.
Southwest Gaming Expo
