BG3 companions: a developer's guide to party design

BG3 companions: how Larian structures the cast that carries a 100-hour CRPG

A companion in Baldur’s Gate 3 is not a follower. It is a long-form narrative system that has to coexist with a six-slot party, a turn-based ruleset, an approval score, an origin-character option, and a publishing model that asked players to spend roughly one hundred hours with these people. The game’s cast of ten recruitable companions, plus the playable origin options, has become a reference point for how a modern CRPG can make party members feel authored rather than assembled, and that is why a GameDev article on BG3 companions is worth writing as a design study rather than a player walkthrough.

For developers and designers, the interesting questions are structural. How does the team keep ten characters feeling distinct inside a shared ruleset? How are approval, romance, and personal quests threaded so they do not block each other or the main narrative? What production trade-offs come with a cast this large, and what lessons translate to other projects that want character-driven systems without a thousand-person studio? This article walks through those questions using only what Larian Studios and its publishing partner have actually shipped, plus public documentation and post-launch reporting on the game’s development. It is not a tier list, a romance guide, or a release recap.

What counts as a BG3 companion in the shipped game

For the purposes of design analysis, a BG3 companion is any recruitable, party-controlled character that joins the player’s roster, has a personal quest, contributes to an approval or affinity system, and is available across a meaningful portion of the three acts. By that definition, the shipped roster comprises ten companions, with a subset of seven also available as origin characters the player can choose at the start of a playthrough.

The ten recruitable companions

Players can recruit all ten companions in a single playthrough if they make the right choices and visit the right locations, although some become available only through specific story branches. The shipped roster, in the order Larian typically presents them, is:

Astarion, a high-elf rogue vampire spawn, encountered in Act 1
Gale, a human wizard with a connection to the goddess Mystra, encountered in Act 1
Lae’zel, a githyanki fighter, encountered in Act 1
Wyll, a human warlock bound to a patron, encountered in Act 1
Shadowheart, a half-elf cleric of Shar, encountered in Act 1
Karlach, a tiefling barbarian, encountered in Act 1
Minthara, a drow paladin, recruited on the goblin-aligned path in Act 1 and later expanded as a written companion in updates
Halsin, a wood-elf druid and former archdruid of the Emerald Grove, recruited in Act 1 or 2
Jaheira, a half-elf druid returning from earlier Baldur’s Gate games, recruited in Act 2
Minsc, a human ranger with a familiar named Boo, recruited in Act 3

Minthara’s place on the roster is a useful design example because the original Act 1 quest structure treated her as a villain first and a party member second, which shaped how her personal quest had to be retrofitted after launch. Larian’s choice to keep her recruitable on a specific path, rather than rewrite the goblin camp entirely, reflects a wider principle: branches that already required distinct quest states can host companion content without adding new maps, which keeps the production footprint manageable.

Origin characters and the playable roster

Origin characters are companions the player can choose to play as instead of recruit. The seven origin options are: Astarion, Gale, Lae’zel, Shadowheart, Wyll, Karlach, and the Dark Urge custom character with their own scripted arc. Choosing an origin swaps the player into that character’s scripted moments, while the rest of the cast becomes available as normal companions. This dual use is a significant design choice and will be discussed in the systems section below, because it changes how the same assets get reused across two playthrough modes.

How BG3 companions are structured as a system

Each BG3 companion is built from a stack of systems that all have to stay consistent across the campaign. Listing the system layers clarifies why character work in this game took a large team and a long production cycle.

The system stack for one companion

A stat block built on the D&D 5e ruleset adapted by Larian, including class, subclass, level progression, and ability scores
A combat AI profile that drives behaviour in turn-based encounters, including cantrip selection, bonus action economy, and reaction use
A camp schedule, which controls where the companion sleeps, what idle activities they perform, and when the player can trigger one-to-one scenes
A dialogue tree, voice acted in full, that branches by approval, race, class, and story flags
A personal quest line with two or three major beats and a final resolution
An approval score that tracks the player’s cumulative choices and gates certain scenes or endings
A romance arc that can be triggered or locked out based on approval, race, and consent choices
Interaction states for party banter, barks, and reaction shots during exploration

