Tag Archives: Design

Aeroblazer

Aeroblazer was the visual component to my MFA thesis. A thesis at SCAD has two components, A written thesis paper, and a visual component that demonstrates the concept or argument of the thesis. My thesis was titled Gameplay Driven Content Generation, and it can be read in its entirety here.

Aeroblazer Alpha Footage

My goal with Aeroblazer was to create a system in which levels are created dynamically while the game is being played. These levels are created in response to player actions, so that the created level becomes the result of how the the user plays the game.

Mechanics Overview:

Aeroblazer is a turn based game involving a vehicle that can both fly like a plane, and hover along the ground like a hovercraft.  In it, two players compete by alternatively flying and driving, creating a track while they do so.  Each turn consists of two phases: the driving phase, where the active player must drive the length of the track and make it to the end, and the flying phase, where the player adds to the track by flying a plane around, avoiding obstacles, collecting powerups, and trying to create a tricky section of track for the other player.

Each turn lasts for a limited amount of time as indicated by a meter in the center of the screen.  Within this time limit, the active player must make it to the end of the track in order to add onto it.  If the player fails to reach the track’s end before the meter runs out, he or she will not be able to add onto the track, and it becomes the next player’s turn.

Since there is no track when the match begins, the driving phase is skipped on the first turn, meaning the first player starts off by flying around the environment.

Aeroblazer Turn 1

Once the first player’s turn has ended, the second player takes his or her turn, starting in the driving phase.  He or she must navigate to the end of the track before time runs out, then continue building onto the end of the track.

Aeroblazer Turn 2

The match continues on in this manor until one of the two winning conditions is met.

Time equation

Timer(in seconds) = 10.0 + v*0.08

Where v is equal to the total number of verticies in the track.

This equation ensures that as the track gets longer, the player is given more time to both navigate the track and to add onto it.

Winning conditions

There are two ways a match can end.  The first way is if one of the players’ health meters is reduced to zero.  Players can lose health in a few different ways.  During the driving phase, players can lose health by hitting the bumpers on the sides of the track, falling off of the track, or failing to reach the end of the track before time runs out.  During the plane phase, players can lose health by colliding with obstacles.   This will cause the player’s turn to end, and discard the section of track he or she was creating.

Aeroblazer Taking Damage


The other way for a match to end is by collecting all five checkpoints.  These checkpoints appear one at a time, and are randomly placed throughout the creation space.  Once a player passes through a checkpoint, he is given a point and the next checkpoint appears.  Aeroblazer CheckpointOnce all five checkpoints are collected, the match ends, and whoever has more points wins.  Three points are needed to win, but the match doesn’t end once one player has three points, meaning the other player can still win if he or she can reduce the winning player’s health to zero before all five checkpoints are collected.

Powerups

There are powerups scattered throughout the environment that can help players in various capacities as well as alter the track that is being created.  These powerups can be collected in two ways.  First, players can collect a powerup by touching it with their vehicle, either in the driving or flying phase.  Second,  while the active player is taking his or her turn, the inactive player can control a cannon mounted on top of the active player’s vehicle.  With this cannon, the inactive player can shoot lasers that collect any powerups they hit.  This not only gives the inactive player something to do during the other player’s turn, but also allows both players to compete over powerups and influence each other.

There are three powerups, and each one has two different effects.  These effects depend on if the powerups are used during the driving or flying phase of a player’s turn.

YellowAeroblazer Yellow Powerup

Yellow powerups give the user a speed boost if used during the driving phase, or create a gap in the track and a ramp with which to jump over it if used during the flying phase.

Purple Aeroblazer Purple Powerup

Purple powerups give the user a shield that protects him or her from losing health from hitting the side bumpers if used during the driving phase, or creates a section of track where the bumpers take away more health if used during the flying phase.

RedAeroblazer Red Powerup

Red powerups give the user back some of his or her health if used during the driving phase, or create a narrow section of track if used during the flying phase.

 

