Guide to Tool Development
Guide to Tool Development for Games
As a technical artist, my main responsibility is to act as the bridge between the artists and the technical hurdles they may face in the art pipeline. This is so that they can turn their attention to the creative aspect as much as possible.
One way I do this is by developing tools.
Definition
In this article, tool development refers to tools or plugins that can be used to basically speed up the art pipeline. However, what I will discuss here could potentially be applied to design and engineering tools as well.
Step 1: Identifying the Need
Identifying the need is a crucial first step in any tool development. Without a need, there is no real reason to spend your time on developing an unnecessary tool — time that could be spent on improving the processes of your current pipeline.
The easiest way to spot needs is by looking at repetitive tasks in your pipeline. This refers to tasks that are repeated quite frequently. From there you can try and see how you could streamline that process, usually simply by automating it.
Another way of identifying needs is simply by asking around. Ask your artists what are some of the more frustrating aspects of the pipeline. You are essentially having them point out the need for you.
In Mighty Bear Games, I don’t just do tool development. I move around a lot in the pipeline and my role in the studio extends to more than just writing tools.
This is very helpful for me because by being more active in the art pipeline, it puts me in a position to better spot out potential needs since I too am a potential user of my own tools.
Tip: If you are new to a team and want to wow your colleagues, one of the first things to develop a tool for should be to address the processes that no one wants to do or that everyone hates doing. You’ll notice a considerable increase in morale among those who had to deal with it. Trust me on this.
Step 2: Getting Feedback
After creating this tool, pass it to the intended user and ask for feedback. The tool needs to be authored for them so ask for suggestions regarding future improvements. They are your users after all and the tool should be authored primarily for their experience.
Ask for as much detail as you can during your feedback session. If you had to guess what they like or dislike, usually that’ll result in a lot of back and forth between you and the users later on, more than you would have if you didn’t have to guess.
Tip: It is very good to start the feedback process as you are developing the tool. Involving the user in the development process ensures that you are both on the same page of what this tool is and what it needs to do.
Step 3: Future Proofing
I tend to develop my tools to solve the needs at the time. This is because I still have other tasks to attend and will need to manage my time between tool development and those tasks.
However, if I have extra time left or if I have time to revisit the tools in the future, I will shift my focus to future proofing it.
When I say future proof, I’m referring to expanding the tool to be used in a more general situation. You may have developed your tool to be used under very specific context because that is what is needed at the time. Now is the time to expand so that it can be used, ideally, in any context.
You should also use this time to look for other things that could improve the user experience of the tool.
Example 1: Screenshot Tool
Identifying the Need
An example is a screenshot tool we had to make for our marketing assets. This also needs to account for the different dimensions depending on the device viewing it.
The need then becomes: “Create a tool that can take screenshots in multiple resolutions”
So I got to work and created a tool that can capture screenshots in the specified resolutions. At the time we only had to support 5 different resolutions. Pretty straightforward and easy to do.
Getting Feedback
At a later point I received feedback it would greatly help if the tool supports localisation. The tool then only supported one language, whichever language was set during that particular playthrough.
This means that localising the screenshots for different languages requires manually changing the text in Photoshop or having to switch to a different language in the settings and then playing through the game again.
At the time of writing this article, we have 18 languages and 5 different resolutions to support. As a result, we would need 90 different image files across the different resolutions and languages per screenshot.
This greatly changes the scope of the original objective and requires more work to support it based on this feedback.
Future Proofing
After supporting the different languages, I still had some time left over. So I expanded the functionality of the tool further and improved the user experience.
This ranges from allowing users to define how the files are named to which key is used to take the screenshots.
Example 2: Auto Renderer
Another example of a tool I developed is an auto rendering tool. In our game, Butter Royale, we have thumbnails for various skins in the Customization menu. These are all pre-rendered images that are rendered in Blender.
Previously, the artist(s) would have to:
- Pose the skins
- Hit “Render”
- Attend to other tasks while waiting for the render to be done, constantly checking so that they can repeat the process for the next skin
Identifying the Need
Seeing how we have well over 50 skins, this can become a long and tedious process. It is not difficult to set up, but it can get quite dull due to the repetitive nature of this process. They could also get too engrossed in attending to their other tasks that they forget to check back in on the rendering, losing precious time to set up and render the next character.
This makes the need of this tool clear: “The tool needs to be able to setup and render multiple skins automatically”.
So I got to creating the tool and made a huge improvement to the rendering process.
Now all they need to do is:
- Select all the characters they want to render
- Run the tool
- Come back in an hour or two to 10+ rendered thumbnails
This “fire-and-forget” solution minimises their effort in the rendering process and allows them to be more active on other tasks. In addition, removing the need to manually setup the render greatly cuts down the time for the process as a whole as well.
Getting Feedback
In this instance, however, the artists are happy with how the tool worked already and didn’t quite have any feedback that I could work on.
If that is the case, then it’s the tool developer’s job to try and see what else could be further improved and sure enough, there are things that could be further worked on to enhance the user experience.
Tip: When your user is satisfied with the tool as is, it’s not really necessary to continue working on it. It might not be worth your time to keep polishing it, especially when there are probably other tools and processes in the pipeline you could be working on. So this is something that should be considered on a case by case basis.
Conclusion
So to wrap things up, when developing tools we need to:
Identify the need
Get feedback
Future proof and/or expand your tools functionality
If you find this article useful, please leave some claps! Do also follow me for upcoming articles where I’ll dive more into the world of technical art!
Guide to Tool Development was originally published in Mighty Bear Games on Medium, where people are continuing the conversation by highlighting and responding to this story.
