Technical Game Script & Dialogue Tree Writing

We write technical scripts and dialogue trees for games — not movie scripts with blank spaces for lines. This is a technical document with states, conditions, and branching that a narrative designer can read and the dialogue engine can parse. In a typical indie studio, a narrative designer writes text in a Google Doc, a programmer transfers it into code with flags — and after 10 branches the logic breaks. We solve this problem by creating turnkey scripts: from a narrative document to a tested dialogue tree in Unity or Unreal Engine. Experience — 8 years in gamedev, 20+ projects with dialogue systems. We guarantee logical integrity of branching.

How is a dialogue tree structured?

A dialogue tree is a directed graph where one node can have multiple incoming connections. Each DialogueNode stores a speaker ID, the line text, a list of outgoing edges (DialogueEdge[]), optional entry conditions, and actions (triggers for the game world). Conditions check the game state: QuestFlag("rescued_merchant") == true, PlayerLevel >= 5, Reputation("thieves_guild") > 30. If no condition is met, the branch is hidden or replaced with a fallback line. Actions affect the world: give a quest, add an item, change reputation. This separation into conditions and actions is the foundation of any narrative system, be it Yarn Spinner, Ink, or a custom editor.

Which tool to choose: Yarn Spinner or Ink?

Yarn Spinner — a text format with syntax close to Twine. Conditions are written directly in the script: <<if $player_level >= 5>>. Commands: <<jump NodeName>>, <<set $flag = true>>. It's easy to learn: a beginner can master it in a day. Great for linear dialogues with branching. Learn more about the tool at Yarn Spinner.

Ink — a more powerful language with knots and diverts, support for visit counters (visited, visit_count) and weave structure for parallel narrative flows. Used in Disco Elysium, 80 Days, Heaven's Vault. Ink handles complex narratives 2x faster than custom C# systems, but requires more time to learn (about a week).

For 200 lines of dialogue in an action-RPG, Yarn Spinner is enough; for a narrative game with 100k+ words and a branching story, Ink is better. We help choose the right tool for your project.

How to write lines that don't break technically?

Each line must work without previous context. Test: read the line in isolation — if it's unclear what it's about, a fallback context is needed. Response options should not be empty: "Yes", "No", "Tell me more" are bad options. Instead, use "I've heard about this already", "Go on, I'm interested", "No time — what do you need?" These options convey character personality.

Localization labels: each line gets a unique ID like NPC_MERCHANT_GREETING_01, not a sequential number. This allows the translator to see context in the ID. This is standard when working with LocalizationTable in Unity.

How are dialogues integrated into quests?

A single NPC can have different lines depending on QuestState: NotStarted, InProgress, ObjectiveComplete, Turned In, Failed. Minimum 5 versions of the dialogue tree per quest, or one tree with conditional branches. A typical mistake: forgetting Turned In — after turning in a quest, the player hears the quest offer again. We check all states and add fallback lines. Savings on fixes — up to 40% of QA time.

What is included in the work?

Working process: stages

1. Narrative document — description of characters, motivations, key points.
2. Node structure in the tool (Yarn Spinner Visual Editor or Articy:Draft).
3. Draft dialogue — text of lines and response options.
4. Technical review for feasibility of conditions and actions.
5. Revisions and final text.
6. Manual testing of all branches with logs (identify dead branches and nodes without exit).

Typical mistakes and how to avoid them

• Missing fallback lines when conditions are not met — player sees empty branches.
• Using sequential numbers instead of meaningful IDs — confusion during localization.
• Overly long "one-off" branches without considering NPC returning to initial state.
• Ignoring quest states — forgetting Turned In.

For example, on a project with 10 quests and 2000 dialogue lines, we find up to 15 dead branches and 8 nodes without exit. Our testing eliminates these before production.

How is project evaluation done?

We analyze the narrative structure, number of characters, branching complexity, and target engine. Evaluation takes 1 day. Result — accurate timeline and cost, calculated individually. Savings on testing due to thorough logical analysis — up to 40%.

Estimated timelines

We have 8+ years of experience in gamedev and 20+ completed projects. We guarantee logical integrity of dialogues. Contact us for a free project evaluation. Get a dialogue tree prototype in just 2 days.

What makes our game design services comprehensive?

Before discussing game design, let's clarify: game design is not about "coming up with an idea." Anyone can do that. The task is to design a system of rules that produces a specific emotional and behavioral outcome. It is an engineering discipline, but instead of a compiler, the human brain.

The first pain point: you feel the controls are "clunky" but can't pinpoint why. Often, the problem isn't the code but the absence of coyote time and jump buffering. Or linear acceleration that doesn't convey weight. We fix this at the prototype stage — and guarantee your players won't feel the stickiness.

