Author Archives: jpbenge

Ctrl-Seek

Ctrl-Seek was a game developed at the 2015 Global Game Jam. It’s a two player game that creates interesting social interaction by having two players to share a keyboard. Before each match, each player sets the movement controls for the other. Each player turns away from the screen while the other sets his or her controls. When the match starts, neither player knows which keys to use for movement. Players must try different keys around the keyboard in order to gain control and destroy the other player.

Gameplay Systems

Movement

For player movement, we knew that players were going to be pressing many keys in succession to try to find their correct movement keys, so our goal was to make it fairly obvious that you had hit a movement key, even if you just tapped it along with several other keys. To accomplish this, and to keep players from sitting still too much, we went for a movement style similar to air hockey, where players keep some of their momentum and drift around the board, bouncing off of walls and each other. For added feedback, when a movement key is hit, we display an arrow on the screen informing that player which direction key or combination of keys is being pressed.

Combat

We wanted combat to be simple enough, but still fun and strategic. We made the decision early on to keep the fire button constant, so that two players holding a keyboard between them can easily reach the fire key and fire at each other at every opportunity. To cut down on unnecessary and complicated aiming, players are always facing each other, and will always fire in the direction of the other player. To prevent matches ending too quickly, players have a hit cooldown that prevents them from taking too much damage at once.

Power-Ups

We wanted to reward players for figuring out their movement, or cleverly utilizing a partially discovered movement set. Naturally, as a player gains more control, it becomes easier to defeat his or her opponent, but we also added in some power-ups that can help players or mix up the flow of a match in other ways. There’s a shotgun style upgrade which turns each shot fired into three, making it easier for a player to hit his or her opponent, a quad shot upgrade, which shoots four shots, in a rotating spiral around a player, which can rapidly damage the nearby environment and may trigger explosive spaces, and finally, there is a health replenishment pickup, which can quickly turn the tide of a match.

Environment

The buttons for fire are constant, and are positioned on opposite ends of the keyboard so that players can fire with their thumbs while holding the keyboard.

To keep firing simple and fun, players always fire in the direction of the other player. Once a player has discovered his or her controls, collecting power-ups and taking cover behind scenery become the keys to winning a match. There are explosives that can appear around the stage too. Hitting one of these with a stray shot will damage and knock nearby players around the stage. This can set off chain reactions that can send players bouncing around the stage. One of the more nuanced design mechanics is that explosions only do modest damage to players, but they ignore damage cooldown, meaning that a chain reaction can devastate a player’s health.

Ctrl-Seek is a simple game, but I’m proud of the polish and design decisions that my team and I put into it. You can download it and play it for yourself through the link below.

Download Game

A Link to some MEL and Python work

I’ve been contacted a few times from people interested in some MEL and python work that I did a few years ago for a VSFX class I took while at SCAD. I thought I would link to the content here in case anyone is interested. I really liked working with MEL and Python, and would like to continue creating tools using them.

Mel and Python Site

Level Design Mod – Vylkinmar

MOD

Preface

In an effort to continue to refine my level design skills, I started work on a level mod for The Elder Scrolls 5: Skyrim. I was looking for a project to work on that would allow me to build a polished level in a reasonable amount of time without having to build core mechanics and create assets. This project allowed be to work with mechanics and player agency already built into the game, and utilize a library of modular assets. The ability to purely focus on encounters and level flow, as well as the fact that really enjoy Skyrim, made this project very enjoyable to work on, and I was able to take the level from concept to completion in just a few short weeks.

I kept a detailed document describing all the encounters and puzzles, as well as my process and challenging parts of development. If you’re interested in a more detailed breakdown than what I’ve provided below, take a look at the linked document below, otherwise stay on this page if you just want the short version.

Level Design Doc

Brief Description

Vylkinmar is a level mod that takes the player through a Nordic styled dungeon that features several unique elements not found in other dungeons in Skyrimk, including an inventory based puzzle to gain entry, an vertical dungeon entrance, and a boat ride with enemies firing arrows and spells at the player.

Gaining Entrance to the Tomb

To enter the tomb, the player must complete a ritual involving placing the correct 3 items in a basin and using a spell or staff to light the basin on fire. The player is clued in on how to complete this ritual by a journal he or she picks up after defeating a pair of necromancers. Completing the ritual successfully opens the sarcophagus that serves as the entrance to Vylkinmar’s Tomb.

