Project Scope

13 people over 7 weeks (school course)

Platform & Engine

PC - Unreal Engine 4

Genre & Theme

Survival horror - What if?

Story Summary

A deep-sea explorer wakes up in what should have been her greatest discovery, only to find that things weren't quite the way she imagined them.

What we made

The AI-predator is a monster that hunts the player throughout Atlantis. Functionally it spawns at point A when the player enters a collider, plays a freaky sound (suspence of disbelief makes this possible underwater), attacks the player if it's been told to do so, and then retreats to point B and despawns.

Initial Design Work

Work on the AI began with me and our system-designer sketching up the basic mechanics in the GDD. Originally our plan was much more dynamic with different behaviours depending on game-state, but for simplicity this was reduced into a single general behaviour.

"Petting Zoo"

When our programmer had implemented the AI, I wanted to test it ASAP. Since we didn't have any levels at the time, I did this by creating a sandbox level, a "petting zoo" so to speak. Through this I was able to prototype key encounters and catch bugs not found during unit testing.

Encounter Placement

Once we had a level, I started adding encounters to it. In general, my goal here was to make it seem like the enemy was always just out of sight. To accomplish this I made it so the enemy only shows itself briefly to the player. Sometimes I didn't even show it at all, I just played the sound effect.

Reflections

I found working with "scary" hard as it's hard to scare yourself, and therefore hard to playtest as you work. However, I think if you're systematic about it (and hire outside playtesters), it's doable. I could for instance have made a template for how far away the predator has to spawn, rather than do it by trial & error.

What we made

As part of the narrative, the player is able to talk with NPCs. For this I implemented a very standard, linear system, it loads dialogue from a table, prints it to the text box and then automatically loads the next line if specified to do so. On subsequent interactions with the same NPC, it can load further dialogue or loop between previous dialogues.

Pre-production

Before work began on the dialogue-system, I wanted to research using the ink narrative engine. Feature-wise this would have been too much for our project, but on the other hand it would have been easier for us to implement. However, we quickly discovered that this caused issues with source-control, so we opted for a custom solution instead.

Initial Prototype

Work on the custom dialogue system began with me developing a rough initial prototype, with basic implementations of the features I knew our narrative designer needed. However, as I wasn't entirely certain what we would need for the end-product, I made the code flexible and left loose ends for potential features.

Inner Workings - Database

The system uses two datatables. The first stores the dialogue line by line, with additional data for who is speaking and textbox colour. The second on the other hand is used as a look-up table for where to start loading dialogue from in the first. Splitting out the additional data would have allowed me to achieve a higher normal form, but I opted not to for short-term simplicity.

Inner Workings - Script

The system relies on two scripts, a regular blueprint and a widget. The blueprint is attached to the NPC and handles loading text, getting player input and communicating with the widget. The widget takes in text, prints it to the screen, reacts to player input and provides a call-back for the blueprint when it's done.

Continued Work

Once the technical-foundation was in place, we needed to iterate on the design and onboard our writer. Normally I would do the former by myself, and then produce a guide for the writer to follow. However, in this case I was able to include the writer in the iterative process, which cut out that whole step.

Reflections

This was a pretty standard task. I didn't put a lot of thought into making it stand out or anything; it just does what it's supposed to. To me that's usually the boring part of game-dev, but good narrative is important to me and with this task I was able to do my part in that. All-in-all I enjoyed working on this.

Prototype Menu

Halfway through the project, I prototyped this 3D-menu with a flashlight effect and a diving bell, as to reinforce the gameplay, story and mood of the game. In the end we were unable to finalize this specific design due to bottlenecks, but it did serve as an important step in the process.

Trailer

I was the one assigned to making the trailer, and what you see is the last prototype I made before the final cut. It still contains some placeholders, and based on feedback from the team I also ended up toning down the emphasis on story.