Unnamed Project

This project is currently in development by myself and some members from GalactiCrab Studio. The project has been in development for 8 months and the team presently comprises 7 members: 3 Designers, 3 Artists and an Audio Designer.

The game is being created using Unreal Engine 5. The team is utilising Agile Development and Git Version Control.

My primary role is as a game designer and I am one of the leading members of the team, heavily influencing project direction and feature production.

My notable contributions so far include:

– Collaborating with other designers to idealise and write the Game Design Document.

– Designing and Prototyping game systems in UE5 with Blueprints.

– Concepting the game’s narrative and characters.

This project’s purpose is to support everyone on the team to further develop their skills and continue collaborating with each other after graduating from university.

Game Concept

Explore a small open world map (top down 3D) with varying biomes, gathering resources and ingredients to customise your home and make food to serve at your daily picnic for the local community. Whilst exploring and at your picnic you have the opportunity to interact with a diverse cast of characters and develop friendships with them. Your goal: get to know all of your neighbours, then build this group of strangers into a close-knit community of friends.

Find and talk to various characters around the neighbourhood. Learn about their daily schedule, history, and opinions on food, furniture and other characters.

Gather resources using a collection of tools from the surrounding area. E.g. Chop down trees with your axe to collect Logs and Acorns, Break boulders with your pickaxe to gather rocks and crystals and use your litter picker to obtain various junk from the Junkyard.

Use your collected resources to either:

– Customise and decorate your home and picnic area with new furniture and embellishments.
– Create food to serve at your next picnic.

Host your daily picnic for the local community. Characters may attend your picnic depending on their relationship with you, if they are interested in today’s menu and how much they like your picnic area.

Core Game Design Principles

We want to replicate the casual and chill atmosphere found in games like Stardew Valley and Animal Crossing but with a focus on the stories surrounding a unique cast of characters. The intended outcome is a relaxing experience where the motivation to move forwards is driven by the player’s own interest to learn about the characters or decorate their character’s home.

The game won’t have any consequences for playing slowly, and the pace of the story is completely controlled by the number of interactions the player decides to have with each character. Whenever time is limited, such as in the exploration segment of the game, there is no consequence to running out of time. Character’s follow a schedule, but you can always talk to them at the picnic or fairly soon the next day most of the time, and the player can always find something useful to do while waiting for a certain character to be available if they need to.

Another important aspect of the gameplay is the player’s ability to express themselves. The main method for this will be through the ability to decorate the player’s home and picnic area with furniture and decorations, making every player’s home area unique to them. The player can also interact with characters in a variety of ways via dialogue choices, which can affect character’s opinions and the relationships the player has with them.

Developing from Coffee with Cryptids

This game is absolutely the spiritual successor to Coffee with Cryptids, a casual game previously developed by GalactiCrab where you manage a cafe.

In Coffee with Cryptids, there was a disconnect between the casual gameplay we were aiming for and the stressful nature of customer management. Whilst I believe that Coffee with Cryptids successfully created a relaxing atmosphere, creating that required simplification of many of the game’s mechanics that we originally intended for the game to add depth to the gameplay, such as crafting drinks and branching upgrades to your kitchen equipment.

This game intends to address this issue, by removing the need for depth in how you effectively serve your customers the correct drinks, and having this depth in mechanics centred around resource gathering and mini-games. Instead of crafting drinks as customers arrive and saving for upgrades which make that easier, the gameplay is all about how you get the ingredients in preparation for a picnic, and how you can get ingredients more efficiently to make more or better food to serve at the picnic.

In this game you have a whole phase centred around exploring the region for ingredients, and collecting tools or mastering minigames which allow you to obtain them. Interacting with characters in this phase is still an option if you know where they are, but the picnic phase, much like the work phase in Coffee with Cryptids, acts as the player’s main opportunity to interact with the characters and without the player having to work as a barista.

My Contribution

System Design and Documentation

Throughout this project I have contributed a steady input into the game’s system designs and the design documentation. So far, I have been responsible for designing the inventory system, time and events systems and character relationships systems. I frequently collaborate with Lyra Shillabeer, Billy Burton and other members of the team to discuss our game systems.

