Goodbye Unity

When I first started developing Highland Hearth, Unity felt like the obvious choice.

My goal was to create a pixel-art village simulation game entirely from scratch, including all of the artwork. At the time, Unity was widely regarded as one of the best engines for 2D game development, with a huge community, extensive documentation, and countless tutorials available for almost any problem.

Over the course of several years, working evenings and weekends around a full-time job, I built the foundations of Highland Hearth in Unity. It was where I learned many of the systems that would eventually shape the game: procedural world generation, villager management, pathfinding, chunk loading, and UI design.

While Unity helped me get started, a combination of policy changes and my own evolving needs eventually pushed me to look elsewhere.

Discovering Godot

After exploring alternative engines, I decided to give Godot a try.

What initially attracted me was its open-source nature and growing reputation within the indie development community. What surprised me was just how well suited it felt for the kind of game I was trying to build.

Many of the workflows that felt complicated in Unity were significantly more straightforward in Godot. Features such as tilemaps, terrain tools, navigation systems, and scene organisation felt more natural to work with, particularly for a large-scale 2D simulation game.

The transition wasn't instant. Learning a new engine meant rebuilding familiar workflows and adapting years of habits from Unity. However, once I became comfortable with Godot, development accelerated dramatically.

Looking back now, moving engines was one of the best decisions I could have made for the project.

The Unity Prototype

Although the Unity version was ultimately left behind, it wasn't wasted work.

In many ways, it served as a prototype that helped me understand what Highland Hearth needed to become. The systems I built taught me valuable lessons about performance, scalability, and game design that continue to influence the current version of the game.

Villager Creator

One of the systems I was most proud of was the villager creation screen.

Players could generate a group of starting villagers, each with unique stats, traits, professions, and family relationships. Creating believable relationships between randomly generated villagers turned out to be a surprisingly complex challenge, as family connections needed to remain consistent across the entire group.

While the interface itself will likely be redesigned in Godot, many of the underlying ideas have carried forward into the current version of the game.

World Setup

The Unity version also included an early world generation setup screen, allowing players to configure world size and generation settings before starting a new game.

Although fairly simple by today's standards, it laid the groundwork for the procedural world generation systems that would later become a major focus of development.

Early Game UI

I also began building the in-game interface, including a hotkey bar and villager management panels.

These screens allowed players to view their villagers, inspect their professions, and assign new roles within the settlement. While the current vision for Highland Hearth has evolved considerably since then, many of the concepts explored here still remain important today.

Loading and Performance Lessons

One feature that perfectly demonstrates how much I've learned since then was the loading screen.

At the time, the world generation process ran entirely on Unity's main thread. This meant the loading bar would appear to progress normally before freezing while the game generated the world in the background.

It technically worked, but it wasn't a particularly elegant solution.

Experiences like this taught me a great deal about optimisation, multithreading, and how important performance considerations become as projects grow in complexity.

Procedural World Generation

Procedural world generation was one of the earliest major technical challenges I tackled.

My goal was to create large, randomly generated worlds using layered noise maps to produce varied terrain, biomes, forests, mountains, and coastlines.

Unlike block-based games, I wanted terrain to blend together smoothly. This required creating systems that could determine which tile graphics should be displayed based on surrounding terrain, allowing grass, dirt, forests, and other environments to connect naturally.

While the system achieved the results I wanted visually, maintaining and expanding it became increasingly difficult. Looking back, it was one of the first areas where I realised I needed better tools and workflows.

Chunk Loading and Object Pooling

Large worlds introduced another challenge: performance.

To keep the game running smoothly, I built a chunk loading system that only loaded the sections of the world currently visible to the player. Alongside this, I implemented object pooling for trees and other world objects to reduce unnecessary memory allocations.

These systems worked, but they also introduced additional complexity and edge cases that became increasingly difficult to manage as the project expanded.

The experience proved invaluable, however, and many of the lessons learned directly influenced the systems I later built in Godot.

Villagers, Tasks, and Pathfinding

By the end of the Unity prototype, villagers were already capable of carrying out simple jobs.

Using grid-based pathfinding, villagers could navigate the world, gather resources, chop down trees, and deliver materials to stockpiles. While relatively basic compared to the systems currently planned for Highland Hearth, these early mechanics represented an important milestone.

For the first time, the world felt alive.

Watching villagers move around the settlement, gather resources, and contribute to the growing village was the moment the project started to feel like a real game rather than a collection of disconnected systems.

Looking Back

Revisiting the Unity project after more than a year away was a strange experience.

Like most developers, I can look at old code and immediately spot countless things I would do differently today. However, it's also a reminder of how much progress has been made.

The Unity version may no longer be in development, but it provided the foundation for everything that followed. The artwork, design ideas, technical experiments, and lessons learned all carried forward into Highland Hearth's current development.

Most importantly, it taught me the fundamentals of building a simulation game from the ground up.

Without the Unity prototype, there would be no Highland Hearth as it exists today.