Technical Components of Ponies vs. Dragons Chris Hofer, Mathew Olinger, Krit Saefang, and Tiffany Terdan Particle Effects OptionManager Unit Control Collision Detection Figure 3 – Diagram of Class Structure for Controlling Units 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. 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. All particle effects in the game are handled by the ParticleManager class. This class is responsible for creating and updating all the effects seen in the game. The effects are sub- divided into individual system classes that handle how certain particle types behave. A separated emitter class, also managed by the ParticleManager, 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 ParticleSettings is employed to allow for small changes in each particle effect system, such as their scale, size, texture, and color. There are six controller classes. Two of the 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. UnitModel and its inheritors have methods for listening to the IInputHandler events. The ModelManager connects these together UpgradeManager During the course of the game, each player may purchase upgrades. These upgrades are managed by an UpgradeManager 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. 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 UnitModel. 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. ModelManager All game entities are tracked by the ModelManager class. The ModelManager is passed between interested classes and keeps track of the location and state of each entity and is responsible for updating all of them. Figure 1 – Screenshot of Particle Effects in Action Figure 4 – Upgrade Screen 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 BasicModel describes basic behavior for drawing to the screen and colliding with other objects. UnitModel 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. Figure 2 – Class Hierarchy for Game Entities