Sour Security

2nd person sandbox puzzle, where you play as a security guard who hacks an office environment to knock out his coworkers.

The game is based on a prototype I developed in the week leading up to this project, which can be found here.

Key Takeaway The importance of readability

TO BE ADDED

RoleTech Gameplay Designer, Product Owner

EngineUnreal Engine 5.4

Team Size7

Timeline4 weeks - Q4 2024

Ideation 3 days

Prototyping 7 days

Production 4 weeks

Overview

Main Challenges

Creating puzzles from individual systems

Making the game readable with a high amount of in-game objects

Highlights

System interactability - ELABORATE

Object highlight system that ensures that the player isn't overwhelmed with the amount of available choices

Onboarding system that ensures that the player performs the action being taught before proceding to the next lesson

Project

Project Brief

Create a game in Unreal Engine based on the theme of AI

Team Goal

Make a 2nd person sandbox puzzle game, where the player eliminates NPCs using the environment without getting caught

Design Pillars

Sillyness

Use simple systems interacting with each other to create comedic, memorable moments

Guilt-free fun

Mess around with people without feeling guilty about it

Tactical genius

Plan and execute the perfect way of getting revenge

Core Gameplay Loop

Gameplay Design

Problem Puzzles were simplistic

No need to think more than 1 step ahead - NPCs could be attracted to knocked out using a single object

Few ways of combining mechanics - leading to the gameplay lacking meaningful depth

Solution Separate crowd control and knock out

Objects that could distract could no longer also knock out NPCs

Crowd control now played a bigger role outside of distracting non-targets to avoid detection The player now has to set up their target's position more carefully, which can require multiple steps.

Gameplay gained complexity giving the game more depth as a whole

Iterations: Iteration 1 Distract and knock out on single object

Players could use a single object to both make an NPC move to it and knock it out
Reason for next iteration
Gameplay felt too simplistic and lacked the tactical depth that we had set a a design pillar

Iteration 2 One function per object

Each object got one function that they can perform. This way, players have to study the level and plan using different objects to knock out an NPC - increasing gameplay engagement.

Solution Shoot to knock out

Objects that can knock out targets at a range

An additional tool for players to knock out their targets

Slapstick humor that was appreciated by testers and observers

Technical Solution: Step 1 Trigger shot

Holding the interaction button initiates interaction and starts filling the power bar.
The force of the shot is determined by how long the interaction button is pressed for, and is automatically triggered after a max press time.

When triggered, a projectile object is spawned at a set location and launched forward.

View blueprint

Step 2 Knock out on hit

If something was hit, check that the velocity was above the set threshold it triggers knock out on the NPC
View blueprint

Problem Difficult to read the game

Hard to find cameras - made navigation harder

Hard to identify object functionality - there was no way of judging the type of interaction an object had without interacting with it

A lot of interactable objects at once - increased cognitive overload by providing too many options at the screen at once

Solution Object highlight manager

The game had a highlight feature that highlighted objects targeted by the player, or all interactable objects in the entire level when the Alt-button was being pressed.

I designed and implemented a system that divided the level into three areas and kept track of the player's progress between them, only enabling objects in the current area.

I also adjusted the design of the highlight feature that would help players differ between different types of interactions, which was implemented by a developer teammate.

Less simultaneous highlights on the screen - reducing the risk of cognitive overload

Different colors for different interactions - helped players identify which objects can be used for distraction, knock out etc...

Iterations: Iteration 1 One color for all objects

All objects had a yellow highlight.
All objects in the level would be highlighted when the highlight button was pressed

Reason for next iteration
Too many objects were shown on the screen at once
Hard to predict object behaviour without first interacting with it.

Iteration 2 Different colors, object subsets

Each type of object has their own color.
Level was split into three areas, and only objects in the active area can be interacted with and highlighted.

Technical Solution: Step 1 Prevent interactions

If an object's interaction setting is set to disabled, incoming requests for interaction and highlight are ignored
View blueprint

Step 2 Elimination check

Whenever an NPC is knocked out, it's removed from the list of remaining targets.
If the list becomes empty, the next area is triggered.

View blueprint

Step 3 Enable and disable areas

When triggered, boxes in the selected area do a box trace and enable or disable objects hit by the trace
View blueprint

Solution Moving cameras

I implemented passive movement and a blinking light as a way to draw attention to cameras, to make them stand out more in the environment and helping players to identifying them quicker

Cameras were easier to see thanks to the motion and blinking light

Added immersion, as the camera movement added to the feeling of someone watching over people

Iterations: Iteration 1 Static cameras

Cameras not possessed by the player would stay still
Reason for next iteration
Playtests showed that it was hard to identify cameras among all objects in the level

Iteration 2 Moving, blinking cameras

Cameras move side to side and have a blinking red light when not possessed

Technical Solution: Move camera when unpossessed

By default, a camera has passive movement enabled, and disables it when it's possessed by a player.
It keeps rotating between the positive and negative values of a set max angle, starting from it's starting rotation.

View blueprint

Problem Limited onboarding

Early onboarding was short and limited, not introducing players to parts of the game

Players missed game mechanics - because the tutorial was limited to a separate area

Players couldn't skip non-functional dialogue that was put there for narrative reasons

Solution Onboarding system

I designed and implemented an onboarding system that would let players skip narrative dialogue and wait for the proper action to be performed before moving on to the next onboarding step

I used dialogue functionality developed by a teammate to show and hide text, and made some adjustments to make it skippable

Opt-in to narrative - players who aren't interested in narrative can skip it

Players can't interact with disabled objects - reducing the risk of players having to start over due to incorrect order of actions

Iterations: Iteration 1 Limited onboarding on separate level

Tutorial that showed how to change camera, distract and knock out by electrocuting an NPC
Due to technical issues before a milestone, the onboarding was moved to a separate level with limited objects and interactions

Reason for next iteration
Players didn't get to try out all mechanics during the tutorial.
Players could perform other actions than the ones requested in the tutorial, possibly preventing them from progressing further.

Some players found it frustrating that narrative dialogue is unskippable.

Iteration 2 Full onboarding on main level

Tutorial works in the main level
Objects can only be interacted with once they are enabled, keeping the tutorial streamlined and reducing the risk of getting stuck

Multiple objects can be enabled at once

Narrative dialogue can be skipped.

Technical Solution

Step 1 Set up onboarding events

All onboarding events are added to an array as a struct

The struct contains:

Actor to highlight (if any)
Dialogue to show
What type of interactions to enable
Any other actors to enable without blink
If dialogue is skippable
Action index for objects that are reused
Name of speaker (character or controls)

Step 2 Trigger onboarding event

Each onboarding event triggers a dialogue.

If an actor has been set in the struct, it is enabled for interaction and starts blinking

View blueprint

Step 3 Perform action

When the blinking object is interacted with it triggers the next onboarding event

View blueprint

Product Owner

Responsibilities

Define a vision together with the team

Support ongoing work to ensure that we work towards a single vision and correct course when necessary

Plan development efforts by proritizing features and defining milestones

Help with cross-discipline communication to ensure alignment for tasks that involve multiple teammates

Plan VS Outcome

Learnings Simplicity over efficiency

When we initially planned the development of the AI system, we split the delivery

Cross-Discipline Communication

Getting the ball rolling

First draft of how the narrative can be intertwined with onboarding

Communication

Game Design Document

I put together a very high level game design document for the team to rally around. The goal was to be concrete enough to paint a picture of what we are trying to make, without restricting creattivity too much.