Coffee with Cryptids

Coffee with Cryptids is a top down isometric cafe management game where every customer is a cryptid or a ghost, and the way you decorate your cafe dictates which characters show up. It is being made in Unreal Engine 4, and draws inspirations from games like Hades and Animal Crossing New Horizons

In a group consisting of 5 Artists, 3 Designers, 2 Programmers, 1 Animator and 1 Audio Student, my roles are mainly in systems design and technical design, creating prototypes for various systems and implementing them into our game using Unreal blueprints.

Concept art by Jesse Hooson

Detailed Game Concept

The game revolves around 3 core systems, which I will explain in the rest of this section: The level editor and aesthetic system, the narrative system, and the drink creation system.

Level Editor and Aesthetic System

The level editor allows players to buy and place new objects inside the cafe, to fulfil a range of purposes. Some objects, known as Stations, unlock new ingredients that the player can use, or gives the player a new ability (for example, choosing which music is playing in the background). There are also furniture objects, which consists of objects like tables and chairs that customers can interact with, and decorational objects, which affect the cafe's atmosphere.

The cafe has 3 main stats (Creepy, Comfy, and Classy), which can be affected directly by placing decorational objects in the scene, although there are other stats which are affected by more specific conditions, such as Illumination, which is affected by the amount of light sources there are in the scene, or cluttered which is affected by how densely packed the cafe's layout is.

These stats directly affect which characters spawn in the cafe, since each character has a list of preferences regarding the stats. Mothman, for example, enjoy a classy and illuminated atmosphere, while he dislikes comfy or creepy cafe designs. This information is not directly revealed to the player and is instead shown to them naturally through discussions with various characters, as well as ghost npcs, which are generic characters with no specific plot points that give incidental dialogue hints.

The level editor allows the player to customise their cafe

Narrative System

Each cryptid character has a narrative made up of 3 story arcs, as well as a large quantity of miscellaneous comments, which are chosen in a weighted bag randomisation system which prioritises important story moments while still allowing characters to comment on relevant changes to the cafe, such as the player adding their favourite drink to the menu, or the player adding a decorational item that they dislike.

Once a character runs out of dialogue, their miscellaneous dialogue is recycled, but only after every other dialogue option has been shown, to avoid the player seeing the same dialogues multiple times in quick succession.

A cryptid responding to wallpaper they dislike, which could serve as a hint that they don't enjoy classy decorations

Drink Serving System

To serve drinks, the player must create a custom menu by choosing which drink to serve, then purchase ingredients from the game's supply menu. The cafe's barista, The Yeti, will then make the drinks for the customers that enter the cafe, and the player then needs to deliver the drinks to the customer, which will then display a dialogue event.

This is because we want the player to have to walk to each character to talk to them, but don't want the player to make the drinks themselves, due to this leading to the game becoming either too fast paced and stressful, or too slow and tedious. For a similar reason, viewing the game's dialogue pauses the game, so the player doesn't feel like they need to rush through things.

The game's supply menu

Summary of Contributions

As a technical and systems designer, my job was to create prototypes for various systems within the game, then implement them using Unreal blueprints, due to the small number of programmers we had to work with. As well as the systems that I have implemented, which I will discuss below, I also taught several of my teammates how to use Unreal Engine, since I was the most experienced person with the engine at the time. I've also been able to help answer questions and fix bugs that my other team members have encountered.

Upgrade Menu

One of the main systems which I created was our game's upgrade system: At the start of every day, the player has an opportunity to use the money they earned to upgrade the cafe's stations in order to unlock ingredients or speed up the time it takes to make drinks.

The current version of the upgrade menu

I took the original prototype of the upgrade menu, which another designer had created, and recreated both the visuals and code to make a robust modular system that utilises Unreal's inheritance system to easily trigger upgrade events. The new upgrade menu featured icons which visually change to show if the upgrade has been purchased and which upgrades are available next, as well as an aesthetically pleasing hierarchical branching layout which allows the player to easily see which upgrades need to be purchased first.

Supply Menu

The supply menu is the menu used to purchase the ingredients used to make drinks, and is probably the system that I iterated through the most. It consists of a list of purachasable ingredient, with a the cost and current count also displayed for each ingredient.

The menu itself is a container filled with cards which display different items in the pre construct phase based on an exposed variable, and display information gathered from a data table which contains a list of every ingredient in the game and their properties. This menu was the first time I had utilised these techniques, and I learnt a lot of valuable skills while working on it.

The supply menu originally had multiple tabs for buying items and viewing your inventory, because we originally planned on items having expiry and delivery dates, however we removed those features from the game because they didn't fit the calm and simple atmosphere we wanted our game to have, and also because they were confusing playtesters a lot.

Similarly, the first draft of the supply menu featured a checkout and cart system, which I originally implemented for the sake of realism and familiarity, however we discovered during playtesting how overly convoluted and unneccessary this system was, so I implented a simple click to buy system instead.

Level Editor

The game's level editor is the most complex system that I have worked on. It consists of two parts: A grid based loading system, and the object placing system.

The grid works by creating a map/dictionary matching grid positions to grid objects (or loading in an existing one if the player is revisiting the menu). It then spawns any objects stored into the world at those grid positions.

When the player selects an object they want to place, a preview object is placed on their cursor, which constantly checks what the nearest grid location is and checks to see if the object can be placed there, then changes the colour of the preview object to reflect this. Every placeable object inherits from a parent class and contains a variable dedicated to how many tiles the object takes up. When checking to see if an object is able to be placed, the object placing system checks the neighbouring tiles based on this variable.

The current progress with the level editor

When the player selects an object they want to place, a preview object is placed on their cursor, which constantly checks what the nearest grid location is and checks to see if the object can be placed there, then changes the colour of the preview object to reflect this. Every placeable object inherits from a parent class and contains a variable dedicated to how many tiles the object takes up. When checking to see if an object is able to be placed, the object placing system checks the neighbouring tiles based on this variable.

When an object is placed, it is added to the grid map/dictionary as a value for the corresponding grid location.

The UI itself is created from a series of cards which are spawned from a data table, similarly to the supply menu. Since this system also utilises knowledge on class inheritence that I gained from working on the upgrade system, it feels like the culmination of the techniques I learned during the rest of the project.

A diagram showing the different possible object size enums that are used to determine if an object is too big to be placed