Expedition 33 guide: building a turn-based RPG on Unreal 5

Expedition 33 guide: scope, reader, and engine decisions

Turn-based role-playing games look deceptively simple to the outside observer. A few characters, a grid, a few menus, and a turn counter. Once a team starts cutting a real build, the same surface reveals hundreds of design and engineering questions. Expedition 33 is the working title that several Western studios have used for internal and announced projects over the last few years, and search interest around the phrase expedition 33 guide comes from three distinct audiences: players looking for a walkthrough, developers interested in the build pipeline, and producers tracking the scope of mid-budget narrative RPGs. This article serves the developer and producer audience. It treats the title as a working case study for a stylized turn-based RPG built in Unreal Engine 5, then maps the choices a small team must lock down before content production scales.

The scope here is deliberately narrow. You will not find a beginner’s tutorial on the Unreal interface, a marketing checklist, or a generic article about the role-playing genre. Instead, the goal is a working reference for the questions that determine whether a turn-based RPG ships on time, runs at target frame rates, and feels responsive to the player. Combat design, ability architecture using the Gameplay Ability System, art direction and content pipeline, narrative data, QA gating, and live operations are the main chapters. Each one is treated as a decision that has to be made early, because the cost of changing it later grows with every content drop.

Two design assumptions frame the rest of the article. First, the game is built on Unreal Engine 5 using the Gameplay Ability System for combat, with a small combat team of three to six engineers and designers. Second, the project targets a single current-generation platform family, with a secondary platform port planned after vertical slice. Those assumptions match the way most Western mid-budget RPGs are scoped. Adjust the time and risk numbers if your team is smaller or if you are using a different engine; the decision logic still applies.

Combat design and the round manager

Turn-based combat looks like a sequence of menus, but the data model behind it is closer to a small real-time engine with discrete ticks. A round in a turn-based RPG is a deterministic state machine, not a free-running simulation. Every ability, every status effect, and every animation has to be reproducible from the same input, otherwise save games, multiplayer, and bug reports become incoherent. The first technical decision is whether the round manager runs on the server, on the local client, or on both, and how it interacts with Unreal’s Gameplay Ability System.

For most single-player projects the answer is the local client. The Gameplay Ability System is replicated by default, but a single-player turn-based game does not need authoritative server state. Instead, the project needs deterministic activation so that a save file restored to a known turn produces the same state. That means commit windows must be ordered, random number generation must be seeded, and any asynchronous asset load must complete before the round resolves. If you plan to add asynchronous multiplayer later, isolating the round logic into a deterministic subsystem now will save a refactor when authority is introduced.

Round structure should be expressed as data, not hard-coded. Each encounter loads an ordered list of combatants, an initiative list, and a set of per-turn events. Designers tune pacing by editing tables, not by editing code. The following list captures the minimum data that a turn manager should own for a stable combat loop:

Initiative ordering with deterministic tie-breaking using combatant index, not random.
Per-turn budget for ability usage, action points, or cooldown windows.
Status effect resolution order so buffs and debuffs apply in a predictable sequence.
Reaction window that can be interrupted by a player choice or by a scripted trigger.
Save and restore points after each turn to allow autosaves, rewinds, and crash recovery.

A useful diagnostic for combat pacing is to instrument the round manager with timing tags. A profiler overlay that prints the cost of each phase (input, ability activation, status resolution, animation, and round cleanup) is more useful than a generic frame-time graph. When combat stutter appears, the developer can see which phase dominates the frame. Without that, teams waste hours arguing about animation versus gameplay cost when the real offender is usually status resolution or effect activation.

Ability architecture with the Gameplay Ability System

The Gameplay Ability System, often called GAS, is the natural choice for ability-driven combat in Unreal Engine 5. It already models attributes, effects, abilities, and tags, which are the basic vocabulary of any turn-based RPG. The mistake teams make is to treat GAS as a black box and to copy patterns from real-time shooters. Turn-based combat has different needs. Abilities are not fired continuously, cooldowns are measured in rounds rather than seconds, and target selection happens through a menu rather than a crosshair. A direct port of a shooter-style GAS setup will work at first, then collapse under the weight of edge cases.

