The Art of Writing Tools

We all agree that all the programmers who work in games never studied games before. or even the other programmers who did study games before, none of those groups of people have studied something called “Art of programming”, because it is simply something I’ve invented it and taught myself !

There is a small portion in this art I really like to call it “The art of writing and making tools”, and as the name said, it is about how to make tools with the most efficient way. If you are using a custom engine, framework or already made engine, you probably hit a limitation which you wanna break this(through) To do this, you will need to)expand the engine and it’s tools a bit more further.

Some people think that making tools is all about programming and writing efficient code. But I disagree with that. here in this small article I’ll be listing the steps/questions I used to follow and ask myself while making the majority of the tools I’ve made in all my entire career. You may disagree with me, but as I mentioned before, it is my own art and my own rules, and any one is welcomed to follow it, and also anyone can ignore it!

1-What('s) the reason behind the tool?
The first and the most important step in the life cycle of making the tool is to  decide why you are going to make this tool, or if you are in the company and it is your task, you need to define the reasons behind making the tool. It might sound silly, but nah the reason behind the tool is very essential for you to follow up in the next steps. the reason behind making a tool must not be [ to finish the task X] or [to do the X functionality]. But it should be something like [to do the X functionality with a proper way that can fit the other X functionality]. So the meaning here is you want to understand the tool and what exactly it can affect, because a short tool reason description might be a reason of breaking some other stuff when you start using the tool.

2-How familiar am I with the API/SDK?
The API, SDK or whatever the rules you are going to follow and use to write the tool. You don’t have to be 100% aware of the API but the more you aware, the better for the step(4). I’ve to mention that some times I’ve been in a situation of writing tools for API’s that I never used or wrote for it before, or in other times I have to use languages that I never used before! Let’s face it, if you don’t know an API you still be able to write for it, you just need to look in the documentation index and give it a roll to know that calls, functions or other stuff it can provide and how you can use it in your tool, and the rest is just about using your programming skills and your syntax knowledge to wrap a tool code that (can or will) work with an API you never used before. I did it before to write some tools for a game bundles in cloud server ! which was really far from my area of working in that company  “gameplay & gameplay tools” but as long as it is coding for the game, I agree that I/any game programmer can or perhaps should do it.

3-Which name should I call it?
Lots of times trying to pick a name for my tool was the main reason of adding new features for the tool !
Try it and you will get amazed how strange it is !!!

4-What else the tool can provide?
Sometimes you can used simple lines of code to achieve something else that can be related to the tool. Or in other times that there is a certain behavior or code that can be reverted or controlled with a value. Lets say we are working in a tool that blends two images to use them as a texture. So why not we add a slider to control the blend ? or why dont we add a check box to enable the user to auto remove the original 2 textures after blending, so he can save some space on the long run..it is all about asking your self what else the user might need, what else can be implemented with zero amount of time, what else the tool should do & what else the tool can integrate. And all that will depends on how familiar you are with the API. the more you know, the more you can add and the more the tool efficiency will be.

5-Is there something the user should know?
Sometimes the tool has something the user should know every time he opens it. It is not about documenting the tool, we will talk about documentation in a later point. But it is about reporting to the user very important information every time he runs the tool. Two of my tools examples were reporting the user that [he can not undo the changes made by the tool] or another one was reporting to the user that when he press a button he should wait because the tool will be looking inside all the project files one by one and that will take some time (I was not able to put a loading bar in that API). And one more thing, for this info try to make it 100% obvious either with different color or big font…or may be with a popup message box with an “OK” button !

6-How it should look like?
We are programmers, we are not artists to make a nice and clean mock-up..BUT as long as we know how to make our code organized, we also know how to make out tool UI organized. So you need to get a paper and pencil, list all your features, all your buttons, sliders and other UI elements. And start organizing the tool with the most user friendly looking. If it looks fine for you, then it will looks fine for others, because it is a tool and will be used with a guy like you who is Engine friendly as well !
In here also you can decide which graphical elements you need to add to the tool (icon, images,….etc).

7-How easy is it to use ?
Making a tool is not about adding too much UI elements and too many buttons. If you can shrink this UI elements and save the user’s time, that will be awesome. Check if the tool is easy to use and the user can not get confused from your UI elements order. if that is fine then you jump to the next step, if it is not, then you need to go back and forth between this step and the previous one!

8-Write it !
Nothing to say about writing the code. just few notes. First, if you can write it in it’s own project and then implement it into the main Engine/project, that would be more safe and you will be sure that you are not going to affect the original project files..We all use version control, but some times for some unknown reasons it get weird !
Second, document the code with some notes. Third any canceled code or feature, just comment it’s code, and never delete it. You might need it later or you might need parts of it to construct another functionality. and that would save your time !

9-Is it need to be documented?
If the tool is too big, complex or whatever. Make sure that you document all the code and document all the buttons functionalities in a PDF. It is nice way to if you can add tooltips to the UI elements of the tool, so it can help. The main reason for this point is that you may leave the company for some reason, and all other team members who get used of the tool can leave as well. So what happens if a brand new people came to the company and they either want to use the tool or improve it ?

10-Is it need to be locked?
Do you need to lock the code ? Can you lock it ? Are you eligible to do that ? then do it !
Sometimes you have some intern, beginners or even other programmer who are not familiar with writing tools, all of them working with you in the same project. Sometimes those people try to learn how to make tools and sometimes they can change some of your code by mistake and submit to git and that will broke the tool for all the project users !
Sometimes other programmer wanna to add an X feature to the tool and he don't want to bother you with that. And he is not aware of it's code as well. and that will break it as well.
So as long as you can lock it it an available choice, then do it to save the tool from unintended mistakes by others

11-Test it !
Test it in all the different cases and take your time in that step, you don't wanna get some one to your disk say your tool is broken !
And if you can test it is an empty project, it would be better,just to save the project from any conflicts that could happen.

As English is not my main language, I get some grammar mistakes quite often. Thanks for my friend "Brad" in helping me to clean the grammar mistakes :)

m;