Agile's Got Game
An amateur group. Minimal budgets. Limited communication. How one team turned these obstacles into a winning combination.
by Andrea Nicolò, Customer, Francesco Carucci, Coach, and Mirco Macrelli, Coach, Diamond Crush Development Team.
What we're about to tell you is not a typical story. It's a different experience, lived in a first person perspective, about a project we've been involved with since last September, and whose results--despite being only 50 percent complete--seem already different. We're creating Diamond Crush (DC), a PC puzzle game whose release is planned for Q4 2006. But that's not the real story. The real story is that it's being developed with Java and Agile development methodologies, which are poorly used in the world of game development. Furthermore, the project is being completed by an amateur group with a minimal budget. To complicate matters, the project is being run in a distributed development context with personnel spread throughout italy. Our only forms of communication are forums and instant messaging software. What once seemed improbable, though, is becoming a reality.
Setup
The Diamonds Project began as a way to teach young volunteer developers in the field how Java and Agile methodologies can make complex tasks possible. We didn't set out to create a video game, however. The project was first conceived in the Computer Programming section of the italian hardware upgrade forum as a simple software program for cataloging CDs and DVDs. That unexciting project didn't generate a great deal of interest, though. After a good deal of discussion, we decided to try something else: a video game. All of sudden, we had their attention. After several proposals beyond our means and thus rejected (developing a 3D shooter would have been endless and a violent school-themed 2D shooter would have required huge art and level design resources), we chose a 2D puzzle game to focus most of the development on the actual programming. We used the old Super Puzzle Fighter 2 Turbo by Capcom as our primary source of inspiration so we'd have a concrete and vastly tested example to refer to.
Francesco Carucci (3D Software engineer at lionhead Studios) volunteered to help us externally. He suggested we use Java as the programming language, and open source tools such as eclipse and Ant to compile the code and create the builds. He and Mirco Macrelli also suggested we employ Agile methodologies to ensure a flexible structure, to minimize the costs of changes, and to shorten the learning curve for the members. Once the what and how were defined, we only needed to decide the who in terms of a Coach and a Customer. Francesco and Mirco, by popular acclaim, were chosen as Coaches; two forum users, MaaX and raoul_benneth (both later replaced by Andrea Nicolò) became the Customers. After putting the repository online on Spartacus, a server freely offered by the Night Sun Network, we were finally ready to go.
Strategy
Our entire development philosophy was based on two very clear-cut, easy-to-grasp values that could be intuitively perceived as useful by everybody in the team: Keep it simple and Don't repeat yourself.
Keep it simple is the measure we apply to the design, the code, and the game itself. The game must be simple to play and simple to work on. The code must reflect this by being simple to write and simple to change when necessary. Features are dismissed if not simple enough to implement. We have always seen any kind of complication as a liability that could compromise the entire project life, and this mentality is still permeating the team after months of development.
Don't repeat yourself involves eliminating duplications in both our design and our code: we want to express our intentions only once and in a very clear manner. Any game features that could potentially lead to duplications in our code base are dismissed as impractical.
To adhere to our values, we chose an iterative design process. Our goals were clear: produce a 2D game for release to the public that is fun to play. How to achieve our goals was less clear, so we needed a way to quickly adapt our game design to the actual needs of the game by evolving it during the development. An iterative process was the natural choice. Game Play
Once we set our values in stone, we had to choose which actual practices could help us in achieving them. We chose to adapt extreme Programming methodologies and its practices to our situation. Extreme Programming values communication over processes during development. Communication was the first big problem we had to solve: as we mentioned, our team is spread throughout the country and only internet forums and instant messaging allow us to communicate. To fit this rather unique situation, we had to tweak some methodology details so they would work for us.
Our standard two-week iterations follow this tweaked-XP plan. The Customer, after discussing technical details with the Coaches, constantly updates a shared development plan document, adding the stories planned for the future iterations. Despite the use of this document, the Customer chooses stories in a flexible way at the start of each iteration, according to the eventual flaws that might emerge after each iteration in the builds tested by the Customer.
After the new stories have been chosen, the Customer posts them publicly on the forum. Mirco (one of our two Coaches) summarizes them in a task list posted right below them. At this point, each team member is free to choose any story by booking them. To book a task, a team member posts the estimated time for the task to be completed along with an acceptance test list to be approved by the Coaches. We also keep track of each task in the development plan document, so we are always able to verify who did what.
Practices such as pair programming seemed almost impossible to put in practice in our situation, yet we needed them to keep the process smooth. We solved this through Pair Programming on the Forum, where two participants take one task and write the relative code and their reasoning as posts in a thread. Throughout the coding, they discuss and explain their design choices via the forum. After the completion of the task, each thread is left on the forum, free to be read and understood by the rest of the team. Despite the slow pace inherent in writing these thoughts compared to just speaking face-to-face, the ability to display the content of what are usually verbal sessions has an ancillary benefit: they have proven to be an invaluable tool not only in writing the actual code, but also in spreading our values, practices, and also small coding tips to the entire team. The result has been incredibly quick adoption by every team member of our coding standards and best practices through these examples. We use Pair Programming on the Forum to quickly introduce new members to the team, further minimizing their time to become a fully productive programmer in the team.
We have also expanded pair programming to other contexts, such as the graphical and artistic sides of the game. Andrea and the Gui designer Sandro lain even did some pair Photoshopping sessions (named this way to make it sound similar to pair programming) to design the Gui used by the game, and it seemed to work well. They both worked on the same file, kept in a shared folder, one at a time. While one was working and adding shadows, effects, and tone changes, the other one would suggest what could be added or changed. The final result was far superior to that obtained before by both of them separately.
Continuous integration was, and actually is, pretty straightforward: we use CruiseControl to manage Ant builds. After a build is completed, CruiseControl sends out emails with the build results and tests to the entire team. RSS feeds are also available and widely used to inform the team of the results. Broken builds are quickly addressed and, since running an Ant build before committing is mandatory, the number of broken build remains low, on the order of 1 percent of the total.
Test-Driven Development (TDD) is another core practice in our day-to-day programming. The entire code base, except for code calling directly into openGl or OpenAL, is written test first, which is proving to lead to a quite minimal and simple design. The product of this practice is a suite of tests that is helping the team to catch early defects introduced during the development of new tasks or during big refactorings. Since communication in our situation is always problematic, the team tends to communicate on the forum through tests rather than written words. For example, a tentative design is explained by a test. Conditions triggering defects are also explained through tests, which leads to one important practice we have in place: every defect in the code is fixed after a test to exercise it is written. This practice is proving vital in minimizing the number of knock-ons after fixes we are experiencing.
TDD is usually seen as a difficult practice to master and use effectively, requiring programmers of great experience and insight. Our experience is suggesting that, on the contrary, programmers with minimal experience in programming, like the members of the Diamonds team, can easily pickup TDD and use it extensively with minimal effort, if properly trained to do so. As a matter of fact, the more experienced programmers in the team were the most difficult to train and were more reluctant to fully adopt TDD. Their long experience with traditional practices of software construction caused them initially to view TDD as a useless and timeconsuming practice. They've since come around.
To stick to our second principle (Don't repeat yourself.), we use refactoring to remove duplications and useless complications from the code base. Refactoring the code both ruthlessly and also whenever a chance arises are now part of the culture of the team. We routinely take various metrics of the code, such as cyclomatic complexity, and use them to isolate classes and methods that need refactoring. To do this, we use some really neat software called Cobertura, also used to check the test suite code coverage. The offending code is posted on the forum, where people not assigned to actual tasks can pick the refactoring tasks up. This practice also promotes team code ownership: because you usually refactor code that isn't your own, each team member is familiar with the whole code base, and can promptly intervene anywhere in order to reduce complexity wherever needed. We encourage this by often rotating the people working on the areas that usually require several refactorings. Refactoring and Test-Driven Development are showing up as invaluable practices to manage the complexity of our code base to achieve our principle of simplicity.
As we strive for simplicity, YAGNI (you Ain't Gonna Need it) has become our mantra, pervading every aspect of our development process. It goes from the game design down to the single line of code: any design feature or code feature that is not clearly expressed and explicitly accepted by our Customer is YAGNI. It has probably been the most difficult concept to grasp and required several iterations to become fully part of the team culture. Several less-experienced team members, and even many of the most experienced ones, had several difficulties in understanding why not writing a feature that seemed useful and reusable in the future could help development, since this concept of code reusability has always been central in software engineering, especially as taught in european universities. The Diamonds Project proved on its small scale how keeping the code base simple, not imposing reusability and complexity if not clearly needed by the evolving requirements of the game, can lead a team of inexperienced programmers to successfully complete their project by managing complexity in an effective way.
Challenges and Obstacles
Over the course of the project, we've also had to face several technical and practical problems. First of all, we've noticed some temporary drops in motivation and spare time, with consequent production slowdowns for two consecutive iterations. As ours is an amateur project led by volunteers, this is not unexpected. We've since found that having fixed objectives, such as the First Playable Version deadline, has strongly increased our whole productivity rate, getting us back on rails quicker than expected. So, constantly setting new deadlines has now become one of our main priorities.
Another problem has been the difficult task of finding the programmers and 2D artists we're looking for (even now) to strengthen our team. 2D artists are pretty rare in the amateur scene, and some of the ones we did manage to secure didn't show much professionalism: they simply disappeared without a trace before starting anything.
Our third--and luckily last--problem, has been how the code base tends to grow in complexity and size every time we stray from our practices. The larger code base makes tasks harder to complete. We performed some heavy refactorings to solve this particular problem.
The Score
Thanks to the principles and practices we are using during the development of Diamond Crush, the first release (an incomplete First Playable Version for offline multiplayer only) is experiencing a truly small number of bug reports: about a dozen, out of the more than 3,000 total downloads we've had so far. Considering that the team is mainly composed of inexperienced programmers, this is an outstanding practical result, demonstrating how Agile methodologies have proven effective in a distributed environment like ours.
What have we learned from our project so far? First of all, as we've directly experienced it, we've learned that Agile methodologies can be successfully used in game development, even with low budgets and inexperienced teams. We've also learned that applying all the principles we've described brings results whose quality is proportional to the constancy of their use. Lastly, as demonstrated by examples like the pair Photoshopping sessions, we've learned that some Agile principles, such as simplicity, pair work, and YAGNI, can also be applied to other contexts, and may be useful even in every day life. Doesn't "live simple, live Agile, live YAGNI" sound nice?
File PDF Originale
Questa è la versione in .pdf che ci hanno inviato dalla redazione.
gotgame_12-17.pdf 8504354e2262f78f74e82124e62493db0cf3de82