The mountiest mounts amount
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.
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. 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. When the player has caught the mount, another popup will tell the player which button to press in order to dismount. The user can dismount at any time he/she wishes. Mounts will remain persistantly in the world and will be running in a separate thread of execution, much like villagers.
3 Code
3.1 classes
We will be modifying the CAXGame, CAXData.h, CAXAvatar, CAXAvatarData, CAXWorldObjectData, CAXWorldObject, CAXInputManager. We will be adding the CAXMount, CAXMountManager, CAXMountData and CAXMountPathManager classes.
3.2 CAXGame
Within the CAXGame class we will be loading the rule based system for the mounts which will include the three states of a mount. A mount can be in one of three mount states: idle, running or caught. As well, the mount has three motion states: walk, run and stop. When the mount state is idle, it will be roaming around the world aimlessly and its motion state will be walk. When a player approaches a mount, the mount will change its state from idle to running and will change its motion state from walk to run. When the player captures a mount, the mounts state will change from running to caught, the motion state will change from run to stop and the player will take control of the mount. As well, the actual mount will be created and placed in the game world within the CAXGame class.
3.3 CAXData.h
Within the CAXData.h file we will be adding the definitions for CAXMountState which will be an enum to define the three states of the mount: idle, running, caught. As well, the CAXMountMotionState will be defined containing the motion states of the mount: walk, run and stop. The mounts data container, CAXMountData will also be defined within CAXData as well as the functions to get the states includeing getState, getVelocity, getMotionState, getPath etc. These functions will be modelled after the same functions of the villager. We will also need to modify the CAXAvatarData to include information for the mount including the data for the change in speed that the mount provides.
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 players 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 users 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 will be based on the CAXVillager class. The mount will be self contained until it is caught. The class will define all the mount constants and parameters, and will have the setAnimationState and animate methods which deal with mount animation. As well there will be the methods for movement, including the velocity and position. There will be the methods for dealing with mounts symbol table and methods to get the mounts current state and to set the mounts current state. There will be the getTarget method which deals with the mount wandering through the world.
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 will handle setting the target of the mount, as well as parsing and dealing with the rule based system. The CAXMountManager class will also deal with the AI of the mount and the pathing and collision detection.
3.8 CAXMountPathManager
The CAXMountPathManager will handle the actual pathing calculations for the mount. The path manager will be called by the mount manager to determine the path the mount should take from point x to point y.
4 Milestones
5 Technology
5.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 idle 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 idle 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.
5.2 Use Case Diagrams
Use Case 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.
Use Case 2
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.
Use Case 3
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.
5.3 Class Diagrams
Class Diagram
5.4 UML Diagrams
UML Diagram
6 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.
7 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 will 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 interact with the physics group mainly in respect to collision detection. We will have to ensure that our mounts cannot run through building or villagers or resource nodes.
8 Progress
We are currently starting to modify the actual game code. We have added the header files for the CAXMount, CAXMountManager and CAXMountData classes based on the CAXVillager classes. We are now reading up on the implementation of the rules based system and starting to work on the source files for these classes. The process we have taken for adding these files is by going through the corresponding Villager files and deleting what we do not need. We have also added mount specific functions that deal with the symbol table and the three mount states. We hope to have a mount showing up in the game world relatively soon.
