Many modern video games are built with hundreds of thousands of different kinds of assets. Volition has written a system that uses Perforce attributes to organize and manipulate these assets. Attributes are used for many different functions, including categorization, dependency graphs and source-to-target asset conversion information. This session will focus on how Volition decided to use Perforce attributes and how it dealt with many of the hidden complexities such as branching, resolving, and performance.

1. Using Perforce Attributes
for Managing Video
Game Asset Metadata
Mark Allender
Studio Technical Director
Volition / THQ

2. Outline
• Disclaimer
• History
• Usage
• Problems faced and solutions
• How attributes are used
• Q & A

3. Disclaimer
Attributes are undocumented. Others wishing to
investigate attribute usage further should use Volition’s
experience as a guide. Perforce Support should be
always be consulted as undocumented features can be
subject to change.

4. History
• Managing asset growth
• 1800 assets in 1994 to over 1M assets today
• Past management techniques
• filename conventions
• directory structure
• ‘inf’ files (meta data stored in additional files
alongside asset)
• Push to use database for metadata storage.
• SQL
• Perforce

5. Brief Tangent
Metadata usage:
• Categorization
• Asset properties (i.e. material counts on meshes,
number of verts/faces on meshes)
• “Crunch” parameters (i.e. texture compression
settings, level of detail compression settings, etc)
• Dependency information
• Breadcrumb trail to source assets (i.e. 3DS Max or
Photoshop files)
• Outsourcing approval pipeline support

6. History (cont.)
• SQL implementation issues
• Database schema grew complicated
• Difficulty with edge case problems keeping Perforce
and database in sync
• Supporting outsourcing was a worry
• Moved to use of Perforce attributes in early 2009

7. Usage
• Two main commands:
• ‘p4 attribute’ – sets/clears attribute data
• ‘p4 fstat -Oa’ – retrieves attribute data
• Attributes stored in db.traits
• Stored randomly on disk
• Attribute changes count as file content change on
submission for purposes of ‘revert unchanged’

8. Problems and Solutions
• Searching too limited for our needs
• Use of -A, -T, and -F flags on fstat not useful for our
needs
• Cache attribute information on local machines
• Use SQLite database on all users machines for
caching attribute data
• Cache built from ‘p4 have’ data
• Cache updated when data changes on disk
• #have files are updated
• ‘opened’ files are updated
• files that change read/write status on disk are
updated
• Complex queries only needed from within GUI

9. Problems and Solutions (cont.)
• No way to resolve attribute conflicts
• Solution had to work without user intervention if
possible
• Needed to “do the right thing”
• Trigger written to do all work automatically
• change-submit was only trigger type that
worked reliably. Forces resubmission
• See white paper for details of trigger

10. Q&A
Questions?