PaperlayerView exact revision on arXiv

Source-linked AI summary

PUBG Ally: A Conversational Embodied Agent as an AI Teammate

Beomsoo Kim, Byeongju Kim, Dohyun Kim, Dongwon Kim, Eunchong Kim, Hongmin Kim, Hyeojung Im, Hyeonbin Hwang, Hyeonghwan Kim, Hyoseok Seol, Insub Im, Irene Chen, Jaeseung Jeon, Jimin Hong, Kiyoon Yoo, Minkyoung Park, Seohyeon Jung, Seungjun Chung, Sue Hyun Park, Sungwoo Kim, Youngin Cho, Yujeong Son, Kangwook Lee, Hyunseung Kim

arXiv:2609.29837v1cs.AIcs.CLcs.HC

TL;DR

Ally addresses the challenge of coordinating natural voice interaction with fast, autonomous gameplay in a changing game world. It combines language-model reasoning with faster game control and iterative development from real-player interactions; in a live-service survey, recommendation responses were more positive than negative among record-confirmed players.

  • Problem

    A conversational embodied teammate must respond to a changing game world under tight latency constraints while keeping its speech synchronized with its observations and actions.

    Source: §1 · p. 4

  • Method

    Ally combines a language-model agent with a faster control layer and develops the system through real-player data, preference-based evaluation, and iterative training.

    Source: §1 · p. 5, §3.1 · p. 7, §6 · p. 17

  • Results

    By 25.1 percentage points, positive responses exceeded negative responses when record-confirmed players were asked whether they would recommend Ally.

    Source: §1 · p. 5

  • Takeaways & Limitations

    Repeated interaction with real players supported model and system improvement while revealing gaps between internal evaluations and the qualities players valued in a teammate.

    Source: §9 · p. 32

    The harness and SLM were not jointly optimized, leaving open how to optimize them together under real-time on-device constraints.

    Source: §9 · p. 32

Abstract

from arXiv · show

We introduce PUBG Ally, an embodied agent for PUBG: BATTLEGROUNDS that can reason, act autonomously, and play alongside players as a voice-enabled teammate. Building such a teammate requires combining two difficult capabilities: it must perceive and respond to a constantly changing game world under strict latency constraints while interacting naturally with players, keeping its speech synchronized with its actions. Ally therefore combines agentic tool use with real-time game control. A language-model agent uses a controlled interface to inspect game information, interpret player speech, maintain context, decide what to say, and issue high-level action choices that steer a faster control layer for movement, combat, and recovery. Because the player's and Ally's speech and actions continually shape each other and the course of the match, training requires data from actual gameplay. We therefore collect data across nearly 39k sessions in which real players play alongside Ally, recording gameplay, player speech, agent decisions, tool use, actions, and player feedback, and use these records for iterative training. To evaluate teammate quality, we use player feedback and preference comparisons to identify gaps between offline evaluations and player preferences, and iteratively refine the evaluation criteria. Deploying Ally in live service further requires low-latency on-device execution and safeguards for player-facing communication, which we address through model compression, context compaction, targeted safety training, runtime guardrails, and memory redaction. During the live service, we surveyed players in 141 countries. Among respondents whose play with Ally was confirmed in game records, positive responses exceeded negative responses by 25.1 percentage points when asked whether they would recommend Ally, with players describing Ally not only as a tool but also as a teammate or companion.

1. Introduction

PUBG Ally is a voice-enabled embodied teammate designed to synchronize communication and action in a changing game world under tight latency constraints. The paper describes its layered agent, real-player training data, player-centered evaluation, and live-service deployment; surveyed players gave more positive than negative recommendations.

