How a Small Indie Team Is Building a Fully Simulated Sandbox RPG in Valorborn

Valorborn is a new medieval sandbox RPG built around the idea of a “living world” that just launched in Early Access last week on Steam. The project leans heavily into interconnected systems, where AI behavior, faction dynamics, and player decisions all feed into a reactive sandbox rather than a scripted experience.

In this interview, the development team shares how they approached building a world that exists independently of the player, why systemic design sits at the core of the experience, and how they’re tackling the technical realities of simulating large-scale environments with limited resources. From layered AI logic to performance-conscious world simulation, the discussion offers a detailed look at what it takes to make a sandbox RPG feel truly alive.

Working in Unreal Engine 5, the team also breaks down their pipeline, optimization strategies, and how Early Access feedback is shaping the game’s evolution toward full release.

Valorborn is positioned as a highly systemic sandbox RPG where players can forge their own path. What were the core design pillars that guided development from the beginning?

Onurhan Akçay, Laps Games Founder and Game Developer: From the very beginning of developing Valorborn, we focused on three fundamental design pillars: a living world, player freedom, and the organic interaction of systems.

Our goal was never to create a large open world. We wanted to build a world that felt active while the player was exploring it, a world with its own dynamics, a world that continued to live independently of the player. That's why we designed the world around systems, not around quests.

The second important point was to truly give the player the space to forge their own path. We value the player not just for following a pre-written route, but for producing different outcomes through their own decisions.

The third pillar is the interconnectedness of this entire structure. AI behaviors, the economy, exploration, conflict, faction relationships, and environmental interactions function not as separate systems, but as parts of the same world. This systemic integrity is what truly defines Valorborn's identity. This system wasn't easy for us to build. That's why we're launching it as an early access title. We will continue as planned throughout this process.

The game emphasizes a living world with AI-driven behaviors, faction conflicts, and player-driven outcomes. How are these systems structured under the hood to remain scalable and reactive?

Onurhan Akçay: We maintain this with a layered structure. Villages under kingdoms and the resources they possess. And also some groups that influence them. At the bottom is the core simulation layer that manages the basic needs, routines, and state changes of the actors in the world. Above that, more macro systems operate, such as faction relations, territorial control, threat level, and resource movements. All together, they form the dynamic foundation of the game.

Practically, how are you even handling the scope of something like that? How many actors and similar systems are simulated at a time?

Onurhan Akçay: We approach the scope with a logic of near, medium, and far worlds. Critical actors in the player's immediate vicinity operate with a full set of behaviours. In more distant areas, the same entities proceed with a lighter logic, with summarized updates.

For example, when the player is in a village, they can fully see life there – working villagers, patrolling soldiers – but in villages further away, instead of fully simulating them, we only process them as data. This way, the world doesn't feel empty, but performance remains under control. We use the same approach for AI, the economy, NPC routines, and world events. So it's not just about how many actors we simulate, but at what level of detail we simulate them.

From an AI perspective, how do you design behaviors that feel natural and unscripted while still supporting gameplay clarity and balance?

Onurhan Akçay: It's actually quite difficult to move this to a completely natural and unscripted point. Especially at this stage of development, creating a structure that both feels natural and remains readable and balanced in terms of gameplay requires a serious balancing act.

 To be frank, during Early Access, we supported this aspect with some controlled solutions. For example, there are specific points where NPCs work, move around, or stand guard. However, to prevent these behaviors from feeling too cyclical and mechanical to the player, we increased the variation as much as possible. We tried to make this feel more natural with behavior transitions, location variety, and reactions to different situations.

 What's important for us here is not a system that behaves completely randomly in front of the player; it's a structure that feels natural but is also readable and serves the gameplay. We have more advanced plans in mind to make this system even more organic after Early Access. Over time, we aim to move the AI ​​side to a more dynamic, more reactive, and less noticeable structure.

From a technical standpoint, what engine are you using, and what made it the right fit for building a large, simulation-driven open world?

Onurhan Akçay: We are developing Valorborn with Unreal Engine 5. Thanks to our previous work on Land of the Vikings, we gained significant experience with Unreal, and we've directly transferred that experience to Valorborn.

The significant enhancement of open-world development tools in UE5 was particularly important to us. World Partition allowed us to manage large-scale worlds in a more organized and sustainable way. The PCG side greatly simplified our work in terms of world generation and environmental diversity.

In addition, Unreal's combination of powerful visualization tools and the technical flexibility we needed created the right balance for us. For a project like Valorborn, which is both open-world and heavily interactive with systems, UE5 was a natural choice.

Can you walk us through your typical workflow for building a gameplay area, from early blockout and systems setup to final art and polish in-engine?

Onurhan Akçay: Generally, we first define an area based on its gameplay objective. Will this area prioritize exploration, generate conflict, provide resources, or carry a specific story or faction tension? We clarify this first.

Then comes a rapid blockout process. Here, our goal isn't visuals, but flow, readability, and spatial rhythm. We test how the player enters the area, what they see, how they change direction, and what risks they take.

Once the basic framework is in place, system layers are added. Elements such as NPC placement, AI routes, resource points, encounter logic, and quest or event triggers are established at this stage. Once the area is functioning systemically, the art and atmosphere aspects come into play.

In the final stage, we focus on performance, visual integrity, navigation, lighting, sound, interactive readability, and minor gameplay lags. For us, an area is considered finished not just if it looks good, but if it feels technically and gameplay-wise seamless.

The world is fully explorable, with every building and cave enterable. How do you approach level design and world-building to support that level of interactivity?

Onurhan Akçay: The fact that every structure and cave is accessible means we shouldn't design the world merely as a beautiful backdrop from afar. Therefore, from the outset, we adopted a "functional space" approach instead of a "visual shell" in our world-building.