Two patterns are worth committing to early. First, every ability is described as data through a combination of an UAbilityDataAsset and a Gameplay Ability class. The data asset holds the descriptive fields that designers tune: name, cost, target rule, animation tag, and effect references. The ability class holds the activation logic. Designers iterate on data without touching code, and engineers change the rules without breaking content. Second, the cost and cooldown system should be expressed through gameplay attributes and gameplay effects, not through custom integer fields on the character. This keeps the rule that any system that applies an effect can also apply a cost, which becomes important when status interactions start chaining.

The table below summarizes a sensible division of responsibility between data, class, and runtime state for a GAS-based ability in a turn-based RPG.

Layer	Owned by	Examples	Iteration cost
Data asset	Designer	Display name, cost, target rule, animation tag, effect references	Low, content-only changes
Ability class	Engineer	Activation order, prediction setup, replication policy	Medium, requires compile
Attribute set	Engineer	Health, mana, action points, armor, status resistance	High, affects balance across content
Effect class	Engineer or technical designer	Damage calculation, status application, tag grant	Medium, often data-driven through curves
Runtime state	Runtime, deterministic per turn	Active ability, queued reaction, predicted target	Should be visible through a debug HUD

Gameplay tags are the other piece of the puzzle. Every state in combat, from “is casting” to “is stunned” to “is overwatching”, should be expressed as a tag rather than a boolean. Tags compose, they serialize cleanly, and they make the rule engine easy to author. The cost is that designers must follow a tag naming convention, and a style guide is mandatory. A common pattern is a domain prefix, a state, and a target, for example Combat.State.Stunned, Combat.Target.Self, or UI.Highlight.Targetable. Without a convention, tag count grows into the hundreds and the search field becomes useless.

One last GAS point worth flagging. Prediction is useful for real-time action combat but rarely useful for turn-based menus. Keep prediction for the small number of cases that need it, like a quick-toggle ability on a controller, and turn it off for menu-driven actions. Otherwise the predicted state and the resolved state will diverge in ways that are hard to debug, and you will spend more time on prediction tooling than on the actual combat feel.

Art direction, content pipeline, and stylized rendering

Stylized RPGs live or die by art consistency. The reference points for a game in the Expedition 33 family are usually a mix of high-contrast painterly lighting, slightly exaggerated silhouettes, and tightly authored textures. The trap is to treat art direction as a mood board rather than as a set of measurable constraints. Without measurable constraints, the production pipeline drifts. A texture that looks fine on the main character becomes a flat blob on a background NPC, the same shader renders as a chalky pink under overcast lighting, and the technical artist becomes a firefighter.

Three pipelines deserve explicit planning. First, the character pipeline needs a small set of base body meshes and a head and costume layering system. The fewer the skeletons, the cheaper the animation cost and the simpler the rigging. Two skeletons is usually a safe target: a humanoid skeleton for the player party and a slightly more compact one for enemies and NPCs. Second, the environment pipeline should lean on modular kits, not on unique per-region art. A small kit of walls, floors, props, and decals, combined with material variants and lighting moods, produces enough variety for a ten to fifteen hour campaign. Third, the VFX pipeline must distinguish ambient effects from gameplay effects. Ambient effects sell the world; gameplay effects must read at a glance and must be visible to color-blind players without losing information.

Rendering choices matter here as well. Many stylized RPGs sit between a forward renderer and a deferred renderer. Unreal Engine 5 offers both, and the choice usually depends on lighting complexity rather than on art style. If the world needs many dynamic lights for readability, deferred is the safer default. If most of the lighting is baked, forward or a hybrid setup is competitive and saves memory. A useful sanity check is to render the same scene under the three candidate configurations and to compare shader cost, memory, and visual quality. The result is rarely what the team expected before the test.

Content production also has a measurable rhythm. The table below suggests a rough division of weekly effort for a small art team of eight to twelve artists working on a stylized RPG. Adjust the numbers for your scope, but keep the relative ratios as a starting point.

Pipeline stage	Estimated share of weekly effort	Primary risk	Mitigation
Character art	25 to 30 percent	Silhouette and costume consistency	Style guide with silhouettes and a small costume palette
Environment and prop art	30 to 35 percent	Modular kit exhaustion and texture drift	Material variants and texture review sessions
Animation	15 to 20 percent	Combat read and state machine complexity	Shared locomotion and state map per skeleton
VFX and lighting	10 to 15 percent	Gameplay readability versus mood	Color-blind safe pass and gameplay effect hierarchy
Tech art and tools	10 percent	Iteration speed for content	Editor utility widgets for the most common edits

