Progress Report 3
From EQUIS Lab Wiki
Contents |
1 Project Description
1.1 The mount concept and benefits
In this project we intend to create a mount that the user will be able to catch and ride while playing the game life is a village. We are attempting the complete implementation of a single mount such as a horse that will roam free until caught. Currently in the game, the player controls a single “lead†villager. Using a stationary bike and handheld controller, the player controls the avatar in all its endeavours. The addition of a mount to the game will benefit the user twofold. Firstly, the process of catching the mount will benefit the user in his goal for exercise. The mounts will not remain stationary in the game, and the user will have to exert effort in order to catch the mount. Secondly, once the user catches the mount, he will be able to ride the mount, which will not only give visual pleasure but will actually increase the speed of the player
1.2 changes to gameplay
The addition of a mount means that the user will move twice as far for the same amount of effort exherted on the exercise bike. This will act as a reward for the effort expended while trying to catch the mount and allows the user the enjoyment of riding the mount and exploring the world faster. When the gameworld grows, this will cut down on the tedium of walking between distant villages as well. Users will not be able to build structures while on a mount, nor will they be able to harvest resource nodes, they will have to dismount in order to do these things. The mounts are for travel purposes only, as well as being fun to catch and ride. However, since this is an exercise based game, we are exploring adding negatives to the mount concept. For example, we are thinking of adding a maximum amount of time you can be on a mount. Or making the mount harder to control the longer you are on it. Or perhaps making travel over certain terrains even harder while on a mount. Since there are only a fixed number of mounts in the game world, these negative aspects will help ensure that no one “hogs†a mount. This is especially important for when the game becomes multiplayer.
1.3 changes to gameplay mechanics
The mechanics of the mount will mimic the mechanics that are already in the game. Mounts will be wandering aimlessly throughout the gameworld at all times. When a player wishes to catch a mount, he/she simply has to run after it. When a player approaches a mount, the mount will run the other way. If the player can come within a small distance of the mount, the will have the option of catching the mount. Once the mount has been caught, there will no longer be two separate avatars (one for the player, one for the mount) but there will be a single avatar of either the player on the mount, or just the mount. This new avatar will be the avatar that the user is now controlling. At any time, the player may dismount from the mount. When the player dismounts, the mount will run away again (the player can run after it and catch it again if he/she wants).
2 User Interface
2.1 changes to the user interface
We will be adding one or two new avatars into the game depending on how we decide to implement the riding of the mount. We will be adding a mount avatar for sure, and we may add an avatar of the user’s avatar sitting ontop of the mount avatar. The actual catching of the mount will be done by either a trigger or by incorporating the jump key that the physics group is working on into a catch key. If we go the trigger route, while catching a mount, if the player comes within a short distance from the mount, a popup will display asking the user to press a button to catch the mount. The interface will be identical to the interface for harvesting resources, a popup informing the player which button to press. If we go the route of the jump key, the player simply has to wait until he is close enough to the mount and simply jump on. When the player has caught the mount, another popup will tell the player which button to press in order to dismount, this will be the same key used to get on the mount. The user can dismount at any time he/she wishes. Mounts will remain persistantly in the world at all times.
3 Code
3.1 classes
Currently, we have already made modifications to the CAXGame and CAXData classes, we will be making changes to the CAXAvatar and CAXInputManager classes and we have already added the CAXMountManager, CAXMount and CAXMountData classes. Instead of creating a CAXMountPathManager class, we are simply using the existing CAXVillagerManager class, as it simply handles building paths.
3.2 CAXGame
Within the CAXGame header, we declare our CAXMountManager object, which is a singleton. This means that at any time throughout the execution of the game, there will only be one Mount Manager in existence. In the .cpp file we initialize our Mount Manager in the constructor. As well, we insert a mount (or many mounts) into the game world through the Mount Managers loadMount method.
3.3 CAXData.h
Within the CAXData.h we define the Mount Job states which include STATE_WALKING, STATE _RUNNING and STATE _CAUGHT. These states are the mount states at any time, while in the walking state the mount will be walking at a constant speed randomly throughout the game world. When in the running state, the mount will be running at an increased speed in the opposite direction of the avatar. While in the caught state, the mount will be controlled by the player. As well, the mount motion states are defined, which are MS_WALKING, MS_RUNNING and MS_STOP. These are the states used for the mesh animation of the mount. Also within CAXData, the CAXMountData class is defined which includes all the relevant information about the mount. Including the direction the mount is facing, the mounts velocity information about pathing, steering, current job and the symbol table.
3.4 CAXAvatar
We will be modifying the CAXAvatar class in order to handle the state when the user is riding the mount. When the player captures a mount, the player’s avatar should change to reflect the captured mount by either becoming the mount itself or by showing an avatar of the player ontop of the mount. As well, the player’s data will have to change accordingly.
3.5 CAXInputManager
We will be modifying the CAXInputManager when creating the mechanism for catching the mount. We will have to define a new button to press for capturing the mount and a button for dismounting.
3.6 CAXMount
The CAXMount class is based on the CAXVillager class. This class defines all the mount constants and parameters, and will have the setAnimationState and animate methods which deal with mount animation. Currently, we have already implemented the mount constructor which uses the ninja mesh. As well we have implemented, the set target, get target, animate, setsymbol, checksymbol, ismoving, get velocity, setstart, getstart methods as well as a bunch of other methods for movement and position. The setTarget and getTarget methods deal with mount movement. To have the mount move from point A to point B simply set the mounts target to point B. The animate function is used to update the mounts animation, it takes a parameter of the amount of time elapsed and moves the clock by that amount of time. The setsymbol and checksymbol methods deal with the mounts symbol table and will be used when implementing the rule based system. The get velocity, ismoving, set start and getstart methods all deal with mount movement and steering.
3.7 CAXMountManager
The CAXMountManager class is responsible for handling the mounts which exist within the game world. The CAXMountManager class is a singleton, which means that only one instance of this class will ever exist. The mountManager handles loading the mounts, setting the targets of all the mounts, as well as parsing and dealing with the rule based system. The Mount Manager also updates the mounts every timeframe and sets the mount’s jobs and actions. The Mount manager class as well deals with steering and pathing and with collision detections (which has not yet been implemented). We currently have the loading of loadmount, updatemounts, and their helper methods completely working. We are in the process of completing the rulebased system of the mounts.
4 Rule Based System
The following is taken from the mountAI XML file
4.1 states
- state_walking
- state_running
- state_stop
4.2 functions
- set_target: builds a path to the next target the mount is walking and changes state to walking
- at_target: checks whether the mount is at a target or not
- run_away: builds a path in the opposite direction of the avatar and changes state to running
- is_safe: checks whether the mount is at a safe distance from the avatar
- is_caught: checks whether the mount is currently caught by the avatar and changes state to stop if true
4.3 rules
Wanderer = state_walking
IF state_walking AND is_safe AND NOT at_target THEN move
IF state_walking AND is_safe AND at_target THEN set_target AND move
IF state_walking AND NOT is_safe THEN run_away AND move
Wanderer = state_running
IF state_running AND NOT is_safe THEN run_away AND move
IF state_running AND is_safe THEN set_target and move
IF state_running AND is_caught THEN NOT move
Wanderer = state_stop
IF state_stop AND is_caught THEN NOT move
IF state_stop AND NOT is_caught THEN set_target AND move
5 Milestones
6 Technology
6.1 Mount Technology and AI
When Life is a village loads up the mounts will be placed at random locations in the game world. When the game starts, the mounts will begin to wander around randomly. This will be achieved by using the setTarget() function to set the target to a randomly determine location in the world. This is the mounts default state, is is the walking state. As the mount wanders through the world, if at any point it comes within a certain radius of a player (radius to be determined later), the mounts state will change from idle to running. While in the running state, the mount will use the basic evasion algorithm and run in the opposite direction of the player. Once the mount is sufficiently far from the user, the mounts state will revert to the walking state and a new random location will be determined for the mount to walk to. However, if the user chases after the mount and comes withing a few feet of the mount, the user will have the option of catching the mount by means of a predetermined button. When this button is pushed, the mounts state changes from running to caught, and the user takes control of the mount. While evadeing, the mount will run away at an attainable speed so the player can actually catch it.
6.2 Activity Diagrams
Activity Diagram 1
This diagram represents the switch between the mounts idle state and the mounts running state. When the user approaches, or chases the mount, the mount should run away from the user.
This diagram represents the switch between the mounts running state and the mounts caught state. When the user catches the mount, the mount should then stay still and be caught by the user, and enter its caught state. From the caught state the user will take control of the mount.
This diagram represents the transition from the caught state to the running state of the mount. When the user dismounts, the state of the mount should change from caught to running and it should immediately run away.
6.3 UML Diagrams
UML Diagram
7 Art Requirements
We require a mesh of a mount, does not matter what kind, could be horse, or dog or whatever, and an animation of the mount walking/running. As well, if possible, (but not required) is a mesh of the player on the mount and an animation of the mount running with the player on its back. We have talked to Ted from the Art class and he is going to re-mention our need for a horse mesh and get back to us with any updates.
8 Interaction with other groups
Our project interacts with the resource and physics groups. We will be modifying lots of the same classes as the resource group when trying to put our mount into the game and we will be discussing approaches to doing this. As well we might be using the same trigger to capture our mount as the resource group is using to harvest resources, so we can collaborate on this action as well. We may also have mounts hindered by resources in some way which we can discuss with the resource group. We interact with the physics respect to collision detection and jumping. We will have to ensure that our mounts cannot run through building or villagers or resource nodes. As well, the catching of mounts may be done by using the “jump†button that the physics team has developed.
9 Progress
We are currently working on completing the rule based system for the mounts. We have done a lot of work in the CAXMount, CAXMountManager and CAXMountData classes based on the CAXVillager classes. As well we have made modifications to the CAXData and CAXGame classes. We can and have placed multiple mounts in the game world and have them walking via the setTarget() function. The process we have taken for adding these files is by going through the corresponding Villager files and modifying them to fit our needs. We have also added mount specific functions that deal with the symbol table and the three mount states. We hope to have mounts walking around randomly relatively soon. After that we will be working on the actual catching procedure and finally if we have time, cleaning up the code and creating a better hierarchy for mobile units.
10 Lessons Learned
We have learned a lot about the structure of the code of life is a village. As well we have learned a lot about the structure of code in a game. We are currently learning a lot about AI in games which is very interesting. We really like the idea of having managers for mounts and villagers and paths that handle all of the functions and updates of these entities during game play. As well, the rule based system that is currently implemented is an interesting approach to “mobile†AI which we had never previously seen before. Finally, we have learned a lot about the interaction between physics and graphics and the virtual world and game play. Things like having mounts interacting with the world and actually having to glue them to the surface of the world to move around ins
