Game Development Reference
After the stakeholders have been defined, the last step is to sort them by priority
and influence. A common approach is to take note of the influence, interest, goals,
and objections to your tool. Prioritize your stakeholders as high or low interest, and
as high or low influence. It is important to remember that the stakeholders do not
always agree with each other, which presents problems with both communication
and requirements gathering.
The issue of reusability is important in any software project, but is very important
when developing tools. If a tool is a throw-away, not meant to be reusable, then
only the minimum amount of time to implement the basic functionality should
be spent on it. A common problem is when a tool is not meant to be reused in the
foreseeable future, but has the potential for reuse. In this situation, it is advisable
to build the tool with future maintainability in mind. If the code is just slapped
together to meet deadlines or save money, all those benefits will be for naught
when a considerable amount of time must be spent refactoring the tool for a later
project when it should have been designed that way from the start.
Designing with reusability in mind, and the level of abstraction or agnostic design
to consider, is definitely a judgment call, especially if the stakeholders are putting
pressure or constraints on you to prevent you from doing so. Maintainability even
comes in the shape of following coding guidelines, commenting any complex con-
structs, and never using hard-coded values or “magic numbers.”
The golden rule is, build reusable code if the functionality of the tool would be
useful in a future project, and if it is feasible to spend a little extra development
time building it. You will gain in the long run when the time comes to build a tool
that solves a problem encountered before.
This section outlines the architecture of the tool or toolset. For a simple tool, this
section will be quite brief, just outlining whether the application is console-,
Windows-, or web-based, and other technical issues related to the application.
However, more detail must be discussed with complex tools or toolsets, tools utiliz-
ing a wide range of technologies, or complex component dependencies. Outlining
the architecture is especially important when thinking about reusable software com-
ponent design, and how to write software with future reusability in mind.