Aeroblazer is currently in an alpha state.  It is playable and the core experience has been refined and balanced to an extent, though I am still developing the game, and there are a lot of features I am still implementing or improving.  Some of these are described in my thesis paper.

NCARB Follow Up

Well, a few short months have gone by and we’ve been continuing work on our NCARB project with the Architecture Department.  For the summer quarter we had a much smaller team, numbering about 6 or so, with others dropping in on occasion to help out with specific tasks.  Our decreased manpower definitely took its toll on our asset output, but we were able to focus in on our game’s issues as well as features we hadn’t gotten around to implementing.

NCARB August build

Now, I know what you’re thinking.  Based on the screenshot it looks really similar to the one from three months ago.  True enough, the main setup looks pretty familiar.  Though the main interface and set dressing will soon be seeing another pass soon, the main changes this quarter came in the design.

Necessary Changes — 

After a few months of working with the architecture students to create scenarios for our game, we noticed our scenario writers were struggling with creating new content.  The issue emerged as a result of our scenario system, and the way each scenario had to be designed in order to work within that system.

The way our system originally worked, a scenario consisted of three possible ‘tracks,’ or sets of scenes that players could follow as they went along.  These tracks weren’t necessarily linear however because it was possible for a player to jump from one track to another after any given scene.

scenario flowchart

It broke down like this:

– The player would select his or her chosen response to the given scene

select choice

– That player would be awarded positive or negative points in seven categories based on his or her choice

value points

– Those points were then compared to another set of values for those seven categories which represent the client’s desired outcome.  This determines an umbrella “Client Satisfaction” value.

equation

– This value then determined which of the three possible scenes the player was given next.

cs values

We tested this system pretty thoroughly and found it worked well to move the player through the scenario.  The issue came about not as a result of the system not working, but our three path structure and evaluation after each scene meant that the premise of a particular scene could not be a continuation of a previous scene because the player could conceivably arrive at that scene from anywhere.  This became a problem for our architecture friends as well as our chief writer because each scene had to be pretty much agnostic of anything that came before it.

In the end we decided it was best for the project to switch to a more open ended branching structure for our scenarios.  This was not an easy decision to make, as it meant throwing out the system we had developed, and reworking a lot of the coding I had done.

So we went back and came up with a system that allowed our writers to create scenarios as with as many branching paths a they wanted.  We did however restrict them to the three choices per scene format.  This was done for a number of reasons, a consistent markup format and interface being among them.

Office Relations — 

Working in an office isn’t just about finishing your work.  interacting with your co-workers is a necessary part of working anywhere.  We’ve finally gotten around to fully integrating our co-worker interaction mini game.

We have four different NPCs that will approach your desk.  depending on which pose they appear in, they could offer you advice, ask for help, or they could want to share the latest gossip with you.  You can choose to ignore them or talk with them, but doing so will have an effect on your time management and office politics.  The player has to balance being a good coworker without wasting too much time on idle gossip.   The intricacies of the co-worker mini game were worked out by Hayley, who stayed on with us to help with design work.

Feedback–

One of the most important requirements of an effective gameplay system is providing feedback to the player.  Without showing players the impact of their decisions, how can they be expected to understand and eventually master the system?  At the beginning of the summer we decided that the system we had devised for showing the consequences of players’ choices wasn’t working.  The original system featured items in the environment reacting in a positive and negative way depending on the impact of players’ choices.  Make a choice that negatively impacts the environment and a plant in the office will start to wilt.  The problem was that we found the connection between choices and the objects in the office weren’t obvious enough.  It wasn’t immediately apparent that objects were animating for a reason and not just at random.  We knew we needed something more immediately obvious,  thus the icon bar was born.  The icons on this bar will turn green or red based on player decisions.  They also get more or less saturated based on the player’s score in these areas.  This gives players an idea of how they are doing without giving them the exact numbers.

There’s still work to be done, but we’re definitely making progress.  The different systems are finally starting to come together, and the game is improving with each build.

NCARB grant project – Studio DAG

