Systematic Gaming

July 16, 2009

Asset Management – Content

Filed under: asset management, workflow — Tags: , , — systematicgaming @ 6:14 am

We’ve already looked at the runtime and processing layers of asset management, now we’re ready to look at the most involved and complex layer – the content layer.

This is the layer where the content producers – artists, level designers, sound artists,  anyone who creates game content truly interfaces with the game engine. At this level we’re not just dealing with runtime data – we need to manage digital content creation (DCC) tool data, such as PhotoShop PSD files, Maya files, etc.  In addition to custom data types produced from in-house tools or game engines.

This layer is all about how content creators use and interact with data and the game engine.  The key components of this layer are:

  • Asset tracking and versioning
  • Tool integration and workflow

Tracking and Versioning

The central issue of asset management is not loading, processing or low-level data manipulation.  At its core asset management is all about identifying and tracking data.  We need to know where data comes from and what state it’s in.  This information is important for a number of reasons:

  • It lets us track project progress – if we know only 3 of 10 levels have been built we know we’re at most only 30% done
  • It lets us track bugs – if our licensed logo needs to be fixed because the TM is slightly off center we need to be able to find and fix all instances of that logo in our game
  • Proper tracking can be used to identify problem areas – why do we have two brick wall textures?
  • Tracking will identify how modifying an asset will affect the game – if you update the brick wall texture what levels are affected?

The bottom line is that asset tracking and versioning lets us know what data is in our game.  This may sound simple, but I’ve worked on projects where source data only existed on some artists desktop folder.  Data was put in the game simply by copying it to some network drive.

This creates huge problems when the artist leaves and their hard drive is formatted, or you try and port to a new system and can’t find the “c:\bobs_work\head.tga” file.  In a complete asset management system these situations shouldn’t be possible.  All game data would be properly tracked.

What do we mean by tracking data?  The idea isn’t really that different from managing code – any competent programming team is using source control and some form of bug tracking.  We just need to create a parallel for managing data.  The key features we want are:

  • Version control – there is a need to see who changed what, when it was changed and the reason for change.  We also have need to revert to older versions of data for testing and bug fixing purposes
  • Authoritative version – we need some way of identifying the “official”  version of our data
  • Asset tracking – we need to know the path data takes to get into the game (e.g. head.psd is exported to head.tga which builds the texture “head”)

Version control can be done a multitude of ways with the simplest being using an existing source control system, like Perforce or Subversion.  Some, such as AlienBrain are designed to work with source art data.  Some systems are faster than others, some cheaper than others, but as long as you can add/remove/update/restore versions of your data your set to go.

Authoritative versions of data require you have some means of identifying (or re-creating) the exact version of data you intend to build.  It is important to know exactly what data is on the DVD you’re creating.  There has been more than one game that shipped with inappropriate “placeholder” assets still on the disc – later discovered by curious gamers.  Any proper version control system will let you do this easily – usually through a  tagging or branching mechanism.

Asset tracking can be difficult to solve with technology – there’s so many possible paths for data.  At the very least you need to be able to clearly associate your runtime data with the source data that generated it.  Whether this is done by some tracking software or simply file convention and documentation (e.g. runtime asset name = source file name), it’s important that the relation is well understood by both the game engine team and the content producers.

Just like with programming you manage your source information, not your output.  Like in programming, proper asset management requires version control.  Version control lets us know exactly what data is being used in our game.  This can be very important if you have to change something like a licensed logo that needs to be fixed or removed. It also lets us ensure we’ve backed up our data properly.  Another common reason for controlling source data is for sequels and ports – for good or bad outsourcing such products is very common, having versioned and controlled access to source assets makes this a more efficient  process.

Tool Integration and Workflow

Tools and workflow are important areas of game development. Workflow is especially important – with today’s content heavy games you need to be able to add, adjust and improve content efficiently.  Asset management plays a large part in a smooth workflow.

Game content is often authored by different people using a variety of tools.  Each step in this process – called the pipeline – may require a separate specialized tool.  This series of tools results in what we call a tool chain – basically a set of tools that we need work with our data.

To meet our goals of tracking and versioning assets, we should be managing the assets as they pass through the entire development pipeline.  It’s clearly desirable that asset management be integrated closely with our entire tool chain.  Close integration will then allow us to track and version data at each and every stage of our pipeline.

