Proof sprint
For a technical discovery, mechanic prototype, benchmark asset or release assessment with a decision at the end.
Best when the unknown is more important than volume.Build the next playable version.
Game co-development, engineering, art, QA and porting around the milestone your team needs to reach next.
06Release
Ship with a clean hand-off
01 / Input
We begin with the build, the decision it must enable and the constraints already shaping production.
Illustrative production map. The actual pipeline, disciplines and acceptance criteria are verified for each project.
01 One shared definition of done
02 Playable increments over status theatre
03 Decisions documented for hand-off
Choose the production problem, not a generic package.
External development works best when ownership is visible. Each engagement starts with the milestone, then identifies the smallest useful team and delivery boundary around it.
01
Game Co-Development
An integrated delivery team for a defined feature stream, production problem or playable milestone.
02Game Prototyping & Vertical Slices
Turn a design or technical hypothesis into a playable result that supports a real production decision.
03Gameplay & Systems Engineering
Gameplay features, supporting systems and designer tools built for repeated iteration in a live codebase.
04Game Art & Technical Art
A repeatable path from visual target and source files to integrated assets that respect the build.
05Game QA & Release Support
Testing and release evidence organized around player impact, change risk and the decision to ship.
06Game Porting & Optimization
Adapt the experience, systems and performance profile for a new release target with measurable proof.
A working rhythm your team can inspect.
The engagement is designed around decisions, reviewable builds and explicit ownership. That keeps an external stream close enough to the product without adding another layer of ceremony.
-
01 / Frame
Map the risk before the team.
We inspect the current build, the milestone, dependencies and the question the work needs to answer. The result is a boundary: what Kioto owns, what stays internal and how acceptance will be decided.
-
02 / Integrate
Plug into the real production system.
Branches, source files, task tracking, build access, review paths and communication are agreed during onboarding. The exact setup follows your security and pipeline requirements; it is not assumed from a pitch deck.
-
03 / Deliver
Review playable increments.
Working output arrives in a cadence that exposes design, technical and integration risk early. Reviews happen against the agreed proof criteria, with decisions and open constraints attached to the build.
-
04 / Transfer
Leave the next team in control.
Source, configuration, known limits, ownership and the reasoning behind consequential decisions form the hand-off. A good delivery can continue into production or end without turning context into leverage.
Keep the build in the room.
A production partner becomes useful when design, engineering, art and QA can inspect the same playable evidence together. The physical setup changes by project; the principle does not.
How the studio works
One build, seen by every discipline.
Production moves when engineering, art, QA and planning can inspect the same state of the work. This moving bench follows that hand-off from review to evidence.
Illustrative editorial scenes. They show representative production moments, not Kioto Gaming staff, premises or client work.
Three ways to establish the boundary.
The right model depends on how much is known, where the risk sits and how closely the work must evolve with your internal team.
Embedded pod
For a feature or production stream that must evolve inside the same backlog, build and review cadence as your team.
Best when context and iteration are continuous.Milestone ownership
For a defined slice, platform adaptation or delivery package with agreed proof points and an explicit hand-off.
Best when the destination is clear enough to govern.Latest from the production blog.
Practical guides for evaluating external development work before it becomes a contract or a bottleneck.
Black Knife Catacombs in Elden Ring: a developer-focused dungeon breakdown
Black Knife Catacombs: a developer-focused look at a compact Liurnia dungeon Tucked into the northern cliffs of Liurnia, just northeast of the Erdtree, the…
Jacinthe Pokémon Legends Z-A: battle prep and team breakdown
Jacinthe pokemon Legends Z-A: the Rank B promotion match explained The Jacinthe pokemon encounter in Pokémon Legends Z-A is the gate between Rank C…
Rowland Oakes map in Hogwarts Legacy: how to read it and follow the trail
Rowland Oakes map: what the parchment actually tells you The first time a player finds a scrap of parchment in a quest, the instinct…
Start with the build, not the sales call.
Send the milestone, the current state and the constraint that worries you most. We will use that context to decide whether a discovery conversation is useful—and say so plainly if the scope is not a fit.