Every few weeks we review the design document to ensure it remains up to date and relevant, running over the systems we have been prototyping and adding any changes we have liked to the documentation. Not every game system has been fully detailed in the Game Design Document yet, some systems won’t go beyond basic conception until we have a clearer idea from our prototype how systems will exactly interact with one another.

System Prototyping

Most of my work hours on this project have gone into creating the game’s prototype. We have been using Unreal Engine 5 as it is currently industry standard software and the engine our team is most comfortable with (having spent our last project working in UE4). Myself and Lyra Shillabeer have been working together to prototype all of our game’s systems, starting with the most fundamental such as movement, interaction and inventory, and recently implementing resource gathering, trading and time progression. Every time one of us finishes a system we meet and discuss which system should logically be prototyped next.

We use an agile board to keep track of which systems are left to do, in development or finished (or in need of review). We also use Git Version Control to track our changes, and utilise branches for each new system we develop.

So far I have been responsible for prototyping the inventory system, trading system, time and events system, character relationship and attendance system and picnic food system. More details of each system prototype coming soon further down this page.

Narrative and Character Design

Whilst my main focus so far has been getting a prototype up and running, I am beginning to work more on the development of the game’s narrative and characters. As the main driving force of the player’s story, the main focus so far has been the character concepts. The team as a whole is always discussing ideas for new characters and developing upon the ones that we like the most. In order to keep track of our ideas and flesh them out into proper concepts, I have been working on writing up character profiles for each character. This should make creating content for each character easier as all of a character’s information is stored in their character profile sheet.

A character profile details the basic information about a character such as their appearance, residence and favourite food, and also the background and specific character quirks that myself and other team members have come up with. In the game every character will follow a unique schedule, of which the regular daily and weekly events for a character are presented in their profile as well. As development progresses I will be writing up a roadmap of each of the character’s stories, which the player will progress through as they interact with them.

I will also be working on other documentation regarding the game’s narrative and writing dialogue when we start implementing characters properly into the prototype.

System Prototypes

Inventory System

With a new focus on resource gathering mechanics, the inventory system would be influencing many other systems throughout the game. So it was important to set up the inventory infrastructure early and was the first system I worked on for this prototype.

The foundation of the inventory system is the item structure and the item blueprint. The item structure is a data type which contains the item type and its quantity, which feeds into the item blueprint, which is an interactable object which contains (and displays through its model) that item structure and when interacted with adds that item to the player’s inventory. There are 2 main inventories, alongside the player’s inventory there is also the storage inventory, which each store arrays of the item structure.

Player Inventory

The player’s inventory or “backpack” is a temporary item storage for the player to use when exploring to hold on to items that they find and move them around. The backpack is a part of the player blueprint and items are moved in and out of it through interacting with item objects and using the drop input. Every time an item is picked up, it is processed through a series of checks to ensure it ends up in the correct inventory slot, prioritising adding it to existing stacks of the same item type or the slot which is selected. If the player inventory is full it will also swap with the selected slot, dropping the items previously stored there.

Storage Inventory

The storage inventory is the record of all the items the player has found throughout the game and taken home. The player accesses the storage through an interactable station object known as the “Storage Box”. This object contains a large list of all item types the player has discovered and when interacted with displays this through a filterable menu interface. This was by far the most complex element of the inventory system to program, and required a large number of functions for ordering the items depending on a large variety of circumstances. However, I think it adds a lot to the accessibility of the game to be able to organise items in this way, especially in the future when the list of available items will be much longer than it is now.

There are 2 features which I have not yet implemented into the inventory system, the search bar in the storage menu, and stack limiting. These aren’t too important for the creation of other systems so we decided to push them down the priority list for now. I very much enjoyed creating this system, and I’m really happy with it as it’s not something I’ve ever made before. It involved a lot of fun challenges that I didn’t expect, helping me to grow as a game designer and programmer.

Trading System

Developing from the inventory system which allows the player to collect and store items, the next feature I prototyped was trading these items with the game’s characters. We didn’t yet have a clear idea of how trading was going to work, only that we didn’t want it to feel too transactional. The team felt that trading should feel like a personal agreement between the player and the character, in order to build on the game’s design pillar and theme around community, so it couldn’t just function like a shop. So for this system, I decided to start prototyping it to see what worked and what didn’t.