Stacking those layers for ten characters, plus origin-specific rewrites of seven, is a production footprint that few RPGs match. The list also explains why some of the design decisions look the way they do: every system has to share a common spine, and the D&D 5e-derived rules provide that spine. A team working on a smaller title can collapse several of those layers. For example, a project that skips romance or camp banter trades player attachment for several months of production time, and that trade-off is usually invisible in the shipped credits.

Approval, affinity, and the conversational economy

Approval in BG3 is a numerical score per companion that shifts when the player makes story choices, party actions, or dialogue selections. The score feeds an internal threshold system that opens or locks companion-specific scenes, romance flags, and ending variations. Approval is intentionally kept hidden in the default UI; the player sees shifts in tone and availability, not a numeric readout. For a designer, the takeaway is that approval functions as a hidden state machine with three or four meaningful breakpoints rather than a continuous resource.

Romance is layered on top of approval, with additional gates around consent, race, and specific Act 2 events. Several companions will not enter a romance path if their personal quest has gone a particular way, which is how the game forces trade-offs between player preference and narrative consequence. This pattern lets Larian preserve the D&D-style moral ambiguity of the original campaign while still giving each companion a satisfying arc. The cost is that players who read guides end up optimising dialogue, which weakens the roleplay the hidden score was meant to protect. Larian has acknowledged this tension in post-launch interviews and has not yet changed the default UI.

Camp as a social hub

Camp is the connective tissue for BG3 companions. It is a small instanced area, accessible at any time outside combat, where the active party and any reserved companions gather. Camp serves four jobs:

A safe space where reserved companions can be swapped into the active party of four
The location for one-to-one scenes, including confessions, confrontations, and Act-defining events
A long rest checkpoint, which is also the main pacing lever because long rest fully restores resources and triggers certain scenes
A place where party banter fires, surfacing micro-stories between main beats

Designing camp as a single social hub, rather than a chain of personalised spaces, lets the team write crossover scenes where two companions argue, flirt, or share a drink. It also makes the long rest mechanic a soft gating system for content pacing, with the limitation that some players will exploit it by resting more often than the designers intended. Patch 5 introduced a partial fix by tying certain companion scenes to story progress rather than rest count, which suggests the team treats the rest economy as an evolving balance lever rather than a fixed design.

Party composition as a design problem

From a system design angle, BG3 companions face a hard constraint: the active party is capped at four characters in combat, drawn from a roster of up to ten plus custom-created hirelings. The developers had to make each companion feel like a complete experience without making any single build mandatory. For broader context on Baldur's Gate 3, the Baldur's Gate provides a concise reference for this section. For broader context on Baldur's Gate 3, the Baldur's Gate provides a concise reference for this section.

Role coverage and complementary kits

The shipped cast is engineered to cover the standard D&D 5e roles, with deliberate overlap in some areas and intentional gaps in others. The table below summarises the intended combat role for each companion, as published in Larian’s official class information and the in-game character sheet. The data reflects the game’s default class assignment and does not account for multiclass experiments the player can perform through respeccing at Withers.

Companion	Race	Default class	Combat role	Notes
Astarion	High elf	Rogue	Single-target damage, control	Subclass path branches in Act 2
Gale	Human	Wizard	Area control, Arcane caster	Resource mechanic tied to personal quest
Lae’zel	Githyanki	Fighter	Frontline melee, burst damage	Strong Act 1 narrative weight
Wyll	Human	Warlock	Ranged damage, support	Patron story shapes power set
Shadowheart	Half elf	Cleric	Healing, support caster	Deity choice affects spells and story
Karlach	Tiefling	Barbarian	Frontline tank, melee damage	Engine overheating mechanic unique to her
Minthara	Drow	Paladin	Frontline tank, support caster	Recruitment requires goblin-aligned path
Halsin	Wood elf	Druid	Support caster, shapeshifter	Recruited mid-game; camp scene tree
Jaheira	Half elf	Druid	Support caster, frontline hybrid	Legacy character with returning party mechanics
Minsc	Human	Ranger	Ranged damage, support	Recruited in Act 3 with Boo in tow

