top of page

Medieval Chicken Courier, July 2023 - Nov 2023

Project Overview & Responsibilites

Medieval Chicken Courier is my capstone project. It was a collaborative effort of five designers and six artists. The project was a first-person, parkour adventure game about delivering chickens and avoiding thieves. In this project I worked as a Technical Designer in Unreal Engine 5.

What I did

  • Created and iterated upon a quest system aimed towards designer use.

  • Scripted a first person character controller with parkour mechanics.

    • Wall-running​

    • Ledgegrabing

    • Wall jumping

    • Picking up and interacting with objects

    • Interacting with AI

  • Documented system functionality using Miro and Confluence.

  • Collaborated with engineers to create a class hierarchy.

  • Worked with artists to provide feedback based on engine implementation and adherence to art style.

  • Prototyped gameplay mechanics according to meet design goals.

Contribution Summary

Movement Mechanics

There are two movement mechanics in the game. A "grounded wall-run" which was a wall-run that had an arch to it, and a ledge grab. These served as the player's traversal mechanics while delivering chickens and avoiding thieves.

Interactions

I implemented most gameplay interactions into the game. This includes interacting with objects (Chickens, barrels, crates), interacting with thieves, and interacting with vendors. 

Quest System

The Quest System is the back bone of the core game loop. It went through a full overhaul in the second month of the project's life-span. The base of the system was made using a tutorial, I added onto that base to fit our project needs.

Advanced Movement 

Wallrunning and Ledgrabbing were our the two advanced movement mechanics in the game. I worked on the implementation of both mechanics throughout the duration of the project.

For the most part I had the logic of the wall-run already together. I ported some code over from a side project then modified the wall-run to incorporate the arch motion depicted in the video. The ledge-grab was ported over as well . However without a root motion animation I was unsure how to implement a ledgegrab which was smooth and felt good. The result is a ledgegrab which feels pretty bad. I attribute this mostly to the fact that I used a timeline to lerp the player character to the top of the ledge.

Implementation

I thought of the wall-run in terms of movement vectors. When the player first attaches to a wall they move with a starting vector of (0.5,0.5), at the plateau the vector equals (1,0), when the player is falling the vector equals (0.5, -0.5). So by lerping from the starting vector to the falling vector a arch is created. To figure out wall-run duration I took into account the players speed when they initiated the wall-run.

image.png

A visualization for the movement vectors I was discussing.

The ledgegrab performs two linetraces, one above the player. The other is directly at chest height. When both hits are valid, we move the character to the chest height hit location, then if the player ops to climb onto the ledge they are moved to the above trace hit location. After revisiting this project I wanted to fix the slow feeling ledgegrab, I did this by converting the timeline functionality into a lerp. You can see a side by side comparison below

Lerp ledgegrab demonstration

Timeline ledgegrab demonstration

Quest System
Implementation

I wanted to make the quest system flexible to encompass future game mechanics. I found this flexibility in a tutorial that I used for the foundation of the system and then tweaked it for this project. This tutorial used components for the core logic of the system and a data table for quest setup. I extended the functionality of that data table, adding the ability for designers to add loss conditions per objective within the quest, select what kind of main objective the quest should activate, and other additions. To make sure I understood the system enough to explain it to others I made a diagram of how information flowed within the system.

I also made supporting blueprints for the system such as such as quest interactables and quest givers. These blueprints and the data table were the two things designers interacted with the most when making quests. I then made documentation to show designers how to use this system.

Documentation

The documentation was made using Miro. In the documentation I break down each element of the data table along with providing a step by step tutorial for creating a quest in-game. Below is part of the documentation, in these images I display a data table and UI element side by side to explain to designers what data correlates to what outcome. 

For the step by step tutorial I tried to leave as little room for confusion as possible. I frequently highlight, draw arrows to, circle or do whatever I need to in order to make sure that the tutorial is as straight forward as possible.

Quest System Challenges

The quest system had usability issues. Designers ran into confusion setting up objectiveIDs. Every step-specific actor needed to have a step-specific objectiveID. This confusion meant that designers were unable to use the quest system to its fullest capabilities. This is how I would redesign the objectiveIDs. A stageID would replace all objectivesIDs, which would be used for all items of a specific stage. This change would eliminate the need to input multiple different ID's across actors, instead centralizing it in one. 

image.png
image.png

This system also suffered UX problems. In the above diagrams, you see a total of nine quest items. A designer would have to click on each actor and enter the ID, a total of nine times. I would fix this by creating an editor utility widget to add and remove IDs from selected actors. This would improve the system workflow by allowing designers to enter the ID once then apply it to multiple actors.

image.png
bottom of page