This project was probably one of my largest and longest-running projects ever. It was also one of my best documented projects, since I started planning early on and kept all the documents in a dedicated folder. I began by conceptualizing. I drew low fidelity mock-ups of what I wanted the product to look like. Then I translated the drawings into more technical terms so that they would be more clear and specific. From those documents, I began to plan out how the program would be structured.
When the program had been sufficiently broken down into smaller problems, each problem could be individually solved by a small segment of code. Knowing the input and output of each class, one could cohesively weld them together into a program without ever needing to know the contents of the class. This is extremely reflective of my design process.
Eventually a working beta version of the program began to emerge. Some flaws became evident once the game was running, so fixes were designed and implemented. Testing continued, and graphics were commissioned from an interested stakeholder.
The game is designed so that units can be dynamically added without significant restructuring of the code. To accomplish this, two classes are necessary:
is a single instance of a unit. However, each
also has a
attached. To create new types of units,
simply needs to be instantiated. Then, when a new
is created, it can be passed an instance of
to assign it its type. This replaces the previous unit heirarchy, where different types of units would have to be subclasses of
. This metaclass
heirarchy was inspired by the design of the programming language Smalltalk
Tortoise SubVersion Control
This project was version controlled using TortoiseSVN
on a Linux fileserver on a local network. Both the source code and the images are stored using the version control system. Unfortunately, because the server was locally hosted, the source code is not available online.