Chapter 11. Agile Art and Audio

Computer-based artwork is dynamic and evolving. Art styles transform, and artists explore new meaning in what they create. The medium that they use has undergone as much change in the past few decades, with the advent of powerful and cheap computers, as it had since the caves in Lascaux, France, were painted 16,000 years ago.

Cell animation and pre-rendered computer graphics have enabled artists to add more motion to their work. This has made it possible for the wild imaginations of artists and storytellers to be more deeply shared such as in the movie Fantasia.

Video games have added a whole new dimension. Now art has to be interactive, which enables it to be used in ways its creators didn’t imagine. The medium is complex and requires the artist to collaborate with designers and programmers to bring their work to life.

This chapter will explore the benefits, concerns, and common practices of artists on cross-discipline agile teams. This chapter covers principles and practices that cover many artistic disciplines including modeling, texturing, animation, audio, and so on. It refers to the members of every discipline as artists.

The Problems We Are Solving with Agile

Why use agile for art? When Michelangelo painted the ceiling of the Sistine Chapel, he wasn’t using agile. He had a plan to paint the entire ceiling.

—A former artist co-worker

In reality, Michelangelo may have been better off using a more agile approach to painting the Sistine Chapel. There was a great deal of trial and error and false starts. He had no idea about how to paint images on a curved and segmented ceiling. He signed a fixed-price contract calling for 12 figures to be painted. Four years later he had painted 300. It’s no wonder he referred to it as one of the worst experiences of his life.

Video game artists face similar challenges. Translating their vision into reality runs headlong into the challenges of the medium, whether it is fresco or graphics processors. Overcoming these challenges and understanding the limitations of the medium before creating the final product are necessary.

The following are some of the main problems artists encounter:

• Artists need to know whether they are creating the right thing and not wasting effort: Parallel development of assets and technology that the assets depend on is a traditional source of wasted effort. Engine development is often started with optimistic feature sets, performance goals, and schedules. Unfortunately, projects fall short of these goals, and the assets created cannot be used as built and have to be rebuilt. Technical iteration requires an ongoing conversation and experimentation with what looks and works best. Every artist knows that the quality of a complex asset, such as a level, depends on a trade-off between polygon count, texture quality, lighting complexity, and the palette of effects available. None of these is independent of each other. Some levels require more effects than others and require trade-offs. We want to build the knowledge of these trade-offs during engine development before we commit to production. This requires frequent collaboration between the technology creators and the artists who leverage their work.

• Artists need a stable, working build: Nothing impacts progress more than a broken build. Graphical defects that impact visual quality prevent an artist from developing the best possible assets. Relying on a separate technology team to solve these problems adds delay. Cross-discipline teams are more likely to have a team member who quickly solves these problems or is able to communicate with someone who can help.

• Artists need faster tools and pipelines: Artists are often limited by slow iteration times and therefore can’t iterate as much as they like. Less iteration translates to lower-quality art. A common problem is that programming team members, who have control over improving tools and pipelines, are not impacted by the same problems. They don’t experience how slow it is to change a texture on a game. They are focused on the tasks that are important to their team. Cross-discipline teams share common goals. Problems that impact individual progress impact the entire team. When this happens, then such problems receive the level of attention they deserve.

Concerns About Agile

Artists have several common concerns about agile and Scrum:

• Scrum is for programmers: Scrum is used to a great extent on software development projects, but it wasn’t created for programmers. In fact, it purposefully has no specific practices for any one discipline. It’s as applicable for artists as it is for any other discipline.

• Art production runs on a schedule. We can’t be iterative: With video games, art and technology have to integrate with the gameplay mechanics to create a fun experience. Teams have to explore how all these components work together. Once they discover this, they can schedule the creation of ten to twelve hours of production content. Exploring in pre-production is necessary. Cross-discipline pre-production teams using by-the-book Scrum thrive. During production, many practices will change but remain agile. Production issues continue to create unexpected challenges. These challenges wreak havoc on the best-planned schedules. Artists creating assets still need rapid response to technical problems. They need to continually find ways to collaborate (see Chapter 7, “Video Game Project Planning”).

• Cross-discipline teams don’t work: On large projects, artists have traditionally been pooled with members of their own discipline, and they’ve learned to work that way. Once they try cross-discipline teams and experience day-to-day responsiveness from teammates who help them solve problems, they change their minds. Scrum doesn’t prevent artists from communicating outside of a sprint. They can form communities of practice (see Chapter 8, “Teams”) and still share ideas and practices with one another.

Like almost any developer, artists need to experience Scrum practices before they’ll agree with the benefits. A sense of skepticism is healthy as long as it is paired with an openness to accept what works.

Art Leadership

As with all leadership roles, agile shifts the responsibility of art leadership from daily command and control to mentoring and facilitation. The role of art leadership is to improve the quality of the art being created and to help artists improve their ability to create art. These two must constantly be balanced.