I recently got the opportunity to work on a joint project between the SCAD architecture department and games department. Our friends in the architecture department applied for and received a grant with the NCARB to develop an interactive game that teaches professional practices to architecture students.

When I came aboard the project, the core system had already been worked out. The basic principle is that you are given a scenario made up of individual scenes- basically decisions that need to be made. Each scene presents you with three possible choices and you must choose the course of action you feel is best. These choices move you down one of three tracks as you move through the scenario.

Another grad student, David Reardon, and I together with our professor worked out that each decision should influence your total values in one of six categories: Communication, Ethics, Environment, Ethics, Politics and Public Relations. As you make decisions, you are constantly being evaluated based on these categories, while also trying to keep the client happy. The interesting dynamic comes into play when these two factors are in opposition. The client usually values time and finances, but if you make too many decisions that negatively impact another category you can still fail, even if the client is happy.

Dave and I have been further developing our core system, while I’ve also been leading the game’s development using Unity. With the help of a class of students, we’ve managed to create develop our initial build.

NCARB June Build

We’ve been working with a larger development team than I’m used to, which has been really great.  We’ve managed to generate a lot of content in just 10 week.s  I just wish we had more programmers.  Still, we managed to produce a vertical slice of Studio DAG (not the title I would have given it) in a very short period of time.

Some things aren’t quite finished, as you’ve no doubt noticed by the giant glaring “character name” in the image above, but those will hopefully get polished up pretty soon.  Myself and a few others will continue work over the summer, so hopefully we can continue work on some of the systems we developed but didn’t get a chance to implement.

 

Ruins of Mono’Zhe

Playthrough Video

I designed and implemented a level called Ruins of Mono’Zhe in UDK.  I designed the level’s three event systems and implemented them using Kismet.  I first blocked out the level, then set-dressed it using built in UDK assets.

Level Design Doc

 

Narrative Overview

Mono‘Zhe is an ancient subterranean ruin located within a vast cave chamber. A local myth tells of a mythical weapon of great power locked away within the forgotten ruins, garnering the attention of international arms research firm Anepco who have started excavating the ruins. Poor working conditions and economic instability have caused the workers to strike, leaving the dig half finished, and the dig site deserted save for the company’s automated defenses. The player has discovered a secret way into the ruins, and decides to venture into the ruins and claim the sword before Anepco can send replacement workers.

Event Breakdown

[Show picture list]

Event 1: Cave Entrance: Improvising a Torch

After a dramatic vehicle accident, the player finds himself in a small wooded enclosure near the mouth of a foreboding cave. The player can attempt to explore the cave, and may even make his way through it, though the path is treacherous and a miscalculated jump could result in a fatal fall into shadowy depths. The way through can be made much easier with the help of an improvised torch created from one of several dried sticks scattered about. To make the torch, the player must find one of the sticks and light it in the flames spewing out from his overturned vehicle. The torch allows for safer passage through the cave, but the player must hurry as the torch will eventually burn out and must be re-lit.

[Show picture list]

Event 2: Inner Ruins: Block Placement Puzzle

Once inside the ruins proper, the player is confronted with a closed stone door. In the same room is a plinth with a large square recess. The player can find an assortment of stone block pieces in different shapes scattered around the room. She can pick these pieces up and bring them to the plinth to place them. They can be moved and rotated over the plinth and placed anywhere they can fit. The player’s job is to place all five block pieces inside the plinth in order to open the door and progress.

[Show picture list]

Event 3: Excavation Lift: Repair the Generator

The final task for the player is to make his way out of the ruins via an elevator that has been built to accommodate an ongoing excavation of the ruins. Upon reaching the lift, the player notices that the lift gate will not open due to a lack of power. The player must then deploy a remote controlled drone to repair the lift generator. Things get complicated when the deployment of the drone alerts the dig site’s security robots. The player must control the drone and fight off the robots while staying close to the generator to repair it power the lift.

Mechanics Study – Barrel Blitz

A while back I did a mechanics study to try to recreate the barrel cannon mechanic from Donkey Kong Country.  I recreated the mechanic  from the mechanics in UDK using a whole mess of Kismet.

