Pearl Abyss has shared the large-scale open world development process it built for 'Crimson Desert' with game developers in Japan. Beyond individual technologies like graphics, engines, and rendering, the presentation focused on the production framework established by a 200-person team to successfully complete an AAA-grade open world.

Doo Seung-bin and Kim Hyun-kyum, leads at the Pearl Abyss Crimson Desert Design Office, delivered a special invited lecture titled 'Crimson Desert: Building a Large-Scale Open World Development Process' at 'CEDEC 2026,' held at Pacifico Yokohama North in Yokohama, Japan, on the 23rd. CEDEC is Japan's largest game developer conference, running this year from the 22nd to the 24th.

Doo Seung-bin began by stating, "What we are sharing today is neither a perfect solution nor a finished methodology. It is an opportunity to look back at the problems we faced during development, what we learned, and how we solved those problems together as a team."

seven Years of Development: "We Saw It as More Than Just a Game"

Crimson Desert is an open world adventure game that launched on PC, Mac, PS5, and Xbox on March 19, 2026. Development took approximately seven years.

Doo Seung-bin attributed the long duration to the team's perspective on the project. "From the beginning, we viewed this project not just as a single game, but as a foundation for the studio's future projects," he said. "We consciously decided not to rush development, and instead spent time improving our tools, workflows, and overall production processes because we wanted that experience to carry over into future projects."

The lecture defined the core challenge of Crimson Desert's development as the gap between the team's goals and available resources. "Our goals were very ambitious," Doo said. "We wanted to create a vivid, large-scale AAA open world filled with things to do, featuring realistic action-based combat, lifelike NPCs, puzzles, exploration, and a world with genuine interactivity."

The constraints, however, were clear. "Our team was about 200 people, much smaller than most teams building open worlds of this caliber," Doo explained. "Furthermore, this was our first attempt at a single-player title after years of primarily developing MMOs. Early on, we realized that simply adding more personnel or encouraging everyone to work harder wasn't enough. We needed a truly scalable process; increasing productivity wasn't just an option—it was the only way to finish the project."

To address this, Pearl Abyss focused on three principles. Doo noted that these three are not separate goals but are closely interconnected and would appear repeatedly throughout the presentation.

The first is Fast Iteration. By shortening the feedback loop, it becomes crucial not only for initial prototyping but also during the polishing phase. Doo stated, "This applies to everything, from how the team collaborates to simple tasks like changing a single parameter and immediately seeing the result."

The second is Maintainability—keeping content flexible and easy to change. "No matter how well you plan, every project is bound to change," he explained. "If content is difficult to change or requires too much time and coordination to modify, people give up on improving it. At our scale, we needed to be able to agilely adjust vast amounts of content whenever requirements changed."

The third is Parallel Workflows, which aim to reduce inter-team dependencies. "If work between departments is too tightly coupled, people spend more time waiting than producing, and bottlenecks slow down production," Doo said. "We needed workflows that allowed teams to move independently and in parallel as much as possible. These three principles became the foundation for all the methodologies we will discuss today."

How to Fill an Open World

Doo Seung-bin identified the first challenge as how to fill a vast open world. "Creating a huge map and making that space meaningful and worth exploring are two different things," he said. "To do this at scale, we needed an efficient and manageable approach."

The solution was to build the world in layers. The first is the environment layer, consisting of terrain, vegetation, wildlife, and points of interest. The second is the content layer, including items, chests, NPC schedules, forts, bandit camps, and puzzle areas. The third is the meta-game layer, which gives the world larger strategic structures, such as trading posts and faction nodes. Each layer was designed to be created, placed, and adjusted somewhat independently.

Doo explained, "Imagine a small valley with harvestable plants, wandering wildlife, a nearby bandit camp, and a cave hiding a treasure chest. Each element is simple on its own, but when placed together, they provide the player with reasons to stop, explore, fight, and discover."