Boat Ride

After reaching the second part of the tomb, players embark on subterranean boat ride inside of a massive cavern beneath the ocean. While on the boat, players are fired upon by ranged draugr using spells and arrows. Players can fight back with their own spells, arrows or shouts, or can do their best to avoid the incoming attacks.

Frozen Ship and Vylkinmar

After reaching the boat’s destination, a door leads the player to an area buried deep withing a glacier. Here the player learns the fate of Vylkinmar and his ship, and must defeat Vylkinmar to complete the quest and the dungeon.

Development Challenges

Sarcophagus Entrance

The sarcophagus asset isn’t meant to be used as a means to enter a dungeon in Skyrim. This caused a few complications that I had to account for. The basin puzzle that the player must complete in order to open the sarcophagus required a bit of scripting, but nothing I couldn’t handle. To make the sarcophagus a working entrance however, required some thought. I used a dark plane to make the sarcophagus look like it led into a dark chamber far below. Some invisible trigger volumes allow the player to enter the tomb by activating the space inside the sarcophagus or by jumping in. I needed to give the player a way out in case he or she decided to exit the dungeon partway through, so I set up a rope that the player can use as a door.

Moving Boat

Skyrim doesn’t really use moving platforms, at least not ones that the player can base on. I scripted a fairly simple waypoint system to move the boat, but accounting for any companions the player might have had in tow made things a bit complicated. I created an AI package to tell followers to boatd the boat at a certain time, and navmeshed both where the boat started out and where it came to rest so that followers could find their way on and off the boat. While the boat was in motion, companions didn’t really have to move, and even managed to engage enemies in ranged combat despite the lack of proper navmeshing.. I also had to consider what would happen if players or companions jumped or fell off the boat. I created a series of trigger volumes to keep players on the boat while it was in motion, and used another trigger to detect if a player or companion did somehow managed to fall off and place them back on. Also, Skyim’s standard enemy behavior allows enemies to attack players, but only within a certain distance. I had to create custom packages that told the enemies to fire at players on the boat even though they might be far away.

Non Modular Glacier

The third section of dungeon I constructed featured a fairly small, but very tall area. It needed to be able to fit the crashed ship, and I wanted players to be able to look up and see the sky far above them. Because of the height and demensions of the room, I had to use non modular glacier pieces instead of the standard tillable ice cave set. Constructing a fully enclosed area that allowed for easy player navigation without using a tileset was a bit of a challenge, but I think I managed it pretty well.

Takaways

This project gave me a chance to work purely on level flow and planning and implementing encounters. It gave me an opportunity to learn a new toolset as well as see how Skyrim handled things like scripting and quest implementation. At first glance, it’s easy to view the creation kit as a bit clunky and lacking in a few modern features like support for multiple viewports, but once you dive deep into it, you start to notice all of the nuanced features it offers that help speed up content creation. Things like quest aliases and leveled items can be really powerful tools. There were a few elements of my level that I wanted to incorporate but had to cut because the toolset wouldn’t support them, but it still proved a very capable tool for level creation.

Download Link

Download Mod

Space Cowboy Game Jam – Gravity Bloke

Gravity Bloke

Recently I was able to take part in a two week long game jam. The longer format afforded us much more time to plan things out and make better decisions than racing to finish in 48 hours, and it made the experience much smoother and less stressful. This time the theme was “Space Cowboys,” definitely the most straightforward theme I’ve ever done a game jam for. So we started out working on a 2D platformer where your goal was to explore the interior of a space ship and collect the bounty on a specific enemy, either by shooting him or using your lasso to capture him and drag him back to your ship.
The game we finished with was a bit different, but I think it ended up becoming much more original and fun. As we got the core mechanisms working, we focused on what was fun about jumping around, lassoing enemies and dragging them around. Dragging them around the environment was the key feature that we found to be the most fun, so we changed our design to make lassoing enemies the central mechanism of our game. Long, explorable levels gave way to a very simple arena style level, and the goal of the game became to achieve a high score by shooting or lassoing as many enemies as you can within the given time limit. Parts of the level are also influenced by different gravitational forces. Certain parts of the level have reversed gravity, while others have very light gravity.
Points are awarded to the player each time he or she either shoots an enemy, or drags one to the capture area. As capturing takes longer, more points are awarded for a capture than for killing an enemy. In addition to the standard enemies, a certain enemy with a higher bounty is always present in the level. After this enemy spawns, his bounty is steadily decreased over time. Players are rewarded for finding the target enemy quickly in order to claim the highest bounty.
As it was a game jam game, there are still plenty of bugs, as well as many areas that could use refinement. Still, it can be played in its submitted state can be downloaded and played here. As I said, it has plenty of bugs, but that’s to be expected from a 2 week build. Also, I’d recommend playing with a controller if you can.