To improve the quality of art, the art lead (or art director) reviews new art in-game and provides feedback. This creates the opportunity to work with the artists directly within a sprint. This influences some of the daily practices. For example, art assets may need a sign-off or approval by a lead artist or art director, so some teams add a column on their task board called “Pending Approval” before the “Done” column to hold an art task to be approved before it is considered done.

A challenge for many agile game teams is how to avoid having art direction approval become a bottleneck for progress. Since art directors are usually not members of any one team, they do not have the same level of commitment to a sprint as teams who depend on their feedback. Delayed feedback is often a source of impediments for these teams. Studios develop unique practices, such as highly visible approval backlogs, to address this.

In addition to asset approval, art leaders must mentor less-experienced artists to improve their art creation workflow. Art cost is as critical as art quality. Without experience or familiarity with all the tools, new artists can waste a lot of time creating assets the hard way.

As the art lead works with artists to improve quality and reduce cost, they will see patterns for improvement that can be shared among all artists or opportunities for improvement that can be championed with the team that supports the pipeline and tools.

Art on a Cross-Discipline Team

An artist on a cross-discipline team is faced with a number of challenges. Different vocabularies must be understood, and the artists must struggle to make themselves understood as well. They are reminded daily of how their art is used: how it leverages the strengths or exposes the weaknesses of the technology.

For a cross-discipline team that is measured by value added to a working game, the role of an artist shifts to that of a “game developer” who specializes in art. An artist doesn’t simply create an asset for someone else to put in the game and make fun. The artist participates in the creation of an experience, where art has an equal value. By having a voice in the discussion about what is being created, the artist elevates the value of what they create and minimizes the cost of creating it.

Creative Tension

When forced to work within a strict framework, the imagination is taxed to its utmost—and will produce the richest ideas. Given total freedom, the work is likely to sprawl.

—T.S. Eliot

Creative tension exists between what we can do and what we want to do in a game. Creative tension is a good thing. It enables us to push the quality of an asset in the game while working within the bounds of technical limits, cost, and schedule. Creative tension puts pressure on our work processes, tools, and practices to find opportunities to eliminate waste.

Some of the best ideas are created from these limitations. When we were developing the game Midtown Madness, the shortage of level artists forced us to rely on a tool that procedurally created a city from a simple line map. This tool generated an entire city in an hour and allowed us to iterate hundreds of times whenever we discovered problems such as curb angles interfering with vehicle wheel physics. Had the entire city been modeled by hand, we could not have iterated as many times to improve the game.

Scrum compels teams to improve their performance every sprint. It forces creative tension to the surface where it belongs.

Art QA

Many problems are avoided when the entire team iterates on the game daily. Asset creation tasks aren’t considered complete when they are exported but when they are verified in-game on the target platform. Verification not only includes seeing the asset in the game and ensuring that it functions well but also includes verifying that some of the less-apparent aspects of its use are correct. In-game asset verification tools aid in checking the construction of assets in the game in many ways:

• Physics geometry view: Does the collision geometry match the visible geometry? Is it aligned properly?

• Texel density view: Are the textures properly mapped? Are the textures the right size?

• Wireframe view: Is the out-of-view geometry being properly culled? Are the asset visibility flags set properly?

• Sound volume view: Are the sound min/max radii properly set? Are the proper sounds triggering at the right time?

• Asset selection and highlight: Is an asset lit properly in the game? It is visible to the player? How often is it instantiated? Rather than searching for an asset, this tool enables the artist to select it from a list and see it highlighted.

Artists need to have access to all the target platforms to test their work. Sometimes it is too expensive to equip every person on the team with platform development kits. In those cases, small groups share a development kit in a location that they can all see and control from their own workstation.

When QA is the responsibility of everyone on the team, then everyone needs to examine how assets are being used and make sure that they adhere to the budget requirements.

Building Art Knowledge

A goal of pre-production is to create knowledge. We want to know how fun the game is, how content will be produced, and how much it is going to cost. Creating this knowledge requires iteration. Unfortunately, teams often focus too much on core mechanics or the fun of the game and not enough on production costs. This result is that many projects exceed their production budgets or schedules. They need to explore production costs more in pre-production.

Level production often costs 50% or more of the production budget. Project teams need to refine their understanding of the effort to build levels during pre-production to avoid mechanics that inflate production costs beyond the budget. For example, some shooters have a fantastic feature that makes it possible for every object in the environment to be destructible. Unfortunately, this feature can double level production costs since building destructible geometry requires far more effort. By knowing this cost impact in pre-production, the product owner can better judge the return on investment for this feature.

Learning about production cost is an iterative process. It begins with a range of estimates based on existing knowledge (perhaps from a previous title) and is iteratively refined during pre-production. Refinement occurs by iterating on mechanics and building a “vocabulary” of rooms or simpler levels that grow as the team learns more.