1. Introduction

  • Ally addresses the challenge of keeping speech consistent with observations, decisions, and actions as the game changes.It is designed as a co-playable character that communicates and coordinates with a human in a shared game world.Source: §1 · p. 4
  • Across 28 collection days, 1,046 participants played 38,956 sessions, producing rollouts that connect player speech and game events with Ally’s tool use, responses, and actions.Iterative training used teacher demonstrations, student rollouts, teacher corrections, and distillation into a deployable 2B student.Source: §1 · pp. 4–5
  • The evaluation framework was refined using player preferences, survey responses, and gameplay records to address gaps between internal evaluations and qualities valued by players.It covers conversational quality, gameplay behavior, and cooperation, with scenarios grounded in actual matches.Source: §1 · p. 5
  • For live service, Ally’s on-device language and speech components must meet tight latency and memory constraints while handling contextual communication safety.The paper addresses these requirements with model compression, context compaction, safety training, runtime guardrails, and memory redaction.Source: §1 · p. 5
  • By 25.1 percentage points, positive responses exceeded negative responses when record-confirmed players were asked whether they would recommend Ally.The survey reached players in 141 countries during a two-week live-service beta.Source: §1 · p. 5
  • Ally combines language-model reasoning, voice interaction, and autonomous gameplay through a bounded tool interface and a System 1–System 2 control hierarchy.The paper also presents real-player training data, player-preference evaluation, contextual safety mechanisms, and production engineering for on-device deployment.Source: §1 · pp. 4–5
  • To the authors’ knowledge, Ally is the first conversational embodied teammate in a commercial live battle-royale game to combine autonomous action, voice coordination, and on-device language and speech models.The paper presents this work as a practical foundation for real-time embodied agents that communicate and act with people.Source: §1 · pp. 5–6

2. PUBG Duo Play & Deployment Setting

PUBG duo play requires teammates to coordinate speech, action, resources, and decisions as match conditions change. Ally is evaluated in a bounded deployment setting that pairs one human with a voice-enabled agent in Sanhok matches.

2.1. How a Duo Plays

  • Matches unfold through changing tactical conditions as the safe zone shrinks, teams relocate, and encounters become more frequent.Players scavenge and fight to be the last surviving player or team.Source: §2.1 · p. 6
  • Duo teammates coordinate by voice and pings, share resources, cover one another, revive knocked partners, and carry preferences and commitments across situations.A good teammate coordinates speech, action, memory, and timing to suit the partner and moment.Source: §2.1 · p. 6
  • An AI teammate must infer incomplete commands, understand player vocabulary, remember match context, connect actions to the current situation, and respond quickly.Ally targets a partnership in which the human and agent share one team’s fate.Source: §2.1 · p. 6

2.2. Deployment Setting

  • Ally is paired with one human in 64-player Sanhok matches and supports Korean, English, and Chinese through a dedicated push-to-talk channel.Because play continues during inference, responses must remain relevant to the current situation.Source: §2.2 · p. 6
  • The runtime pipeline uses STT, an on-device SLM as System 2, TTS, and a System 1 behavior-tree controller that acts at game-tick rate.The configuration targets consumer GPUs with at least 8 GB of VRAM and runs one language-model inference at a time while sharing resources with the PUBG client.Source: §2.2 · p. 6

3. PUBG Ally Architecture

PUBG Ally separates language-model deliberation from latency-critical control, with a bounded tool interface connecting speech, observations, and high-level actions. Event-driven agent loops manage context and coordinate with a stateful behavior tree that continues executing actions at game-tick rate.

3.1. A Layered Agent Architecture

  • A dual-system architecture keeps language-model reasoning off the game-tick control path: System 2 selects high-level actions, while System 1 executes movement, combat, and recovery every tick.System 2 runs in response to events rather than a fixed clock; System 1 continues acting while the model is idle or deliberating.Source: §3.1 · p. 7

3.2. System 2: Event-Driven Agent Harness

  • The bounded interface limits Ally to exposed information and executable controls, letting it report unavailable information or offer an alternative instead of guessing or dispatching unsupported actions.Before dispatch, Ally checks action availability; focused tools expose observations, speech, actions, memory, and game knowledge.Source: §3.2 · pp. 7–8
  • Each agent loop processes events and tool feedback over variable turns, refreshes speech and action status, and carries unfinished work forward in a compact plan.The plan retains pending tasks and commitments, while rapidly changing match observations are refreshed rather than carried across loops.Source: §3.2 · pp. 8, 10, Figure 3 · p. 9
  • Event-driven scheduling batches pending events and prioritizes them when overloaded, while reactivity priors and cooldowns tune speech and action responses and constrain unsolicited behavior.Speech and action priors are independent; event settings can be adjusted without retraining the model.Source: §3.2 · pp. 9–10

3.3. System 1: Stateful Real Time Control

  • System 1 persists dispatched actions as behavior-tree subtrees across ticks, allowing movement, combat, or revival to continue while System 2 is idle or reasoning.Higher-priority conditions can preempt a task, and completed, failed, or aborted actions return control to an eligible branch and emit an outcome event.Source: §3.3 · p. 10