If we continue work on the game, which I plan to, I’ll update this post with updated versions.

NCARB Grant Project – Studio DAG

I had 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 architectural students the professional skills and practices they will need to succeed in the real world.

The project lasted for two terms, around 6 months. For the first term, we had a large development team of around 20 or so, and for the second, our team shrank to about 6 or so. We collaborated with architectural students, who were able to give us very valuable information and an informed viewpoint that helped us tailor the project to the field of architecture.

–Systems Design Breakdown —

The core system went through two iterations. The first incarnation of the system had largely been worked out by my professor and project lead when I joined the project, but I was involved in further developing and building out that system. Later down the road, we decided that we needed to change the way our progression system worked in order to make scenario creation easier and faster.

The basic structure of the game involves players working their way through a number of different scenarios, talking with clients and responding to different situations that arise during a contract. Each decision players make affects their scores in seven different categories, Finance, Ethics, Environment, Communication, Public Relations, Time Management, and Office Relations. As players make decisions, they are constantly being evaluated based on these categories, while also trying to keep the client happy. This creates an interesting dynamic where these different factors are in opposition to the wishes of the client. Players must balance keeping the client happy, while considering the brander impact of their decisions.

Scene Progression

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

– 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.

– 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. Now, any choice can lead players to any in the scenario. 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. To simulate this, we implemented a minigame in which players must interact, or choose to ignore, their co-workers.

There are four different NPCs that approach the player’s desk. depending on which pose they appear in, they could offer the player advice, ask for help, or they could want to share the latest gossip. Players can then choose to ignore them or talk with them, but doing so will have an effect on the player’s time management and office politics. The player has to balance being a good coworker without wasting too much time on idle gossip.

Scenario Creation

For our second term of development, we had a student from screenwriting bought on to assist us with writing scenarios, but during the early days, the other grad student, David and I were very involved with the scenario creation process. The architecture students provided us with situations they came up with that would provide interesting, challenging dilemmas that an architect might face. It was then our job to take these concepts and make them workable in the game. We had to go through and assign point values for the categories that each choice effected, as well as write dialogue that would make each choice sound viable to players. One big takeaway I found was that it can be pretty challenging to create choices that you know are wrong, without making them sound wrong to players.

— Development —

In addition to acting as a systems designer, I was also the head of Unity development for the project. It was my job to ensure that assets and code all made their way into the engine, and ultimately my responsibility to get all the pieces working together. I did a lot of coding for the project, and was able to learn a few techniques that I had never used before. I decided that our scenarios should be saved and read in as xml files, which made then easily editable. I hadn’t worked with reading and writing xml files in the past, so it was a great opportunity to learn.

Taking code that had been written by several other people and getting it all to function together proved time consuming, and if I could do the project over, I would have handled some elements differently, but I think it was a success overall.

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.

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.

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.

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. Once 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.

Yellow

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

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.

Red

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.

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.

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

– 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.

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

cs values

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.

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.

Comrade’s first Steps

I recently completed a class that taught programming with Flash. For the final we had to make a simple game. Having only a few weeks to work on it, I made a simple SHMUP featuring a character I had on my mind for a while named Comrade.

If the sprites look a bit big for a SHMUP and a dog shooting lasers seems a bit weird it’s because I didn’t really design this character for a SHMUP. My plan for Comrade is to create an exploration based 2D platformer with him as the main character. Expect to see more of Comrade as that project continues. I should also note that this was my first time doing any real pixel art work, so I know I have some improvements to make.

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.