Techartist Working Methodology
During my time in the University of Utah's game design master program, I found that a lot of issues arose when engineers tried to integrate techartists' works into the games. Misusing the VFXs, wrong settings of the initialization, and complex configuration of VFXs and state machines often caused bad results for the product and redundant, time-consuming back-and-forth communications. Therefore, I came up with a working methodology aimed at solving those issues.
Think like an SDK engineer
With an SDK engineer background, I think like an SDK engineer when I am working on my techart works. I consider each of my works as a tool, and the gameplay engineer is the user of my tool. When I make my works, I want to get full control of them, including how the animations look, and how the variables of particle systems and materials are given. On the other hand, I will also consider every possible use case of my work. In this way, I can satisfy the needs of the gameplay engineer without letting any unexpected result happen.
In the following, I will use one of the works I did for Project Evree as an example to celebrate how I execute my working methodology.
Steps
1. Create needed animations and VFXs
I start by creating the needed animations and VFXs. In this case, they are the translations of different components on the control panle and the particle effect of the wave function.
2. Expose the needed variables and create state machines for animations
Then, I will consider what needs to be controlled and changed during the runtime of the game for the VFXs, and to create animation state machines for the animations. Usually, the techartists will stop at this step and hand over their work pieces to the engineer.
Then, I will consider what needs to be controlled and changed during the runtime of the game for the VFXs, and to create animation state machines for the animations. Usually, the techartists will stop at this step and hand over their work pieces to the engineer.
3. Create an interface to control all my workpieces
However, I will continue to write an interface to control all the animations and VFXs I mentioned in above.
However, I will continue to write an interface to control all the animations and VFXs I mentioned in above.
The APIs created for the engineers to call.
By doing so, I only allow the engineers to call the APIs I created for them, while I do all the details of actually controlling the animation state machines and VFXs by myself.
In the APIs, I do all the dirty works for the engineers, as I am the person who know how to use my work pieces the most.
4. Create a sample scene and sample code
Finally, I will create a sample scene and sample code for the engineers to understand how to call the APIs and what will be the result.
Finally, I will create a sample scene and sample code for the engineers to understand how to call the APIs and what will be the result.
With a sample code, the engineers can easily understand how to use the APIs.
Result
In this way, the engineer can use my work pieces without too much redundant back-and-forth communication and minimize the possibility of unexpected results. As shown below, everything was perfectly packed, will not be broken, and is easy to use.