Building a shippable level before a vocabulary of mechanics is established is wasteful. This waste is seen on many milestone-driven projects. Teams feel compelled to show something that is polished to their publisher when the gameplay is still undetermined. These polished milestone levels are eventually thrown out or require a great deal of rework when the team learns more about the gameplay.

Overcoming the “Not Done Yet” Syndrome

Teams are often called upon to demonstrate the potential value of a mechanic in a low-cost way. This often requires that stand-in assets, such as low polygon models or roughly blended animations, be used instead of polished assets. These demonstrations are useful tracer bullets to indicate where the game is headed. Although the results might be thrown away, their purpose is to learn more about a feature before deciding to invest more time in it.

Artists often resist showing stand-in assets to the world and want to add more polish for a prototype. There is nothing wrong with doing this as long as it doesn’t negatively impact the goal. For example, one project team discovered that their prototype level was running extremely slowly. After exploring the problem, it was discovered that hundreds of the props placed in the level were dynamically lit. The artists had done this since they didn’t have enough time to properly prelight the level and wanted everything to look good.

Iteration often requires showing proof-of-concept work to demonstrate knowledge gained. Stand-in assets are fine to use, but care should be taken to make it obvious they are temporary. Candy-stripe textures or characters that look like “crash-test dummies” allow stakeholders to look beyond the test assets and judge the results.

Budgets

One of the most frustrating things for an artist is seeing their work go to waste. It’s not unusual to review the assets created for a game and realize that enough of them were created and discarded to complete two games. The majority of the team often consists of artists, so wasting 50% of their effort is a tremendous burden.

Much of the waste comes from assets being created when not enough about their requirements and budgets are known. Because a game artist’s creation tools are often separate from the game itself, they “get ahead” of the rest of the project and create assets that are based more on speculation rather than the constraints of the emergent game. This is usually driven by schedule and resource allocation plans. A schedule might stipulate a certain number of assets created by a specific date, which in turn drives staffing on a project that may not be ready for it.

For example, a project plan and schedule may forecast a date when a set of characters is complete. As a result, a group of character modelers and animators join the project months before this date to start producing the character assets. At this point it’s expected that the project has proven character requirements and budgets such as the following:

• The skeletal budgets, such as how many bones are required, and so on

• The model polygon requirements, such as how many characters are on the screen at any one time

• An identified set of behaviors to derive the animation sets

• Character motion needs, such as whether all the animations are identified for characters to “look good” while moving

If character mechanics are not sufficiently developed to the point where these things are known, it leads to waste. The character artists would have to guess about these requirements and, because they have to keep busy, start building assets with them. This usually results in character assets that need a great deal of rework or, worse, have to be used as is.

Cross-discipline teams iterate and refine specific asset budgets and requirements as part of the goal of finding the fun and the cost. As pre-production moves forward, budgets and production tool requirements need to become part of the definition of done for asset classes. When these elements become “out of sync,” the team identifies it quickly and corrects the problem (such as altering team membership or future sprint goals).

Audio at the “End of the Chain”

Adding audio to an otherwise completed asset or mechanic is often the “last step” in a chain of steps (see Chapter 7), even in pre-production. This can lead to audio designers or composers with little to do at the start of a sprint and then too much to do at the end. Scrum teams often change the assumptions about handing off work and find ways to interleave work on multiple assets and increase collaboration across disciplines. Chapter 16, “Launching Scrum,” addresses this in more detail.

Collaboration in Production

In Chapter 7, we explored lean production practices and how cross-discipline teams work together to reduce waste while continually improving what they are creating and how they are creating it. A side effect of these practices is that role boundaries begin to blur. For example, as concept artists shift from handing off drawings to engaging in more collaborative daily conversations with level designers, both begin to learn each other’s role and vocabulary. The level designer won’t start drawing concept art and the concept artist will not start editing levels, but they learn more about each other’s goals and methods. They use this knowledge to modify their practices to better accommodate one another. For example, when working on a racing game that took place in Paris, the concept artist learned about the layout, landmarks, and visual style of Paris, while the level designer focused on what the vehicle was able to do. The two worked closely together to find intersecting areas (landmarks and street styles of Paris that worked well with the vehicle dynamics), and the result improved quality and reduced waste.

Summary

Artists face many challenges on game development teams. They are often at the mercy of uncertain technology and impossible schedules that end up forcing them to overproduce assets and compromise quality. As teams grow, these challenges will also grow.

As with the other disciplines, artists need to see themselves as game developers first and artists second. When they work on art teams in isolation, it creates communication barriers between the other disciplines. Players aren’t buying just art; they’re buying art that does something entertaining. This requires a cross-discipline approach to creating value, which is what Scrum promotes.

Additional Reading

Goldscheider, L. 1953. Michelangelo: Paintings, Sculpture, Architecture. London: Phaidon Press.