Sorry if this has been asked before...I did a search and didn't find anything, although maybe my search efforts are just not going well today. Feel free to point me to any threads where this topic was discussed in detail.
The concept of creating libraries of small reusable components for game assets has been around for years. Presumably these little bits/widgets get used as part of high poly models, although certainly they could be used for low poly elements as well.
Does anyone have feedback on how well this approach has worked, for AAA style games they worked on? Was it a kick-ass time saver, helping maintain a consistent high quality look? Was it a waste of time, with small pointless libraries being ignored by most of the artists who created assets? Difficult to implement? Easy to implement? Helpful (or not) when shared with Outsource Vendors? Any other thoughts about the approach?
My own experience - although this topic has come up for discussion on several AAA games I've worked on, for some reason none of the projects actually implemented a robust approach for it. I started a widget library once or twice on projects, but the idea never caught on with the team to the extent that it became super useful....usually I just used the library for assets I personally worked on.
Replies
Here's some obstacles you have to overcome / features you need:
* solid search ability and tagging!
* for outsourcers: Vietnamese, Chinese, whatever translation of those tags (use Google??)
* a good browser
* ability to run the browser inside your DCC app and directly insert meshes into the DCC app (web browsers that require a dozen clicks to get a single file into Max or Maya suck).
nice to have:
* bookmark cool meshes for the future
* share meshes with rest of the team (e.g via that bookmark)
* metadata: polycount, file format (maybe less an issue for high poly stuff)
* (c) info: can it be re-used across multiple projects, or is it generic enough to ignore (c) issues?
other:
* issue: how will you create thumbnails? batch? manual? how to deal with different formats, such as MAX, ZTL, Mudbox?
* issue: allow users to add their own content? Who screens it for quality?
* issue: who will maintain the data, i.e. assets, tags, metadata in the system?
* issue: who will maintain your browser front-end?
* issue: who will maintain the infrastructure? (and share it with outsourcer)
Make sure you have people ready to maintain it before you implement it. Often such libraries fall apart at this stage. e.g. the amount of assets is low. Or they are badly tagged and cannot be searched, or it's cumbersome to get them. Nobody feels responsible for maintaining and advertising the system.
Other issues: perfectionism! many generic assets are not exactly what you're looking for as artists, because they are generic. If your artists have a mindset of "not perfect, but gets the job done satisfactory" then they can work with such a library. Otherwise they'll rather do it from scratch to have the asset perfect (no matter if the client/art director cares or not).
Final issue: you need to find a balance. If your assets are too generic, you'll end up with exactly 1 asset of each category, e.g. 1 set of screws, 1 set of door knob, etc. and artists will not use them because there's no variety. Add too much variety and assets become too "custom" - i.e. they stand out so much, that they're not generic and that the audience will recognize the re-use (although on project or level specific assets this could be intended).