When designing a structure, we don't just look at its exterior silhouette; we consider questions like: who lives inside, what do they produce, what do they store, how is it protected, and why would a player want to enter? The same applies to caves. Instead of empty spaces consisting only of entrances and exits, we strive to create places with their own atmosphere, risks, rewards, and spatial identity.

This approach directly impacts the level design side as well. Because every interior space needs to have a function, a rhythm, and a value for exploration. When you enter a village, you'll see dozens of buildings, and you'll know that every building is accessible. If you see a distant aqueduct, you'll be able to examine every detail of it. We paid particular attention to these aspects during the design process.

What tools and software are central to your pipeline for environments, characters, and assets?

Onurhan Akçay: At the heart of it all is, of course, Unreal Engine 5. Around it, we have a few core tools we use for environment generation, character, material, and the overall asset pipeline.

For modeling, we use 3ds Max and Blender; for sculpting, ZBrush; and for texture and material generation, Substance 3D Painter and Designer. Character Creator is a crucial part of our pipeline for character creation. We also use Perforce for version control.

What's most important to us isn't the individual tools themselves, but how seamlessly they work together. Because we're a small team, fast iteration is critical. Therefore, we strive to build our pipeline as practically, flexibly, and reproducibly as possible.

Also, because we're a small team, we utilize ready-made content as efficiently as possible. Specifically, we purchase character armor sets and some environment packs from FAB and integrate them into our pipeline to speed up our creation process. Our goal here isn't to simply use ready-made content, but to adapt it to the game's overall visual style and technical needs, integrating it correctly into the project.

Performance can be a major challenge in simulation-heavy open worlds. What optimization strategies have been most important during development?

Onurhan Akçay: Optimization is one of the most challenging areas in the development process. It's not a problem solved in a single step; it's multi-layered and requires careful control at every stage.

Especially on the CPU side, we use layered systems to maintain performance. We dynamically optimize tick times and update frequencies based on the player, camera, and character locations. This way, we avoid unnecessary costs on systems that the player doesn't directly interact with.

On the GPU and RAM side, LOD usage plays a crucial role. Since players often see characters and world elements from a distance in our game, we gain performance by using lower-resolution textures and lighter asset variations at longer distances.

In general, our approach is to maintain quality in the areas the player actually sees and feels, rather than running every system at the same intensity, while intelligently reducing the underlying cost.

As a small indie team working on an ambitious project, how do you structure collaboration across disciplines like design, engineering, and art?

Onurhan Akçay: We could say we yell at each other in the office. But jokes aside, because we're a small team and have limited time, we try to discuss problems as quickly as possible and move forward in a solution-oriented way.

We can't keep the design, software, and art sides separate. That's why we keep communication as direct as possible. Instead of spreading a problem out over long meetings, we quickly come together, evaluate it, and turn it into a viable solution.

We also take advantage of being a small team here. Our iteration speed is high, our decision-making chain is shorter, and our transition from prototyping to production is more agile. We can review a decision we made during the day and quickly adapt to new conditions. This gives us significant flexibility in such an ambitious project.

How has community feedback during testing and Early Access influenced your development priorities and workflow?

Onurhan Akçay: The answer to that question is definitely a lot. In such an open-world and system-driven game, community feedback makes many things visible that you can't see on paper.

We clearly saw that the systems we built internally with a certain logic weren't always perceived the same way by the player. Some mechanics that were clear to us might not be easily understood by the player. Some systems that seemed strong in theory might not feel as satisfying in practice as we expected.

Therefore, community feedback became not just a bug-finding tool for us, but a prioritization tool. We saw which areas needed more polish, which systems needed clearer explanations, and which friction points unnecessarily hindered the player experience. This had a significant impact on the workflow as well; we test more frequently, gather feedback earlier, and revise some decisions based not on internal assumptions, but on actual player behavior.

Looking ahead, how do you plan to evolve your pipeline and systems as Valorborn grows toward full release

With the EA launch, our goal isn't just to add more content, but to make the current production pipeline more efficient, sustainable, and controlled. Because as the project grows, the real issue isn't just how much content you produce, but how consistently you produce it and how well you manage the process.

In our initial updates, our priority will be bug fixes and carefully analyzing the features players specifically want or don't want, and improving the game accordingly. At this stage, solving issues that directly affect the player experience and strengthening the core structure is our top priority.

Following this, new content updates and updates expanding the mechanics we promised will come. Features like Magic, which increase the game's system depth, will further strengthen Valorborn's sandbox structure in the future.

The feedback we receive from players is crucial here. We will largely shape our roadmap based on this feedback. Our aim is to transform Valorborn into the strongest, deepest, and most vibrant sandbox game possible.

We will determine the process leading up to the full release not only according to our internal schedule, but also based on whether the game is truly ready and whether the players clearly feel that way. We will only proceed with the full release when we both feel the game is ready and the community confirms this.

Finally, are there any behind-the-scenes materials, such as debug views, system breakdowns, or in-engine tools, you can share to help developers better understand how the game is built?

This is definitely an option to explore and gladly talk and help other devs if they have a technical question, but for now, I have to be blunt and say that, because of our size, we would not have the time to properly answer a question around this topic.

Overall, we love the idea of knowledge sharing, for it helps everyone to improve, and ultimately it helps to create better and better games.

Onurhan Akçay, Laps Games Founder and Developer of Valorborn

Interview conducted by David Jagneaux

Don't forget to subscribe to our Newsletter, join our 80 Level Talent platform, follow us on Twitter, LinkedIn, Telegram, and Instagram, where we share breakdowns, the latest news, awesome artworks, and more.

Are you a fan of what we do here at 80 Level? Then make sure to set us as a Preferred Source on Google to see more of our content in your feed.