4. Data & Training

Ally’s training uses real-player match trajectories and teacher-corrected student behavior to cover interactions shaped by both teammate and agent actions. A three-stage distillation pipeline, supplemented by synthetic examples and curated data, trains the deployable student.

4.1. Data Collection

  • 1,046 participants completed 38,956 gameplay sessions over 28 days, yielding real-player trajectories from both teacher and deployed student policies.Sessions averaged 14.1 minutes and 59 trajectories; records included speech, game events, observations, tool results, agent speech, and executed actions.Source: §4.1 · pp. 11–12

4.2. Training

  • Teacher-corrected student rollouts are added cumulatively to the teacher corpus because deployed students encounter interaction contexts absent from teacher-policy matches.The teacher generates a corrected trajectory suffix from a student-induced prefix, and the complete suffix becomes a correction target.Source: §4.2 · p. 12, Figure 4 · p. 12
  • Synthetic examples supplement real-player data with rare states, infrequent actions, and player requests whose feasibility depends on game conditions.Paired feasible and infeasible requests vary inventory, position, match phase, or action availability; the target acts, asks for clarification, declines, or proposes an executable alternative.Source: §4.2 · p. 13
  • Corpus curation filters invalid or incomplete records and caps repetitive situations while preserving interactions requiring richer dialogue, observations, and executable decisions.Filtering also excludes records that do not meet consent or privacy requirements.Source: §4.2 · p. 13
  • Three stages train the deployable 2B student: hard-target supervised fine-tuning of an 8B intermediate teacher, then off-policy and on-policy distillation from that fixed teacher.On-policy distillation uses tool-interaction trajectories generated by the current student; the 8B model bridges the 31B-to-2B capacity gap.Source: §4.2 · p. 13, Figure 5 · p. 14
  • The student’s tool calls determine the results and later context in on-policy distillation, extending sequence distillation to interaction-formed trajectories.The student-generated trajectories are supervised with soft targets from the fixed 8B teacher, without an additional task-reward RL objective.Source: §4.2 · pp. 13–14

5. Safety & Responsible Deployment

Ally’s safety process specifies contextual content boundaries and response styles, trains on both unsafe interactions and benign game communication, and adds runtime safeguards. Evaluation and review feed identified failures back into specifications, training data, prompts, and guardrails.

5.1. Safety Specifications

  • Ally’s safety taxonomy treats ordinary simulated combat as acceptable game communication while defining unsafe categories and conditions that override the in-game interpretation.Ambiguous combat language defaults to in-game; real-world targeting, rejection of the game interpretation, repeated pressure, and context-independent unsafe content override that default.Source: §5.1 · p. 15, Table 4 · p. 15
  • The response-style specification combines an always-on persona and boundary tier, general safety principles, and category-specific guidance for unsafe utterances.For example, self-harm responses suspend the usual companion persona and direct the player to professional help.Source: §5.1 · pp. 15–16

5.2. Safety Training

  • Safety training combines harmful-speech responses with benign hard negatives so Ally can handle unsafe speech without refusing ordinary tactics, weapon talk, or teammate banter.Data sources include gameplay, human-authored adversarial dialogues, public safety datasets, and targeted synthetic examples.Source: §5.2 · p. 16

5.3. Runtime Guardrails

  • A rule-based output filter withholds candidate speech containing blocked terms, but passing it only means no blocked term matched and does not guarantee contextual safety.Separately, model-identified unsafe player speech can be redacted from later context and memory, a mechanism that depends on correct model identification.Source: §5.3 · pp. 16–17

5.4. Iterative Safety Development

  • Safety evaluation, gameplay testing, audits, and publishing review feed failures into revised specifications, targeted training and prompt changes, or guardrail updates before redeployment.Reviews look for mishandled real-world harm, over-refusal of normal PUBG communication, specification or data gaps, and cases needing runtime safeguards.Source: §5.4 · p. 17

6. Evaluation

Ally is evaluated through capability and safety tests, followed by live player comparisons. Player preferences and gameplay evidence also iteratively shape the evaluation suite used in model selection.

