UE5 Capstone Project

ROLE

Lead Game Designer, Systems Designer

DESCRIPTION

Asurya's Embers is a First-Person, Bow-and-Arrow shooter game created in Unreal Engine 5. Our team consists of 23 people, including 3 team leads and 2 producers.

My primary responsibilities were to maintain the vision of the game by communicating with 3 discipline leads(Design, Art, Engineering), and 2 producers. Besides my leadership responsibilities, I was also in charge of designing the overarching narrative of the project, major gameplay systems, and combat.

TEAM SIZE

23 Team members

PROJECT TIMEFRAME

May 2023 - Dec 2023

GENRE

FPS, Bow and Arrow, Run and Gun

ENGINE USED

Unreal Engine 5.3

MAIN RESPONSIBILITIES

Create a First-Person, Bow-and-Arrow shooter Game Experience

Produce and maintain design documents that can later be fleshed out into game systems

Lead a 23-person team, maintaining the vision of the project with open, and transparent communication

Design major gameplay systems, such as quest systems and combat systems

RESPONSIBILITIES & CONTRIBUTION

Below I will share my process of designing combat systems, quest systems, and interactable systems in this project. The systems I designed for this project include but are not limited to an engaging, balanced combat system, a flexible quest system, an interactable door object, and a note pickup object that allows the Player to immerse in the narrative. I am also involved in designing the starter level of the game - its iterative process is also documented below.

Combat System

Combat Design Components Overview

There are three major components to Asurya's Embers' combat design. We utilized available resources for all the components work together to form a cohesive experience.

Enemy Design Inspirations

Stemmed from the narrative background of the game. Our combat design team started enemy designs off with references from Asian mythological creatures.

Enemy Design Metrics

After reviewing the combat team's references, I came up with a table that metricizes the enemy parameters.

Enemy Design Round 1

After revieiwng the brainstorm phase, the combat team took the metrics I designed and fleshed out the selected enemy designs.

Enemy Design Round 2

After Round 1, the leads team reviewed all the designs and refined the designs to 6 enemy types based on gameplay needs and resources. Then, the design team moved on to finer behavior tree designs.

Enemy Design Final Round

Eventually, we ended up with four enemy archetypes that make up the core compositions of the combat dynamic - the Fodder, the Pusher, the Dive Bomber, and the Tank.

Enemy Archetype Stat Table

I took the existing enemy archetypes and prioritized them in terms of combat importance. Then, I arranged them based on roles in a combat composition.

Combat Balancing Sheet

I then started putting all the parameters in the metricized table into an Excel spreadsheet. Using HP, Damage Points and Animation Timeframe to calculate TTK, DPS, and overall arena kill time.

Quest System

First, I consider what information is needed for our quest. I know that I need a quest title, an objective, and descriptions for these items. Then, I drafted a data structure flowchart that demonstrates the way I want a quest to lay out. I have referenced the structure of Fallout 4 Quests Systems.

Then, I consider what information the system needs to communicate with each objective and objective item. I have added QuestID, and IsCompleted boolean to support a flexible scripting system.

Then I created a supporting system for the quest giver that kickstarts a quest and allows the Player to return the quest to collect rewards.

Implementation Details

This blueprint acts as a construction component of a Quest component that spawns in the scene, whenever a new quest is added in the game. This component retrieves all the detailed information in the quest (called by the ObjectiveID) and checks whether this objective is already completed, or if the quest has already been added. Then carries on to the next operation.

This Blueprint is a Function within the Quest Base component, which is used in the previous Blueprint example. The purpose of this Blueprint is to retrieve Quest Data details and return them to the construction graph. When setting up a system, I like to modularize components with functions that Actors can share and utilize.

With the ObjectiveID system in place, the interactable object simply needs to be set up with a universal Interaction Interface, which inherits two default functions. One of the two functions returns an Objective ID, that will be "heard" by the quest base component; once heard, the quest functions will carry on operation.

2023-09-25 19_19_52-Interactable_object.png

Door Object

As part of our narrative, the Player needs to converse with the villagers to get a sense of the current status quo. Due to the limitations of our production schedule, we will not have time to create an NPC character who can roam around the level. Instead, I designed "door objects" that the Player can interact with, and the NPCs will "speak with the Player from behind the door".

This door object will need to be an interactable object that plays a specific sound asset based on the progression of the quest.

The diagram on the right is my systems flowchart for this interactable object design.

Implementation Details

I've considered using Line Trace to prompt the Player to interact, but I've decided to use Trigger Box to prototype this functionality because our BP_Player is under development, and Trigger Box is the most stable way to prototype this object.