He continued, "Instead of hand-crafting every area from scratch, we had teams create different types of content separately and then combine them. This naturally created diversity and density without having to manually plan every possible combination. Layering turned empty space into playable space while keeping the workload manageable."

"A World Playable Without Quests"

Kim Hyun-kyum then explained the process of redefining the relationship between the world and quests. "One of the main goals of this layer-based approach was to ensure the world remained fully playable even when players weren't following quests," he said. "This meant rethinking the typical relationship between the world and quest structures."

Kim noted, "In many games, quests lead the game while the world functions primarily as a backdrop for the story, but we wanted to flip this structure. We wanted the open world itself to be the primary source of gameplay." He added, "Story and quests are still important, but we treated them as a guide to an already interesting world, rather than the sole reason for visiting a specific area."

There were two reasons for this. The first was development philosophy. "In an open world game, players should be able to find something meaningful regardless of which direction they choose or how far they have progressed in the main quest," Kim said. "Even if you set the story aside completely, the world should still offer places to discover, enemies to fight, and resources to gather. In other words, exploration itself had to feel like real gameplay, with quests adding context and narrative on top of that."

The second reason was productivity. "Early in development, we followed a quest-first approach. It was a sequential process: design the quest first, create the necessary environment, and then add auxiliary content around it," Kim explained. "It works well on a small scale, but at the scale of Crimson Desert, real problems began to arise." Production cycles lengthened, inter-team dependencies piled up, and changes to quest objectives often required reworking the environment and content as well.

So, they switched to a world-first approach. "Instead of waiting for quests to define every area, we built the world's playable foundation first," Kim said. "Once the foundation was in place, environment work, content placement, and quest development could overlap and proceed simultaneously."

He emphasized that this should not be misunderstood as a lack of communication between teams. "The story and quest teams still collaborated closely with the environment and content teams, and we would adjust areas when the narrative absolutely required it." The key difference was that quests were no longer the only starting point for an area.

"Terrain, points of interest, and content layers all became a common foundation shared by all teams, which dramatically reduced dependencies," Kim said. "Even if the story changed, we no longer had to rebuild the entire area. We just had to adjust the quest layer, modify objectives, or add a few elements on top of an already fully playable space. As a result, iteration became faster, rework was reduced, and multiple teams could work in parallel."

Houdini Auto-Placement + Manual Spot Placement

The world-first pipeline was supported in practice by a placement strategy. "To fill the open world efficiently, we utilized a hybrid approach that combined automatic placement with manual spot placement," Kim said.

Houdini was actively used for large-scale layouts, particularly for major elements that form the core structure of the world, such as rivers and roads. "Using procedural generation tools allowed us to create and modify these elements much faster than by hand," Kim explained.

In addition, content was automatically placed more broadly based on regional and terrain data. "The system could fill forests with small animals, place fish in water, spread vegetation according to terrain type, and place NPCs along roads," Kim said. "This provided basic density across the entire world. Every area felt filled in even before it underwent manual work."

Spot placement was used for locations requiring strong intent or memorable moments. This includes small performances showing NPC daily routines, schedule-based activities, distinct events, and important characters. Pearl Abyss classified regions and terrain with bitmaps and triggers, and based on this data, automatically spawned characters, world objects, wandering NPCs, and wildlife.

One example Kim gave was NPCs fighting each other. "The scene where NPCs fight is not a fully scripted sequence. We simply place opposing factions in one area, and the NPCs follow their AI to engage in combat when they encounter enemies," he explained. "This also helped fill a massive battlefield with minimal effort." He summarized, "The basic principle was simple: handle broad areas with automation and emphasize specific spots manually. Automation made the world feel filled, while spot placement breathed extra life into it."

"Story Criticism, Our Development Method Was a Factor"

Unusually, Kim Hyun-kyum did not paint this approach as perfect. "I'm not saying this method was perfect," he said. "While the world-first pipeline brought practical benefits like large play spaces, reduced inter-team dependencies, and fast cross-functional iteration, there were trade-offs."

