The first big thing to consider is whether you are going to be implementing a dependency based build system, or one that “just builds everything”. Have you figured out which approach you’re going to take? In a dependency based system, a rig might be build because a model references it, because a level/world references the model, and because the world is referenced by some world editor DB file (or whatever). In the other approach, the build system just builds everything it sees whether it is referenced by something or not. There are advantages and disadvantages to both…
The system I’m working with now is a “just build everything” based system. There are rules for how certain directories in a directory tree are processed, but other than that, everything goes into the wood-chipper together. We end up with a dependency graph of what is used, by whom, etc, but this comes out at the end and doesn’t drive the system itself.
Another thing to figure out is where your asset metadata is going to live. If a model has a parameter “breakable”, or “mass”, or “trigger-object”, etc. where does this data live? It could exist as data within the model file itself (Max in your case), in a separate file “model_metadata.xml”, or in a DB. It sounds like you are favoring the DB approach. Again, there are ups and downs with each approach.
[ul]
[li]DB[/li]If you are storing your object metadata in a DB, how are you going to do “atomic” submits that keep the DB and revision control in sync? Say you want to rename a directory full of assets, you will need to rename them and queue that change up in your RCS package, then you need to rename the entries in the DB. How do you submit these changes together, and hopefully in such a way that you can revert this change should something go wrong? How do you submit 100 changes to the DB that corespond to the file rename operations without exposing this to others on the team mid-change?
[li]In File[/li]Since you’re adding metadata to the individual binary files (At least with Maya you have a .ma you can parse if need be), how are you going to batch process changes to those files? Let’s say you need to know which files are flagged as “breakable”, how do you come up with a list? Do you have to rely on the builder for this info? After a build has completed, and you have a list of files that need to be altered, how are you going to wrap Max so that it can grind through those 100 files to make the change? BTW, I have never had any art package remain “trustworthy” after opening more than a few dozen files. Having done this with both Max and Maya, you will need to have a system that either launches a new copy of the executable for each file processed, or which can in some way detect with things have “gone south” and allows you to pick up your batch process mid stream. Since you are working from a list generated by the last build, you may not catch all the cases where the parameter needs to be changed unless you’ve told the artists that the pool is closed.
[li]Separate File[/li]Hey, at least you can do a find in files with these, and determine how many “player_placeable” items there are (or whatever). How are you going to keep the data in these separate files in sync with what is in the asset (Max) file? Say you can mark a bone/joint in a rig as being an FX emitter. This data lives in the metadata file. What happens if an artist renames or removes that bone? What catches this, and conveys to the artist that this is their issue to fix? What will your file format be, and how will you edit it? Will you need to write an app that modifies them? (spoiler: you will) I would recommend using one of the standards for serialized data like this, but which one XML, JSON, Protobuf, INI. etc.? Each has varying degrees of favorability for specific tasks, and disadvantages in others. For example, INI files are easily human readable and grep-able, but their schema is flat and doesn’t extend or support complex data easily.
[/ul]
Anyway, there’s a couple things to think over…