To modularize this interactable object, I created an Audio ID system and a data structure that allow designers to input the corresponding audio asset ID.

I have created a simple map structure to store the audio files, mapping to a simple Integer index. I hope to simplify the structure so the designers can reference audio assets with ease.

This section of the Blueprint detects whether the Player has entered the Trigger Box, if they have, then prompt the Player to interact. I am tracking the Player's state with a boolean, which can help me determine whether to fire the interaction event or not.

I am detecting the Player's input with a node because I am developing this prototype in isolation from the rest of the project. When integrated into the project, I will be using a universal interaction interface that is set up by our engineers. Here I use the Map data structure I created to track which sound to play. I made the Audio ID a public variable, which allows the designers to edit it from the Details panel instead of changing it manually via Blueprint.

Level Iterations

Before and After Showcase of Post-Tutorial Village Entrance

Before and After Showcase of Post-Tutorial Village Plaza

Before and After Showcase of Post-Tutorial Elder's House

Before and After Showcase of Post-Tutorial Player Sightline

PRODUCTION PROCESS

Pre-Production - Team Formation Process

One of the most difficult challenges for a team leader is how to manage resources and group teammates together to facilitate efficiency. We started with a team culture sync. We gauged the interest of everyone and started off with function teams.

Pre-Production - Identifying those Important Things

Is the game going to be in the 3rd Person Perspective or the 1st Person Perspective? What are the core game loops? What are the core pillars? I used mind mapping tools to record discussions with leads and designers, and identified these pillars and loops very early on in the development.

Pre-Production - Pacing & Narrative

I decided early on that our game will be in a hub-and-spoke structure, inspired by games like Dishonored. Then I tried to identify narrative beats for the game, where the Player can design an appropriate mission for their repsective levels.

Pre-Production - Pipeline Development

I wanted to make sure the cross-disciplines are working as cohesively as possible with smooth communications, and I wanted to develop a sense of continuity as we moved forward in development process. To achieve this, I designed multiple pipelines that makes the most sense for our team.

PROJECT SHOWCASE

PROJECT POST-MORTEM

What Went Well

Pre-Production Planning
- Our leads team has used the pre-production time to identify the core production pipelines, such as our mod kit production pipeline, level design production pipeline, and UI design pipeline.
- As a result, we did not have to do a lot of asset cuts, and all the art assets created were used in the final build.
Vertical Communication and Communication Transparency
- Our team encouraged vertical communication transparency, team members felt comfortable sharing their thoughts and concerns with the leads team and those concerns were taken into meetings and were properly dealt with.
Identifying the Core of the Game and Making Cuts Early
- As a GD, I spent a lot of time during the production evaluating the core "fun" of the game and our minute-to-minute gameplay.
- As a result, we were able to boil down to key gameplay abilities and enemy types that contribute the most to our gameplay experience.
Maximize Team Resources for Optimal Production Quality
- At the beginning of production, we identified a team culture, which is to create a near-AAA quality project, even though it means sacrificing gameplay time.
- We scoped and planned out art style, asset creation pipeline, and clear team formation around that team culture.

What Went Wrong

Integrating Playtest Notes from Playtesters
- While we set up a playtest pipeline early in the development, we were unable to fully integrate each playtest session's notes into our development interaction process.
- A lot of playtest notes were concerning features that were either in progress or not yet implemented but planned.
- I believe we missed out on many polishing opportunities because of this.
Late Integration of Narrative
- I neglected the importance of narrative in this project hence the narrative was incomplete when the game launched;
- Narrative decisions were not made systematically, many narrative points were decided within a day.
Not Involved Enough in Level Iteration Processes
- I should have been more involved in the iteration processes of all levels to ensure gameplay experience consistency.
- I have not done enough gameplay progression balancing to ensure combat experience between levels.

Even Better If...

Playtest Notes are Organized into Production Plans
- When we receive playtest notes, it would be best if all the items mentioned are organized into actionable items in a production plan, so that we can work each item into our production schedule.
- We can also prioritize these feedback items into impact and workload - so we can better gauge what needs to be done to make the experience better.
Host Game Direction Announcement Per Milestone
- Near the end of the production, some team members and the lead team are not on the same page about the direction of the project.
- I believe it would be beneficial for me to host a short game direction meeting with the design team to reinforce the current direction of the game, and be transparent about some of the design decisions throughout production.
Make Bolder Level Size Cuts
- The early stage of the development should have a lot more level size cuts to prevent level size blowout.
- Enemy count can increase based on the size of the combat arena.