Style guides and reference boards are not optional. A one-page reference board for each main biome, pinned to a wall in the art area and shared in a single source-of-truth folder, will save dozens of review meetings. The same board becomes the basis for the lighting mood per biome. Lighting artists use it to set sky, fog, and exposure baselines, and combat designers use it to check that the player’s abilities still read against the mood.

Animation, timing, and combat feel

Combat feel is the result of three layers: input latency, animation timing, and effect timing. In a turn-based RPG, input latency is mostly about menu responsiveness, but the rule is the same as in any other genre. The first measurable target is the time from button press to UI confirmation. Anything above 100 milliseconds starts to feel sluggish on a controller, and above 150 milliseconds is usually a bug. The fix is rarely to speed up the animation; the fix is to confirm the action immediately and to play the animation as a visual response, not as a gate on the action.

Animation timing is the next layer. A common mistake is to author a unique animation for every status effect on every character. The pipeline cost becomes unsustainable. A more maintainable structure is to separate the action animation from the reaction animation. The attacker plays a strike or cast animation, and the defender plays a hit reaction chosen through a layered blend. This lets the same strike animation trigger many different reactions, and the reaction set can grow independently of the strike set. The result is a combat sequence with a stable rhythm and far fewer animation files.

Effect timing is where the team’s taste becomes visible. The reference for a satisfying hit is a small cascade: a bright frame on contact, a pause for the eye to register, a knockback or recoil, a small camera shake, and an audio cue that masks the worst of the asset pop. The pause is the part that inexperienced teams skip. A hit that resolves in two frames reads as a glitch; a hit that resolves over twelve to eighteen frames reads as a hit. Lengthen the pause deliberately, then trim if the combat pace suffers.

For an expedition 33 guide aimed at developers, the practical takeaway is that combat feel is a measured budget. Decide a frame budget for the hit cascade, instrument the animation system so the budget is visible, and review one or two combat sequences per sprint against the budget. A good review compares the in-engine sequence to a reference clip frame by frame and notes where the in-game version drifted from the intent. The conversation is then concrete instead of aesthetic.

Narrative, quests, and content data

Narrative in a turn-based RPG is not just dialogue. It is the dialogue tree, the quest state, the world state, the script triggers, and the cinematic data. A common failure mode is to treat narrative as text added at the end of a vertical slice. By the time the writer sees the world, the level design is locked, the encounter zones are placed, and the dialogue has to bend around the world instead of the other way around. A better pattern is to author the narrative beats against a high-level world map before white-box geometry is placed, then to let the level designer place the beats in a sequence that the encounter system can read.

The concept of an expedition in the broader sense is also useful framing for the project itself. A long production journey with a known start, a planned route, periodic resupply, and a defined destination is a good model for a multi-year RPG production. The model is not new, but it remains a useful antidote to the idea that a project can be improvised from sprint to sprint. A project without a route wastes time, and a project without resupply runs out of energy before it reaches the destination.

Quest state is the next decision. A flat list of boolean flags works for a five-hour game and collapses for a twenty-hour game. A state machine per quest, with stages, optional branches, and an explicit fail state, is more verbose but vastly easier to debug. The state machine lives in the data layer, the dialogue tree references the state, and the encounter system reads the same state to decide which combat block to load. With that structure, the same quest can present different encounters, different NPCs, and different cinematics based on the player’s earlier choices, without rewriting any level.

Localization is the third decision that has to be made before content scales. Text in source language should be stored as keys, not as inline strings, and the keys should be stable across patches. Audio localization needs a script-driven VO plan, with per-language timing windows and a fallback strategy for missing recordings. The cheapest moment to add localization is at the start of production, and the most expensive moment is the localization pass after the game is feature-complete.

For studio teams planning a turn-based RPG on Unreal Engine 5 like the one implied by an expedition 33 guide, a useful checklist is the following list. It is short on purpose. Each item represents a decision that compounds, not a small fix:

