Game Development Reference
Stakeholders: Internal Versus External
Defined as anyone who stands to gain or lose from the success or failure of an
application, the stakeholders greatly affect the quality and functionality of a tool.
They are the users who are most affected by the introduction of a tool, and they
ultimately contribute to the design and goals. If the tool is meant only for internal
use, there is typically little to no documentation, and the user interface is general-
ly unintuitive or “messy.” If the tool is meant to ship with a game to provide mod-
ification abilities, then the tool is typically feature and user interface rich, and is
accompanied with excellent documentation and tutorials.
Most tools never ship with the game, and constantly evolve as the game is devel-
oped. Many tools are developed for internal use and, if written properly, can be
reused across multiple projects as well.
If the tool is designed for use by the developer only, it is typically as featureless and
unintuitive as possible. The code is usually horrible to navigate, and maintainabil-
ity is almost impossible. Since tools are generally designed to produce content for
the game itself, far less time is spent developing good tools. There is a fine balance
between wasting too much time and resources on the tools for a game, and not
spending enough time making tools that are actually worthwhile. Ideally, you
would want to build the tools as quickly as possible, but with a reasonable level of
quality. This is where improvements to development workflow and component
reusability play a large part in the success of a tool and the developers behind it.
If the common components of your tools have a loosely coupled design and solid
modularity, then more time can be spent making better tools because you do not have
to keep redeveloping common functionality duplicated across different projects.
To describe an example later detailed in this topic, imagine that you have three
batch file processing tools that each process files differently, yet share the same
logic behind traversing the directory structure and selecting target files using pat-
tern matching. If you hard code three tools as quickly as possible, you end up
debugging the common functionality three times, individually debugging the
logic each tool performs, and limiting yourself in terms of future improvements
Now, if that core functionality were separated into a reusable library and extra
time spent ensuring that the code was stable and generically configurable, all three
tools could interface with the library and debugging time would be minimized to
just the tool logic itself. The result is a better tool, and one change to the base
framework propagates to all three tools. This common functionality could now be