This is the summary of the first session of my GDC 2004 roundtable: By the Books: Software Engineering in the Games Industry. Unlike other years, each session focused on different topics. This one starts with a general discussion of what we need software engineering for in the games industry and then looks into specific techniques that teams can adopt as part of their development process right away.
Overview and Attendance
Thanks again to everybody who attended the roundtables this year. All in all we had about 150 people show up (with the first two sessions being completely packed), which means the interest in software engineering continues to increase as projects get more complicated, and team sizes and budgets continue to increase.
We continued the trend from previous years and we had about 30-35% of managers and project leads. That’s a good thing because for things to change management needs to get involved, and the sooner they do, the better.
The large majority of the attendees were working on PC and console games (surprisingly, about the same number of both), with very few handheld and web game representation.
C++ this year was the undisputed king of the programming languages (so much that I couldn’t count the number of hands). There were only a handful of people using straight C, but a higher representation of Java and higher-level scripting languages like Python or Lua. Several people were starting to use C# for their tools development.
One new piece of data I collected this year was team size. I really wish I could compare this against previous years, but the results were very telling even by themselves. Specifically, I asked for the number of programmers in their teams. These are the results:
- 1-5: 35%
- 6-10: 45%
- 10-20: 20%
- > 20: 0.05%
All of the programmers who were working on a team of 20+ people were either from Electronic Arts or from outside of the games industry. Still, the numbers are pretty high already, and those are probably just signs of things to come. Even John Carmack lamented the increasing number of people required to make a game in his keynote speech.
Wednesday 24th: Software Engineering and Techniques
The session started with a discussion of how can software engineering help game development. Lots of reasons were brought up:
- Reducing risk
- Reducing bugs
- Helping with reuse
- Easier multiplatform development
- Reduce crunch time
- Easier transfer between projects
- Better support of their content teams
All of those are reasons that will continue becoming more and more important in the near future.
A few people had concerns about over-engineering things and brought up the need to strike a middle ground. Even so, nobody admitted to doing too much engineering in their teams (although people did have over-engineered, or over-complicated, pieces of code).
About 75% of the attendees actually had coding standards in their companies (or, in some cases, multiple coding standards!). Only about half of them actually followed them, but most people who had a coding standard found them useful. The reasons given were that it was a good leveler by making the code more similar throughout the project, and that it saved programmer time and headaches.
However, not everybody was in favor of them, and certainly not everybody agreed on what they should cover and in what detail. Some people argued that a coding standard should only cover interfaces and not interfere with implementation details. Some found it difficult to maintain a standard when interfacing with third-party code or APIs. A good point that was brought up was that a coding standard shouldn’t be too detailed
Participants identified three main types of code ownership:
- Team ownership: The whole team owns the code.
- Loose code ownership: One or two people are mostly responsible for an area of code, but other people can still modify it.
- Strict code ownership: Only one person can modify the code.
Very few people had team code ownership (the few who did were doing pair programming). Most people either had loose or strict code ownership. The benefits of team code ownership are avoiding the “hit-by-a-bus syndrome” (where you might lose your most important programmer because of some unexpected turn of events), and spreading the knowledge of the system to everybody and making all the team members more valuable. The disadvantages were that sometimes people did not take responsibility for their own actions. Team code ownership requires a lot of communication and might work best in smaller teams (5-6 programmers).
About 20% of the participants had some form of code review in place, but the specifics varied a lot. Some people’s reviews were just a quick look by someone else before the code was checked-in (code buddy). This was done more frequently around milestone time to avoid people checking in code that would break the build.
A few people had more formal processes in place, printing out the code, and reviewing it in more depth. However, a lot of people found this type of reviewing more tedious than it was worth, and it has the potential to quickly degenerate into pointing out formatting problems or allowing people to go off in tangents about their favorite language feature.
The question of what exactly was the purpose of the code review came up. It clearly doesn’t help any with code design because the review happens after the code is written and working. The main reasons listed were bug prevention and avoiding horribly inefficient code.
About 40% of the participants had some sort of automated build system in place (way up from the 15-20% of last year!). Most of these automated builds were done by custom scripts in a high-level language such as Perl or Python. How and when the builds are done also varied a lot: some people had them triggered with each check-in, others had a machine building continuously, and others were simply doing nightly builds.
Some of the benefits claimed for automated builds were checking that the code could always compile and link, and easier version labeling and tracking. A lot of people, in addition to building the source code, were also doing asset builds. As an additional step, many people were doing some form of validation on their executables by loading a few levels or playing back some input (especially random input). People collected the results of the build by either sending emails or posting results on an internal web site.
Two points of caution were raised: A fast turnaround time was important, otherwise the QA and the engineering team could get out of synch and make bug fixing more difficult. The other point is that bad automation could be worse than no automation.
Only a few people were using some form of UML (about 10%). Most of them were just using it in the initial stages of development to sketch out some ideas and discuss them, but then the models were quickly discarded and not kept up to date. Interestingly, some people were generating UML after the project was complete to pass it along to another team.
Only one person was using many of the UML features (sequence diagrams, use cases, etc), and everybody else was mostly using it for static class design. Several other people reported doing initial design just using “boxes and lines” instead of formal UML, which worked very well for their projects.
Some of the tools people were using were ArgoUML(free and open source), Enterprise Architect, and UMLNotepad (free, open source). Not exactly UML, but several people mentioned Doxygen as a tool to generate some visual representation of the code, which was particularly useful to explore code without existing documentation.
Previous GDC roundtables