He continued, "Because the world and content layers were built first, the narrative sometimes had to be shoehorned into spaces already centered on exploration, combat, and system-based gameplay. As a result, some players felt the story progression wasn't as intense or cohesive as they had hoped. We listened to that criticism, and honestly, I think our development method played a part in that."

"How can we maintain the scale and productivity of the world-first pipeline while giving the main story a stronger presence throughout the experience? That is the question we are asking ourselves now," he added. "We don't have a clean answer yet, but we are continuing to discuss, test, and improve."

A Responsive World

Kim then explained how they made the world interactive. "For us, interaction was key to making the world convincing. The world shouldn't be something the player just looks at or passes by; it had to be a responsive entity," he said. "We approached this with two axes: what the player does, and what part of the world reacts." The player side ranges from simple movement and direct actions to long-term progression, while the world side covers everything from a single plant to an entire level zone. "The goal was to make exploration more dynamic, building a world that players don't just pass through but can actively move and change."

The first layer was vegetation. "In many open world games, grass and trees are mostly decorative, but we wanted vegetation to be part of an interactive world as much as possible," Kim said. Basic movement generates terrain-specific feedback like dust, dirt, or small debris depending on the surface the player is standing on, and grass and thin trees react when the player passes through. In the action phase, players can cut grass or reeds with weapons, chop down trees, or bend them to use the recoil to leap forward.

Next are objects. "We didn't want the world to feel like a static set of props," Kim said. "We set a simple guideline: as many objects as possible should be interactive, destructible, or react in some way." The development team internally called script-based gameplay objects with clearly defined states and behaviors 'gimmicks.' Gimmicks range from simple things like traps that trigger when a player gets close or boxes that can be lifted, to complex ones like cranes where multiple parts move like a single machine.

To apply this at scale, they built a custom XML scripting system, allowing designers to define gimmick behaviors without coding each case from scratch. It also supported automatic object replacement, allowing environment placement and gimmick production to proceed in parallel. While artists continued to build the world with general objects, designers prepared interactive versions separately and swapped them out at once. Simpler reactions were added to general objects that weren't gimmicks, such as some reacting to physics and others being destroyed by strong impacts.

Kim explained that they tried to broaden the utility of objects. "We wanted players to be able to interact with objects in some way, even if they didn't have a specific function," he said. "Some objects could be lifted and used in attacks, while others could be turned into items to sell at a shop or placed in a home as decoration." He added, "We tried to make things that looked functional actually work. We didn't want carriages, elevators, trains, or castle gates to remain static decorations in the world. We wanted to reward the player's sense of exploration by making these objects interactive and giving them mechanical functions."

The final layer of interaction is at the level scale. "So far, most reactions have been local, but at the level scale, we wanted the state of the world itself to change according to player progress," Kim said. "Imagine an enemy fort. At first, it's occupied by enemies, but once the player clears it, the same location becomes an allied outpost."

A simple method is to create completely different versions of the map and load them when the state changes. However, Kim noted, "In an open world, that approach doesn't scale. The terrain is huge, many systems share the same world data, and maintaining multiple full versions of an area causes significant overhead."

Pearl Abyss chose the concept of 'Phase Switching.' The key is to separate what is fixed from what can change. Large, persistent elements that generally don't change, like terrain, are kept in the 'Base Level,' while elements that change according to the phase—such as buildings, NPCs, obstacles, enemy placement, and puzzle gimmicks—are kept in a separate 'Gameplay Level.' When player progress triggers a phase change, the Base Level remains loaded while only the Gameplay Level is swapped. The same location can represent different states over time without duplicating the entire map. Phase logic was also data-driven via XML, allowing designers to define the conditions, transition timing, and Gameplay Levels to activate for each phase.

Kim gave the example of a familiar base in the game. "It was a camp that had to evolve according to the player's journey, and it was built by stacking modular Gameplay Levels on top of a shared Base Level," he explained. "Thanks to this, designers could freely iterate without touching the Base Level, and players could see the camp grow naturally over time."

XML Chart System

