Petrichoria

Petrichoria is a farming, social, and management sim built around fairies and fae creatures, developed at Code Cozy in Unreal Engine 5.5. I joined in June 2025 as a systems developer and designer on a team of roughly ten, and owned four of the core gameplay systems: save/load, farming, inventory, and building.

The premise picks up after the world gets saved. A group of adventurers is returning to normal life and finding the aftermath everywhere — damage they caused, damage the big evil caused — and trying to remedy it. You play as a Fae who starts a tea shop and a farm to make a living.

The Save System

The project was using a third-party save plugin that wasn’t holding up. Persistence was unreliable and loading a save back in rarely landed cleanly, so rebuilding it was the first thing I took on.

Day and time, NPC locations, farm state, inventory — all of it had to survive a save and reload reliably. I reworked the plugin into something functional and extensible, using a mix of custom serialization and Unreal SaveGame objects depending on what each system needed.

One advantage of the timing: since existing saves weren’t reliable anyway, I didn’t have to preserve backwards compatibility. That freed me to restructure things properly instead of patching around the old format.

The system supports both autosave and manual saving. The harder requirement was persisting NPCs mid-action so they resume what they were doing on load rather than snapping back to a default state. I also built debugging tools to read, edit, and clear save data both from inside the game and directly in Unreal, which made everyone else’s testing faster.

Farming

The farming loop follows the standard for the genre: till a plot, plant a seed, water it, and keep watering it daily while it grows. Crops can wither and die from neglect, and also from environmental pressure like seasons turning over.

Inventory

The inventory started from a multiplayer crafting/survival plugin already in the project. I took it and built it out into what the game actually needed — resizable inventory, dropping items, chests, and hotbar usage. It also had to feed the building system, since builds require specific materials and tools.

Items are a custom struct, with each item category defined as its own struct variant. They were spread across several data tables; consolidating those down to a single table and removing duplicates was in progress when development stopped. Everything lives in a local database and gets serialized through the save system to keep the two in sync.

I also reworked the existing inventory UI to add the new pages and dialog popups. The game was early enough in development that the leads were mostly artists, so there was a lot of good material to build against. Menus are Unreal widgets.

Building

The player gets a dedicated stretch of land behind the tea shop for building and farming, with sections walled off behind future unlocks. You enter build mode from a crafting bench, then walk around placing building blueprints wherever you want them — the system compensates for ground level, checks collisions, and respects what you’ve unlocked so far.

Once a blueprint is placed, the player gets a checklist of what the build needs: materials plus specific tools. That requirement is what set it apart from the usual farming-game approach, where you place something and it simply exists.

Free-form tilling — letting the player farm anywhere on the map instead of only inside the designated plot — was planned and would have run on the same placement logic, but it didn’t get resourced for early access.

Optimization

The game had real framerate problems, and the two biggest contributors were water and lighting.

The entire map was built as a single Unreal level, with one giant ocean stretching across all of it — out to the horizon and, unhelpfully, underneath the terrain as well. I trimmed the ocean so it no longer existed under the landmass, then wrote simple shaders so water outside the player’s view isn’t processed at all. From there I tuned the water physics plugin’s parameters to hold the look we wanted at a much lower CPU cost.

Lighting was the same story: very intricate lighting spread across the entire map, all of it live. I reworked it to follow the player and adjusted reflections and tracing to bring the cost down.

Working On A Team

Around ten people, coordinated through Jira tasks, Discord, and GitHub changelogs. I wasn’t the only developer-designer, but the other focused more on level design and NPCs, which left the core systems to me. The project lived on GitHub, and I kept an additional local backup on my own Perforce server.

Design decisions were made as a group in weekly meetings — we’d talk through what we could realistically implement, scope time frames, and turn it into Jira tasks from there.

Status

Development stalled in May 2026 when leadership stepped away for health reasons and the team dispersed. The project is unreleased. I’m still part of the team if it comes back together.