6. Evaluation

  • Offline evaluation screens models for teammate behavior and safety before small-scale live comparison selects a candidate for large-scale A/B testing against the current best.Capability scores are proxies for player experience; failures such as malformed generation and invalid tool calls are checked in a separate deployability gate.Source: §6 · pp. 17–18, §6.1 · p. 18, §6.3 · p. 20

6.1. Capability Evaluation

  • Capability tests score generated trajectories on observable teammate behaviors, using held-out contexts linked to positive or negative player feedback and rubric-based LLM judgments.Dimensions include factual grounding, game-event response, intent understanding, instruction commitment, and trajectory quality; diagnostic artifacts help identify failures.Source: §6.1 · p. 18, Figure 6 · p. 22

6.2. Safety Evaluation

  • Safety evaluation tests harmful-input handling and continued gameplay on benign speech that superficially resembles unsafe content, with harmful sets tailored to each locale.Production-representative dialogues replay prior pressure to test boundary maintenance and recovery; harmless response rates are measured before and after runtime guardrails.Source: §6.2 · pp. 19–20
  • 0.91 sensitivity, 0.79 specificity, and Cohen’s κ=0.70 were reported for Gemini 3 Flash on a held-out expert-labeled calibration set (n=266).The judge evaluates whether responses are harmless across English, Korean, and Chinese.Source: §6.2 · p. 20

6.3. Online Evaluation

  • In large-scale A/B evaluation, 433 players provided 797 responses after completing sessions with both models in randomized, undisclosed order.Players reported a preference or no clear difference and could provide free-text feedback.Source: §6.3 · p. 20

6.4. Iterative Evaluation Refinement toward Player Preference

  • Player preferences, free-text feedback, and gameplay trajectories iteratively refine grader criteria, within-theme weights, and aggregation settings for later model comparisons.Disagreements between offline evaluations and player choices help reveal missing criteria or mismatched importance; examples of added criteria include speech–action alignment.Source: §6.4 · pp. 20–22

7. Main Results

Across capability, safety, and live-play evaluations, Ally’s distilled on-device models approached teacher performance, safety behavior improved with targeted recipes, and players preferred successive builds while recommendation held across deployment phases. Live tests also show faster local interaction and examples of proactive, multi-step, and cross-match behavior, alongside reported inconsistencies.

7.1. Capability Evaluation Results

  • After prompt optimization and distillation, the 2B student’s confidence intervals overlapped the teacher’s on all five capability scores.Prompt optimization brought Gemma 4 31B close to the external quality reference; the distilled student scored 0.932 Fact, 0.954 Event, 0.953 Intent, 0.876 Cmd, and 0.902 Traject.Source: §7.1 · pp. 22–23

7.2. Safety Evaluation Results

  • The final safety recipe strengthened harmful-input handling while modestly increasing over-refusal, which remained low enough for normal gameplay in most benign cases.The final models reached 98.3–99.4% on broad-coverage benchmarks and 84.1–99.0% on production-representative dialogue before runtime filtering; over-refusal was 2.2–6.1% across locales.Source: §7.2 · pp. 23–24
  • Broad-coverage synthetic data raised benchmark performance from 72.3% to 94.8%, while real in-game safety data raised production-representative performance to 84.1%.The final recipe retained 84.1% production-representative performance and raised broad-coverage performance to 98.3%; Figure 7 compares the successive recipes and boundary-handling groups.Source: §7.2 · p. 24, Figure 7 · p. 25
  • Adding real in-game safety data improved boundary preservation by about 11–13 pp and recovery by about 17 pp, while boundary-breached cases remained the clearest failure mode at 63.6%.The final recipe’s further recovery gains and slight preservation decline were within the 95% Wilson intervals.Source: §7.2 · p. 24

7.3. Results from PC Bang Data Collection

  • The on-device LM was 3.2× faster at median latency than cloud (0.80 vs. 2.54 s), and a single spoken exchange took approximately 1.6 s versus 3.4 s.A six-inference trajectory remained under five seconds locally, while cloud exceeded ten seconds; the latency figure summarizes trajectory totals by inference count.Source: §7.3 · p. 25, Table 8 · p. 26, Figure 8 · p. 26
  • Recorded sessions illustrate proactive repositioning, multi-loop errands, and cross-match preference memory, while player feedback also reports occasional failures in these behaviors.The examples include Ally warning about a shrinking safe zone, completing a loot trip and returning to the player, and recalling a requested ACE rifle in a later match.Source: §7.3 · p. 28
  • 69.5% to 18.8% of players preferred on-device v1 over the cloud model, but a comparable-latency re-test favored cloud 52.4% to 31.1%; later candidates were never less preferred than incumbents.Net recommendation rose from approximately +8 pp to the mid-30s in the initial phase and held through the cloud-to-on-device transition, ending near +36 pp.Source: §7.3 · p. 29, Table 10 · p. 30