Two design points stand out. First, Larian overlaps two clerics and two druids, then differentiates them through narrative rather than mechanics, so the player is not punished for a story-driven pick. Second, the roster is built so that an all-melee or all-caster party is viable on lower difficulties, which means the design is willing to trade optimal play for thematic variety. A third point is subtler: every companion has a class that the ruleset already supports, so Larian did not have to invent new subsystems for character identity. The personality work is layered on top of an existing mechanical frame, which is one of the reasons the cast feels coherent rather than bespoke.

Multiclassing as a player-facing extension of the system

Because BG3 uses a 5e-derived ruleset, players can multiclass companions at Withers’ camp, a feature that turns the class column in the table above into a starting point rather than a ceiling. Larian’s role here is to expose the rules cleanly and balance the encounter design around the assumption that the player may not multiclass at all. Encounters that lean on a single class weakness, such as a heavy wisdom-save effect against a party of fighters, assume the player will find a way around it through items, consumables, or pre-buffing, not through a multiclass respec. The practical consequence is that encounter designers have to plan for two audiences at once: players who treat the game as a system to optimise, and players who treat the cast as a set of characters to roleplay. The combat design tolerates both because the difficulty modes sit on a separate slider from the roleplay content.

Production trade-offs of a ten-companion cast

Character-driven RPGs usually scale their cast up or down based on production budget. BG3 sits at the higher end, but the choices that made that scale possible are worth examining, because most of them translate to smaller budgets once the priorities are clear.

Voice acting and recorded lines

Every companion is fully voiced across the main campaign, including alternative lines based on the player’s race, class, and approval level. Post-launch reporting on the game’s budget places the spoken dialogue count well above one hundred thousand lines, which is consistent with the size of the cast. The cost of that decision is borne by the studio in casting, recording, localisation, and QA. The benefit is that scenes can play out in-engine with cinematic camera work rather than a text box, which in turn supports the romance and approval systems because players hear the actor respond to their choices in real time.

One production pattern worth noting is the use of barks, short reaction lines that fire during exploration and combat. Barks are cheap to record individually but expensive in aggregate, because each companion needs hundreds of them to avoid repetition. Larian’s approach was to pool barks across the cast and reuse context, so a “we should be careful here” line can serve multiple companions with different voice actors. Studios considering a similar system can adopt the same trick to keep total line counts down without losing ambient character presence.

Localisation as a compounding cost

Full voice acting compounds with every supported language. A scene that is a single recording in English becomes a recording in every localised language, and the QA cost grows with the number of recorded lines per language. For a developer weighing similar investments, the question is not whether full voice acting is desirable, it clearly is, but how many lines per companion can be recorded before the budget for a new companion displaces another system. Larian’s answer appears to have been to commit to a smaller cast of deeply written companions rather than a larger cast with thinner coverage.

Localisation also affects the dialogue tree itself. Languages that run longer than English on screen force the UI to either widen the text box or shorten the line, which in turn forces the writers to keep sentences compact. The game ships with a localisation team large enough to enforce that constraint at script level, and that investment is one of the reasons the localised versions do not feel like text dumps. Smaller projects can still aim for a similar result by writing short lines first and expanding in English only when there is room in the budget.

Animation, cinematics, and barks

Companions have idle animations for camp, walking animations for exploration, attack animations for each weapon, casting animations for each spell school, and a set of reaction barks for combat and exploration. Cinematic dialogue cameras add another layer, because the engine has to choose a camera setup that frames two characters, three characters, or a crowd without occluding the UI. These are routine costs, but they scale with the cast and with the number of permutations. A team that wants a smaller version of this system can start by limiting the number of cinematic camera cuts per scene and by sharing idle animations across the cast.

