Document your Workflow & Pipeline Changes
This is an area that I think often gets neglected… I am willing to admit that I neglect it when push comes to shove!!
We are currently reworking BLUR, and that requires two major steps. Firstly, reworking all the old Art into the new engine. Secondly, creating new Art for the next release. Both these steps require a complete understanding of where we came from… why we did what we did 8 months ago, etc! This is where keeping documentation regarding specific pipeline choices becomes highly important, and useful when that information is easily available.
For example, why were we using 2×1 textures for the car bodys instead of a standard square map??? Check your documentation…. Aaaah, simply to save on file size because this is a downloadable game!!
But these could go as far as, why are we using one form of collision instead of another?!
So I since we are right at the beginning of setting up our new systems and pipelines, I am documenting every move we/I make with my own personal wiki! I found this nice little standalone free app called Notebook Wiki. Its nothing like a real wiki, and acts as a subtly more advanced version of Notepad, but with wiki page linking features. It allows, page renaming (and corrects page linking) bold, italics, bullet lists, etc.
A nice little touch is that it can export to .html pages which is great if you want to be able to share the wiki eventually with some others on the team, but removing the editability of it. The .html pages are not kept up-to-date automatically, only when you re-export them.
I have began documenting every feature, art handling, or change we make from, texture resolution standards, vert counts, shader techniques & setups, world item specs, vehicle specs, node structures, to even how different mesh types handle specific shader setups. I have even began keeping a listing of tests that I have gone thru, the results of which often are cause for a pipeline choice and the detailing’ behind MaxTools we have been writing!!
It may take some time out of your day, and or break your workflow at the time (like if you’re in the Zone) but you will be amazed at how valuable this sort of information will be when you look back on the project (post mortems) or get asked to rework it or create new content.


Leave a Reply