Progress Report (Quest and Crafting System)

From EQUIS Lab Wiki

Contents 1 Quest and Crafting System 1.1 Group Members 1.2 Goals 1.2.1 Project Goals 1.2.2 High Level Goals 1.3 User Interface 1.4 Models required for the project 1.5 Project Status (Technology) 1.5.1 Quest System 1.5.1.1 CAXQuestManager 1.5.1.2 CAXVillager Class Modification 1.5.1.3 Game Triggers Modification 1.5.1.4 Game state modification 1.5.2 Crafting System (Time Permitting) 1.6 Project Milestones 1.7 Interaction with other Groups

Quest and Crafting System

Group Members

• Xiao Feng Qiu (Eric)
• Jeffrey Yim

Goals

Project Goals

The goals for this project include the creation of a quest system and, time permitting, a crafting system.

The quest system will allow the user to take part in a variety of activities that will provide the game with a sense of purpose. Such activities include collecting items scattered throughout the environment, collecting a certain number of resources, or traveling to a particular location.

Upon completing an activity or chain of activities, the player will be rewarded. These rewards will be in the form of new structures or objects that the user may build. Therefore the purpose of the crafting system is to provide a method for the user to place these new objects in the game world.

High Level Goals

The quest system should be able to read in config files which contain information about quests. The information in the config file will be saved within the Quest Manager, and the appropriate triggers will be created for each quest.

Alternatively, quests may be randomly generated. If there are no quests available, a random quest will be generated based on preset parameters.

User Interface

The user interface has been updated with an additional text box in the upper left corner of the screen. This text box is used to display information about the current quest. Once a quest is complete, a new message will be appended to the list of quest messages.

An issue with the text box is once too many messages are added, they will soon flow beyond the borders of the box. Additionally, since messages are merely appended one after the other, there is no method to dynamically update the status of the quest.

Additional pop up messages will appear to the user when they encounter specific quests or states within the game. Some examples of new messages are “Press enter to collect” for collectQuests, and “Press enter to receive a quest” when retrieving quests from villagers.

An ongoing issue with pop up messages is some messages will not disappear after they have popped up.

Models required for the project

A variety of models will be required as rewards for the user to build. Additionally, a flag pole or sign model would be desirable for quests that require a user to travel to a certain location. Such a model would be useful in marking off a location so users can easily identify where to go.

Project Status (Technology)

Quest System

CAXQuestManager

In the original game, no class existed that could be suitably modified to accommodate the needs of a quest system. Generally, such a class would need to be able to handle all quest activities. Such quest activities include initializing quests and their triggers, maintaining quest messages, storing variables shared by various triggers, and providing all the necessary accessor and mutator methods required to access the variables.

As a result, an entirely new class, the CAXQuestManager, was created to provide the above functionality. Once complete, it will receive a vector containing a variety of quests. The first quest on the vector will be stripped and the type of quest will be determined. The corresponding trigger is created utilizing the information stored in the quest. Once the quest is complete (trigger has fired), the next quest is stripped off the vector. This continues until we have reached the end of the vector.

As stated before, an alternative method is to have randomly generated quests. With this approach, if there are no quests, a new quest will be created at random based on the existing quests. To prevent the random generation of absurd quests, such as collecting one million items, restrictions on the range of values will be applied. Thus far a basic quest manager has been implemented. It can currently take in information about a quest and create a trigger. Once the quest and trigger code has been completed, the quest initialization code will be finalized.

CAXVillager Class Modification

In addition to a quest manager, the quest system requires a means for the player to access these quests within the context of the game. For a player to retrieve a quest, they must walk within the proximity of a specific villager within the game. Once they are in range, the villager will prompt the user to press a key to begin a quest. Upon pressing the key, code within the quest manager will be called to initialize a quest.

To provide this functionality, the CAXVillager class was modified so that only a specific villager would provide quests to the player. In order to achieve that, a new name attribute was added into CAXVillagerData, and related functions getName, setName were added. In addition, getVillager, and setVillager, which are wrapper functions, were added into CAXVillager.

In CAXVillagerManager, loadVillager was modified so when the villagers are created, they are given names. AddVillagerTrigger was also added into glueVillagerToGround so that only one specific villager, say Demi, can be the quest giver. The player has to get close to her to trigger the quest system, and get the quests.

The initialization of all villagers’ names is made in the CAXGame, along with the creation of villagers themselves.