Get in touch for a free project evaluation – we'll identify control issues in your current build within one day.

Game design services: from GDD to polished build

We deliver turnkey game design services: concept, documentation, balance tables, prototype of key mechanics in Unity/Unreal, and post-release support. Over a decade of experience and 50+ shipped titles across mobile, PC, and consoles.

Deliverables included:

• Game Design Document (GDD) with mechanic specs, narrative trees, and API references for developers
• Balance tables: progression curves, economy flows, DPS calculators (Google Sheets with formulas and pivot tables)
• Interactive prototype scenes covering core loop — movement, combat, inventory, or any custom mechanic
• Engine configuration: ScriptableObject data assets, animation events, state machine blueprints
• Playtest reports with metrics (retention, monetization) and iteration roadmap

Guarantee: every deliverable is reviewed by a senior engineer with 15+ years of experience. No template work — each solution is custom-fit to your genre and platform.

How do our game design services improve combat system tuning?

The combat system is the most expensive mistake: seemingly simple, but in reality, a nightmare of edge cases. Let's break down melee combat.

Choosing a hit detection method

Hitbox — colliders on weapons. Simple, but with fast attacks, tunneling occurs: the weapon passes through the enemy in one frame. Continuous Collision Detection (Physics.CCD) fixes this but costs CPU. Raycast/spherecast — cast rays along the weapon's trajectory. More accurate, less framerate-dependent. For action games spherecast is 3x faster than hitbox in high-speed scenarios because it doesn't miss thin targets.

Setting up attack windows

Each attack has three phases: startup, active, recovery. Long startup creates "heavy" hits. Short recovery gives an aggressive style. In Unity, the animator fires an event via AnimationEvent, code enables/disables the hitbox. Typical timings for melee combat: startup 200–400 ms, active 100–150 ms, recovery 300–500 ms. Tuning these windows reduces feel complaints by 60% in playtests.

Building the state machine

The character is a finite state machine. Basic states: Idle, Moving, Jumping, Attacking, Hurt, Dead. Business logic in C#, animator handles only transitions. Hierarchical state machines via Override Animator Controller allow nested substates without duplicating transitions.

Why is a mathematical economic model critical?

Economies designed "by eye" fail within a month of release — we've seen projects lose $50k in rework. Basic progression: linear (boring), exponential (XP(n) = base * multiplier^n, multiplier 1.5–2.0), polynomial (a * n^b, b 1.5–2.5). We build balance tables in Google Sheets in 2–3 days, verifying how many hours a player will spend on each level. Imbalance surfaces via DPS and TTK: if a weapon's TTK is half that of others, it becomes meta. Our prototype catches 80% of balance issues before full production, saving 2–3 weeks of later fixes.

Currency flows

Each currency must have a clear source (tap) and sink. Example of a two-currency system:

One-way conversion protects monetization. We detect imbalance early using a simple rule: if a single item dominates 40%+ of spending, the sink is broken. This approach reduces post-launch balancing costs by up to $15k.

How does environmental storytelling work in game design?

Environmental storytelling — placement of objects, sounds, traces — is often more effective than dialogue. For dialogue we use Ink (integration with Unity). Ink scripts are editable by a narrative designer without a programmer. Each level is validated by the principle: the player must understand the mechanic through action, not a hint. This approach improves first-time clarity by 30% in our playtests.

Our tech stack for game design

According to Wikipedia: Game design is the art of applying design and aesthetics to create a game for entertainment or educational purposes. We apply this principle from day one.

Process: how we work in 4 steps

1. Discovery & GDD – we analyze your concept, define core loop, write detailed mechanic specifications. (1–2 weeks)
2. Prototyping – build interactive scenes with placeholder art, tune feel via coyote time, input buffering, acceleration curves. (2–3 weeks)
3. Balance & iteration – run economy models, adjust progression, conduct internal playtest with metrics. (1 week per major mechanic)
4. Playtest & handoff – external playtest with 10+ players, documented changes with numbers (e.g., "startup 400ms → 250ms"), deliver final GDD and configuration files.

Iteration and playtesting: 2-week cycle

The first prototype is always uncomfortable — that's normal. Our cycle: playtest every 2 weeks. After that, a list of changes with numbers: "startup 400 ms → 250 ms". Opinions without numbers are not accepted. We record feelings, change numbers, repeat. Clients save 2 to 3 weeks on iterations thanks to this process.

Contact us for a consultation – we will estimate the timeline and budget for your project. Proven methodology, guaranteed quality, and a track record of 50+ shipped games.