Part of my responsibility while working on Achromatic was designing and prototyping the main visual mechanic of the game.

I created a lighting shader/camera setup that would divide the world in half between a monochrome and colored version.

The default view of the world would be projected in monochrome, and while in this state certain details and/or objects could be hidden.

The shader implementation of the light system.

Objects that were given a white mask would act as a source of "light" in the game and would reveal a world of color to the player. Certain objects (like the horse monster) could be made to only be releaced in this color mode.

An intial version of this "light" was a player flashlight that we put in the center of the screen, but later we moved this be an external light source in the environment

A Walkthrough of the player being chased by the horse creature, with the player only being able to see them through light sources in the enviornment.

While developing for Achromatic, I was also in charge of making the pipeline between level design and art as smooth as possible.

To do this I developed a Cinematic Outline Tool that the level designers could use to plan out animated moments in the game.

These outlines, once placed by the level designers and given a description would then automatically compile themselves into a list that the art team could then use and make tasks off of.

The main level design challenge in designing for Achromatic was trying to figure out how to create levels for an environment that was supposed to wrap in on itself.

Taking reference from similar games such as Anti-Chamber, I developed a simple system of teleporting the player with uniform hallways. By requiring the player to go through hallways that block line of sight to both the starting and exiting room, we are able to swap rooms in and out. This creates a "non-Euclidean" effect for the player allowing us to surprise them with an adapting environment.

The above image illustrates how we can swap out rooms as the player moves through the environment.

This can be used to for both puzzle design purposes and to lead the player directly into new areas/levels of the game

Achromatic

First Person Horror Game

Role: Lead Technical Game Designer

Achromatic was a first person horror game that I was in charge of designing for my college capstone as a team of 16.

I acted as a go-between for all programming,art, and design members of the team and in addition to creating the main mechanic of the game I also assisted in tool creation to provide assistance to the rest of the team.

Unity | College Capstone Project

Itch.io

Steam

The Challenge

Developing for ICU patient's represented a strong design challenge, as we would be developing for a player who would likely be in some form of stupor from being sedated and intubated. In addition, depending on their reason for being in the ICU they may also find themselves physically impaired as well.

To achieve this, I developed a single activity game that had the player sauté a pan of food over a burner. The burner(s) would move around thus requiring the patient to maintain their position over the burner to cook the food in as little time as possible.

First VDD of Sautéing Activity

Testing the game revealed that while making the game simple was definitly a good idea for ICU patients, the game in it's current state was still too complicated for most ICU patients.

As a result of this feedback, I decided to remove the wheels from the burners and have them be stationary. The burners would then alternate which one was active.

Second Iteration of Sautéing Game

Having four different corners to manage between ultimately ended up being still too difficult for some patients, and our physical device was unable to properly accommodate for forwards and backwards momentum.

As such, the final kitchen design features four burners in a neat horizontal row that best accommodates a simple left right X-axis for ICU patients.

Final Kitchen Layout

The Challenge

Developing a game for ICU patients presented a challenge in the fact that not all ICU patients where going to have access to full physical movement. As such, structuring the world in a static way for an able-bodied person might result in the game being unplayable depending on the patient.

To resolve this issue, two steps where needed. The first step was to identify how far the patient could actually move their arms. Some patients could in theory have total motor movement, but it was also likely that some patients would have mild to sever motor impairment.

The calibration scene would grab what the patent selects as the middle of the screen as well as the farthest they could reach up, down, left, and right.

Using the gathered calibration data, we were able to always place the player's cursor (pan) within reach of all necessary gameplay elements.

This was achieved by extending the distance of the cursor whenever the player was moving their arm in a direction that they struggled with and retracting in directions they excelled in.

This way, no matter the physical aptitude of the patient, they were always able to play the game.

The end result of this system us a tool that will allow the controller to adapt for any patient regardless of who is playing or what game it is.

Your Kitchen

Medical Therapy Game

Unity Developer and Technical Game Designer

"Your Kitchen" is a medical therapy game designed to be an activity that patients could engage with that would act as both therapy and a physical monitor of their condition. This would be done using a custom motion sense controller that would be strapped to the patients arms.

My responsibility in this project was designing and creating a patient friendly activity as well as coding how the controller would best interface with the rest of the game environment.

Unity | Contract/Internship

The Idea

The main Idea I had when making this project was figuring out how I wanted to represent the connection between the player's phone and the game space.

I wanted to obfuscate the controls of the player, so rather than being able to simply move in any direction at a time, the player instead had to pick a direction by powering certain buttons would enable that movement.

A given button might require two or three different puzzles to power and each puzzle had a different outcome that could power a different direction, so by trying to go in one direction you would have to power down a different direction

Design Learnings

Tying movement to a puzzle interface drastically slows down gameplay and the decision making time frame of players. Levels that required the player to make it over tight turns faired worst as players had no functional way to correct for overshooting which would often result in much frustrated back and forth movement.

An experiment to try in the future would be to give the player access to full movement, but then obfuscate other gameplay actions, giving the player more options at a time but still keeping the puzzle aspect to their controls.

Technical Achievements

This experiment with Networked puzzle interfaces was a good learning experience when it came to setting up networked projects in Unity. By the end of the prototype I was able to host multiple players from three separate devices in one game, with each individual screen showing their own separate controls panel.

Stealth Mobile

Multiplayer Puzzle Platformer

Role: Technical Designer (Sole Developer)

Stealth Mobile was an exploration on the idea of what if you could use your phone as a controller for an external game similar to games like Jack Box.

The resulting game was a simple networked puzzle platformer in which multiple players could join and would compete against each other to see who could get to the end of the level the fastest.

Unity | Mobile Game Seminar Project

Resume

About

Benjamin Operhall

My Projects

Achromatic

Your Kitchen

Stealth Mobile