Beyond Blue


Responsibilities

Gameplay Programming, AI, Infrastructure, Graphics/Shader Development, Prototyping

Project Length

September 2016 – July 2017

Game Description

Beyond Blue is a third person narrative adventure game about exploring the ocean’s mysteries and the creatures inhabiting it. Developed in partnership with BBC Studios, it features mini-documenteries called Ocean Insights, similar to Never Alone‘s Cultural Insights.

I was part of the pre-production phase of the project, and created various prototypes, mechanics, and tech to help prove out the idea.

Lighting

One of my favorite parts of working on this project was working closely with the art team to match the look of the ocean. We wanted it to be rooted in realism, but still have stylistic control. To achieve this, I implemented stylistic fog inspired by Firewatch, and custom lighting. The fog sampled a gradients for color based on camera depth and view angle to mimic how light travels through water. The custom deferred light calculation was similar, except calculated for each light.

Something really interesting about the deep ocean is how light travels. Blue and green lights penetrate the most, and since the game was planned to feature the deep ocean often, this lighting setup was key in re-creating that look.

Visors & Ability System

We really wanted to capture the feeling of being a scientist connecting with creatures in the ocean and seeing the world as they do. One of the ideas the team had to do this was by using a set of “visors” the player could switch between. I implemented these visors and an ability system manage them, making it easy to swap abilities out and add new ones.

Some of my favorites to create were the sonar and the biofluorescent visors, since I got to create some cool shader effects for them. They were a bit challenging to create, but they were really satisfying to play around with. The sonar visor would send out a visualized ping across objects, making it easier to see in pitch dark. The biofluorescent visor worked by aiming a light at creatures and plants, causing them to glow for a short time.

Dependency Injection Framework

Going into this project, I was very interested in code design patterns, and project architecture in general. I started experimenting with various frameworks, including StrangeIoC, which is an inversion-of-control framework. However, I found it to be a bit cumbersome in how it enforced MVC patterns for everything. A senior engineer told me a quote that was something like “if the only tool you have is a hammer, it is tempting to treat everything as a nail.

This lead me to finding Zenject, a dependency injection framework. I liked it because it encouraged loosely coupled code, yet allowed the freedom to use other patterns with it, whether that be MVC or something else. However, I was having trouble gaining traction of using it for our projects internally. There were concerns about putting so much trust into code that isn’t owned by someone on the team, as well as the general complexity that Zenject brought.

So, my solution was to create my own dependency injection framework, and show lots of examples of how it could improve our projects. It was much simpler, yet provided the core functionality of contexts and injection that Zenject had, and was easier to digest for the rest of the team. This framework was largely a personal project, and I later created a version you can see on my github. Shortly after this project, I decided to continue using Zenject, though the experience of creating my own library gave me a deep understanding of dependency injection and Zenject that I brought into other projects.

Utility AI

Since a lot of the focus in this game was observing and interacting with the ocean’s creatures, it was important to have believable creature behavior. Something I learned about during my time at DigiPen was Utility-based UI, where the various behaviors an entity can perform are scored dynamically, and the highest scoring is performed. I like how simple it is to understand, since behaviors can be kept atomic, yet you can still get interesting and believable behavior.

Since it felt like a good fit, I pitched this setup to the design team, and they liked it as well. So, I created a state-based system that allowed designers to easily configure utility score calculation, and linked nicely with our internal visual scripting system, which seemed to work well for our needs.