Doo Seung-bin introduced the tools and data systems that supported this workflow. "In our studio, XML is the common language for content-related data and scripts across the board," he said. "We define different chart formats for each type of content."

They use Action Charts for character actions (movement, attacks, etc.), AI Charts for NPC behavior logic, Gimmick Charts for the states and changes of interactive objects, and Stage Charts for events and progression in stage content. "Taking Action Charts as an example, character actions are state machines where each action is a state and each XML node represents one of those states," Doo explained. "Sub-nodes within a node describe what actually happens during the action. Animation nodes determine the animation to play, frame event nodes trigger events like effects, attacks, or sounds at specific frames, and branch nodes define transitions to other states." The XML structure corresponds directly to the action state machine.

Doo presented several advantages of the XML approach. First, it lowers the technical barrier for designers. "Designers can create, adjust, and test content directly with data without needing to write engine code for every small change, which makes prototyping and iteration much faster," he said. "This allows programmers to focus on building a toolbox of reusable engine features like actions, events, conditions, and runtime systems."

Another reason for choosing XML is that it serves as a practical middle ground between coding languages and visual editors. "XML is easier for non-programmers to read and learn than languages like Python or Lua, and the node hierarchy clearly reveals relationships," Doo said. "Because we use XML in all content areas, the basic syntax is consistent everywhere." He added, "Compared to visual editors like Blueprints, the construction and maintenance costs are much lower. There's no need to develop and maintain custom editor UIs for every type of content, and there are no UX-related issues."

"You can utilize standard text editor and IDE features like search, multi-edit, regular expressions, undo history, and project navigation," he said. "Because it's text-based, it works well with version control, making it easy to review changes, merge, and have multiple people edit content simultaneously." He also mentioned a recent benefit: "Since it's a text format, it works very well with AI-assisted tools like Claude."

Another area where XML was applied is static game data. "Like many games, we started with Excel spreadsheets because they are familiar, easy to edit, and widely accepted as an industry standard," Doo said. "But as the project grew, we hit the limits that many of you have likely experienced."

"First is complexity. As the number of columns kept increasing, it became difficult to track relationships between data, and some sheets became extremely difficult to read, review, and edit safely," he said. "Second is version control. Spreadsheets are particularly weak at comparison and merging when multiple people edit them simultaneously, often leading to situations where one person had to wait for another to finish their work."

Ultimately, instead of continuing to grow the spreadsheet workflow, they replaced static game data with a custom XML format. "What used to be data columns in Excel are now defined as attributes or sub-nodes," Doo explained. "Attributes that can be defined in common are bundled into macros to reduce repetition, and most character-related information can now be viewed on a single screen."

The effect was evident in the practical workflow. "The data structure became much easier to read and access, allowing more people to access and edit data directly," Doo said. "There was no longer a need to go through a dedicated game data specialist to add new data or fix existing data; those who needed to could do it themselves." Being text-based, it allows multiple people to edit simultaneously, and batch editing with regular expressions and standard editors has become easier.

Role Boundaries Began to Overlap

Doo emphasized that the significance of this change goes beyond individual work speed. "The greater implication is that the way different roles work together has changed," he said. "As scripts and data became this accessible, they became a language shared by the entire team. Programmers, designers, and artists could look at the same data, understand how things were actually implemented, and discuss specific details together."

However, he drew a line: "This doesn't mean everyone does the same thing or that expertise disappears. Each role maintains its expertise, but the boundaries between roles have begun to overlap in meaningful ways." He continued, "Artists can change things themselves without waiting for someone to reflect resources in the game, and designers can prototype directly in the game without going through a programmer for every small change. At the same time, programmers gain a much better understanding of how the systems they build are actually used. Communication becomes more specific, inter-team overhead is reduced, and overall quality increases."

Puzzle prototyping was presented as a concrete example. "At first, the workflow was very linear: designers would write puzzle plans, the level art team would create the environment and assets, and then gameplay logic would be implemented on top," Doo said. "Design intent and the constraints of the actual environment didn't always match, often leading to repeated revisions."