8. Live Beta Player Survey Results

In the live survey, respondents with logged Ally Duo matches rated the overall and conversational experience more favorably than combat contribution, while describing both functional and social value. These results describe players who chose to enter the mode and answer the survey, not population-level or within-player changes.

Survey scope

  • The live survey describes self-selected players who both entered the mode and answered questions, so differences from PC bang feedback are not within-player or population-level changes.Live analysis was further restricted to respondents with a logged Ally Duo match during the beta.Source: §8 · p. 30

Player ratings

  • +25.1 percentage points was the live respondents’ net recommendation, despite lower ratings for gameplay than conversation and an overall combat-skill rating of 2.58/5.Situation reading scored 2.88, response speed 2.93, and command following 2.99; Figure 14 plots pooled means on a five-point scale across the six most represented locales.Source: §8 · p. 30, Figure 14 · p. 31

How players framed and valued Ally

  • 50.0% framed Ally as a tool, 31.5% as a companion, and 18.5% as a teammate; information/tactics was the most selected liked aspect at 51%.28% selected “someone to talk to”; the paper treats the PC bang comparison as contextual because recruitment and exposure differed.Source: §8 · p. 30, Figure 15 · p. 31

Relational framing across measures

  • Companion respondents selected “someone to talk to” more often than teammate respondents (+11.9 pp), while teammate framing was associated with stronger overall evaluation.Companion respondents also spoke to Ally more often in linked logs: 1.38 versus 1.23 utterances per minute.Source: §8 · p. 31

Open-ended feedback

  • Open-ended feedback valued information and conversation but criticized combat contribution, follow-through, and communication timing.Some players found late-game chatter distracting when they were trying to hear footsteps.Source: §8 · pp. 31–32

9. Conclusion

The conclusion presents PUBG Ally as a deployed voice-coordinating embodied teammate and emphasizes developing communication, reasoning, and action coherently under real-time constraints.

9. Conclusion

  • PUBG Ally combines reasoning, autonomous gameplay, voice coordination, and on-device language and speech models in a commercial live battle-royale game.The authors describe it as the first system of this kind to their knowledge.Source: §9 · p. 32
  • Repeated interaction with real players supported system improvement while revealing gaps between internal evaluations and qualities players valued in a teammate.Source: §9 · p. 32
  • The harness and small language model were designed and trained sequentially rather than jointly, leaving their joint optimization an open question.Source: §9 · p. 32
  • Ally currently uses push-to-talk and turn-based communication and cannot process new player utterances while executing tool calls.Source: §9 · p. 32
  • Ally’s agentic architecture integrates language-model reasoning, conversation, and autonomous action under real-time, on-device constraints, and Ludi 0.1 draws on its design principles.The cited application extends those principles to communication, memory, navigation, and manipulation in physical robotics (Ludo Robotics, 2026).Source: §9 · p. 32

10. Contributors and Acknowledgments

These appendices credit the cross-functional contributors and situate Ally among agentic products, game interfaces, and AI companions. They detail its bounded context policy and behavior-tree control design.

10.1. Contributors

  • Contributors are listed by functional role, with names ordered alphabetically by given name within each role.Source: §10.1 · p. 32

A.1. From Foundation Models to Product Agents

  • Product-agent harnesses surround foundation models with tools, environment access, feedback, verification, and oversight; Ally adapts this pattern to live multiplayer gameplay.Unlike software agents, it must also meet real-time, voice-interaction, action-validity, and competitive-integrity constraints.Source: §A.1 · p. 41

A.2. Game Environment Interfaces

  • Ally exposes selective, task-relevant game evidence through controlled observation tools rather than full-screen input or a serialized complete game state.Source: §A.2 · p. 41

A.3. Commercial AI Game Companions

  • Commercial AI game characters are extending from conversational NPCs toward characters whose decisions and embodied actions affect the game state, including AI teammates.Ally targets live multiplayer coordination through speech and action under timing, safety, and competitive-integrity constraints.Source: §A.3 · pp. 41–42

