Game Development Reference
This section addresses what the tool is supposed to do. As mentioned earlier, stake-
holders are the people using the tool, so the requirements are generally centered
on their goals and expectations. I cannot stress the importance of this section
enough. The majority of tools that fail to deliver are because of malpractice with
gathering user requirements. Developers often over-complicate interfaces or build
complex functionality when all the stakeholders wanted was a throw-away utility
to perform a simple process.
If user requirements are gathered correctly from the start, you will save both your-
self and your stakeholders a lot of grief and expense. The old saying, “Time is
money,” describes this problem best. When you are on a tight schedule to produce
tools that are required to build the content for a game or improve workflow to
meet deadlines, time cannot be wasted on building tools that are of no or limited
use to the end user.
Every software application goes through a design phase to some extent, and it is
important that you standardize how the design of the tool is expressed or mod-
eled. A common method is through the use of the Unified Modeling Language, or
UML for short. UML is definitely beyond the scope of this topic, but I personally
use it and advise that you at least read up on it if you are not currently using
another modeling language.
I will admit that UML has a time and a place in regards to software design. Some
tools are so simple or unimportant in the scheme of things that it would be a waste
of time to utilize UML. A modeling language serves as a way to visualize how all
the components of your tool or toolset fit together at a high level, and also aids
with future maintainability if the code itself is not self-explanatory.
However you design the functionality and communication of your tools or com-
ponents, be sure to document your standards in this section and follow them.
A tool or software application in general cannot be considered great strictly on
functionality and performance alone. Since the importance of reusability should
be quite clear by now, it is apparent that the source code for the application must
be easy to read, understand, and maintain for future versions of the software. It is
a common fact that every developer has a unique style to his code, which is perfectly