A related cost is mocap for the cinematic dialogue scenes. Most companions use a combination of facial capture and hand-keyed body animation, because full-body mocap for every line is prohibitively expensive at this line count. The trade-off is that emotional beats land in the face and the voice, while body language is more reserved. Studios that plan a fully mocapped cast should budget for either a smaller line count or a much longer production schedule, because the per-line cost of mocap is roughly an order of magnitude higher than voice alone.

Testing and combinatorial blow-up

The hardest production cost is testing. Each companion’s personal quest, romance arc, and approval thresholds interact with the main story, with party banter, and with each other. A scene that is correct in isolation may still break when two specific companions are present, when the player has a particular class, or when the party is full. The game’s public launch state, followed by several patches, reflects the reality that even a heavily tested cast will surface edge cases that only appear in a real playthrough. Studios that plan for a similar system need to budget for post-launch content updates that fix combinations the test team did not hit.gamesradar.com/baldurs-gate-3-companions-party/” target=”_blank” rel=”noopener”>all baldur's gate companions and party for an independent source about all baldur's gate 3 companions and party members. Readers can also consult the all baldur's gate companions and party for an independent source about all baldur's gate 3 companions and party members.

The combinatorial blow-up is not linear. Ten companions, three acts, four party slots, and a few thousand story flags produce a state space that no QA team can enumerate. Larian’s mitigation has been to write scenes that are robust to a small amount of context loss, so a missing voice line or a swapped party order does not break the encounter. Designers who build companion systems from scratch should plan for that robustness from the first script, because retrofitting it after launch is more expensive than writing it in.

What the design gets right and where it strains

An honest assessment has to call out both the wins and the places where the design pushes against its own limits. A design study that lists only strengths is not useful to a developer trying to learn from the project, so this section covers both sides with concrete examples.

Where the design works

Each companion’s combat kit is recognisable in the first hour, so the player learns the system through play rather than reading
Camp as a shared space supports cross-companion scenes that the main quest cannot fit, which is where much of the cast’s personality actually lives
Hidden approval lets players who ignore the system still see a coherent story, while players who optimise get a second layer of reward
Origin characters give replay value without requiring the team to write brand new companions for a second playthrough

Where the design strains

Late-game companions, particularly Halsin, Jaheira, and Minsc, arrive with less story runway than early companions and feel thinner in Act 3 as a result
The long rest economy is easy to exploit, which dilutes the resource tension the combat system otherwise does well
Approval is global across the party but is interpreted per companion, which can cause scenes to fire in an order the player did not expect
Romance gating is sometimes invisible, so a player can lock themselves out of content without knowing the rules

None of these are fatal problems, and most of them are visible because the rest of the design is so carefully integrated. A smaller cast at a smaller studio would not face all of them at once, but the same trade-offs appear in a milder form in any companion-driven game. The honest read is that BG3 ships a cast that is closer to its ideal than most projects will reach, and the imperfections are mostly the cost of having that many voices in one game.

BG3 companions as a reference for other projects

Studios working on companion-heavy games can borrow the structural decisions without borrowing the budget. The table below maps each design lesson to a concrete production cost, so a small team can decide which trade-offs fit their project. The costs are rough orders of magnitude rather than precise figures, because real budgets depend on studio location, voice talent rates, and engine reuse.

Design choice	What it costs	What it returns	Where it falls on a smaller budget
Full voice acting for the cast	Casting, recording, localisation, QA	Cinematic scenes, roleplay immersion, romance weight	Cut to two voice leads, text for the rest
Single social hub (camp)	One instanced map plus idle scenes	Crossover content, banter, pacing lever	Reuse a tavern or ship deck in the main game
Hidden approval system	Threshold tables, scene gating logic	Replayability, roleplay protection	Replace with a visible two-stage affinity
Origin characters	Scripted branch rewriting, extra cinematics	Replay value, asset reuse	Pick one or two origin options only
Personal quest per companion	Writing, voice, quest scripting, QA	Character depth, ending variety	Two short beats instead of a full arc
Romance arcs	Approval gates, consent logic, scene variants	Emotional investment, fan attachment	One romance path, rest as friendship
Multiclass respeccing at camp	UI, balance pass, encounter tuning	Build variety, theorycraft community	Lock classes, allow subclass swap only
Legacy character returns	Licensing checks, legacy dialogue writing	Series fans, marketing pull	Skip for non-sequel projects