Author quest data through a state machine, not through flat flags.
Reference narrative state from the encounter system so the same combat block can be reused across quests.
Store dialogue through stable keys, with a style guide for length, tone, and pronouns.
Plan VO recording and lipsync pipelines before the first cinematic is locked.
Reserve a small set of cinematics for replays, and reuse rig and camera assets across them.

QA, certification, and the build matrix

QA in a turn-based RPG tends to focus on three areas: combat correctness, narrative continuity, and platform certification. Combat correctness means that every ability interaction produces the expected state for every combination of targets, statuses, and levels. The only reliable way to test this is a property-based test suite that runs through scripted combat scenarios and compares the resolved state to a known good state. The test suite lives next to the combat code, and a CI job runs the suite on every change. Without that, regressions sneak in through status effect interactions that no designer thought to test by hand.

Narrative continuity is harder. A flag that fails to set, an event that fires twice, or a state that resets across a save can break the player’s experience without crashing. A scripted playthrough per major quest branch is the baseline. The first playthrough is exploratory, and the second is a regression run with diffs against an expected event log. The event log is the most valuable artifact in narrative QA because it is the only place where the team’s expectation meets the actual game state.

Platform certification adds a different category of risk. Console certification has hard rules around suspend and resume, error handling, controller disconnect, and accessibility. PC certification through storefronts has its own rules around anti-cheat, save migration, and update integrity. The certification pass should start as soon as the combat system is feature-complete, not at the end of the project, because the lead time to fix a certification finding is usually several weeks. A useful pattern is a weekly certification review where a producer walks the most recent build through a small subset of the certification checklist.

A build matrix is the third QA decision. The matrix lists the platforms, the input devices, the graphics presets, the languages, the save states, and the build variants that the team tests every week. The matrix starts small and grows. A reasonable initial matrix for a single-platform project looks like the example below. Adjust the row count as the project grows.

Build axis	Initial matrix	Full matrix	Owner
Platforms	Primary target only	Primary plus secondary target	Producer and port lead
Input devices	Controller and keyboard plus mouse	Add touch and accessibility hardware	UX lead
Graphics presets	One low and one high preset	Three presets plus a benchmark scene	Tech art
Languages	Source language plus one secondary	All launch languages	Localization lead
Save states	One fresh save and one mid-game save	Add a late-game save and a corrupted save	QA lead
Build variants	Debug, development, and release candidate	Add a store submission build and a hotfix branch	Release engineer

Performance, profiling, and shipping targets

Performance work on a stylized turn-based RPG is more forgiving than on a real-time action game, but the rules are the same. Decide a target frame rate, decide a target hardware tier, and instrument the build so the team can see the gap between target and actual. Unreal Engine 5 ships with a profiler suite, but most teams underuse the insights view because the data is dense. The fix is to add a small set of custom stats: round resolution time, status effect count per turn, animation sample count, and active ability count. The four numbers cover most of the performance regressions in turn-based combat.

Memory is the second axis. Stylized assets tend to look heavier than they are because the textures are large and the meshes are dense. A common audit is to compare the on-disk size of each asset to its in-memory size and to its on-screen size. An asset that occupies 50 MB on disk, 80 MB in memory, and 200 pixels on screen is a candidate for downsizing. The audit runs as a weekly job that produces a spreadsheet, and the spreadsheet is reviewed by the tech art lead.

Optimization work also has a sequence. The first pass is on the data: reduce texture sizes, share materials, and combine meshes. The second pass is on the runtime: cut down particle counts, simplify shaders, and reduce overdraw. The third pass is on the gameplay: shorten effect lifetimes, lower the cost of status resolution, and tighten the round manager. Each pass has a measurable outcome, and a pass is considered done only when the measurement improves. A team that skips the measurement produces a build that runs ten percent faster on the developer’s machine and not at all faster on the player’s machine.

For an expedition 33 guide, the practical performance list is short:

Lock the target frame rate and the target hardware tier before white-box levels are blocked out.
Add four custom profiler stats that cover round resolution, status effect count, animation sample count, and active abilities.
Run a weekly asset audit that compares on-disk size, in-memory size, and on-screen size.
Sequence optimization as data, runtime, and gameplay, with a measurable outcome for each pass.
Reserve the last four to six weeks of production for platform-specific tuning rather than for new features.

Live operations, patches, and the post-launch plan

Turn-based RPGs have a different live operations rhythm than live service shooters. Most of the post-launch work is patches, balance updates, and sometimes a story expansion. The pipeline that supports that work has to be in place before the launch build is cut. A patch system that updates a binary is straightforward. A patch system that updates content without redownloading the whole game is harder, and the team has to decide between cooked content patches, asset bundles, and a content delivery network.

Balance updates are the post-launch work that most directly affects the player. A good balance update pipeline keeps a list of tracked metrics, a triage of issues, and a regular cadence. The cadence matters more than the size of any single update. Players learn to expect a balance pass on a fixed date, and the predictability reduces the load on community management. The internal cadence is usually a weekly triage, a monthly patch, and a quarterly larger revision.

Save data migration is the other post-launch decision. Any balance change that affects numerical values needs a save migration that brings older saves up to date. The migration is part of the patch, and a missing migration is a bug that will surface weeks after launch. The migration code lives with the data layer and is covered by the same test suite that covers the data layer in development.

The decision a small studio has to make is whether the post-launch plan is a maintenance plan or a content plan. A maintenance plan assumes one to two patches per quarter and no new content. A content plan assumes at least one paid expansion or a free content drop in the first year. The cost difference is large, and the plan has to be honest about the studio’s capacity. A small team that promises a content plan and delivers a maintenance plan will lose player trust faster than a team that under-promises and over-delivers.

Project planning, scope, and the production triangle

Every project of this kind runs into the same three pressures: scope, schedule, and quality. The production triangle says that one of the three has to give, and the team has to decide which one early. For a stylized turn-based RPG with a small team, the realistic answer is usually scope. Quality is the brand promise that brought the team together in the first place, and schedule is fixed by the publisher or by the marketing window. Scope is the variable.

Scope discipline starts with a feature list and a cut list. The feature list is the experience the team is committed to delivering. The cut list is the experience the team is willing to cut without breaking the game. A useful framing is to grade each candidate feature on three axes: critical to the experience, expensive to build, and replaceable by a simpler version. A feature that is critical and expensive is a candidate to simplify. A feature that is replaceable and expensive is a candidate to cut. A feature that is critical and replaceable is a candidate to ship first, and the simpler version becomes the production reference.

The risk register is the other production artifact that compounds. A risk is an event that has not happened yet and that, if it happens, will require a change. A risk is owned by a name, has a probability, has an impact, and has a mitigation. The risk register is reviewed weekly, and a risk that has materialized becomes an issue and is tracked in a different column. Without that distinction, the register becomes a complaint board and loses its planning value.

For an expedition 33 guide aimed at producers, the planning list is the following list. It is intentionally short, and each item represents a decision that has to be made in the first third of the project.

Lock the feature list, the cut list, and the milestone definitions in the first month of production.
Open a risk register on day one and review it weekly, with a clear separation between risk and issue.
Define a build matrix and a certification pass cadence before the first vertical slice.
Sequence the post-launch plan as maintenance or content before launch marketing is locked.
Reserve a buffer of four to six weeks between feature complete and certification submission.

Working with the engine, the publisher, and the platform holder

Three external relationships shape the production. The engine vendor, the publisher, and the platform holder. The engine vendor relationship is usually the most stable. For Unreal Engine 5, the public documentation, the developer community, and the source access through the Epic Games launcher form a support structure that most small teams can rely on. The relationship that is more variable is the publisher relationship, and the variable that is the most constrained is the platform holder relationship.

A publisher adds value through funding, marketing, and certification guidance, and adds cost through milestone gates, approval cycles, and revenue share. The trade is usually worth it for a small team, but the milestone gates have to be defined in the contract. A vague milestone is a source of conflict. A specific milestone has a binary, observable outcome: did the build do the thing the milestone promised, or did it not. The binary outcome is what makes milestone reviews productive, and the absence of binary outcomes is what makes them political.

Platform holder relationships are governed by technical requirements and by marketing opportunities. The technical requirements are the certification rules that were discussed earlier. The marketing opportunities are store features, festival selections, and platform-specific events. A small team benefits from a clear store strategy: a launch trailer, a press kit, a day-one patch, a wishlist campaign, and a post-launch content plan. The store strategy is part of the production plan, not a late addition, because the assets and the timing of the assets have to be planned alongside the game.

