Where'd It Go? It Was Just Here!
Managing Assets for the
Next Age of Real-Time Strategy Games
Beyond Asset Management
In addition to the texture browser and game viewport, we added a number of other features beyond basic asset management. One of the simplest and most useful features was the versioning of Max plug-ins. File information is stored on the server about the current versions of Max plug-ins, including the asset manager itself. If a plug-in is out of date, the user is notified upon starting up Max. This has helped in many situations where the user has accidentally installed an older plug-in when reinstalling a workstation. Additional functionality was added to allow the asset manager to update itself automatically when new versions are posted internally. This has eliminated the need for the user to worry about keeping track of the latest version and its location. All users need to do to get the latest version is to restart Max.
The three-node workflow system helped us understand the state of game assets more clearly (Figure 7). New assets are marked "not ready for game." When an asset is ready to be exported to the game, it becomes "ready for game," and then finally "final." An asset can stay in any node as long as is necessary.
![]() |
![]() |
![]() | ||
![]() | ||||
![]() |
Figure 7. A simple three-node workflow system with branching. |
One of the benefits of using SQL Server directly was that we could create stored procedures to enhance asset workflow. One example of this is a configurable notification system that automatically e-mails the game designer using MAPI (Messaging Application Programming Interface) the first time a game asset becomes ready for the game. This takes the burden off the creator of the asset of having to remember to send a separate e-mail, and ensures that the designer is kept aware of when assets become available.
There is also a branching system so that an asset that is either "ready for game" or "completed" can be branched to the next lower node. This allows the artist or designer to leave the last version that they know is good enough for the game to continue to be exported, while allowing them to go back and potentially make major revisions. Once the user is ready for the latest version of the asset to be exported again, the asset is unbranched (Figure 8).
Asset types were added to allow the teams to classify new assets added to the system. Some of these asset types, such as "Mesh (in game)" or "Texture (in game)" are backed by code in the asset manager that performs special functions. In these two cases, in-game versions of the assets are created and checked in whenever the original assets themselves are checked in.
![]() |
![]() |
![]() | ||
![]() | ||||
![]() |
Figure 7. Example of unbranched (left) and branched. |
Future Work
While our asset management system has solved a number of problems that we have experienced in managing game assets in the past, several areas still need additional work. The hardest area that we have yet to address is the issue of the "build machine" -- the versioning of the tools themselves. We've already run into this problem once in creating a patch for one of our previous games almost a year after it shipped. The original game was compiled using Microsoft Visual C++ 5. Our current compiler is Visual C++ 6 with Service Pack 3.
Getting the game to finally compile correctly with the latest version of the compiler took several days. While the new compiler certainly improved the code quality and allowed us to find some problems that the old compiler had missed, we don't know what additional problems the new compiler might have introduced.
It seems that the only way to fully version-off the tools that were used to create the game is to set a workstation in the corner that contains the tools and the shipping version of the source code. Any other solution that involves storing the program install disks away and having to reinstall old software probably will not be utilized.
One of the other problems to solve is being able to regenerate all the in-game versions of assets from the original versions stored in the asset manager. Although we try to make sure that we never break existing game assets, there usually comes a time (sometimes more than once, unfortunately) where all of the art, sound, or levels for the game need to be reprocessed. With the original data, and the information on how it was exported for the game stored in the asset manager, it's possible to write a batch system that can perform this reconversion. One of our next goals is to actually implement this using the Max DCOM sample code to create our own batch system to reprocess assets as necessary.
Summary
In the end, it would have been easier if there were an off-the-shelf asset management solution that met our needs right out of the box. Those asset management systems directed towards game and content creation all seem competent in delivering basic asset management functionality, but they are sorely lacking in the areas of front-end and third-party integration and workflow.
For us, developing an asset management system completely in-house was well worth the effort. We ended up with a system that met our needs, and because we fully understand the design and architecture, we can continue to add functionality as needs arise.
The total staffing time was about eight full-time man-weeks of programming, and three part-time weeks of testing. The programming time did run over by a couple of weeks, but this was mainly due to adding new features during development. It should also be noted that the programming time would have taken significantly longer if we hadn't already had back-end server design and implementation experience in-house.
Overall, the biggest problems revolved around our inability to modify and integrate with the Max user interface system more simply. The whole Max user interface needs to be based on MaxScript, and MaxScript itself needs to be much more powerful in order to do what we need to do. An even better solution would be if Max provided a specified asset management interface similar to Microsoft's Visual C++, thereby allowing third parties to create asset management solutions for it.
Acknowledgements
Creating an effective and useful asset management system was a team effort. Thanks to everyone involved throughout the process for remembering those little details. Thanks also to everyone at Ensemble Studios for reviewing this article.
For More
Information:
MSDN
Felder, Ken. "Microsoft Visual SourceSafe OLE Automation." Microsoft Developer Network. Microsoft Corp., October 1995.
http://msdn.microsoft.com/library/techart/msdn_vssole.htm
Web
Sites
Bulldog
Two.Six
http://www.bulldog.com/
Discreet 3D
Studio Max
http://www.discreet.com/
eMotion
Cinebase3
http://www.emotion.com/
Filemaker
Pro
http://www.filemaker.com/
Lead
Tools
http://www.leadtools.com/
Microsoft
SQL Server
www.microsoft.com/sqlserver
Microsoft
Visual SourceSafe 6
http://msdn.microsoft.com/
Oracle
http://www.oracle.com/
Sybase
http://www.sybase.com/
Merant
PVCS
http://www.pvcs.com/
NxN
Alienbrain
http://www.alienbrain.com/
Discuss this article in Gamasutra's discussion forum