The right column is where most small projects will sit, and the table is meant as a starting point rather than a recipe. The lesson is that the structural decisions scale down with the budget, while the writing work does not, which is why the writing is usually the first thing to be cut on a constrained project. A team that keeps the writing intact and reduces the surrounding production will get a smaller game that still feels authored.

Pick a system spine and stick to it

BG3 leans on D&D 5e as a common ruleset for stats, classes, and combat. A smaller project can choose a simpler system, such as a fixed role per companion, but the rule should apply to every character. Inconsistency in the spine is what makes companion design feel like a collection of prototypes rather than a single game. The most common mistake on small projects is to give one companion a unique resource bar, then a second companion a different one, then run out of design time before the third. A shared spine is what keeps the third companion as polished as the first.

Keep personal quests short and intertwined

Each companion’s personal quest is roughly two to four hours of focused play. That length is short enough to write and test, and long enough to feel like a real story. Intertwining personal quests with the main campaign is what keeps the player from ignoring the cast, and it can be done with a small team as long as the main story has clear windows where the personal quest can resolve. A useful test is whether the personal quest can be skipped without breaking the main quest. If it can, the two are well separated. If it cannot, the writer should plan for the dependency rather than discover it in QA.

Use a single social hub

Camp is one instanced location that holds the cast together. A smaller game can use a tavern, a ship, or a guild hall with the same effect. The risk is to scatter the cast across separate hubs, which fragments the writing and makes crossover scenes prohibitively expensive. The hub also gives the player a mental map of where to find each companion, which is a small but real usability gain that a dispersed cast cannot offer.

Treat romance and approval as soft gates

Hard-gated romance that requires a specific dialogue choice is brittle and feels like a quiz. Soft-gated romance that responds to cumulative approval and a small number of story flags is more forgiving and easier to localise. BG3’s approach is a reasonable template, with the caveat that the hidden nature of approval can confuse players who want to plan their choices. A small project can use a visible two-stage affinity system (warm and devoted, for example) and still get most of the roleplay protection of a hidden score, with the bonus that the player can see why a scene has fired.

Lessons for the next companion-driven CRPG

Looking at BG3 as a whole, four design lessons stand out for a team that wants a similar cast without the same budget.

Smaller casts with deeper personal content outperform larger casts with shallow content, because the marginal cost of each companion is mostly in writing and recording, not in combat design
A shared social hub is the cheapest way to create character chemistry, because it lets the team write crossover scenes that reuse the same location and camera setups
Origin characters are an efficient replayability feature because the same script, art, and voice work supports both a recruited companion and a player character, which doubles the value of the assets already produced
Post-launch patches are part of the plan, not a failure of pre-launch testing, and a companion system that survives public launch will need at least one round of content updates to fix combination bugs the test team cannot reach

For a studio, the practical question is not whether to copy Larian’s cast size, it is whether the project’s central fantasy benefits from a character-driven party at all. A strategy game with named generals, a tactics game with a fixed squad, and an open-world action game with a single playable hero do not need a BG3-style cast, and forcing one in will dilute the rest of the design. The cast should fit the fantasy, not the other way around, and the projects that get this right tend to be the ones that pick a cast size they can finish.

How this article fits a GameDev publication

Talvoryx Studios is a working game production and content site, and an article on BG3 companions has to earn its place alongside the studio’s other coverage of game development, pipelines, and platform topics. The connection is straightforward: the companion system is a case study in how a shipped game organises character work, and the same lessons feed directly into decisions a development partner has to make on smaller projects. For readers who want the broader context, the studio’s overview of full cycle game development covers the production scope that wraps around a system like this, and the article on gaming development explains how a studio chooses where to invest in character-driven content versus other features.