Tool integration means our tools understand our underlying asset management system.  This may simply mean that a tool can load/edit/commit changes to our source control.  It can be expanded to include automatically build runtime data whenever we make changes to source assets.  This tightly-coupled integration between tools, pipeline and runtime provides an efficient workflow for content creators.

How we integrate with tools varies a lot from tool to tool.  In-house developed tools can be most easily integrated since we have complete control over them.  External tools – such as Maya and Photoshop – are a bit more difficult.  Some, like Maya, allow for extensive customization and have their own scripting environments.  With effort we can mold them to integrate with our asset management systems.  Some tools have only minor customization – via plugins – or none at all.  This means we have a less than seamless integration, any may require some manual step to import/export data.   Alternatively we may choose to develop an external management system, such as a custom GUI asset management program, a Windows Explorer extension or even a lowly set of batch files from which to manage our assets.

Ultimately we need to make the experience of managing assets simple, seamless and error free as possible.  Remember – the target audience of these tools aren’t usually programmers and generally won’t fully understand the end-to-end pipeline.  So we should try to automate as much as possible with out removing control when needed.  There will always be a balance between simplicity and control, you’ll have to find your own balance to meet your project’s needs.

Workflow is what people do on a day to day basis.  The key there is people.  Workflow is all about how people operate and work with our game engine and tools.  Where the pipeline is the path that data travels to get into our game, the workflow is the collection of processes people follow to create and manipulate our assets.  The distinction is important because we can implement every technical requirement I’ve mentioned: versioning, optimized data packing, runtime ready data, and still have a poor workflow.

Where asset management comes in is with a managed workflow – which ties the human process of content creation to the underlying asset management system.  The exact details of a managed workflow are very task specific – each type of content, each stage of a process may have very different requirments.  However, a few common high-level issues that asset management can improve are:

  • Locating – we have thousands of assets in our game, how do we find the one we need right now?
  • Sharing – content may pass through many hands and tools, how do we smoothly pass data between different people?
  • Validating – how do we know if our data is correct? Functional?  High quality?

Locating assets is actually a very large problem, difficult to locate data makes creating composite assets time consuming.  The simplest methods are simply searching by asset name – but this requires consistent and logical naming.  Creating a consistent and logical naming convention for assets is more difficult than it first sounds, and often leads to ugly names – e.g. dg043_bark.wav, hd_093_spec_03.tga.  Which may be perfectly logical – but not very easy to remember.

We should attempt to match the way we locate data with the way to use data.  This can be as simple as adding categories to each asset (tag-like metadata).  Perhaps it’s better to visually represent data if possible – a thumbnail gallery for textures is one possibility.  Even better still to allow both – categorized galleries.  The ultimate may be a context senstive editor that automatically displays appropriate assets – rock and tree textures when editing a forest level, bricks and rusty metal for your urban scenes.  However, the needs of your animator may be completely different.

Sharing assets is more and more important as teams grow and roles are specialized.  Once upon a time a single game artist may do it all – modeling, texturing, rigging and animation.  Now it likely that separate people – even separate teams – are resonsible for each of the above steps.  You need to optimize this workflow by providing an efficient way of passing assets through this pipeline.  Maybe just adding a “status” tag to each asset is enough, maybe you need to add some notification to the next person along the pipeline when a stage is completed.  Whatever you do you need to ensure that you manage these transitions when tracking your assets.

Validating assets involves testing the data in the actual game before releasing it to the wider team.  Each stage of a pipeline may need to be reviewed before passing along to the next.  In level design often a “level designer” will create a basic block level, pass it along to an artist to texture and polish, then pass it to a lighter who’ll add lighting to the scene.  At each stage we may need an art director or gameplay lead to review the work before passing along to the next person in the pipeline.  Asset management needs to accomidate these reviews, and similar to the sharing, allow the status of assets to be know.


The highest level of asset management you’ll notice there aren’t as many clear answers or technical solutions to the issues.  This is because content creation – where we design and compose our assets – is not about implementing technolgy to solve our problems.  Its about finding creative people and helping them create assets.

Hopefully you can now see how asset management is involved with every stage of the data pipeline and how we can improve our workflow and game engines by leveraging proper asset management.

       Vector3 position;
       Vector3 rotation;
       Vector3 scale;

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Create a free website or blog at

%d bloggers like this: