Chapter 13
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 explores the benefits, concerns, and common practices of artists on cross-discipline Agile teams. This chapter covers principles and practices that apply to many artistic disciplines including modeling, texturing, animation, audio, and so on. It refers to the members of every discipline as artists.
The Solutions in This Chapter
An artist once asked, “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.”
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 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. This chapter focuses on their solutions:
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. After they discover this, they can schedule the creation of 10 to 12 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 10, “Video Game Project Management”).
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 21, “Scaling Agile Game 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.
The Artists Decide to Join
When High Moon Studios started experimenting with Scrum, our artists were very skeptical of it. Some thought it was a “management fad” or a covert form of micromanagement. They wanted no part of it, and we didn’t force it on them.
The programmers decided to try it and formed teams. Their Daily Scrums quickly identified impediments that impacted their progress. Many of these addressed the lack of proper assets to work with. The producers, recruited to be the Scrum Masters, spent much of their time pestering the artists to produce the assets the teams demanded.
After the artists saw the producers focusing their effort on solving Scrum-raised impediments, they wanted to start using Scrum, too.
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. 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, she 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.
Experience
In the mid-nineties, many 3D games were a mix of 2D and 3D. One (canceled) game I was working on at Angel Studios took place outdoors. In these outdoor levels, there were trees in the distance that, because of the limited rendering budgets, were tree pictures on billboards (2D cards that always rotate to face the player). One artist made beautiful tree billboards, but he was very slow in making them. This went on for a few months until the lead artist visited him and discovered that he was creating a full three-dimensional tree on the PC modeling tool, taking a picture of it, and using the picture for the billboard! That practice was changed.
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, artists elevate the value of what they create and minimize 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.
95-Mile-Per-Hour Art
Game art has a function and a form. Its purpose guides its creation. Its function is less apparent when artists are separated from the game. During the development of Midnight Club, a city racing game, a group of artists created assets for the streets in a separate room. We were looking forward to seeing their work because we had a city filled with gray cubes. The day finally arrived when the new geometry was placed in the city. It was stunning. The city was truly coming to life. We started driving around and discovered a major problem. Much of the new detailed geometry was at the street level. The actual city we were modeling had a lot of this detail itself, but it was a terrible problem for a racing game. A staircase jutting out from a building could instantly stop a car using the sidewalk. Low planters became uncrossable barriers. Fun transformed into frustration.
Much of this detail had to be removed to eliminate the barriers at street level. From then on, the mantra repeated daily was “Create 95-mile-per-hour art.” The art had to look good and function well for players in cars traveling past it at 95 miles per hour. This art can be considerably different from art that looks good standing still in Maya!
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? Is it 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.
Target testing: Does the art look good on all the target phones? Is it too dark for people playing in a well-lit environment?
Artists need to have access to all the target platforms to test their work. Sometimes, equipping every person on the team with platform development kits is too expensive. 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 percent 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 because 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 (See Chapter 10).
Building a finished level before a vocabulary of mechanics is established is wasteful. This waste is seen on many milestone-driven projects. Teams often 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.
Tip
Often level designers create a set of basic level shapes they refer to as LEGO′ bricks that allow them to “snap together” a large level very quickly. These levels give a sense of scale for production levels that take many times more effort to create.
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 its 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 because they didn’t have enough time to properly pre-light 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.
Experience
Be careful of using reference assets. Because they look good, they are often forgotten until there is a problem, such as the time an artist pasted in the eyeball of a character with a photo that was a megabyte in size! Another time, on Midtown Madness 2, an artist textured a garbage can with a picture from a real garbage can. The company whose logo was on that can successfully sued for its illegal use!
Budgets
One of the most frustrating things for artists 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 percent 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).
Murderous Artists
When optimization and target integration are late, artists are often the ones to suffer the most.
When we were preparing Midnight Club for shipping, we discovered very late that the PlayStation’s ability to stream textures into memory wasn’t as fast as advertised. As a result, we had to fit all of our cities’ textures into memory, which reduced our texture budget by 50 percent. The artists were very unhappy with this news and struggled to minimize texture use where possible, but it was a tough choice for them, and they didn’t hit their target soon enough for our technical lead, so he re-exported all the city textures to one quarter of their original size (the engine at the time required square textures) to make them fit. What was worse was he didn’t tell anyone he did it. None of the artists saw the result until they received their retail copies months later.
The artists were so furious with the quality of the textures they saw in the game, I became concerned for the technical lead’s safety. I wouldn’t have been surprised to find him beaten to death with a Wacom tablet in the parking lot.
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 10), 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.
Shifting to Kanban
Chapter 10 described the challenge of moving into content production using Sprints. When the less predictable swarm of exploratory work shifts to a more predictable flow of mass-producing assets, then time-boxed Sprints become less useful. Teams should recognize the following symptoms as triggers to shift to Kanban:
Content completion does not fit cleanly into a Sprint.
Sprint planning is less useful because the workflow has been established for one or more asset types in previous Sprints.
Daily emergence of tasks shifts to a repeated hand-off of work in an established flow.
When ready, a team can quickly shift to Kanban practices as described in Chapter 6, “Kanban.”
What Good Looks Like
In Chapter 10, 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.
Experience
When I started creating tools for artists and designers, my understanding of the complete process of creating games grew by a magnitude. It altered my approach to how I developed code and later led teams. A wider view of other disciplines benefits every role and is a natural advantage of cross-discipline teams.
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
Austin, R.D., and L. Devin. 2003. Artful Making: What Managers Need to Know About How Artists Work.
Catmull, E.E., and A. Wallace. 2014. Creativity, Inc.: Overcoming the unseen forces that stand in the way of true inspiration. New York: Random House.
Goldscheider, L. 1953. Michelangelo: Paintings, Sculpture, Architecture. London: Phaidon Press.