Technical Components of Ponies vs Dragons Chris Hofer

  • Slides: 1
Download presentation
Technical Components of Ponies vs. Dragons Chris Hofer, Mathew Olinger, Krit Saefang, and Tiffany

Technical Components of Ponies vs. Dragons Chris Hofer, Mathew Olinger, Krit Saefang, and Tiffany Terdan Particle Effects All particle effects in the game are handled by the Particle. Manager class. This class is responsible for creating and updating all the effects seen in the game. The effects are subdivided into individual system classes that handle how certain particle types behave. A separated emitter class, also managed by the Particle. Manager, is responsible for keeping track of the particle effects’ locations and interpolating points between positions to allow for a smooth line of effects for moving objects. A helper class called Particle. Settings is employed to allow for small changes in each particle effect system, such as their scale, size, texture, and color. Class Hierarchy for Game Entities Figure 2 shows the basic class hierarchy for all of the game entities. As you can see this describes the behavior for the cities, creeps, heroes, towers, projectiles, and pickups. The most base class Basic. Model describes basic behavior for drawing to the screen and colliding with other objects. Unit. Model describes further behavior that gives an entity health and other stats, allows modifiers and abilities to be attached to it, allows a controller to control it, etc. Unit Control Figure 3 – Diagram of Class Structure for Controlling Units There are six controller classes. Two of them allow a hero to be controlled with either a keyboard and mouse or a gamepad. These are used for enabling player control of a hero. The other four are for the AI. Unit. Model and its inheritors have methods for listening to the IInput. Handler events. The Model. Manager connects these together Figure 2 – Class Hierarchy for Game Entities Upgrade. Manager Figure 1 – Screenshot of Particle Effects in Action Modifiers To control things such as pickups, upgrades, and even damage from attacks, we opted to use a modifier system that can be applied to any Unit. Model. A modifier changes an attribute such as the health of a unit and can be momentary or persistent. For instance, when a projectile hits a creep, the projectile applies a health modifier that removes a certain amount of health from the creep’s available health. Collision Detection In order to perform collision detection, we first generate an axis-aligned bounding box (AABB) around the model in object space by finding the min and max vertices in object space. Then we can wrap an oriented bounding box (OBB) around the AABB and apply the model’s world transformation to it. Model. Manager All game entities are tracked by the Model. Manager class. The Model. Manager is passed between interested classes and keeps track of the location and state of each entity and is responsible for updating all of them. During the course of the game, each player may purchase upgrades. These upgrades are managed by an Upgrade. Manager class. Units can use this class to determine which upgrades should be applied to them at any time. Whenever an upgrade is purchased, we enumerate though all existing units to retroactively apply it. Option. Manager Options for the game such as the base health of each unit, cooldowns for abilities, and initial placement of towers are stored in an XML file. This allows for changing game settings in a central location and without rebuilding the source every time a change needs to be made. Figure 4 – Upgrade Screen