"Once we could easily write XML-based puzzle scripts, the process became much more collaborative," he explained. "Designers could prototype puzzle interactions directly with proxy meshes placed in the environment at actual scale, communicating their intent much more clearly and verifying it in the actual environment." Level artists also gained more control over the final result. "Artists could adjust timing, pacing, responsiveness, and cinematic feel themselves, and prepare assets by setting pivots so doors rotate more easily or separating model parts for destruction in line with expected script behavior. The one-way handoff turned into a two-way collaboration, and this pattern appeared across all areas of development."

Doo explained that simplifying data and scripting increased the versatility of game designers. "Designers work across various content areas—combat actions, AI patterns, stage logic, gimmicks, etc.—and if these systems share a single integrated XML syntax, they don't need to learn completely different workflows for each area," he said. "Once you understand the basic structure, you can apply the same approach to all content types."

"For example, when creating a boss fight, a single designer can define stage logic, set combat actions, configure AI patterns, and place gimmicks or traps within the same stage without constant handoffs," he continued. "They can handle cross-disciplinary tasks more independently, iterate and improve the overall experience more directly, and reduce communication overhead as there are fewer cases where small changes require separate handoffs."

Flexibility also increases from a team management perspective. "You can move designers between content areas depending on what the project needs most at the moment," Doo emphasized. "These advantages don't just increase individual productivity; they make the entire production team more flexible and agile."

"Aerial Bug, Turned into a Feature by Preserving the Fun"

In the subsequent Q&A, Doo addressed the size of the development staff: "The team size fluctuated, but I believe it never exceeded 300 people even at its peak. That's why we focused heavily on productivity, efficiency, and parallel work; without those, we wouldn't have been able to finish the project." He added, "Of course, the development culture, which isn't fully captured in the presentation, also played a huge role."

When asked about the criteria for setting priorities, he replied, "As long as it didn't harm the core gameplay, we tried to go in the direction the users wanted." He cited an early bug as an example. "There was a bug where players could keep flying into the sky by repeating aerial stat moves, but users were enjoying that experience," Doo said. "We polished the excessive parts but changed it in a way that preserved the fun."

Regarding development culture, he said, "We don't plan how many man-hours to spend on a specific system or new motion. We say, 'Let's just try it,' and there is no approval process to go through before starting development on a new system." On iteration speed, he explained, "It applies not just to the scale of reducing a week-long iteration to a few days, but also to simple tasks like reducing an hour-long task to 10 minutes, or a one-minute task to 10 seconds. This increases the productivity of the time people actually spend working."

He also mentioned plans to expand XML. "There are areas of the development pipeline that still rely more on code than data, such as UI. We plan to convert these systems to the XML format as well," he said. "However, even using the same format, there are small differences in syntax between scripts—for example, the conditions used in action scripts are different from those in stage scripts. Unifying the common syntax, such as condition formats, would be helpful."

Regarding the scope of Houdini usage, he clarified, "Houdini was used for procedural generation of rivers and roads, but level data was separate and not handled via XML." On the issue of interference during parallel work, he explained, "When someone places something in the world, we use markers so others know its location, and trigger events for short stages include triggers that define the area occupied by that stage so that auto-placement avoids it." However, he noted there is no way to automatically detect placement overlaps yet. "We can't conclude that overlap itself is a problem. There are cases where it's fine if they appear under different conditions," Doo said. "Ultimately, you have to manually scan the level to check for anomalies or mistakes. It's an area that would be ideal to have more automated procedures for."

On narrative-related questions, he reaffirmed the presentation's content. "We use quests more as a means to guide the world rather than a way for the story to lead exploration," Doo said. "We received a lot of feedback from users that the narrative was somewhat weak, and I think part of that is due to our development pipeline. It's a question we are asking ourselves." He concluded, "We don't want to lose the productivity our current pipeline provides. We are continuing to work on how to deliver a meaningful narrative while maintaining that productivity."