Game Triggers Modification

To provide the functionality required by specific quests, and to evaluate the status of each quest, various types of triggers were created. Therefore, the CAXTrigger class was modified with the addition of three new trigger types.

Within LIAV, there is a class known as CAXTrigger. This class contains code for proximity triggers as well as timer triggers. Triggers are objects within the game that are evaluated every frame. Each trigger has two phases, an initialization phase, and an evaluation phase.

During the initialization phase, the trigger is initialized with variables and the game world is changed to allow for the proper evaluation of a quest. For instance in a Collect Quest, internal variables such as the number of objects to collect are saved, and the world is changed by adding objects in the world to collect.

In the evaluation phase, each trigger is evaluated every frame to see if its conditions are met. Once they are met, a specified method is fired and the trigger is deleted. For instance, proximity triggers may prompt the user to harvest a tree once they have walked within a certain radius.

The majority of our quests require the use of triggers. Therefore multiple triggers specifically tailored to each quest were added to the CAXTrigger class. We have added three triggers to the CAXTrigger class:

• ResourceQuest Trigger
• CollectQuest Trigger
• LocationQuest Trigger

ResourceQuest Trigger When this trigger is created, the number and types of resources that need to be collected are stored. This trigger will fire once the user has collected enough of each type of resource. This trigger is directly tied in with the existing resource system. Therefore in the future, if new resources are added, they can also be added as resources for this quest.

This trigger is complete and can handle the collection of multiple types of resources.

CollectQuest Trigger Upon initialization, the collect quest trigger will randomly place objects within a radius of a given location. Each object has its own proximity trigger which will prompt the user to collect the resource when they have stepped within a certain radius. When they press the action key, the object and trigger are destroyed and an internal counter increases. Once the counter reaches the goal amount, the collect quest trigger fires and the quest is complete.

This trigger is complete for the most part. Due to the way triggers are structured, only one type of item may be collected at any given time. The reason is there is an integer within CAXQuestManager that can only keep track of one collect quest item at a time. Further research is required before a more efficient method can be implemented.

LocationQuest Trigger The location quest trigger will fire once the user has reached a certain location.

Currently the location is marked off with a sphere. However, in the future, we wish to replace this with a model of a flag pole or sign. With sufficient time, we would like to add an on screen indicator that points the user in the direction of where they need to go.

This trigger is complete. However in its current state, a series of checkpoints can not be stored in a single trigger. Instead, a new location trigger must be created for each checkpoint. For instance, if a race with five checkpoints was created, five different location triggers must be initialized.

Game state modification

Based on the actions of the user, the state of the game world constantly changes. CAXGameState is responsible for providing a variety of game states as well as the transitions between them. To accommodate the addition of the quest system, several new states were added.

The CAXGameState class was modified to accommodate the collection of items scattered in the environment. CAXCollectInGameState is similar to the original ActionInGameState. However, instead of prompting the user to harvest resources, CAXCollectInGameState prompts the user to collect items on the ground.

This new game state is tied in with the CollectQuestTrigger. Once the user is within the proximity of an item, the game state changes to the CAXCollectInGameState. At this point, a pointer points to the item to be deleted and a message is displayed to prompt the user to pick up the item. If they press the action key, the item and trigger are deleted, a counter is incremented, and we return to the standard in game state.

CAXQuestInGameState is another new game state. Its purpose is to provide a means for the core game to communicate with the quest system. It changes the game state depending on whether or not the user has a quest, displays different messages to inform the player of the status of their quest, and prompts the player when a quest is finished.

Crafting System (Time Permitting)

A system is already in place to create buildings in the game. We hope to modify this code to allow for the creation of new buildings once the user has completed a certain number of quests. Once a quest or series of quests are completed, a flag within the current insert building code will be enabled. Once this flag is enabled, the building will be added to the list of build able structures.

Project Milestones

Midterm Presentation and Report March 2, 2007

Complete research on config files or random quests Continue work on Villager quest giver code Iron out serious bugs with current quests March 9, 2007

Decide which approach to take and create first prototype March 16, 2007

Complete code for quest generation March 23, 2007

Debug and polish quest system March 30, 2007

Final presentation and report April 5, 2007

Interaction with other Groups

Currently there are no plans to integrate our project with another group. Once our features are finalized, we may be interested in merging our program with the “Building a Backbone for Building” project.