Handling Asset Data in Large Projects

As animators, we work with a large amount of data and a multitude of assets. Therefore it is essential that the asset data is handled correctly and organized well in large group projects. In this blog I will look at how I have handled this issue in the Rapid Reboot and Zurvivor projects, and how these methods can be improved for future projects.

Reboot Project

In the Rapid Reboot project we predominantly used Google Drive with communication over Slack. I initially set up this drive and created several different folders to help separate data.

CaptureI find that this keeps everything neatly organized and helps when trying to find particular assets. Additionally, Luke established a naming convention that was successfully utilized throughout the project.

The naming convention was as follows:

Name_Asset_Detail

Examples:

02This helped us to easily see what had been done and who had done what.

Although the handling of asset data was relatively successful, there are several improvements that could have been made:

1.       A detailed asset list.

Our project lacked any sort of asset list. We just kind of told each other what was needed. This was a very unorganised way to create assets. To rectify this we could have had a detailed asset list which outlined the required assets and who was creating said assets. The list should also include a progress tracker and update box. This would have allowed the team members to mark their progress off (e.g. “Unstarted”, “Draft Done”, “Final Done”) and allows managers to easily see where everyone is up to. An update box would allow team members others that a completed asset had been changed or modified (e.g. “Updated: Version 3”).

2.       Version numbers.

This relates to the above mentioned update box. A version number should be incorporated into the naming convention in order to allow team members to easily see which the most recent version of a particular asset is:

Name_Asset_Detail_V01

This will also allow for roll back. For example, if Version 4 breaks and is completely unusable, the team can simply use Version 3 which works perfectly but is not as polished. This helps prevent a loss of data as early versions are always accessible.

Zurvivor

How we handled asset data in Zurvivor is very similar to the Rapid Reboot project. We use a well organized Google Drive and a naming convention. However, at the start of the project, Rowan created a detailed asset list:

04This was extremely helpful to the animators as it clearly showed what the asset was meant to be and what type of asset it is. From here I moved this information to an “Asset List and Delegation” sheet. Using what I had learned in the Reboot project, I added a progress marker, delegation section and update section.

03This has noticeably improved the workflow and has allowed Ben, Hamish and me to work quickly to finish assets.

Again, we haven’t yet incorporate version numbers. As these assets are for a game, they are either “Placeholder”, “First Pass”, “Second Pass”, and so on. So far this has been a sufficient replacement for version numbers. However, for larger, longer running projects I will definitely be utilizing a version system.

To the Future

For future projects I will using:

  • Organized Google Drive
  • Detailed asset list
  • Progress marker and update box
  • Naming convention
  • Version numbers

These should allow for productive and efficient workflow.

Advertisements

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s