The barrel cannons operate pretty much exactly as they did in Donkey Kong Country.  Red Barrels shoot you automatically, while the blue ones fire when you press the ‘f’ key.  There are moving barrels, collectable goodies throughout the level, and eventually obstacles that you have to avoid using precise timing.

While doing this study I learned a lot about how Unreal works, and how to really dig deep with Kismet.  I also learned that most of the things I had to implement with complex Kismet sequences I could have accomplished much easier by modifying the player package.

In doing this project I also learned a ton about the design language of the DKC games.  There are a number of elements that I noticed in the original levels that I was able to implement in my own example.

Take The Plunge

Barrel Blast

Barrel Blast

 

 

Placing items right at the edge of players’ vision is an effective way of luring them to areas they might otherwise perceive as dangerous.  As long as you provide a hidden means of safety, this is definitely a fun way of hiding secrets.  This is used all the time in DKC.

 

Give Them What They Expect

Barrel Blitz

Barrel Blitz

 

 

 

 

 

This is something I didn’t foresee.  I placed a hidden item to the left of this cannon at the top of a vertical crevasse.  The cannon shoots the player right, but if you jump over the barrel to the left, you can find a secret.  The interesting part is that everyone that found the secret stopped searching to the left immediately after finding it.  The arbitrary pickup was enough to satisfy players’ curiosity.  Up until this point in the level I had been training players to look for these hidden spiky things, so once they found this one they were satisfied and moved on.  Smaller secrets can be effective means of concealing larger ones.

Follow the Glowy Things

Barrel Blitz

DKC does this all the time.  Notice how the next barrel the player should fire themselves towards is nowhere to be seen.  The only indication of direction is the trail of glowing things.  By this point the player knows these things are good, so sometimes that is enough to lead him or her.

Accidents Will Happen

Barrel BlitzBarrel Blitz

 

 

 

 

 

Surprising the player with a secret when he or she expects to fail can be really fun.  Here the player has to fire the rotating cannon to reach the next barrel.  If the player fires straight up instead of to the right, either by accident or by intention, he is rewarded with a secret path and a huge haul of goodies.

 

Non-Digital Zelda

Non Digital Zelda

I did a bit of non-digital game design.  I was given an assignment to convert an existing digital game to a non-digital analogue while still keeping the spirit of the original title.  I chose to convert The Legend of Zelda: The Four Swords to a four player board game.  I really like the cooperative/competitive dynamic of the game in its digital form, and wanted to touch on that with my non-digital counterpart.  Players work their way through various dungeon tiles while competing ot collect the most rupees.

Looking at the final product, I think it needs some revision.  It plays a bit too slow and combat feels a bit tedious for my liking.  It was a great project to work on though, and I’m still working to improve it.  Zelda is a series I have a lot of passion for, which really motivates me to make this adaptation do the series justice.

Take a look through the design document for a full breakdown of the rules.

Game Design Doc

Bombs Away

Bombs Away

Software Used: Maya, Photoshop, Unity

Role: Lead Programmer, Designer

Bombs Away is a competitive action game for up to five players. The project was planned as a game played on both iPad and PC together, but we ended up finishing the standalone PC version and a separate version for iPad. There are four bots all competing to be the last bot standing. They do this by picking up bombs and throwing them at other robots, or picking up other bots and throwing them into bombs or spikes. There is also a player called the overseer. He controls the environment by moving spikes around, rotating the environment, or placing additional bombs in the arena.

Bombs Away Gameplay

This was the project I worked on for my senior project at Drexel. I served as lead programmer on a five person team.  Due to the size of the team, we all had to contribute to pretty much every aspect.  In addition to programming I had a strong influence on the design of the game.  Though it was tough working with this team at times, and the way our senior project is structured was frustrating, I still enjoyed working on this project. It was nice to get pretty much all the functionality we wanted working in the game. I learned a ton about Unity through this project.  Most of my scripting skills come from working through this project for six months

Here’s a video explanation