Centralised Asset Management
It was quickly realised that the development of Fable Legends would bring with it the requirement of much higher levels of detail and result in far higher disk space requirements. We also needed a quick way to traverse, search and organise our data.
We also wanted complete traceability between assets and so we chose to utilise an MSSQL Server to store all the asset locators, metadata and dependency information. The final result was an Asset Manager which allowed users to query and traverse assets regardless of whether they existed on the users machine or not. Equally, the user never had to sync to source assets directly - instead all dependencies of an asset would be sync'ed on the fly as they were needed.
All Assets are managed through an SQL database which is updated whenever a user submits new versions of their work. The database tracks any dependent files such as referenced rigs and geometries for animated scenes as well as textures for geometries. Having all content tracked through the database means users can quickly search using a partial name, path or username without having to navigate through large folder structures.
By managing all the import/export process this system allows the user to spend more time in the creation process and less time handling asset management manually (including exporting and validation). It also ensures all content is handled in a consistent way allowing for reliable batch processing.
To ensure consistency between source control and the database a perforce trigger was utilised, which would fire an RPC call to a server whenever a check-in of tracked file types were submitted. It was then the responsibility of this server to parse the asset and update the database accordingly - using asset processors (typically ascii parsers that would parse the asset directly, or metadata relating to the asset). This meant that whilst we always want the user to submit via our pipeline tools, if for any reason submissions were required outside it, the system would still pick up the changes.
The codebase for this system was built using Python (using PyMel for Maya specific tasks), with SQL being handled through a wrapper class surrounding pyodbc. All the user interface was built using PyQt/PySide, with the main browser being driven by a QAbstractItemModel.
The Asset System described in the previous slides was developed originally by myself at the very start of Fable Legends, working closely with James Vale (a Senior Artist) to ensure usability - this was also a point in time when we switched from Softimage to Maya. As R&D for Legends merged into pre-production the TA team grew to three people and from there we all had a heavy hand in steering, evolving and refining the pipeline. This process, as ever, continued after I left the TA team, allowing (the awesome) Andy Cousins to take the reigns and drive its roadmap.
This system worked reliably and was eventually (after I left the Tech Art team) merged with the game asset database to create complete traceability from source to engine. Much of the responsibility of the RPC Server was also later incorporated into a Teamcity Runner too - which gave far better tracking and system validation - but i cannot take the credit for that awesome improvement (Louise Malinowski)!
In hindsight a more thorough approach would have been to expose a feature rich REST API to the database and query logic to allow more applications and languages to interface with the database consistently - as well as create an extra layer of security between users and the server.
Starting a new project on a new DCC at a time with a single TA certainly shows - as the foundation of this was developed at the same time as Ark, to ensure we could get the content creation teams moving as soon as they began to ramp up. Therefore it is unsuprising that some of the code ended up being a little worse-for-wear. Lesson to take away - slow down, test, document, test and test and document a bit more.