The Chosen Ones - Final Report
From EQUIS Lab Wiki
CISC 864 Group Project Final Report
Group Name: The Chosen Ones
Members: Edwin Locke, Sean Richards
Due: Friday April 7th 2006
Contents |
Description of the Project
The project has changed a great deal since its inception, but we have continued on with the work we enumerated since Report 2. Mainly, we have created a number of new buildings for our village, adding a new way to introduce variety and customization into users' villages. The buildings that we introduced use placeholder art, which is denoted below.
For reference, please see this comprehensive list of the new buildings and their effects.
The buildings that we introduced have really entrenched the idea that what you are building is a village, instead of a loose collection of dwellings. Resource collection buildings add purpose and definition to villager tasks, while the Elder's Hall adds structure to the entire organization. Creating prerequisites for certain buildings and resources adds a basis of a goal for players to pursue, as they wind their way up towards (what will eventually be) more and more advanced buildings and bigger villages.
As can be seen in the diagram above, each building in the game is meant to have specific resource requirements that have to be met in order to advance, making a sort of advancement quasi-tree. For example, in order to build a cabin, the player needs a specific amount of wood and stone (currently set at 10 wood and 15 stone, but these can easily be modified via the XML building templates to suit game balance issues).
Alongside buildings having resource requirements, resources are also meant to have building requirements. For example, the Elder's Hall and Lumber Mill serve as a drop points for the wood resource. Therefore wood cannot be harvested until one of these buildings is built. Since the Lumber Mill requires a certain amount of lumber to build (currently 10), it cannot be built until some lumber is harvested, which means the Elder's Hall is the first building that must be built. Stone cannot be harvested at all until the Stone Quarry is built, and that building also costs wood to build.
In our game idea, a player starts out with nothing but their avatar. They do not start with villagers, resources, or buildings of any sort. They use this to explore until they find a suitable location for their city, where they place their Elder's Hall. This building automatically generates two peasants that can be used for harvesting resources. The player harvests wood until he is able to build a stone quarry, and then harvests stone until he can afford cabins, which generate more peasants.
The task that required the most amount of work in our project, ironically, didn't deal with buildings specifically, but with placing them, which meant altering the game state. Life is a Village is, in essence, an overly complex state machine. In the original code, when a cabin is placed, the game cycles through a number of game states in order to stop the avatar's movement, remap key commands, and change the camera's perspective. Inserting the ability to change building types and to ensure the player has sufficient resources to place a building meant adding some new states, as well as making sure all states were maintained legal despite our additions.
User Interface
The interface needed to be changed in the way buildings are placed. This is a technical aspect of the game that required very verbose user feedback. If something goes wrong when the user is placing a building, they need to be alerted to why so that they may take steps to remedy the problem. If they do not have enough resources to place a building, for example, then they should be alerted to this on the screen so that they do not continue to try to place the building in futility.
Alongside these changes to error messages, an entire system was required for placing buildings. The original code had a way to place a cabin very easily, as that was the only building in the game at the time. Our addition of multiple buildings required a way for the user to flip through all the buildings we have created and choose the one they want. This new feature also needed a verbose message to instruct the user how to select new buildings.
In order to accomplish these tasks, we decided to use the tools that were already in the game. The overlay system available from Ogre's OverlayManager.h allowed us to simply insert messages to the user when the game was in certain states (for example, if the user had insufficient resources to place the building they wanted).
This type of error message and recovery results in a type of error handling that is not available in many other parts of the game. If the user does something illegal, the game does not crash, but instead the system informs the user and allows them to fix their mistake. We feel this is a great strength in the design of our code, as this type of planning and robustness is a highly desirable quality in any form of software.
Flipping through buildings was accomplished by modifying the states that the game can be in. When the user attempts to place a building, the camera swings to an overhead view and the keys are remapped. It is important to keep the game in the overhead state while buildings are being selected, even if a user selects a building that cannot be currently placed. This required a sort of cyclic loop that can only be broken if the user cancels the attempt to place a building, or successfully places a building.
Implementation Design
Very little has changed with the overall implementation of the game in general from our side. It was unnecessary to design new classes or functions, for instance. The functionality of numerous functions was expanded upon throughout CAXGameState, CAXWorldResourceManager, CAXData, CAXBuildingManager, and CAXBuilding. CAXInputManager required some new functions to implement the controls that were added for building placement, but these were mainly mundane in nature, and only necessary to link new tasks to keys.
Interaction with Other Groups
The only group with which we had any crossover was the Innovative Resources group. Their new resource was integrated with our new buildings in a symbiotic way. We created buildings that could process specific resources, but also added a feature to the game that required those resources in order to purchase buildings.
Because of the extensive amount of crossover between our projects, we had to make use of many of CAXWorldResourceManager's functions. CAXWorldResourceManager holds functions for calculating how many of each resource a player has, for subtracting spent resources, and for finding if a building is a drop point for each resource. These and other resource specific functions were referenced in our own code, while yet more functions from CAXWorldResourceManager needed to be tweaked or fixed for our needs.
To a lesser extent, there was a sort of crossover with the physics group. It was very minor, and is only mentioned for the sake of interest. The models for the new buildings that we introduced needed to be factored into their work to make sure collision detection worked properly with these new structures. This was an entirely passive interaction on the part of our group.
Lessons Learned
Alongside the already much expounded upon "importance of being right early" lesson that was the obvious focus of this group, we think if this project were to be done over again, we would not choose to follow another group so closely. The problems that we ran into with CAXWorldResourceManager were many and varied in nature, due mainly to the half-completed attempt of the Resource group to create resource templates. While many functions are declared generically, others were still declared specific to resources (CAXWorldResourceManager:: numCollectedWood & numCollectedStone). Other essential functions were deleted entirely (CAXWorldResourceManager::removeCollectedWood), with nothing left to replace them, or were declared as complicated dummy functions, operating in the same fashion as a Rube Goldberg Machine (CAXData.h's isResourceDropOff). This made dealing with that class very difficult and frustrating, and led to us having to rewrite a few of the functions in order to eliminate the terminal bugs that resulted from the confusion. We assumed that the version of CAXWorldResourceManager that was made available around the middle of the semester was a rough draft, and that the resources group has been putting the finishing touches on that class since their last repository commit. However, since our work relied heavily on it, it made it all the more difficult to work with something that was half complete, meaning we lost a lot of time and energy to unforseen problems in the buggy code.
However, we don't see this as a negative experience, as surely this sort of thing is a very common occurence when multiple parties work on the same code. It was just an incident where unfinished code provided a stumbling block, which naturally led to longer production times.
--Edwin 20:54, 6 Apr 2006 (EDT)
