Guns Get Bigger is my Capstone Project for Ferris State University.
In GGB, competitors take up avatars in the arena and shed all pretense as they battle for glory - and bragging rights - in ever evolving gunfights. As each competitor guns down an opposing avatar, his own weapon grows in power, and each time a competitor falls they’re brought back to try again, until the final whistle blows and a champion is crowned…
Guns Get Bigger brings in-match progression mechanics to the multiplayer first person shooter genre, giving competitive PC gamers who are always looking for new ways to compete, and new ways to win, a unique twist on a classic genre by adding a new form of replayability in bite sized bouts of competition against their friends and foes.
GGB was built in Unreal Engine 4, and utilizes Steam networking. All of the programming was done in Blueprints, and a majority of the visual assets are stock Unreal assets, apart from the weapons which were modeled in blender. It’s single map was designed to support 8 player competition. Players start at level 1, and fight until one of them reaches level 20, which gives them 18 upgrade points to spend on the 4 skill trees during each match. Each tree impacts the players weapon differently, immediately after the player levels up, and players can put up to 6 points in each tree.
Additional features include the players ability to select their name and color and save those for their next play session, a lobby chat, the ability to play on LAN connections, and more.
The final show-off of GGB for capstone, showing the game in it’s current state.
This animatic was used as part of my pitch, with a focus on showing progression elements as players progress.
These are the simple model examples of the modular weapon design I intend to use. As players spend their progression points in various upgrade trees, the weapon model will update in simple ways to reflect it, giving players visual reminders of how far into the match the game has gone.
Rough first sketches of the map. The map is intended to be a very open floor-plan, to allow for mobile action. A large cylinder dominates the middle of the map, surrounded by 2 tilted rings, giving the map the nickname “The Atom”. This would later become a hollow dome. Pillars would come in to support the rings, providing more ground cover, and a few walkways up top connect the dome and the rings.
The Atom is a very fast-paced environment, designed so that players can find each-other easily but not necessarily kill each-other easily. It’s stark white color scheme puts the bright characters into high contrast.
Blue Torch is a Virtual Reality project in which users would take the role of police officers in dangerous situations, with the intent of leveraging the special interactivity and suspension of disbelief provided by VR towards improving the simulations already used in Criminal Justice training situations.
Blue Torch had 2 main modes, one of which was a “Reflex Trainer” in which players would shoot targets, having to separate and identify threats from the neutral targets.
The other more extensive mode for Blue Torch was the “Situational Trainer.” This scenario-based trainer functioned as scripted environments where users had to read situations and react properly.
Blue Torch was intended as a rolling project for Ferris State University, where multiple teams would consecutively take over every semester. My team was second. Our big challenge was researching and starting the build for the first scenario, as well as iterating upon the Reflex level that the first team had built.
(Headphone Warning)
The initial iteration of the reflex trainer was a classic arcade shooting range - a few moving targets in front of the player.
To help bring the interaction into a 3d environment and normalize VR use, we changed the environment from a shooting gallery to a 360-degree environment. The original gallery was a warehouse, so we kept those assets. To add in a wrinkle, targets either had a knife or a phone in their hands, forcing the player to do a modicum of threat recognition in addition to simple point-and-shoot mechanics.
The primary function of the reflex trainer was, however, simply to integrate players into VR and get them used to that ‘headspace’ before throwing them into the simulations.
We decided to start the situational training with a traffic stop, a benign looking interaction that happens to be one of the most consistently dangerous for Police Officers. I researched the various paths that these stops take, how officers might escalate and defuse the situation.
One of the most dangerous, and unexpected occurrences is when a driver just immediately leaves his vehicle and attacks - officers are trained to expect ambushes at the window (and there are all kinds of rules about how to approach the vehicle), but this kind of brazen assault right away is a surprise. So I built a scenario where this happens as our demo for how Blue Torch can prepare trainees for the worst and most unexpected events.
In this scenario, the officer starts standing outside of their car on a freeway in the city, a contained environment. The first hurdle they have to clear is checking for traffic - just stepping out into the road will get the player creamed by the passing vehicle. As they approach the stopped vehicle, the occupant exits, a huge red flag, and then immediately draws and fires a weapon, forcing our player officer to do the same.
Gordon Yasmar: Master of the Gauntlet was the brainchild of Joe Senneker. This project was built for the web, in javascript. I was part of a small team that included Jon Champion, Eric Selover, Joe, and myself.
Master of the Gauntlet was a simple JRPG style dungeon crawler in which players toured a randomly generated dungeon until they encountered enemies, which they fought in turn based combat. Players could approach and defeat bosses to move on to a different floor.
My primary contributions were in laying out the Inventory and Level Up menus, and in programming their function.
Joe designed the art and combat systems, while Eric was in charge of the dungeon generation. Jon handled the website MotG was originally on, which is now defunct.
I hope to get my hands on the code again soon and have a playable copy on this site: STAY TUNED!
One of the key features I worked on for this project was the inventory system, which displayed items and allowed them to be equipped or unequipped.
The other core function I worked on was the level up system for Gordon, and the core stats system behind it. This would be used to influence the combat system, and go hand in hand with the inventory system.
Baby Vs. Adult was a game prototype I built with a small team starting in the fall of 2014.
It was a game concept in which an Adult has to quickly run around and baby-proof the environment before the baby can hurt itself. It was built as a split-screen multiplayer experience.
This project allowed my team to be very creative in our design, I suggested we use a crayon-drawn texture as the base of our Aesthetic and it turned out very well.
BvA was my first major try at building something in Blueprints using Unreal Engine 4, and my first time handling any real volume of custom assets, using custom animations, etc.
BvA never made it past the experiment stage but remains one of the most fun concepts I’ve ever worked on.
The Team included: Brandon Young (Project Lead), Myself (Programming Lead), Trevor Collard (Character Modeler/Animator), Arturo Campos, Max Overholser, and Anthony Barbato (Modeling/Texturing), and Joe Senneker (Unreal Consultant)
This simple logo did a great job representing the whimsy we were going for in BvA.
An example of the kind of simple interactions BvA was based around. Here, the Adult player would interact with a fire pit. Completing the interaction would put up a gate, and prevent the baby from harming itself.
These interactions were balanced for time, effect, and sometimes differed from interaction to interaction - putting up this gate took a long time for the adult, but the baby could burn itself quickly for serious damage in the fireplace if the gate wasn’t up. This created a priority system within the competition.
Here you can see the split screen effect, with the Baby’s health (the bottle) on the Baby’s screen only - the Adult needed to be mindful of all times of what the baby was doing, or they could lose track of the baby’s health and what hazards they’d triggered.
The adult here is picking up a battery left out (a choking hazard) - a much quicker interaction than the fireplace, but also one we’d deemed less damaging. If the Baby ate the battery when the Adult was busy, it wasn’t the worst concession to make.
Also highlighted here was the different perspective of the Adult and Baby - there were certain things the baby might have difficulty accessing, and the Baby had to crawl much slower than the Adult could walk. This meant that while the Adult had many things to baby-proof, and the Baby needed at worst 4 hazards, and sometimes only one, to hurt itself, good prioritization from the Adult could keep them ahead.
A screenshot of the small environment that BvA took place in. Luckily, we were able to pack quite a few interactions into a simple one-level home as a proof of concept.
The damages counter, up top, was intended to be a score for the Baby - how many things could it knock over/eat/destroy before the adult finished baby proofing, or the Baby croaked? Unfortunately we never managed to implament those mechanics - but just think of the crash of the Baby pulling over a chair as the Adult sets up the fire grate, and smashing plates as the Adult rushes to put protectors on every wall socket.