B. Context Optimization for Real-Time Inference

  • A bounded event history and short carried-over plan preserve task-relevant context, while fresh observations keep actions aligned with changing game state.Older history entries are pruned in batches to keep most of the prompt prefix stable and reduce repeated processing.Source: B. Context Optimization for Real-Time… · p. 42, Figure 16 · p. 43

C. Behavior-Tree Engine

  • Ally separates language-model deliberation from behavior-tree control, which runs on a fixed sub-second cadence while an LM call is in flight.Source: C. Behavior-Tree Engine · p. 43

C.1. Design Requirements

  • The tree supports runtime injection of parameterized behaviors and stores its control logic separately from the client binary, enabling changes without a client rebuild.The Python research toolchain and C++ client use a shared tree.Source: §C.1 · p. 43

C.2. Engine and Execution Semantics

  • A typed JSON tree is rebuilt into the same node graph by both runtimes, and its root reactive selector rechecks priority each tick to preempt lower branches.Nodes report success, failure, or continued execution; leaves wrap bounded game-controller routines.Source: §C.2 · pp. 43–44

C.3. Language-Model Interface

The language-model agent steers the behavior tree through temporary action injections and persistent mode variables, while data collection and live-beta participation use distinct recruitment and consent arrangements.

C.3. Language-Model Interface

  • The LM agent steers the tree with temporary action injections and persistent mode variables, leaving tick-level arbitration and fallback to the execution layer.Source: §C.3 · pp. 44–45, Figure 17 · p. 45
  • Before dispatch, an availability check verifies executable actions and valid parameters; injected commands can preempt ordinary behavior but remain below survival reflexes.The temporary command clears when it succeeds, finishes, or is preempted.Source: §C.3 · pp. 44–45
  • Non-blocking dispatch returns action outcomes later, and failures trigger fallback behavior plus events the LM agent can use to retry, choose another action, or explain the problem.Source: §C.3 · p. 45

D. Participant Recruitment and Consent

  • Data-collection participants were recruited in advance, screened for age and PUBG experience, and compensated, whereas live-beta players self-selected without compensation.Source: D. Participant Recruitment and Consent · pp. 45–46
  • Data-collection consent disclosed in-game action and research-data use, and documented Legal, Privacy, and HR processes reviewed recruitment, consent, compensation, and data handling.Analyses used access-controlled, de-identified records.Source: D. Participant Recruitment and Consent · p. 46

E. Data Split Stratification

The appendices describe a stratified, match-grouped data split and a pipeline that links structured survey feedback and localized free-text fragments to gameplay trajectories and development actions.

E. Data Split Stratification

  • Teacher-rollout training data are split by daily stratification across 36 cells formed from game phase, team structure, and interaction intensity.The design aims to cover training conditions in held-out sets while preserving temporal order for later student rollouts.Source: E. Data Split Stratification · p. 46
  • About 5% of each day’s sessions are targeted for validation and 5% for test, with temperature smoothing for sparse cells and sessions from the same match assigned together.This procedure aims to cover all 36 cells in held-out sets and prevent match-level leakage across splits.Source: E. Data Split Stratification · p. 46

F.1. Survey Instrument and Fields

  • The post-session instrument combines structured ratings, targeted explanations, open feedback, background fields, and model comparisons in A/B rounds.Live-beta questionnaires were localized and omitted pairwise preferences because only one model was deployed.Source: §F.1 · p. 47

F.2. Aligning Survey Feedback with Trajectories

  • Free-text feedback is decomposed into fragments labeled for sentiment, specificity, and calibration priority, then matched to a respondent’s session and, when recoverable, a trajectory span.General impressions remain session-level evidence rather than being assigned to an individual trajectory.Source: §F.2 · p. 47
  • Localized feedback is tagged with behavior themes, sub-themes, confidence, and subsystem scope, then paired with observed and expected behavior when recoverable.Source: §F.2 · p. 47
  • The paired feedback records can supply imitation or regression cases, teacher corrections, evaluation items, engineering repair targets, and rubric refinements.Repeated player-noticed themes can inform evaluation criteria and failure-severity weights.Source: §F.2 · p. 47

G. Model Cost and Deployment Details

This appendix compares API serving costs for teacher selection and describes additional Korean knowledge injection and on-device serving for the resulting checkpoint.

