Agile game dev (4/5) - Keith 2010

Agile game development with Scrum, Clinton Keith, 2010

Part IV - Agile disciplines

Read the series: 1/5, 2/5, 3/5, 4/5, and 5/5.

Programming

Flexibility is essential to not waste time during development. Over-architecting can not take into account all the possibilities from the start.

XP includes TDD and pair-programming. TDD maintains stability when refactoring happens. It works best when accompanied by a continuous integration server. Pair-programming helps junior coders learn the ropes and decreases the time spent surfing the web or checking emails: when someone else sits next to you, you don't dare.

Debugging and QA happen throughout development. Bugs transform into stories, and make their way in the product backlog. Their priority is decided by the owner based on the magnitude of the consequences.

Optimization should also happen throughout development to be able to reach the shippable definition of "done". Example of a definition of "done" not for shippable but to be able to see the fun in the game: 50% of frames run at 60+ FPS, 95% at 30+ FPS, and the level loading time should not exceed 1 min. Spikes can be used to explore optimization techniques if need be.

Art and audio

Teamwork in a cross-disciplinary team turns artists who deliver art into art-specialized developers who deliver an experience. Artists generate assets ranging from textures, and models to sounds and music. To make their assets, artists rely on tools. If artists work in purely artistic teams, they observe an unavoidable tradeoff between the cost of making assets and their quality. In a cross-discipline team, tools and practices are continuously being improved, hence quality may increase while cost decreases.

Art QA is performed all along by the whole team. To test their assets in-game, artists need a build that is relatively stable. The quality of assets can be verified manually in-game and/or automatically by tools. Often, assets have to be approved by the art director to be considered "done". To save time to everyone, an evident "art director approval" column can be added to the Kanban board.

Pre-prod is really important because it is when production costs are learned. 50% of production costs come from level production. These costs can be estimated by building a vocabulary (ie patterns) of simple levels and their mechanics. Artists should also know, before entering production, the constraints and budget: how many bones per character, how many polygons on the screen, which character behaviors and motions are necessary, etc.

Game design

The roles assumed by designers are varied. Since designers represent players, senior designers can assume the role of product owner, provided they take into account cost and ROI. In teams, designers should go in teams where they know the domain: designers with UI/UX skills go to the HUD team, and senior designers to the core gameplay team.

The design document should not be too detailed. It should be updated daily with what becomes known about the game. It should not try to answer the unknown, because the only way to answer unknown features is to try them in-game. The design document also holds the vision for the game. Designers in cross-disciplinary teams relay this vision to their team and filter and adapt ideas generated by the team.

Designing from "parts on the garage floor" happens when parts are developed separately and integrated 2 weeks before shipping. The resulting game is very different from the vision, but it is too late to fix or polish.

Set-based development is preferred to point-based development. Point-based development consists of iterating each discipline in isolation from the others. For instance, the designers want the feeling of a seamless world. They think that contiguous locations could be streamed from the disc, so they go ahead with their design without asking the programmer if it is actually possible. The next build shows it is not possible with the current engine. Designers also learn that artists did not have the appropriate tools to bake streamable assets. They abandon the idea.
In set-based development, disciplines share their possibilities and constraints. In our previous example, designers would ask around whether it is possible to stream scenes to provide a seamless world experience. They get feedback from programmers, who decide to update the engine to support streamable scenes, and from artists, who request tools to bake streamable assets.

QA and producer

QA in traditional development processes happens in post-alpha, when minor tweaks and polishing are possible, but major defects can not be fixed. A studio culture that considers bugs to be part of making games does not help. Agile changes this.

In production, white-box testing can be performed in-house every day. QA takes care of regression testing on the build, developing testing tools, and testing pipeline changes. Each agile team already does QA to improve its practices, especially with TDD. Yet at the beginning of prod, teams can contain one tester to increase the quality of testing. In a team, testers help define "done" and the CoS for the stories. They also help the team keep a consumer eye on gameplay. If smoke-tests can take care of what can be automated, testers can still conduct walkthroughs to assess usability, playability, challenge, pacing, and the level of polishing.

In post-prod, or even at the end of production, testing and tuning ramp up. Pools of testers can be shared between teams. Bug-tracking repositories can replace sprint boards. QA can also organize playtest sessions using local university students or local game shop customers.

Producers in scrum can take the role of scrum master, but should never micro-manage. They can also be (co-)product owner, taking care of licensing, outsourcing, and publishing issues. They also plan resources.

Read more:

• McConnell 2004, Code Complete
• Beck 2004, XP explained
• McGuire 2006, Game design with agile methodologies (online)
• Poppendieck 2003, Set-based development (online, ch2 p26)
• Irish 2005, Game producer's handbook