Frequently asked questions

What does the term Expedition 33 mean in a GameDev context?

Within game development, the term refers to a working title for a stylized turn-based role-playing project. It is also used as a shorthand in production documents for a specific scope of mid-budget RPG work, and the phrase appears in design discussions as a placeholder for a project that combines narrative, combat, and a moderate scope. Players, however, often encounter the phrase as the name of an actual announced or released game, and the developer context and the player context are not interchangeable. This article treats the term as a developer case study, not as a player walkthrough.

Which engine is the best fit for a stylized turn-based RPG like Expedition 33?

Unreal Engine 5 is a strong default for projects of this size because of the Gameplay Ability System, the animation toolchain, and the rendering quality at the cost of a longer learning curve. Unity is a credible alternative for smaller teams, especially when the team has existing Unity experience, and a custom engine is a real option for studios with the capacity to maintain it. The choice is rarely about which engine is the best in the abstract. The choice is about which engine the team can ship with the available time and budget.

How does the Gameplay Ability System help turn-based combat?

It provides a structured way to model abilities, attributes, effects, and tags. For turn-based combat, the value is the data-driven design and the deterministic activation model when prediction is disabled. The system is more verbose than a custom solution, and the team has to commit to a tag naming convention and to a clear separation between data assets and runtime state. With those commitments, the system scales across hundreds of abilities and dozens of status effects without collapsing into a custom rules engine.

How long does a stylized turn-based RPG take to produce?

Production length depends on scope, team size, and platform. A small team of fifteen to twenty people can produce a ten to fifteen hour stylized RPG in roughly two to three years, assuming the team is experienced with the engine and the genre. Larger teams can shorten the schedule or expand the scope, and smaller teams can extend the schedule with the same outcome. The honest answer for any given project is the schedule that fits the team’s history, the publisher’s expectations, and the platform’s certification window.

What is the most common cause of schedule slip on a project like this?

Scope creep is the most common cause, and it is usually invisible until the project misses a milestone. The early symptom is a feature list that grows faster than the cut list. The second most common cause is platform-specific rework that was not planned, and the third is a certification finding that requires a long fix. Each of these is preventable with the right artifacts, and the artifacts are the feature list, the cut list, the build matrix, and the certification review cadence.

How should a small team approach certification for a console launch?

Start the certification review as soon as the combat system is feature-complete, and run a weekly review against a small subset of the checklist. The review produces a list of findings, the findings are tracked in the risk register, and the fixes are folded into the next sprint. By the time the project is feature-complete, the certification list should be small enough to fix in a single buffer. A team that waits until the end of the project will not have the buffer.

What is the right way to plan post-launch content for a turn-based RPG?

Decide early whether the post-launch plan is a maintenance plan or a content plan. A maintenance plan assumes one to two patches per quarter, and a content plan assumes at least one paid expansion or a free content drop in the first year. The cost difference is large, and the team has to be honest about its capacity. A clear plan avoids the worst failure mode, which is a vague promise that the team cannot keep and that the players cannot forgive.

Can a small team build a stylized RPG with the same visual quality as larger studios?

Yes, but the production choices have to be disciplined. A small team cannot afford unique art for every region, so the team relies on modular kits, material variants, and a small set of skeletons. The visual quality comes from a consistent art direction, a small but well-curated asset library, and a lighting and VFX pass that ties everything together. The trade is that the player will not see as many unique assets, but the player will see a coherent world, and coherence is what carries a stylized RPG.

What is the best way to balance a turn-based RPG across a long campaign?

Treat balance as a data problem rather than a design problem. Express costs, cooldowns, and damage through data curves, and review the curves against encounter data per region. A useful artifact is a spreadsheet that maps each ability to its cost, its expected damage per turn, and its expected utility, and the spreadsheet is reviewed alongside the level design. Without that artifact, balance is improvised per encounter, and the campaign becomes inconsistent.

How does a team decide between a content patch and a binary patch?

The decision is driven by the size of the change, the size of the player base, and the platform’s patch rules. A small balance change is usually a binary patch, and a large content change is usually a content patch through asset bundles. The platform’s patch rules limit the size of the binary patch and the size of the content patch, and the team has to plan the change within those limits. The decision is rarely about the content and almost always about the cost of distribution.