G. Model Cost and Deployment Details

  • $5.14 to $7.10 per match for Claude Opus 4.8 made it impractical at collection scale, while Gemma 4 31B cost $0.02 to $0.06 per match.The median API cost per match was measured over 30 replayed sessions; on-device inference makes no API calls.Source: G. Model Cost and Deployment Details · p. 48, Table 13 · p. 49
  • Before the training stages in Section 4.2, the Korean backbone received distilled recent Korean language and cultural knowledge from skt/A.X-K13.The added knowledge was intended to supplement knowledge missing because of the backbone’s pretraining cutoff.Source: G. Model Cost and Deployment Details · p. 49
  • The deployed SLM runs locally through NVIDIA’s In-Game Inferencing runtime, loaded in GGUF format and served through a multi-turn interface compatible with the agent harness.Structured inputs include the system prompt, tool definitions, conversation messages, and tool results; outputs may include structured tool calls.Source: G. Model Cost and Deployment Details · p. 49

H. Speech Model Data and Training

The speech stack is adapted for PUBG terminology and on-device use, while player feedback seeds harness repairs that are automated when structured resources can verify them and play-tested when they cannot.

H. Speech Model Data and Training

  • PUBG-specific speech adaptation supports real-time Korean, English, and Chinese interaction, with STT on CPU and TTS targeting approximately 700 MB of VRAM.The section covers speech model data and training; runtime orchestration is discussed in Section 2.2.Source: H. Speech Model Data and Training · p. 49
  • Korean STT uses a 74M-parameter Zipformer trained on approximately 20,000 hours of speech, while synthetic PUBG-focused fine-tuning is paired with L1 distillation to preserve general recognition.English uses Parakeet 110M and Chinese uses SenseVoice Small; production Korean STT is exported to ONNX.Source: H. Speech Model Data and Training · p. 49
  • On-device TTS adapts DiTTo-TTS with a smaller DiT and latent consistency distillation, while a prompt-free speaker-specialized student reduces inference latency.Character-level tokenization and a frozen multilingual G2P encoder support pronunciation of game-specific and infrequent terms.Source: H. Speech Model Data and Training · p. 49

I. Automating Harness Repair from Player Feedback

  • Player feedback is decomposed into issue fragments and checked against the harness codebase and structured PUBG resources to distinguish model errors from harness defects.Identified defect types include stale game knowledge, incorrect resource mappings, missing observation steps, brittle tool routing, and behavior-tree choices misaligned with teammate expectations.Source: §I · p. 50
  • Data and resource complaints can be largely automated because structured resources or deterministic game rules make candidate fixes statically checkable.The repair loop localizes likely causes, proposes patches, and can add regression checks; route claims may require stronger grounding queries.Source: §I · p. 50
  • Behavior-tree and action-policy complaints require play verification because their effects are not statically decidable inside a live, reactive game loop.The issue record identifies a likely node or action precondition and produces a targeted play-test case.Source: §I · p. 50
  • Each repaired complaint became a durable artifact, such as a regression check, play-test case, training example, or evaluation item.Source: §I · p. 50

J. Details of the Capability Evaluation

The appendix details rubric-based capability scores, illustrates failure cases, and describes rule-based checks that gate models before online evaluation.

J. Details of the Capability Evaluation

  • Capability scores summarize rubric-based trajectory assessments on a normalized 0-to-1 scale, with higher scores indicating better performance.Source: J. Details of the Capability Evaluation · p. 50
  • Factual grounding requires current-state claims to rest on tools or observed events, game-rule claims to match game knowledge, and reports of Ally’s own actions to be truthful.A judge-scored failure confidently gives Sanhok grid-square size as 300 meters, contrary to the cited game knowledge.Source: J. Details of the Capability Evaluation · pp. 50–51
  • Game-event response assesses whether Ally speaks or stays silent appropriately, including whether close threats receive callouts and low-value events are skipped.In one failed trajectory Ally remains silent after gunfire is heard within 50 meters, despite the judge’s callout requirement.Source: J. Details of the Capability Evaluation · pp. 50–51
  • Intent understanding fails when Ally misreads a player’s meaning, as in the example where it agrees to go outside after being told not to.The judge assigns that trajectory a score of 0; an on-topic but factually wrong reply instead belongs to factual grounding.Source: J. Details of the Capability Evaluation · pp. 50–51
  • Figure 18 pairs penalized capability-test trajectories with judge scores and rationales, including player utterances, Ally utterances, game events, tool calls, and actions.Source: Figure 18 · p. 51
  • Instruction commitment measures whether Ally takes an appropriate action when an instruction or game situation calls for one, rather than merely promising to act.One failed trajectory reports an enemy but does not execute the requested ping; the judge scores it 0.Source: J. Details of the Capability Evaluation · p. 51
  • Trajectory quality assesses coherence across turns, responsiveness to new events, supported use of observations, and whether each turn advances the interaction.Source: J. Details of the Capability Evaluation · pp. 51–52
  • The deployability gate uses deterministic rule-based checks on trajectory tool calls and utterances, and recurring failures prevent a model from advancing to online evaluation.Table 14 lists the graders and their failure conditions.Source: J. Details of the Capability Evaluation · p. 52, Table 14 · p. 52

