Yeah.
A couple of weeks ago I made a joke about just using Maya as our level editor that and rather than laughing at it, everyone else thought it was a good idea. So when CP was assigned to build a way to read the levels from .fbx files, I had Charlie assign me to help him out with the 'art' side of things.
Now we already knew that we basically wanted the levels to be just a bunch of locators with names that described what they did (spawn points) with the possibility of large objects that wouldn't be rendered and whose bounding spheres we would use as sort of event triggers. Everything else would probably be done in code. Functional, but something of a pain to work with. I had another idea that actually worked out great after a little bit of research.
Maya allows users to create and assign custom attributes to objects which is incredibly useful for rigging purposes. With a bit of help from CP and Google, we figured out how to read the custom attributes of each locator into XNA. This meant that instead of either hardcoding most of the level or having really complex names on each locator we could simply specify a few different types of locators (spawn_fighters, spawn_player, etc.) and a set of standardized attributes per type. But that's annoying to do by hand and leaves the possibility of typos and a bunch of other problems that would take a minute or two to fix. So I wrote a series of MEL scripts that would create the locators with the correct names and custom attributes.
At that point we had a functioning level editor. The only issue was that there was no way to tell what any given locator was supposed to do except by selecting it and looking at the name/attributes, which made it really hard to tell what was going on in the level while editing it. So I modified my scripts to also create various platonic solids alongside the locators and constrain their XYZ coordinates to those of the locators. I also created two more scripts, one which creates a series of shaders and another which iterates through all the locators in the scene, checks their attributes, and reassigns the shader on the attached polygon accordingly. (I would have create a custom node type and just linked the color of each polygon to appropriate attribute and thus automated the color updates, but from what I understand I need admin access to do that.)
Now not only did the editor work, but the person creating the level could tell at a glance what was going on in the level. Still not good enough, though, because you had to select the locators to modify their custom attributes and move things around and the polygons, being actual 3D objects rather than single pixel lines creating a 3D cross, tended to get in the way of selecting the locators. To fix that problem I wound up adding the attributes to the polygons, flipping the direction of the point constraints, and linking the attributes of the locators to the polygons. I also hid the attributes on the locators so that people couldn't modify them by accident without modifying the ones on the polygons, although I'm not sure if that would actually matter or if the attribute would just immediately revert.
Now all I need (okay, WANT) to do is finish up a script that cleans up the scene to prepare it for export. And add floating names over each object to make it even easier to see whats going on. One of those two is almost certainly never going to happen.
No comments:
Post a Comment