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

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.

It broke down like this:

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

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

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.

Wave Trekker GDD

I created a complete design document for a theoretical game called Wave Trekker. The document covers pretty much everything short of actually making the game. It’s a 3D open world style boating adventure in which the player travels around an open ocean in search of massive sea monsters to defeat. It was really liberating being able to design a game without having to actually make it at the same time. I really had fun working out the systems, writing out dialogue, and mapping out the areas.

Take a look at the design document to view the details of the game.

Selected Systems Breakdown

To demonstrate some of the finer aspects of the game, I’ve selected a few of the game’s major systems and broken them down below. For a much more complete explanation, take a look at the design doc linked above.

Items

There are a number of items in the game that the player can collect. These items do various things, from loot that the player can sell to upgrades for the player’s boat. Below is table of all the items in the game. I also made a Google docs version which can be found here

Fuel and Boosting

The primary way the player moves around the game world in Wave Trekker is by boat. One of the key decisions I had to make was whether or not the boat’s engine would consume fuel. The most obvious concern I had was what would happen if the player ran out of fuel in the middle of the ocean? Additionally, I didn’t want players to have to keep track of a constantly depreciating resource that would ultimately bog down the experience and draw focus away from the more important elements of the game such as exploration and combat. I did end up incorporating a fuel resource, but it is only consumed when the player uses the boost ability.

Part way through the game, the player’s boat gains the ability to boost. This can be useful as a means to travel across the world more quickly, evade enemy attacks, or ram certain enemies. This boosting ability consumes fuel, limiting how often the player can use it.

Fuel Consumption Equation:

Fuel Consumed = 5+(10*t)

where ‘t’ is the time in seconds that the boost button is held down

The initial cost of 5 units of fuel as soon as the button is pressed ensures that boosting has an up front cost followed by a slower burn. This makes it more cost effective for players to utilize longer, more carefullly thought out boosts rather than quickly tapping the button. Initially, the player can hold a maximum of 100 units of fuel, meaning that a single boost held down for 9.5 seconds would completely drain a full fuel tank.

A normal boost doubles the boat’s speed. However, the player can collect an upgrade that will increase the boost speed to 3 times the normal boat speed.

Damage output equation:

Boost Damage Output = 100*(Boost Speed)

This means that boost damage is increased along with speed once the player collects the advanced boost module.