SECOND-LOOP

KAKARU STUDIO / DEVELOPMENT

Behind
the loop.

We build the game.
We build the tools behind it.

Founded in 2023, Kakaru Studio develops SECOND-LOOP. Our internal tools connect playtest evidence, game text, and physics changes with the people who review them.

Explore the three workflows
INTERNAL PRODUCTION TOOLS 01—03

FROM PRODUCTION CONTEXT
TO A HUMAN DECISION

  1. 01
    SECOND-LOOP QA AnalystPLAYTEST → ISSUE REVIEW
  2. 02
    Localization QAGAME STRINGS → LANGUAGE REVIEW
  3. 03
    Physics Regression PlannerGAMEPLAY CHANGE → TEST PLAN
SOURCEANALYSISREVIEW

Claude-assisted analysis. Traceable inputs.
Decisions stay with the development team.

THE STUDIO TOOLSET

Three different questions.
One reviewable workflow.

What happened? Does the text communicate the right action? What should we test after a change?

01

PLAYTEST → ISSUE REVIEW

SECOND-LOOP QA Analyst

Turn scattered playtest observations into a bug draft the team can investigate.

Internal tool
WHO IT SUPPORTS
Developers and QA reviewers working on SECOND-LOOP.
INPUT
Studio-owned playtest notes, selected runtime logs, session timestamps, and build IDs.
OUTPUT
Reviewable issue drafts with source references, observed behavior, suggested reproduction steps, and unresolved questions.
  1. 01

    Anchor the evidence

    Keep each note and log excerpt attached to its session and build. Missing context stays visible.

  2. 02

    Connect the observations

    Claude-assisted analysis groups related observations and drafts a concise issue description with evidence references.

  3. 03

    Reproduce and review

    A developer checks the sources, reproduces the issue in the game, and decides what enters the bug tracker.

AI analysis

Groups related reports and turns informal notes into structured issue drafts. Inferred steps remain suggestions until a reviewer confirms them.

Checks & validation

Build IDs, timestamps, and source references establish traceability. Only an actual reproduction in the target build confirms a bug.

SYNTHETIC EXAMPLEA release that needs a closer look

Invented inputs and an illustrative output. This example is not a production log or a measured result.

Sample input

  • BUILD: SYNTH-QA-014 · SESSION: SAMPLE-07
  • NOTE N-02 / 00:42 — After releasing a held crate, movement briefly felt blocked.
  • LOG L-08 / 00:42 — Interaction state changed: held → released.

Illustrative output

Draft: Check player movement immediately after releasing a held object.

Evidence: N-02 + L-08. Suggested reproduction: hold the sample crate, release it, then move forward. Unknown: duration and collision state. Status: awaiting reproduction.

Review boundaryA log excerpt can show a symptom without revealing its cause. The analyst does not play the game, prove a root cause, or automatically close an issue.

02

GAME STRINGS → LANGUAGE REVIEW

Localization QA

Review the meaning of a game string without losing the rules that make it work.

Internal tool
WHO IT SUPPORTS
Writers, localization reviewers, and developers maintaining in-game text.
INPUT
String keys, source and translated text, studio glossaries, placeholder rules, and available gameplay context.
OUTPUT
A review list that separates terminology or meaning concerns from concrete placeholder and formatting problems.
  1. 01

    Preserve the string contract

    Retain keys, variables, and markup so every review item points back to its source string.

  2. 02

    Review meaning in context

    Claude-assisted review highlights ambiguous instructions, inconsistent terms, and translation choices that may change the intended action.

  3. 03

    Validate in the game

    A human reviewer approves wording and checks it in the actual UI for layout, timing, and gameplay meaning.

AI analysis

Explains semantic differences and proposes wording for reviewer consideration using the supplied glossary and context.

Checks & validation

Literal comparisons identify missing placeholders or markup. Length checks can flag a constraint; they cannot establish visual fit.

SYNTHETIC EXAMPLEKeep the action and the placeholder intact

Invented inputs and an illustrative output. This example is not a production log or a measured result.

Sample input

  • KEY: SAMPLE.INTERACTION.DETACH
  • SOURCE: Detach {partName}
  • CANDIDATE: Delete part

Illustrative output

Review: The candidate drops {partName} and changes the action from detaching to deleting.

Rule finding: missing placeholder {partName}. Semantic concern: the action may be misunderstood. Reviewer action: preserve the variable, confirm the gameplay intent, then check the approved wording in the UI.

Review boundaryText-only review cannot see every UI state or substitute for a fluent reviewer. A suggested translation is not an approved game string.

03

GAMEPLAY CHANGE → TEST PLAN

Physics Regression Planner

Translate a physics gameplay change into a focused set of checks for the next build.

Internal tool
WHO IT SUPPORTS
Gameplay developers and QA reviewers testing SECOND-LOOP physics interactions.
INPUT
Change notes, interaction rules, affected object types, target build IDs, and studio-owned previous test cases.
OUTPUT
A reviewable regression matrix with preconditions, actions, expected observations, and space for actual test evidence.
  1. 01

    Scope the change

    Identify the affected interaction and record the rules and build that the test plan should cover.

  2. 02

    Expand the test cases

    Claude-assisted planning suggests relevant combinations and edge cases, with assumptions made explicit.

  3. 03

    Run and record

    The team executes the approved checks in Unreal Engine and records observed results against the target build.

AI analysis

Drafts test cases from written changes and prior coverage. It helps the team consider combinations that deserve a test.

Checks & validation

Unreal Engine execution and repeatable assertions supply the actual results. The written plan and the test result remain separate records.

SYNTHETIC EXAMPLEReview a change to object detachment

Invented inputs and an illustrative output. This example is not a production log or a measured result.

Sample input

  • TARGET: SYNTH-PHYS-022
  • CHANGE: Update the rule for releasing a connected object.
  • CONTEXT: Compare a stationary object with an object already in motion.

Illustrative output

Draft cases: detach at rest; detach during motion; reconnect after detachment.

For each case, capture the initial connection state, action sequence, resulting motion, and a build-linked observation. Expected behavior must come from an approved design rule. Result: not executed in this illustrative example.

Review boundaryA generated matrix does not simulate physics, prove determinism, or certify that a build passes. Coverage depends on the supplied change context.

BUILT AROUND OUR DEVELOPMENT WORK

Talk to the studio.

These tools support Kakaru Studio’s internal production workflows. For development and business enquiries, contact our team.

biz@kakarustudio.com