Asset Development Process
Continuing on with my chain of thought on tool-chains, we come to the process of developing an asset for a game. The process described and illustrated below is a fairly simplified model of how it would actually work, the simplification being in the number of revising points and the lack of a fail path in the overall design of things. It is assumed that some content can be discarded as being inappropriate for the current project, but any decent development studio will utilize some form of asset storage, thus allowing the developed IP to be stored and used at a later date.
I’ve drafted out a sample process flow for the development of a model to be used within a game, as seen below. The model could be a prefab, or an actual character within the game. Whatever the object in question is, it is typically drafted out by a concept artist; this process involves attempting to match the object in question to the theme of the world. The resulting concept art will have to pass its way through a lead artist’s hands and into a game designer’s hands for approval. After a few revisions it will meet the designer’s requirements and can move on to the next stage.
At this point it is up to a modeler to turn the concept art into an object that can be used in the game, typically a 3d model. Again the process involves a series of interactions between the modeler, the lead artist, and the game designer, in an attempt to ensure that the object fits within the game world. After several iterations the object in question will hopefully match up with the game designer’s vision of the game world, and it can move on. If the object can’t fit in, it will typically not be included in game, or used in a secondary role (although this isn’t strictly true, and there have been many games that have included assets that didn’t fit within the game world, nor within the mechanics of the game, very well).
Now we come to near the end of our sample processes, at this point we have a model which has passed through the hands of the game designer, and should fit within the overall theme of the game world. However, the game designer is rarely the final stage of approval, and it tends to be in the hands of a lead game designer to make decisions such as these. At this point, the lead game designer must decide if the object in question (a model in our sample) is appropriate, and ultimately can send it back for further revising, or can approve its inclusion.
The diagram though is a bit misleading however; as rarely does a model just jump straight into the game. Instead the model will be used within a level or set of levels, and thus the theme of the level comes into play here. Rejection of the model can happen by the level and lead level designers, as it may not fit properly within the theme of the level. This can thus result in further revisions, or discarding of the model entirely. It should also be noted that story and design changes (illustrated) can cause revisions to a model and even concept art.
Tools and our process
So how do we fit our tools into this process? Well, there are a few different ways we can fit tools into this process, both to help ease the process of developing assets, and to ease the process of revising assets. These can be tools we develop and maintain, or they could be premade tools that we have acquired.
Artists, in general, tend to favor Photoshop as one of the better art editors out there, although Corel also has a following. Art information will typically be stored in a format that is native to those editors. This will increase the artist’s ability to edit and modify the art in question, as was discussed previously. However, since purchasing licenses for these particular software packages can be quite expensive, it is not necessarily beneficial for everyone to have it. Therefore, at some point, you will probably want to convert the data to an easier format, such as PNG. These can be reviewed by a game designer, or a modeler, and even have changes made to them without the need for an expensive art package.
This is also true in the case of 3d modeling, packages like 3D Studio Max and Maya are both fairly expensive, and not everyone is going to need these tools, even though they might need access to the models built from these tools. Typically a game designer can get away with only having a model viewer, or the ability to drop the model into the game world and view it that way. Both methods have the advantage of allowing the designer to see if it fits within the overall theme of the world. Therefore some form of an export to a format understandable by the game, or an intermediate format that can be processed into a game understandable format, would be beneficial for the designer.
Then comes the revision and approval process, here we can benefit greatly from a set of tools capable of allowing the designers and artists to flag objects in various manners. For instance, a designer should be able to mark a model as requiring revision, and attach some notes (perhaps even pictures with markup showing the disputed areas) to the object. This should then end up automatically on the desk of the artist/lead artist in charge of that model. When revisions are completed, the artist should be able to mark it as requiring approval and it should automatically flow up the chain of command (to a lead artist, then game designer, then lead game designer in our diagram). An automated tool that allows IT or managers to build a workflow modeling this process would allow for changes and optimizations (or additional layers of approvals as needed, for instance an additional layer to the publisher might be required).
The process described above is not perfect, mind you. It needs quite a few more stages and other elements added to be completed. As mentioned above, art assets might prove to be a poor fit to the particular level they were designed for; hence they may require revising from there. Also, the animations of a model might not fit appropriately and that can also require feedback and changes before approval or even post-approval. QA also comes into play here, but we’ll leave that to another time.
Ideally one would be able to diagram out how the workflow operates and use that to not only build the tools, but to test and ensure that they operate in a smooth and easy to understand manner. Unfortunately, as with most things in enterprise development, workflows are still a work in progress and only recently have large advancements been made on that front. There’s also the question of optimizing your workflows, to ensure that things get done as quickly as possible. If you examine the diagram above, you may note that a lot work appears to be dumped on the lead artist and the game designer; however this is as it should be. This allows the lead game designer to focus on his role as a game architect, ensuring that the game will fit the vision and story. This assumes, of course, that there would be multiple designers and leads on a project, thus allowing this form of delegation to work.