top of page
wide.png

That Which Lurks

There's more than fish down there...

About That Which Lurks

University Project | Unity | 3 Months

Created during my second year of university, That Which Lurks is an homage to early 2010's horror games.
The themes are largely Lovecraftian, primarily inspired by The Shadow over Innsmouth.

🔗 GitHub | Game 🔗

Group Responsibilities

  • Item interaction system using interfaces.

  • Horror creature AI, implemented using a finite state machine.​

  • ​1st person player controller.

  • Production timeline.

Context

That Which Lurks was created as a group of 5 students (2 programmers, 3 artists) during my second year of university over the course of about 10 weeks.

​​

The player is presented with the immediate goal of escaping a deep sea facility due to the escape of an unknown specimen. Investigating reveals that the facility was poorly run, with maintenance and security protocols not being met, presenting the player with several obstacles that need addressing before escape is possible.
Unfortunately, the thing that killed all the crew still seems to be out there somewhere...

​

The core gameplay was intentionally kept quite light, with a bigger focus being given to creating an atmosphere.
UI was kept diegetic where possible and progress is communicated via environmental means.

Interaction System

The interaction system relies on a raycast that detects what object is being looked at and attempts to access an interface that contains information for:

  • What to display on the UI when looking at an object

  • Clearing UI elements when looking elsewhere.

  • What behaviour to execute when interacted with.

​

In future implementations of this system I opted to replace the interaction wrapper of the interface with an event, since this works better for designers with Unity's interface.

interaction-1.png
interaction-2.png
interaction-3.png
interaction-4.png

Finite State Machine AI

The core of the experience was always intended to be the monster and it's environmental interactions.
Unfortunately, 10 weeks is not enough time to build and test a more complex implementation (i.e. behaviour trees) while also building the rest of the primary mechanics.
​

​

While finite state machines are an older approach to game AI, they still function more than well enough for this scale and can be built fairly quickly.
I based the state pattern on elements from this book with some modifications for ease of use.

​​

The monster has 4 states:

  • Idle - waits and then transitions into patrol state.

  • Patrol - wanders in the local and neighbouring areas.

  • Investigate - moves to largest sensory input.

  • Chase - actively moves towards the player to attack.

​

The monster is blind but reacts strongly to noise, to represent this many interactable elements (and the player) will emit noise data in a radius.

gameplay.jpg
terry_edited.jpg

Patrol Pathing

To allow for the monster to patrol the whole facility we wanted a system that would allow patrol locations to be placed on the navmesh that could automatically connect to neighbouring points within a given radius (or manually connected).

​

This was done with the intention of allowing the AI agent to autonomously choose a new patrol location within its local area rather than having it follow a strict route.
Due to time, weighting the nodes was omitted.

bottom of page