Combining the thrill of mystery with the terror of time crunch, short projects are great ways to flex my skills in rapid prototyping and design iteration. I have participated in game jams, design challenges, and personal projects both with teams as well as individually and both online and local. While I have participated on several team development projects, all entries contained inside this portfolio are my own work from top to bottom.
Created in three days, Ghost Brawl was built with the jam theme of "one room". The idea behind it was a puppet theater, a theater stage being the single room. Originally, there were going to be stage transitions and changing thematic sets, though due to the time constraint, I wasn't able to facilitate much of the art required for the transitions and set pieces. So instead, I focused on getting the concept of "the puppet" coalesced in both feel and visual recognition.
Using a series of physics joints and hinges I was able to get this wibbly-wobbly puppet, featuring these floating spring-like noodle arms. The motion of the arms as the punching motions goes back and forth really brings home the "this is a puppet" feel to the character model.
I also wanted to play around with in-world UI as opposed to a screen overlay UI. I did this by creating the beer-mug health bar. There's four quarters of "health bar" located inside a transparent mug that drains from top to bottom as health is taken. To help convey the concept of "beer" I added a foaming particle effect that disperses when enough beer is taken from the system.
There were some design hangups in this creation. I created two rails that the ghosts spawn between (to be punched with left and right puppet fists) and due to the perspective camera, they aren't easily distinguished. I tried to quickly somewhat solve this problem by adding lights on the bottom of the ghosts, but Unity3D can only dynamically render so many light sources at one time and the hordes of ghosts quickly exhaust that number. Once that lighting cap is hit, no new lights can be generated, so that spawn in after that number fly at the player without announcing visually what rail they are on, making figuring out what fist to punch with a little confusing. A particle system or a numerical/colored indicator may have been a better solution.
Ghost Brawl specs
Middleware: Rewired, Playmaker
Crunch was a game built in three days. It was a submission to the theme of "Shapeshift". With this game, I wanted to play with the notion of safe versus not safe in physical space. When you are a sphere, you are not safe and will die if enemies touch you too much. As a mallet (cylinder), you are safe and destroy your enemies with ease, but your only mode of locomotion is gravity. Move around with the circle, crush your foes with the mallet.
The core mechanics of this game turned out to be fairly straightforward and easy to iterate upon. Once I got movement, swapping character controllers, and the NPC AI Nav-Mesh up and running, the core mechanics were done and I was able to then focus a some time on polishing. This includes a large focus on feed back. A big thing I wanted for this game was to "feel good" while playing it, and that is achieved bot visual through the particle effects and camera shakes as well as audiably through the sound of every player action.
I created an interactive tutorial that tells the player to do a thing, listens on the input commands for that thing, and then moves on once the system realizes the thing is completed. At the end of the tutorial, it tells the player how to leave the tutorial (crunch the big button with the mallet). The button was there since the beginning and the player can leave the tutorial at any time, so once they've been through the tutorial once, they don't have to sit through it ever again, just go push the button and get ready to crunch stuff.
I played with Unity standard Shuriken Particle System a bit to get a special kind of gory-ness to the crunch action and the player death event. While not simulating real blood or having chunks of viscera flying about, I focused a lot on color and spray pattern to get a pleasing array of various red "bits" flying all about when enemies are crunched.
- Engine: Unity3D
- Code: C#
- Middleware: Playmaker
While I was in school for game development, a group of students would hold local game jams between semesters to keep everyone's skills fresh and hopping for the next round of classes. This is the submission I made to the game jam's theme of "Alchemy".
The jam entry was made in one week. My open interpretation of alchemy was "the mixing of substances to create a new or drastically altered substance" (changing lead into gold and all of that). This made me imagine how colors are created in the real world with paints or dyes that are mixed together. I then thought of having a first person shooter where color was important and you have to mix colors in your gun and to match certian colors to the world.
How this works in my game is that I have special triggers in the game world that the gun listens for. Once the player puts the gun into the trigger volume, the gun will figure out what color that trigger volume is associated with, what color the gun is currently and either assume the new color if the current one couldn't be mixed or mix the old color with the new one.
For instance, if you have a white gun, the only color that mixes with white is black to get grey. If you put that white gun into a blue color volume, the gun will see the blue, see that itself is white, know that white can't mix with blue, so the end result is the gun turns blue. The color combinations is two tiered meaning that colors can only be mixed one step into new colors before having to change completely. The color matrix is [red - blue - yellow -> purple - orange - green | white - black -> grey].
Another system I played around with was the idea of chunky bullets. The bullets you shoot are big, physical, and they bounce around a bit. You only get a set number of them and you have to pick them back up to shoot again. This makes bullets extremely valuable to the player since if they lose them, they have to go without. The less bullets the player has the more dire their situation as enemies and puzzles loom over them and bullets is how the player primarily interacts with the world.
I am planning on returning to Alchemy to develop further upon the project. I'd like to explore avenues for color as it pertains to puzzles and enemy AI design. One of the AI concepts that has been knocking around is some sort of plant monster who only has a color hidden inside a bloom. The plant might move around when it's blossom is closed, then stop to attack the player, exposing it's vulnerable color at the same time. So the player has to choose between attacking and defending and figure out what color they will need and how to get it to approach the enemy.
I want to also play with bullets having endogenous value by making them an in-game currency. Players will be able to find more bullets in a level, but may only hold as many as their gun can shoot (clip size). Bullets then are expended when attacking certain enemies or lost due to hazards or missed shots. The player will have to think hard about what bullets to save, how many to use, and how many do they want to spend on upgrades or other items in an in-game shop. Bullets can be counted at the end of the game to give scores and bonuses based on how little or how much the player carried to the end.
- Engine: Unity3D
- Code: C#
- Middleware: Playmaker, ProBuilder
I learned a great deal from my path through the world of academic game development. Some of which I'd like to share here to highlight several important aspects of game design that I have learned throughout my educational career. Like in the game jam section above, while I have worked with teams while in college, I was the sole developer on all projects contained within this portfolio.
Beware the Light
Beware the Light was a quick prototype drawn up in two weeks for an in-class design challenge. It focuses a theme of "safety". The idea is that in darkness, the player is the most safe. Darkness poses problems, however, as you can't see where you are going. There are points of light that dot the level. Many of theses points are clickable and in doing so, the light will expand and brighten letting you see more of your surroundings. But the light is not safe. As you gain the ability of sight, so so too do the monsters.
I used a nav-mesh for monster path-finding and trigger volumes to decide when the player is visible or not. As the light expands, the volume expands to fit the light's rendered edges. If the player is caught in it, the monster(s) associated with that volume will ping the player's current location (each frame) and move to that location. When the monster touches the player, the player is "eaten". The player then respawns back at the start of the level or the corresponding check-point, depending on what areas within the level the player has previously reached.
Beware the Light Specs
Middleware: ProBuilder, Playmaker
Project Kaiju was made for an in-class game jam that spanned two weeks. We were given the theme of "Kaiju" which was then clarified to mean "giant monster with large amounts of collateral damage". For this game, I focused primarily on the collateral damage, wanting to get that rampaging Godzilla feel first and foremost.
To get that feel of destruction, I was looking at two options. The first option would be to build stacks of 3D primitive objects and knock them down in some manner (fun, but not really "damage and destruction"). The second option was to find some sort of middleware that could splice apart object meshes in a way that looks like they've been broken into chips and chunks.
After doing a lot of research on middleware, I decided to go that route and found a system called "fracture and destroy". It is an algorithm that calculates the size and physics of each chunk within a spliced mesh and handles collisions and other elements of the physics engine for each piece of the original mesh.
Talking with my professor, Richard Flemming, we discussed ways to display a giant monster and animate it. He set me to working with the animation control system in unity called "Mechanim". Through that, I was able to create a monster that moved in a sort of marionette fashion.
The last piece of the puzzle was to get the buildings moving down the track towards the monster (ready for stomping) at the right speeds to sync up with the monster's stomping. I programmed a quick UI and added support for a Windows Game Pad. Also, I added the killer rainbow "Death Beam" using particle effects and explosion physics.
Project Kaiju Specs
Middleware: Fracture & Destroy, Playmaker, CartoonFX pack 4
Although most of the work displayed on this website is solo development. I have worked in teams to create interesting projects as well. I've worked in various capacities within larger teams. I've been a writer, a copy editor, and even a systems, technical, or narrative designer.
Seed was made in a team development environment for a game jamming group called Jamming.Games, hosted by Howard Smith. From the game jam website:
"The proposed goal for Jam #3 was a metroidvania game where you play a robot built by rogue terraforming nanomachines on a distant uninhabited planet. We had the restriction of no procedural generation, so we had to hand craft each environment."
My roll in SEED was that of a technicle and narrative designer. I developed the core puzzle mechanic and helped design character abilities such as cloning and teleporting.
For the story, we designed it around the idea of nanomachines in a post-tech-apocolyptic world.
In this section I will go over my professional writing career. I have been published both academically and in a journalistic capacity. During my studies I've written various works of fiction in both traditional and digital mediums. I've found charcter studies and world building are the parts that I most enjoy followed closely by writing out dialogue and screen plays.
Scifi4Me.com is an online Kansas City based entertainment magazine focusing on science fiction in media, which ranges from novels, comics, film, television, internet content, to podcasts, streams, webisodes, you name it. I joined on as a journalist for the publication back in 2009 as a video game correspondent and have participated and contributed to both articles and videos relating to video games.
Mostly, my articles focus on reviews of various games and industry happenings based on research of public records and game industry history of various companies both big and small as it relates to new and retro gaming.
Film Matters Magazine
While I was a student at the University of Kansas, my college did a call out for film student essays. My submission on how fan cultures affect content creators as well as vise versa was one of the articles from my university got accepted into the Film Matters journal Issue 3 Volume 3 in 2013.
Back in 2013 a rebooted animation with an incredibly high production value was wreaking havoc on the nerd fan culture sphere. This, of course, was the [then] new My Little Pony franchise, created by Lauren Faust. Due to the deep well of world building in the writing, nods to internet culture, seamless animation flow and overall high quality, as well as great voice actors such as the mighty Tara Strong and guest villain John de Lancie, nerd culture latched on to this franchise with a fiery ferocity.
Content creators both of the show and outside took notice. References to the show's fans were made on popular television shows such as The Colbert Report. A level had a general "My Little Pony" theme in Blizzard Entertainment's game DiabloIII that included pony themed named enemies. There were even strange purpose filled mix-ups with Hasbro's (the owners of the My Little Pony franchise) toy line to both fuel and were inspired by internet jokes being made by fan based media commentators.
This published essay focuses on that strange iteration that happened with the rise of that nerd culture and how it reflects a growing trend with the strenghtening link between content creation, nerd culture, and fans of said content.
Untitled Rail Shooter
Back in the early 90's I adored a game from Nintendo that came out on the Nintendo Entertainment System titled "StarFox". It was a space fighter pilot themed rail shooter that held elements of a WWII pilot film drama in a first time ever 3D environment. It was pretty glorious back then and they hit gold again with a reboot several years later titled StarFox64 for the Nintendo64 console.
Since then, however, other than a re-release of the Nintendo64 version for the Nintendo DS, the Nintendo company hasn't really created a "next in line" for this style of rail shooter. They tried to do so with Starfox Zero for the WiiU, but instead of iterating on the fun designs that are core to the StarFox gameplay, Nintendo instead attempted to make a non-intuitive WiiU Game Pad tech demo, missing a unique opportunity to make a new masterpiece as well as highly likely dooming the StarFox franchise.
This misstep made me rather frustrated as a player and a fan of Nintendo's past. But I'm not just a player and a fan, I'm also a game developer. While I was finishing my graduating capstone course in college, I thought often "Why don't I make my own StarFox inspired rail shooter?" And then I one day, I just started making it.
The idea I have for this project is to focus on the core mechanics and then iterate into new, and hopefully exciting, play styles. For the core mechanics, there are three systems I need to create: Ship movement and shooting/aiming, Narrative mechanics for the characters that talk to each other during play, and the multiple rails the player follows along that can be switched between throughout a playthrough.
Currently the focus is on the player controller as it relates to game flow and mechanic feel. Next iteration will be on UI and narrative interface followed by the first level rails, enemy AI, and menu systems.
Originally, I started with the flight system being controlled through the Unity3D physics engine by applying forces to (Pitch, Yaw, and Roll) respectively. This created a system that looked good, but was impossible to aim with any sort of accuracy as the difficulty was compounded by the perspective camera. Through several iterations I've come to a system where I use a mix of animations and code to simulate the ship's visual state and orientation while at the same time using projected UI (reticle) to control aiming.
The idea behind the character controller is that the player controls the center (square) reticle and the ship reacts to the player's applied changes. The ship is a seesaw with the ship model on one end and the secondary reticle (the green "X") at the other while the center reticle (square) and camera act as the fulcrum.
This gives the player a great deal of control both on where the ship is located in physical space as well as how accurate the ship is while shooting. The more in-line with the three systems the player is (ship -> square -> X), the more accurate the player's shots. The further away the three elements are from each other, the less accurate the player becomes.
Secondarily this also makes the player have to choose which space they occupy. If they want to be more safe, they become less accurate through dodging away from enemy fire. while if they want to shoot their targets with any sort of accuracy, they have to fly purposefully into harms way (enemy fire/obstacles) to line up correctly.