Progress Report (Building a Backbone for Building)
From EQUIS Lab Wiki
Contents |
Building a Backbone for Building
Summary
Progress in the project has continued as expected. The original goals, as detailed in the project proposal, are all still expected to be implemented as part of this project. The 3d building insertion menu has been mostly completed, along with the rewrite of the load building-data code. All other goals have been planned out and are in various stages of completion, with work on the project as a whole expected to be completed by March 16th. After that time, there is a 3 week window to integrate with the other groups before the final presentation.
Project Approach
The single largest advancement from the initial stage of the project to the current state is the advancement in the understanding of the game architecture. Without a clear understanding of the structure of LIAV, it would have been impossible to implement any change while respecting the current purposes of each class in the existing structure.
A rudimentary building system was already implemented in LIAV, though it did not actual work. That architecture is shown in figure 1. When the insert building button was pressed, the game would swing the camera to a top down view, draw a new building on the screen, and then allow the user to cycle through buildings to insert, move the building around on the screen, and then eventually insert the building. While functional, the system had several shortcomings:
Figure 1: Original Building System Architecture
1) Communication – Very little information was communicated to the user during the building process. If a building could not be built due to lack of resources, this was not communicated until the user actually clicked the final insert button. The user had no idea that a problem existed until the last stage of the process, and even then wasn’t informed how many resources were required but simply told that resources were insufficient.
2) Building Placement – No checks were made to ensure legal building placement. It was possible to insert a building on top of a tree, villager, other building, etc.
3) Architectural Issues – Almost all code to insert a building was placed into the InsertBuildingInGameState. This was problematic, in that the game states should be concise listings of a number of commands that need to be executed when the game is in a current state. The other game states typically had very little code, and simply called methods to run the game at that state. In addition, this code is very specific. A more generalized version could be multipurposed for other game functionalities outside of the scope of this project.
4) Loading of Building Data – When the first request to create a building (e.g. ‘log_cabin’) was made, the BuildingManager class would look for a file with that same name (e.g. ‘log_cabin.building’). If the file was not present, the game would crash. This was the error that caused the insert building functionality to fail. In addition, this approach forced the developer to always work with a known name; it was not possible to perform functions on the list of buildings.
These issues, once clearly outlined, added a few additional goals to the project as compared to the original proposal. Thus, the finalized list of project goals is as follows:
• Allow the player to insert buildings into the game.
• Provide a view that is useful for placing buildings in legal positions.
• Tie the building system into the resource system.
• Provide a useful menu that allows the player to easily select building types
• Enable the player to build ‘special’ buildings when certain conditions are met (for instance, as a reward for completing a quest)
• Add construction-in-progress. Buildings start out as a construction site, and progress through a series of models. For example, this could progress by showing a bare construction site, a basic frame, a frame with a roof, a mostly finished building, and an occupied building.
• Enforce the concept of a village. Only allow buildings to be placed within a certain distance of your village centre. Allow the player to initially choose the village centre by placing a permanent marker.
• (NEW) Rewrite the load building data sections of code. Change it so that all building data is loaded from a single source in a single pass
• (NEW) Move some insert building functionality from the GameState class to a more appropriate location. The remainder of this report will go through each of these goals in detail, discussing how the changes will affect the UI of the game, the art requirements of each change, the related milestones, and the implementation details.
Loading Building Data
When a building is first created, the system must go to an external .xml file and loads the building data. As described above, this prevents a developer from using the list of buildings for any operation. In addition, each building was described in its own .xml file, which is not consistent with other resources such as the concept.overlay file. The solution to this is quite straightforward. When the BuildingManager is instantiated, the constructor calls a new method called loadBuildingData(). This goes to a new .xml file called buildings.liav that contains the building data for all buildings. In one pass, all building data is read from that file and a corresponding buildingData object is created. Thus, all of the data is preloaded and buildings can be created from this data. No more reading is necessary. Figure 2 shows an excerpt of the building data file. As well, the code to read information from some tags was inconsistent and poorly laid-out. This was corrected.
Figure 2: Excerpt from building.liav
To make a new building available in the game, simply define a new <building> entry in the buildings.liav file. On the next execution of the game, the new building will be present.
This change will be invisible to the user. As such, there is no involvement from arts students. This was the first change made to the game as part of this project and is already implemented and tested. The change is complete.
Building Selection Menu
A main proposal in this project was the creation of a menu that allows the user to select the building to be inserted. Based on difficulty, there was a question as to whether or not the building would be a simple 2d menu that merely listed allowed buildings, or a 3d menu that would list buildings and show the model for the building that is currently selected. Figure 3 shows an artist’s conception of how the change should appear to the user.
Figure 3: Artist's Conception of New Menu
While attaching the Crazy Eddie GUI library was considered, it turns out that OGRE overlays are sophisticated enough to allow 3d elements to be attached. As a result, it was decided that this project would attempt to create a 3d menu without using CEGUI.
The first issue in implementing this change was the creation of a list of buildings that could be inserted. First, a Boolean tag was added to the building data files – Buildable. This tag indicates if the building is buildable. A tree, for instance, is not buildable, while a town hall is buildable. The load building data was also modified to read the new tag. With the change in loading building information, this became quite straightforward. A new public method, called getBuildableList(), was added to the BuildingManager() class. It goes through the loaded buildings and returns an array that lists the name of all the buildings that are buildable. This method is extremely valuable, in that any additional checks (i.e. village centre, resources) may be done here.
A new overlay was added to the concepts.overlay file that would act as the basis for the 3d overlay. Several elements were added to it (title bar, lines of data). This overlay is updated on the fly to show the current list of buildable buildings, and to show the current selection in red text.
Lastly, the 3d element had to be incorporated. Since OGRE shares resources for nodes and meshes in the world, the node had to be created as a ‘rogue scene node’ that reads the mesh file directly. The material for the mesh also had to be altered in several ways. These changes were needed so that ogre would render the 3d element as part of the overlay and, most importantly, on top of everything else. Changes include setting the render order to the overlay buffer, setting the z-value of the rendered object, disabling lighting effects on the object, and others. Simply put, if the node was created normally, many of the changes to the material would have appeared in other scene nodes using the same material, severely disrupting the display.
A new class was created to manage the new overlay: CAX3dDialog. This new class is a wrapper for an OGRE Overlay and provides several methods to interact with the dialog. It provides functionality to set the 3d element, set the list of data to display, scroll through the list, and output the user’s selection. Creating a separate class allows the dialog to be used for other purposes as well, such as integrating with the Quest group.
While the change has clear visual implications for the user, no new graphics are necessary. Thus, arts student did not need to be involved in the creation of the menu. Figure 4 shows an in-game screen shot of the actual change. The majority of the work to create the menu is done. While there are some bugs that need fixing, and the list does not yet have full functionality (e.g. more than 4 elements cannot be handled), work is generally complete. Final touches on this feature should be completed within the week (i.e. before March 9th)
Figure 4: Screenshot of Building Select Menu
Location of Insert Building Code
Currently, much of the insert building code and all of the camera-swinging code is located directly within the game state class. This is inappropriate, as game states are most easily understood as a set of actions to take when a game is in a certain states, along with a new control mapping that applies to that state. Computation for specific processes happens to occur in a game state does not rightly belong there.
Since the code in question is all related to building insertion, it makes sense to move as much of this code as possible to the BuildingManager class. As well, much of the current code can be entirely eliminated due to existence of the building selection dialog. This work has not yet been undertaken, but will be addressed this week (before March 9th).
In addition, the new building selection code (that calls and operates the new 3d dialog) must be located somewhere. The solution is to add a new game state, called CAXBuildingSelectGameState which inherits from InGameState. The old and new game state diagrams are show in figure 5. The new UML for the game state is shown in figure 6.
Figure 5: Game State Diagram
Figure 6: UML diagram showing game states and CAX3dDialog
CAXBuildingSelectGameState manages the 3d dialog. It creates and destroys it as necessary, assigns the 3d element, sends it the list of options, and changes the selection as necessary. Once a building has been selected, the state is moved to the building insert game state.
It should also be noted that a pause state has been added. While this is not relevant to the project, it was done originally as a quick test of the game state code. However, it worked correctly and has a clear usefulness, so it was left in. When using the bike as input, it allows the user to take a quick break for water, for instance.
The work for the new game states is already complete. This is entirely architecture based, and thus has no appearance to the user. No art is necessary.
Allowing Building Insertion in Legal Positions
As a feature that was previously implemented, much of the work is already done here. However, there are many smaller things that should be done to ensure this feature will operate correctly with other changes. First, the current system does some building selection, which is now redundant with the 3d menu. Secondly, it must now accept a building as input, that is, the building placement must accept the output of the building selection menu as input. Both of these changes are fairly small, and result in no changes to the in-game appearance. Also, no art student interaction is required for this aspect of the project.
However, there is one additional change that should be made that will be visible to the player. Currently, a building may be placed anywhere, including on top of other existing structures. Since this is the part of the process where a building location is selected, it is also the part of the process where a check should made that no overlapping is occurring. If it is, the proposed building should be drawn in red to indicate that the current location is illegal. Otherwise, the building should appear normally. This should be achievable by creating a red ambient light on the object. This change should be finished by March 9th.
Tying together Buildings and Resources
All buildings have a resource cost. The idea is that when a structure is built, the resource cost will be deducted from the player’s current resources. If the player lacks adequate resources, the building will not be built. While this is loosely enforced in the existing system, it is not adequate – resources are never actually deducted.
To both enforce the system and provide feedback to the user, the following system will be implemented. When the building selection menu is created, all buildable buildings will appear, regardless of resource requirements. If, however, a given building cannot be built due to inadequate resources, the menu listing will appear in an easily distinguishable grey colour. When that building is selected, the menu will short an information message that notifies the user of insufficient resources. The user will not be able to select that menu option. In other words, any building that is selected will be guaranteed to have sufficient resources. When the building is actually inserted, the resources will be deducted.
No new art elements are necessary to implement this feature. The timeline puts completion of this task by March 16th.
Special Buildings as Quest Rewards
The current system now supports this change trivially. By default, any quest reward item can be set by default to buildable=false. It will never appear on the building selection menu. Once the quest is completed, the flag can be toggled such that the building is now buildable and will appear on the building selection menu. Depending on the building and the purpose of the quest reward, the flag can be toggled back to false after building so that only one can be build
This change is straightforward and will only be implemented if interaction with the Quest group takes place.
Construction-In-Progress
This change presents a ready opportunity for art students. John has been working on the creation of several intermediate stages of building construction (construction pit, frame, frame with roof, etc). To implement this, the mesh for the building needs to be temporarily overridden with the appropriate model. Using a Timer-Trigger, the model needs to be updated to intermediate stages. Once the stages have been completed, the final timer trigger needs to return the building to its default model. This work will be done in the BuildingManager class. When a building is created, it will call a method in the BuildingManager class to initiate the sequence of trigger-update, trigger-update, etc.
This work will only be undertaken if the intermediate models are created. If so, it should be done by March 16th.
Village Concept
The idea of a village in the scope of this project is essentially ‘a group of houses’. In order to enforce this, an additional check must be introduced that forces the user to build structures within ‘village-limits’. What are the village limits, and how is the village first established? The concept of a village centre is introduced as a building data property. If a building is a village centre, other buildings can be built within a certain (arbitrary) distance of it.
This creates a potential problem - if you must build near a village centre, and there are no village centres already built, then nothing can ever be built. To solve this, either village centres could ignore that check, or the concept of an ‘outpost’ can be added. If a building is flagged as an outpost, then it can be built anywhere. Since the outpost concept is less limiting, this route will be taken.
To implement this feature then, we must read in two new tags from the buildings.liav file, and then add a check at the appropriate point in the building process. While there isn’t yet a final decision on the most appropriate location, it will most likely be in the same area where the ‘legal position’ is checked in the building insert phase of the building process.
This is the least likely change to be implemented. If other work proceeds well, then it may be undertaken. However, it must be finished before March 16th. If that is unlikely, it will not be done.
There is cooperation with the arts students on this feature. Jen has been making various objects, such as arches and water fountains that will act as interesting and attractive village centres.
Interaction with other groups
While no specific interactions have been planned, it is expected that all code will eventually be brought together. Since all work is scheduled for completion by March 16th, there is a 3 week window that can be used to integrate with other groups before the final presentation. I am currently staging a computer to act as an always-up Subversion code server. This should be done in the next few days, so that others may begin to integrate sooner if they wish.
