Armarium

Defend your study from waves of book monsters. You control a wizard protecting his sacred tome at the center of his study from evil bookmonsters. By casting spells kill the bookmonsters before they can explode and destroy the tome or kill you.

Team

Paul Sullivan (Manager), Dylan Graves, Alex Cross, Daniel Girerd, Sean Troehler

User’s Guide

WASD to move
1 or Left Mouse for Fireball
2 or Space for Arcane Explosion
3 or Right Mouse for Scatter Shot
T to Toggle Quadtree outline
IJKL to rotate camera
Scroll to zoom
ESC to exit
R to Restart

Title Screen

Gameplay Video

Technologies

Shooting a spell

Shading (Dylan)

Deffered Shading

Rendering is done in 2 passes. The first pass outputs three textures to framebuffer objects. These textures include a position, diffused color, and normals of all objects in the scene. Then in the second pass the fragment shader calculates shading based on the cook-torrance shading model using the values for each fragment stored in the textures from the previous pass.

Cook-Torrance

Cook-Torrance model is a BRDF shading model that is a very accurate physically based lighting model. The model allows materials to have a roughness property that is used in calculating how light interacts with the surfaces microfacets. These microfacets determine how the light reflects of the surfaces or how the light is scattered/absorbed across the surface.

View Frustum Culling (Daniel)

When we add objects to our game their center and radius is automatically calculated. This is updated when the objects are moved or scaled and then compared against six planes to see if they should be drawn. The relatively small size of our world meant that using the spatial data structure to decide which objects to check culling for would not provide any noticeable benefit.

Shadow Mapping (Paul)

We decided to go with shadow mapping for our shadows. This was a giant mess and we almost had it working when we realised we forced our programs to use the same shaders. After that we decided to add deferred shading, which added more complexities to our game. In the end, we were unable to get shadow maps to display with the other technologies.

Collision Detection (Daniel and Paul)

We support both rectangular and circular collisions depending on which fits the object shape best. The collision shapes are generated automatically and then can easily be set to circular or rectangular and have a multiplier applied by hand if necessary to improve feel. We also coded smooth movement around circular objects.

Particle System with Billboarding (Dylan)

One of the main goals of Armarium was to have impressive spell effects which particles excell at creating. The fireball spell is the only spell that utilizes the particle system. This spell uses a CPU based particle system, where the particles positions and life values are updated on the CPU then written to the GPU. As the particle ages its representation is moved along a sprite sheet of an explosion.

For the billboarding effect the particles vertex positions are actually calculated in the vertex shader. All the particles have the vertices start at the corners of a quad that are then transformed by the location of the center of the particle. An interesting thing to note is that this setup of billboard creation allows us to use instancing when drawing. Instancing means we dont have to send the same 4 vertex values for each particle we can just send one set and use the same set over and over, saving us bandwidth. http://www.opengl-tutorial.org/intermediate-tutorials/billboards-particles/particles-instancing/

One major improvement to the particle system would be to emplement the particles in a feedback buffer. See references for some useful articles on feedback buffers.

Spatial Data Structure (Alex)

We use a Quadtree structure to store all objects and query it to reduce collision comparisons. The quadtree allows for the gamespace to be divided in a way that collision detections are only required for nearby object that have a reasonable chance of collision. The quadtree is constructed top-down by inserting all collidable game objects into the root node of the tree each frame. When the number of objects in any node of the tree exceeds a preset maximum, that node is subdivided into 4 subquadrants of equal size. Any objects that fit completely within a subquadrant are assigned to that subquadrant, and removed from the list of objects in the initial node. An object that spans multiple subquadrants remains in the initial node. Some implementations will place an object that spans subquadrants into all spanned subquadrants, but the implementation for this project was chosen as it prevents redundant data from being stored in the quadtree, and results in a quadtree that is faster to traverse. After the quadtree is constructed, it can be used to retrieve a list of collisions against which a given object should check for collisions. The collision list is constructed by adding all objects from the root node to the list, and then recursively calling the retrieve function on any subquadrants that the given object spans.

Audio (Dylan and Alex)

We use the FMOD Ex library for audio playback. The FMOD Ex library provides a diverse instruction set that allows for complete control over all aspects of audio feedback including 3D sound fall off. The library also handles audio mixing so that multiple sounds can be played at once, without the developer having to worry about overlaying the sounds. FMOD Ex provides support for many platforms and audio file types, making it very versatile to use.

Environment mapping (Paul)

As a minor technology I attempted environement mapping. The idea was to have a cyrstal ball or something that reflected the environment. One picture of the empty environment would be taken at the beginning of the program and used for the reflections. The texture would not be updated dynamically since that would have a huge impact on performance. I was able to get a sandbox working (and you can see that in my Spring 2015 572 final project) but I had trouble intigrating the code into the rest of the game.

HUD (Sean)

For the hud, I wanted it to be cartoony and informative. All of the health is displayed neatly for both the book and the player. Also the spells are shown right in the middle corresponding to the keys that you can press to use them. When they cannot be used, they are colored red, indicating that they are on cooldown. The HUD uses its own shader that takes in the image, and its overlay dictating its opacity.

Enemy Spawning and Pathing (Paul and Daniel)

We created an enemy spawner class that handeles creating new enemies. Each enemy has a starting location and is given a path to the center based off of this. We originally wanted to use A* for pathing but we ran into trouble with that and hard coded the paths. These enemies are grouped into waves and the enemy spawner keeps track of how much time has passed and creates the new wave at an adjustable time period. The final path that the enemies take is the output of the original path fed through a spline function. This enemies move along this final spline curve.

Complex Environment (Sean)

For the game I wanted an environment that was cohesive and nice to look at. I wanted to go with a pallete that was easy to look at where the player, the eneimes, and the spells especially stuck out. All assets in the game are made by me using blender and photoshop.

Animation (Sean)

I used vertex skinning on all of the characters. Both the book monsters and the wizard use skinning. All of the calculations for the translations are done on the GPU as opposed to the CPU. This results in much faster performance. The models were personally modeled, textured, rigged, and animated myself.

Cross-Platform and GLFW

By the end our game ran on Linux and Windows, however Windows had unidentified framerate problems. The largest problem was using GLFW since it requires a different installation per machine. However once we got it installed GLFW was great for handling key and button presses as well as doing windowing. GLFW allowed us to have the option of being fullscreen and also automatically scaling the resolution based on the monitor’s default. Also Eigen matrix bugs on Windows, primarily because of array alignment issues. Lastly we were stuck for a while on OpenGL bugs because we were telling the program what version of OpenGL to use before the OpenGL instance was set so it actually using the default version on each of our machines which all default to different versions.