Progress Report 2 (Innovative Resources)

From EQUIS Lab Wiki

Extending Resources in LIAV

Rob Fletcher and Banani Roy

March 17, 2006

Contents 1 Objectives and Motivation 2 User Interface 2.1 Head's Up Display (HUD) 2.2 Notification 3 Art Requirements 4 Project Milestones 4.1 Milestone 1: Rock 5 Technology 5.1 Tools 5.1.1 mappainter.py 5.1.2 liavresources.resources 5.2 Classes Modified 5.2.1 CAXWorldResourceManager 5.3 Modifying the AI Routines 6 Interaction with other groups

Objectives and Motivation

Our objectives have remained the same after successfully attempting to fulfil our initial goals. We have nearly actualized all of our initial goals of providing a new selection of resources as well as the ability to easily add new resources without recompiling through the modification of configuration files.

Once our changes have been fully implemented, we will have satisfied our motivations which were to make the game a more attractive an interesting world in which the players can partake.

User Interface

Head's Up Display (HUD)

Our changes to the user interface have been as predicted. The dynamic information update area in the top-left corner of the HUD has been modified to display the varying amounts of each variety of resource. The dimensions and contents of this box will change based on the data found in the resource configuration scripts. Previously a recompilation was required to make any adjustments to the data displayed, and modifications to a seperate overlays script was needed to redimension the box to contain all of the new elements.

Notification

We have also made major headway towards generalizing the "harvest query" messages which appear when a player approaches a resource node. We have removed the static bitmap being displayed in favour of a dynamic text message which can display a message of our choosing. Presently this feature is not entirely implemented (it displays the same message no matter what resource has been approached) but the infrastructure is in place to allow for the message to be context sensitive and relevant to the player.

This approach will also save memory as a large bitmap will not need to be loaded in order to notify the player. As new resources will be added, new bitmaps would also need to be created which would have lead to the use of even more memory.

Art Requirements

Our art requirements have actually decreased since the initial phase, as we plan on implementing invisible resources for items which might not have a representation on the surface of the game world. An example of this could be 'rock' which will be collected from the earth, and not from a large boulder (or cube) sticking out from the terrain. We are still using the OGRE head as a resource marker, however it would be great to replace it with a more appropriate and asthetically pleasing model.

Project Milestones

Milestone 1: Rock

Our first milestone has been completed. It was our goal to first implement a new resource through brute duplication of existing code in order to get an overview of the issues required. Through this, we learned about the difficulties of detecting the appropriate resource node type based on the existing system of proximity triggers. We also were able to determine which classes would require modification in order to allow us to generalize the resource system.

Based on what we had learned, we were able to deploy a generalized resource system which reads the resource types at runtime from a script and then applies them when the game world is generated and throughout gameplay. We also provided a new suite of generalized AI routines (not yet parameterised) which would allow for generic harvesting behaviour on any type of resource.

Technology

We have completed each of the steps we listed previously. Our technology is still similar to the original LIAV abilities (no new libraries were needed to extend the resources), and we used the existing XML reading technology implemented with TinyXML (used for building data) to read our new scripts.

Tools

mappainter.py

We have extended mappainter.py and it's input files to use a more general approach. Elements which are the children of the resourcemap document head node are each processed and a file is created based on the element name. There is no longer a static, hardcoded list of all possible elements.

liavresources.resources

Our new dynamic resource script is a simple XML file. We are parsing this XML file with the TinyXML functions already included in the CAXConcept. The root node is 'resources' and all of its children are 'resource' elements. Each is required to have attributes regarding its name (used for generating the alphamap), the time it takes to harvest in seconds, the carrying capacity of the element for a villager, the name of the building which is representing the resource, and the name of the good it produces, used for outputting onto the overlays. Here is an example of our debugging resources. Harvest times have been reduced so we could monitor the behaviour in a timely fashion.

<resources>
	<resource name="tree"  harvesttime="2" carrycapacity="15" buildingname="mypinetree" good="Wood"/>
	<resource name="rock"  harvesttime="2" carrycapacity="10" buildingname="rock" good="Stone"/>
</resources>

Classes Modified

CAXWorldResourceManager

We have removed all of our new rock-specific functions which we had added in the previous phase of work. We have also removed all of the original tree-specific functions. In their place, we have added a suite of new functions which are all named irrespective of the resource types. For example we are using "distributeResources" instead of "plantRocks" and "plantTrees".

The following are the methods we added to this class to allow for general resources:

void distributeResources( ResourceType typeOfResource, string alphamap );
void distributeResourceNodes( ResourceType typeOfResource, string alphamap);
CAXBuilding* getClosestResource( ResourceType resourceType, const Vector3& pos );
CAXBuilding* getClosestResourceNode ( ResourceType resourceType, const Vector3& pos );
CAXBuilding* getResourceForResourceNode ( ResourceType resourceType, CAXBuilding& rsrcnode );
void removeResource ( ResourceType resourceType, CAXBuilding* resource);
unsigned numCollectedResources( ResourceType resourceType);
void addCollectedResource ( ResourceType resourceType);

Modifying the AI Routines

We have added new general AI rules as well as several new rules which provide new rules for new villager behaviours to ensure that villagers will not continue harvesting forever. These new rules relate to quitting the job, indicating when the villager is tired, and relaxing to recover their energy.

We also replaced the specific to resource rules such as job_chop_rock with generic ones like job_harvest.

   job_harvest	A simple resource harvesting (like tree or rock)
   go_to_resource     builds a path to a tree the villager should cut down
   at_resource        checks whether the villager is at a tree or not
   harvest_timeout    checks whether the villager is finished chopping down the three or not
   remove_resource    destroys the tree that the villager was cutting down
   drop_off_resource  builds a path to a building where the villager should bring resources
   at_resource_drop_off   checks whether the villager is at a resource drop-off or not
   drop_resource       drops the wood (adding to the user's resource stockpile)
   harvesting        checks whether or not the player is currently harvesting something
   going_to_resource_drop

Interaction with other groups

We have been able to update our code and introduce the changes introduced by the Titans, allow our avatar to hop along beside the new dynamic resource system. We have committed our changes as well. One side effect of updating with the physics before committing our changes was all of the functions we had originally deleted from the code were restored from their version. These will be removed again before our next commit.