Grading Guide

This page describes our implemented features, engine changes, and requirements for the final project.

Requirements

• Supports 3 Scenes:
• We have a total of five scenes, see GameSrc/src/MyGame/Scenes
• Splash screen features navigation to other scenes
• Boss Battle contains our game
• Credits has information about the game creation
• Controls displays some of the basic controls
• Results has multiple states for victory and defeat depending on the results in Boss Battle
• Appropriate Game Complexity
• We have implemented over a dozen game objects and objects for managing sets of game objects, UI elements, game state, and more
• Terrain, Platform, Arrow, FireArrow, Hero, Golem, ...
• See /GameSrc/src/MyGame/Objects for more
• Our main scene initialization function creates more than 50 instances of objects tracked in the Layer Manager
• Even more are created dynamically with the Hero & Boss attacks.
• Per-pixel accurate Collisions
• We took out per-pixel accurate collisions for the final product due to performance issues.
• We created our assets with tight rigid bodies in mind to remove the need for the more expensive pixel collision.
• We consulted Professor Sung to implement additional features in exchange for dropping per-pixel collisions.
• At least 2 camera views
• We feature only one camera view.
• Multiple cameras did not have a particularly useful place in our game.
• We consulted with Professor Sung to implement additional features in exchange for dropping multiple camera views.
• Object Behavior:
• Interpolation
• Our boss makes use of interpolation with its movements.
• ShakePosition
• When our character is hit by an attack we implement camera shake.
• Pseudo autonomous
• The boss features a complex set of states to interact with the hero in a psuedo autonomous manner.
• The boss' purple attack implements chase behavior.
• Physics:
• Most of our objects feature rigid bodies and can be physics enabled.
• Prominent uses of physics include our arrows, the hero jumping, knock back from the boss melee attack.
• Game World:
• We support up to 25 active lights at a time in our main game scene.
• Two directional lights, one for providing a base light level and another for illuminating our UI.
• 22 possible Point lights use by toches, boss projectiles, fire arrows, & ice arrows.
• We do not feature a spot light, we found that it did not enhance our game and consulted Professor Kelvin to add other features in exchange for dropping it.
• We have multiple lights with animated parameters.
• Torches have flicking radius and color
• Multiple types of lights change their position following projectiles.
• Most of our objects are illuminated by lights
• Even our UI has a dedicated directional light to make it not be as dark as the rest of the Boss Battle scene
• Our platforms, midbackground, hero, boss, & torches all feature normal map illumination.
• Four Person Group:
• We implemented shadows and particles.
• Ice arrows, Fire arrows, & torches all emit particles
• Most of our objects cast shadows. The main exceptions are dynamically created objects like projectiles

Additional Features:

Engine Work:

Physics engine modifications:

Modified the Physics engine to support a feature similar to onCollisionEnter2D from Unity. Each time there is a collision between two Physics objects, each object will call the userCollisionHandling function, passing the other object as a parameter.

Example:
 i.userCollisionHandling(j);
 j.userCollisionHandling(i);

These functions have a default implementation in the GameObject.js file which simply returns false. The user has the option of returning nothing, or returning true from these functions, along with handling the collision in any way they wish. If they return true from either function, the Physics engine will skip the positionalCorrection and resolveCollision calls. We use this to have certain physics-enabled objects (such as the Golem projectiles) ignore all collisions with objects other than the Hero (and IceArrow in the case of the Homing projectile).

Game objects with multiple rigid bodies:

Created a RigidSet which facilitates the use of multiple Rigidbodies for a single GameObject. This is related to the EmptyGameObject file as well. EmptyGameObject serves as a GameObject with no Renderable, and just a Rigidbody, as well as a reference to its parent object & x/y offsets so that it can be properly positioned with respect to its parent.

Lighting Modifications:

We added support for up to 25 lights.

Modifiable Audio levels:

Background audio and audio cues can both be passed a float parameter from 0-1 to control their volume. A lot of our feedback focused on the audio being too loud, so we sent the audio through a gain node to be able to modify volume. This should probably be a default feature of the engine.

Camera modifications:

We added a relative positioning system for UI elements to be able to translate to and from world coordinates.

Layer Manager Modifications:

We modified the shadow receiver layer to use a new type of set. Since shadow receivers are not game objects we ran into issues

Line Renderable Modifications:

We modified the Line Renderables to have additional utilty functions for moving vertices relative to their previous positions.

Parallax Game Objects:

Added support for parallax game objects to move on their own. This functionality appears to have been lost with the new physics engine.

Game Implementation:

The Golem:

• Features more than 10 different states
• Has a set of 7 rigid bodies making up its hitbox. These are configured to move with the animations.
• Has a melee attack that will knock back the hero and demonstrates the set of rigid bodies moving with the animations.
• Currently features two types of projectile attacks (Homing and Blast), additional attacks were scrapped due to time constraints
• The Homing projectile generates a spinning magical symbol above the boss. It grows in size as it spins and then chases the Hero, guaranteeing a hit. The Hero can prevent this by firing an IceArrow at the projectile. Upon hitting it, the projectile will be stunned briefly, and then will fly in a linear path, no longer tracking the Hero.
• Also, the "Blast" attack is the green ring that encircles the Golem, similar to the purple one, and then fires at the Hero's current location, but does not track.
• Check out the Golem_Rigidbodies and Golem_Animation files to see how the RigidSet is animated/created.

The Arrows:

• Three different types of arrows featuring different behaviors & appearances
• Adjust rotation while in flight to replicate real arrow behavior.
• Are followed by lights that turn on and off dynamically with arrow creation and deletion.
• Emit particles, depending on type of arrow.
• Remember state on collision to appear like they are sticking.
• Are managed with a specific set to allow for modifiable cooldowns and time that they stay "alive."
• Controled with an arrow vector to allow the player to easily control the strength and angle of shooting an arrow.
• Can be controlled from tail to head ("pushing" the arrows forward) or head to tail ("pulling" the bow back)

Config:

While there are still a few hard-coded values, we generally tried to keep as much of them as possible in our Config files (in the Config folder). This is just a system of constants that is referenced through the Global variable "Config", but it allows us to keep our code extremely readable and organized.

Lighting:

We feature a lot of lights to emphasize our dungeon like game environment. They are used extensively to emphasize projectiles and to light torches. We also have a light dedicated to lighting our UI elements so that we can maintain our dark background and still have the UI standout. Modifications to lights were made to support variable number of lights and not having to create every light possible.