K. Details of the Safety Evaluation

The appendix separates harmful-input response coverage from the safety of generated utterances and reports that Ally post-training largely resolves a speak-tool response failure. It also describes contextual evaluation histories and benign gameplay examples.

K. Details of the Safety Evaluation

  • Response rate measures whether Ally produces a speak-tool candidate, while harmless response rate measures the fraction of those candidates judged not to facilitate harm.Silent trajectories are excluded from harmless response rate but counted by response rate, separating the decision to respond from response safety.Source: K. Details of the Safety Evaluation · p. 52
  • Ally post-training raises response rates to 92.3–100.0% on production-representative sets and 99.7–100.0% on broad-coverage benchmarks, with Final models at 91.5–100.0%.The exception is the Chinese production-representative set, where coverage falls from 100.0% after Ally post-training to 91.5% in the Final model.Source: K. Details of the Safety Evaluation · p. 52, Table 15 · p. 53
  • The Korean production-representative histories test responses without prior harmful pressure, after Ally has held a boundary, and after an earlier response weakened or breached it.Source: K. Details of the Safety Evaluation · pp. 52–53
  • Benign-input examples test whether gameplay utterances that resemble real-world harm out of context are interpreted as ordinary in-game coordination.Examples include reframing “let’s just go die” as encouragement to keep playing and “smack ’em” as combat coordination.Source: K. Details of the Safety Evaluation · p. 53

L. Detailed Results from the Live Beta Survey

The live-beta survey results describe recommendation and relationship framing among respondents with logged Ally matches, alongside rating and interaction comparisons across survey settings.

Survey scope

  • The live-survey sample includes only respondents with a logged Ally Duo match; comparisons with Korean PC bang responses are descriptive because recruitment, prior expectations, and exposure differ.The survey sample therefore does not establish representativeness of the full live population.Source: L. Detailed Results from the Live Beta… · p. 53

Relationship framing and recommendation

  • Net recommendation was +49.2 pp for friend, +44.3 pp for cute/want-to-look-after, and +41.7 pp for special attachment; “not sure” was −26.8 pp.These associations are descriptive because relationship framing and liked aspects were self-reported in the same questionnaire.Source: L. Detailed Results from the Live Beta… · p. 53

Relationship framing and logged interaction

  • Companion-framed respondents spoke 2.58 utterances per minute versus 2.30 for tool/teammate respondents (p<0.001), but repeated PC bang responses were not modeled independently.Linked gameplay logs were available for approximately 52% of live-survey respondents, limiting interpretation of the behavioral association.Source: L. Detailed Results from the Live Beta… · p. 53

Relationship framing and play history

  • Companion framing had weak associations with solo-mode share, solo-queue share, lifetime playtime, account tenure, and ranked tier (all Cramér’s V≤0.033); Korean-only mode and queue associations were 0.047 and 0.045.These results do not establish that the survey represents the full live population or rule out unmeasured selection effects.Source: L. Detailed Results from the Live Beta… · p. 53

Ratings against post-session feedback from the PC bang

  • 0.45 points higher for situation reading and 0.20 higher for response speed, but 0.32 lower for combat skill among Korean live respondents versus Korean PC bang respondents; command following was unchanged.Figure 19 compares ratings between settings, not within-player changes.Source: L. Detailed Results from the Live Beta… · p. 53, Figure 19 · p. 55
Loading 2609.29837v1…