This is a summation of the discussion and progress I’ve reported so far, and will continue to do (until such time as my employment at Vigil ends… at the end of the month), on this Tech-Artists.org thread
First, some background. When I started at Vigil as an Environment Artist, the extent of Tech Art at the studio was a few tools that had been created for Darksiders I back in 2007. Few people at the company know MaxScript, or Python, and the Environment Art team had no one to go to if they thought of something that needed automation. If those people existed, their presence wasn’t well-publicized. In my first few weeks, I noticed myself hitting the same buttons hundreds of times to do the same things. I pinged h6x6n to give me a hand and automate one of these things, and in the process acted as an intermediary between him and Max to make sure the code worked. From there, the artists immediately around me started to request other automated macros. A few months later I was adding these scripts and others into our official toolset, had access to the code branch, and spent more and more time writing tools both in Python and Maxscript. The scope of the tools I was writing grew, the number of teams I was assisting grew, I started talking to programmers, helping producers generate reports on various pieces of data in the game. I was a tech artist. Familiar story, yes? It all goes down hill from there…
As the tool and tool support load started to let up for a couple weeks, it was dawned on me that in order for Tech Art to grow at Vigil, I had to find ways to move it from being “That one guy in the corner who knows Maxscript” to a more professional, scalabe, and accessible entity. To build up the Tech Art infrastructure here, I want to have the following in place:
– Transparency to Production
– Internal Code Libraries
– Track Tool Usage
– Robust End-User Documentation
– Robust Tech Art Documentation
– Training Resources
– Support Process
– Increase Artist Access to Tech Art for Feature Requests and Bug Reporting
– Be able to Deploy Alpha Toolset to Trusted Partners
– Scalable Tech Art Task Pool
Coincidentally, this all started dawning on me about the same time as the 2012 Tech Art Boot Camp talks got posted. Being in such a lonely position, I thought it’d be useful to expose the process of building up the Tech Art infrastructure at Vigil to TAO in order to take in feedback, advice, and pitfalls I’ll potentially run across.
The first task I really tackled was to get more tranparency to production in place. We have a company wiki, and that worked well to create a base for tech art, to create an umbrella area to contain all that information. There I host the end-user guides for our tools, a high-level goals page, resources for TAs, as well as a directory of Tool/Feature specs to get more granular on the details of those high-level goals. Each of those Tool Specs answers the following questions:
Strategic Questions
What is this tool/feature?
How will the target user interact with this tool/feature?
Why does this tool/feature need to exist?Tactical Questions
What are the subsystems and steps necessary to complete this tool/feature?
What are the reviewable phases of this tool/feature’s development?
Code Libraries
Once I had that in place, I set to the task of developing internal code libraries. This involved looking over a huge chunk of code from Vigil’s sister studio, Volition. The Tech Art department there is rather impressive, with tools that have gone through multiple game cycles. Being that I had no one to really discuss and guide me through the authoring process, I was grateful to have their code to learn from.
Debate was lively as to how to best implement these Maxscript libraries. Ultimately, each of these code libraries are stored as public methods of structs that are instantiated when Max boots up. This ensures the code is always available to any other script that needs those function, regardless of the file’s location in the 3ds Max 2012 directory, and each function only ever has to be updated in one spot.
Documentation
To the task of documentation, I hit an interesting wall. These libraries are, in a way, tools for Tech Artists. They need to be designed as tools for people to use. Approaching it like this, I saw a way to translate some important features of design to these libraries. I focused on a few things:
- Straight-forward Use -> Make sure they can only work one way. The right way. If someone passes in the wrong variable type, or it’s not in a format that your function will accept, throw an exception.
- Levels of Mastery -> Their workings should be readily available to a first-time user, and as a user becomes more familiar with the tool they can quickly make use of it with minimal reference to documentation.
- Creating Emergent Complexity Through Simple Verbs -> By writing functions with broad uses, instead of narrow ones, it opens up the possibility to combine functions in new and interesting ways to create tools that don’t exist, but are all built on the same base functions. For example, which of these two functions are more useful?
- This function selects all the nodes in the scene with a bounding box size greater than [256,256,256]
- This function returns the bounding box size of a node passed in as an argument
While Doxygen and Sphinx work great for Python, my first priority was to develop libraries for Maxscript. It follows, then, that this code needs to be well-documented. I found script on TAO that is able to take a docstring of a pre-defined format, and based on the docstring’s parent function and struct, creates an HTML document with a Table of Contents of all the .ms files it documents, with each .ms file showing its header, and all the docstrings for all the functions therein.
That’s all well and good, and it’s certainly part of the documentation pipeline I’m developing. One thing I’ve added to that, though, is to make that information accessible in Max. Each library has a .help() method, that prints the docstring. Right now, That’s just me copying and pasting the header of each file into a string inside a method. Down the line, the plan is to get the Maxscript Documenter to write the same content from the HTML file to an ini file that each .help() method reads and outputs the exact same data as is in the .html files. Same information, multiple avenues of access. Heck, I was using those .help() methods to write a new tool today because I couldn’t remember all the functions I had available to me.
On Maintaining Fluidity
As I was working out these libraries, a few of the possibilities that crossed my desk, and came up in discussion with production, had so many subsystems and components that they needed to be chunked out into their own separate tasks, with their own specs and information. This ended up being things like tracking usage, and source control integration in 3DS Max. Things that will certainly have functions stored in a library structure similar to the other code libraries I’ve written, as well as many subcomponents to better present and access their functionality.
I’ll continue to summarize progress as I move forward. Unfortunately, I have to do much of this work with the mindset that someone else will have to pick up the torch after me. The layoffs at Vigil resulted in my contract closing out at the end of April.