Whilst developing the fundamentals of a trading system, I worked to tune traditional features to better fit our game’s theming. For example, instead of characters having a list of items for sale with consistent prices, they have a list of “trades” that they would be interested in. A “trade” is a data structure that contains one item type and the amount that the character is willing to part with, and a list of items (with quantities) of which the character would accept one of in return. In one specific “trade” these details would not change, the player either chooses to make the trade or doesn’t.

To further enforce the concept that trading in this game as a conversation and not a transaction, the central focus of the trade menu is the character’s dialogue box. The menu doesn’t tell you what things cost, the character does and in their own talking style.

This system was definitely one of the hardest ones for me to work on due to how unclear the concept was. With the inventory system I had a fairly clear idea of what I wanted, and whilst I did add new features to it as I prototyped it, it still adheres to the basic design concept I initially came up with. However, with the trading system I started by creating the fundamentals of a trading system as I imagine a standard game shop system would work, then assessed, experimented with and edited each feature as I made them to increase their suitability with our design pillars.

I think it was fairly enjoyable, and proved a valuable method for designing a game system which I’m not used to. I’m usually the type to plan what I want to make, then make the thing, and change things that don’t work, but I found just getting into engine and experimenting with different mechanic ideas worked quite well here. The system could use a few tweaks, especially in the UX, but it now has its own concept and identity which it didn’t have before I made it. It is now much easier to brainstorm ideas, additions and changes to make to the system in the future. For example, I want to make it so some trades can also be completed by doing a favour for a character, rather than just giving an item, like a quest but integrated into the same system as trading.

One last thing to touch on is that I also worked on integrating this system into Lyra Shillabeer’s dialogue prototype for this project. Lyra’s dialogue system allows for us to easily create readable branching dialogue directly in blueprints using a Macro Library. Each macro represents a different aspect of a dialogue interaction. For example, a segment macro is a display of text in a dialogue box with a set talk sprite and a choice is a list of interactable buttons which lead into a switch statement changing the route of the dialogue interaction depending on what is selected. After creating the trade menu, I also created a macro for starting a trade in this macro library, meaning that trading can be accessed through a dialogue interaction rather than a specific input.

Time Progression System

Up until this point, I haven’t used time that much in Unreal Engine, other than for small things such as setting random intervals for object spawners. What we need is a system which counts up to a set number of seconds (equal to the length of an in-game day), constantly displays this time in a readable format and allows for certain events to take place at specified times. I achieved most of this by combining the use of an Unreal Engine 5 Timeline Node and a Set Timer by Event Node.

The Timeline Node is particularly useful and I know I’ll find it very helpful in future now I know how to use it. Here I’ve used it to keep track of the current time in seconds as a float, and then each frame it inputs this float into a function which converts it into a custom data structure which contains the number of in-game hours and minutes, which is then displayed on screen through UI. I then used the same technique with the Timeline Node to later update the position and colour of the scene’s light source each frame as well, simulating an in-game sunset and sunrise.

Some of this showcase also shows the phase system, which I will be writing more about soon down below.

I collaborated with Em Ellis, our team’s primary environment artist, to create appropriate lighting and shadow effects throughout the time of the in-game day which best reflects how we want it to look.

I used the Set Timer by Event Node to track scheduled events. At the start of the Timeline a timer is started which runs an event every second that checks if there are any in-game events listed to happen at that time. For example, at midnight the weekday changes to the next, and for a test I created an event where a character walks to a specified location at 20:10.

A Scheduled Event is a blueprint class which is spawned in the level at the time it is set to occur, it performs its functions on spawn and is handed any object references it needs from the gamemode class. All Scheduled Events information is stored in a datatable. In order to prepare the system for when there will be many scheduled events, they are organised via enum into daily events, weekly events and day specific events. At the start of each day, the gamemode runs a function which finds every event that can happen during the upcoming day (if it is a monday it will find and add every weekly event which happens on a monday) and adds them to a list which is what the Timer Event on the timeline checks through every second.

I don’t know if this is the most effective way of writing this system, but it seems to work without any issues and I’ve tried my best to prepare for any optimization problems that may come up. Either way this is just a prototype, so for now it’s good as it accomplishes everything we wanted the system to do and it functions as planned. We may research alternative methods in the future when we move past the prototyping phase of the project.