Frequently asked questions

How many BG3 companions are there in the shipped game?

The shipped version of Baldur’s Gate 3 has ten recruitable companions: Astarion, Gale, Lae’zel, Wyll, Shadowheart, Karlach, Minthara, Halsin, Jaheira, and Minsc. Seven of those, Astarion, Gale, Lae’zel, Shadowheart, Wyll, Karlach, and the Dark Urge, can also be chosen as origin characters at the start of a playthrough.

Which BG3 companions can the player romance?

The companions with full romance arcs in the shipped game are Astarion, Gale, Lae’zel, Shadowheart, Wyll, Karlach, and Halsin. Jaheira has a flirtation path, and Minthara’s romance was expanded in post-launch updates. Each romance is gated by approval, race, consent choices, and the outcome of at least one personal quest, which is why the order of choices during Act 1 and Act 2 matters.

What is an origin character in BG3?

An origin character is a companion the player can choose to play as instead of recruit. The seven origin options are Astarion, Gale, Lae’zel, Shadowheart, Wyll, Karlach, and the Dark Urge custom character. Playing an origin puts the player inside that character’s scripted scenes, with the rest of the cast available as normal companions and the player’s custom character appearing as a separate NPC.

Can the player recruit all ten BG3 companions in a single playthrough?

Yes, but only with careful choices in Act 1, particularly around the goblin camp, the druid grove, and the companion-versus-companion conflicts. Minthara requires the goblin-aligned path, which means at least one grove character has to be sacrificed. The other nine can be recruited in any order across the three acts.

Do BG3 companions use the D&D 5e ruleset?

Yes. The game is built on a modified version of the Dungeons and Dragons 5th Edition ruleset, with changes for turn-based combat, scripted interactions, and a small number of adjustments to underused mechanics. Companion stat blocks, classes, and subclasses are drawn from the 5e source books that Larian licensed for the project, and the player can respec companions into multiclass combinations through the Withers service at camp.

How does the approval system in BG3 work?

Each companion tracks a hidden approval score that shifts in response to the player’s dialogue choices, story decisions, and party actions. The score feeds an internal threshold system that opens or locks companion-specific scenes, romance paths, and ending variations. Players can see approval change through in-game cues, such as a companion approving or disapproving out loud, but the exact number is hidden in the default interface.

What role does camp play for BG3 companions?

Camp is the shared social hub where the active party and reserved companions gather. It is where the player swaps companions in and out, triggers one-to-one scenes, watches party banter, and takes long rests. Camp is also the location where many personal quest resolutions and romance confirmations take place, which is why it functions as the structural anchor for the cast.

Which BG3 companions return from earlier Baldur’s Gate games?

Jaheira, a half-elf druid, and Minsc, a human ranger, return from earlier entries in the Baldur’s Gate series. Both are recruited in Act 2 and Act 3 respectively, and their dialogue references past events while remaining accessible to players who have not played the earlier games. The return of legacy characters is one of the design choices the development team discussed publicly during the game’s marketing cycle.

Can a player build a balanced party without using any BG3 companions at all?

Yes. The game allows the player to run a custom party of created characters, with up to four in the active party and additional hirelings stashed at camp. This option exists in addition to the origin and companion rosters, and it is the closest the game comes to a classic D&D party built from scratch. Many players use this mode for self-imposed challenges, such as solo or origin-only runs.

How do BG3 companions compare with party members in earlier CRPGs?

Compared with earlier CRPGs, BG3 companions sit closer to the player’s emotional centre of gravity. Earlier games typically voiced the protagonist and used text dialogue for companions, while BG3 voices the full cast and ties each companion to a personal quest, an approval system, and a romance path. The trade-off is the much higher production cost, which is why most CRPGs that follow this template either accept a smaller cast or accept a longer development cycle.

BG3 companions: a developer’s guide to party design