top of page
Enter a world and venture on a journey to banish a deadly miasma as the last of the Moon Priestesses through an small-open world, exploration game.

Solo Passion Project 

Engine: Unity 6​

Duration: 7 Months - Completed June 2026

Genre: Exploration, Text-Adventure

As a passion project, I wanted to build upon skills and systems I wasn't able to explore fully before. I chose a crafting and inventory system to challenge my capabilities. In addition, I wanted to experiment in 3D with this project as I normally stick to 2D with its ease of art creation, camera and player movements.

 

The goal of this project was that I wanted to create a game that allows me to expand upon my knowledge and test myself with no time constraints allowing me to do just that. Moreover, I wanted to combine gameplay elements from other games I enjoy as inspiration.

Events 

I used an Event Bus to better handle communication between scripts and to allow event management to be centralized for easier troubleshooting and readability across scripts. I also created a base interface for all specific events to inherit from.

I also used an Event Bus because I have familiarity with using one before. 

Screenshot 2025-09-16 174652.png
Events - Moon Game.png

Player 

I utilized a StateMachine for my player controller as it'll provide me the most freedom with player functionality split across designated scripts, and my player controller will be more readable with  functionality separated. 

I chose to work with a StateMachine  because I wanted to get more comfortable with them as they're commonly used for their flexibility, such as for enemy functionality and quests behaviour. It would also be valuable knowledge for me for future game projects.

Player - MoonGame1.png
Player - MoonGame2.png

Inventory 

I utilized scriptable objects to handle the construction of an inventory item and the full inventory. I chose this approach as I'll have a larger number of items, allowing more flexibility across any or all items' construction. The inventory slots are more for visual purposes on the UI for currently held inventory items.

I have a separate inventory manager script responsible for all the inventory functionality, such as adding items, removing items, and more. 

Crafting materials and craftable items are also inventory items, and that allows for easy recognition if the correct materials are in the player's inventory. I wanted to reuse assets as much as I could.

Creating a separate inventory scriptable object was to get around coupling between the inventory manager and the crafting manager when they would need to communicate if certain materials were in the inventory to successfully craft an item.

 

This results in changes successfully being made to both the inventory slots and the overall inventory when any actions were made, whether it'd be crafting, dropping items, picking up items, or more.

Inventory - MoonGame 1.png
Inventory - MoonGame 2.png

Text System - Moon Puzzle

To make the text system flexible enough for all the use cases I would be needing for this game, I implemented scriptable objects. This allowed for dialogue and button options to be easily editable across different moon puzzles.

I wanted a maximum of three option buttons that could change dialogue for a single dialogue branch. What's shown is the structure of the buttons' messages of what each button's text should display as well as which button number will prompt the next branch of dialogue to successfully progress to the next moon puzzle's question:​​​​​​

MoonPuzzle - MoonGame1.png

For dialogue that would iterate when progressing through the moon puzzle, I made a new structure object to make the puzzle branching unique based on the player's actions. These dialogue branches would be triggered by whichever button the player chooses to press and prompted by the text adventure UI responsible for moon puzzling.

 

The scriptable object are the dialogue branches for each trial, and this allowed for dialogue to be edited individually.

I chose to make unique dialogue branching to develop variation across the puzzles and increase difficulty. 

MoonPuzzle - MoonGame2.png

Text System - Storytelling

I understood at the beginning of this project I would be creating two different types of text-adventure systems with differing levels of complexity. For UI that'll only iterate through dialogue upon a button/mouse click, I would need a simple scriptable object for that. 

I wanted to reuse assets as much as I could, so this scriptable object is also reused for a smaller dialogue box on the main player UI.

Because I'm reusing this scriptable object for dialogue on the main player UI that'll be on a smaller display, I needed to distinguish keywords to stand out to the player, so I made an array of keywords for that. 

For keywords to be visually clear in the inspector, I grouped keywords with every individual dialogue message within a serializable class. 

Storytelling - MoonGame.png

Conclusion

Troubleshooting

I definitely learnt how essential troubleshooting is with this project. I made multiple iterations of my systems when I needed to add features further into development. It taught me to be extremely thorough in my playtesting and meticulous in my codebase, having missed issues that I catch into the later stages of the project. Overall, this project taught me how intricate and delicate inventory and crafting systems can be in larger-scale games with how closely they work with each other.

Experimenting with 3D 

I had experimented with 3D modelling because I wasn't able to find assets that matched my vision. I made all the moon statue models, excluding the crescent moon, and the ghost's cape, all in Blender. While 3D modelling is not my focus for game development, I got to test my skills from college and put them to use and learnt a few tricks navigating Blender's interface. I've gained a greater appreciation for 3D assets and games as a whole because of this. Programming a 3D character controller made me more comfortable working in 3D; furthermore, I became more comfortable with using Cinemachine for my camera system, needing both systems to work accordingly and seamlessly. 

Documentation

I became more comfortable in providing documentation for my project, having allocated meaningful time to detail each aspect of my game. Furthermore, I wanted to better structure my scripts and better refactor them. I commonly forgot my progress whenever I took breaks and would come back to this project given the scale of it, so I understand why documentation is necessary, even external notetaking. 

New-found Knowledge

Before this project, I had little knowledge and experience working with post-processing, lighting and environmental effects. Now, I understand lighting on a deeper level performance-wise and utilization-wise in scenarios I needed certain lights to behave in a particular manner. I'm more confident in post-processing, choosing and modifying effects that enhances the gloomy atmosphere to match my vision, as well as understanding performance costs to keep the number of effects to a minimum. Although, I know not every aspect of a game can be perfect, especially performance-wise when it's developed by one individual, so I became creative with the environmental fog and diverge away from my initial plans. Combined with post-processing, I was able to create a depth of field for the camera to mimic real-life fog. This keeps the fear of getting lost in the dense miasma much more real and dangerous, nudging the player to always be cautious. 

What I would do differently

What I would have done differently is fully planning out exactly how I wanted my inventory and crafting systems to function together to minimize the amount of times I needed to reiterate those systems. I missed features that I initially wanted but never wrote anywhere, even minor features, that I'd only pick up after several hours of playtesting. This caused me to back track multiple times and development time to lengthen without making meaningful progress. 

Motivation

Having no time constraints meant I had to be my own motivator, needing to set aside meaningful time for this project. While I took breaks, I became more in-tune with how I work, needing to be both a leader and a friend to myself. This project was a great experiment for me. Including elements from games I enjoy kept development fun and made me remember why I enjoy programming for game development. 

bottom of page