post: GPU-skinned herds — agent_skinned renderer + engine private, builds public
This commit is contained in:
+66
-35
@@ -262,43 +262,74 @@
|
||||
<a href="/blog/" class="post__back">← All Posts</a>
|
||||
<span class="post__date">25 May 2026</span>
|
||||
<h1 class="post__title">What an Agent Harness Is and Why Game Dev Needs One</h1>
|
||||
<p class="post__lead">Open Claude or ChatGPT right now and ask it to review your last PR. It'll say "I don't have access to your repository." Ask it to take a screenshot of your game. It'll say "I can't interact with your operating system." Ask it what you were working on yesterday. It'll say "I don't have memory of previous conversations."</p>
|
||||
<p class="post__lead">Open Claude or ChatGPT right now and ask it to review your last PR. It'll say "I don't have access to your repository." Ask it to take a screenshot of your game. It'll say "I can't interact with your operating system." Ask it what you were working on yesterday. It'll say "I don't have memory of previous conversations."
|
||||
|
||||
A raw AI model is a brain without hands, eyes, or memory. An <strong>agent harness</strong> is the layer that gives it all three — plus identity, tools, and guardrails. And game development needs one that understands binary assets, visual pipelines, and spatial systems.
|
||||
|
||||
## What a harness provides
|
||||
|
||||
Every agent harness, regardless of domain, needs five things:
|
||||
|
||||
<strong>Identity.</strong> Who the agent is, what it values, how it should behave. Not "you are a helpful assistant" — that's generic and unmoored. A soul file that says "you're working on Ariki, a survival colony sim. The team is four people. Never push to main without review. Prefer existing conventions." Identity creates consistency across sessions.
|
||||
|
||||
<strong>Memory.</strong> What happened last session. What decisions were made. What failed and why. Without memory, every conversation is a cold start — "let me explain the project..." Memory stored as markdown in git means it's version-controlled, diffable, and human-readable. When something goes wrong, you <code>git log</code> instead of debugging a vector database.
|
||||
|
||||
<strong>Tools.</strong> What the agent can actually do beyond generating text. A CLI that takes screenshots, checks service health, and loads project context. API wrappers for git, CI, image generation. Without tools, the agent is a very articulate oracle that can't touch anything.
|
||||
|
||||
<strong>Context.</strong> Which project this is. Who's asking. What machine they're on. What services are reachable. A single CLI call — <code>tinqs identity</code> — returns all of this in 100ms. No re-reading the README. No "what repo are we in?"
|
||||
|
||||
<strong>Guardrails.</strong> What the agent must never do. No merging to main without review. No pushing to public repos without approval. No running destructive commands. The harness enforces these at the platform layer, not in the prompt. Prompts can be ignored. Platform gates cannot.
|
||||
|
||||
## Why generic harnesses fail for game dev
|
||||
|
||||
LangChain, CrewAI, and AutoGen are built for web apps. They assume text-in, text-out. Game development is different in ways that break those assumptions:
|
||||
|
||||
<strong>Assets are binary.</strong> A web PR is a text diff. A game PR is a 150MB GLB file with textures, rigging, and animations. You can't review it without seeing it. Our harness renders 3D models in the browser during code review — rotate, zoom, check materials. The artist pushes, the lead inspects, no downloads required.
|
||||
|
||||
<strong>The pipeline is visual.</strong> Concept art → 3D model → rigged character → in-engine asset. Each step uses different tools. The harness needs to orchestrate image generators, 3D modellers, auto-riggers, and game engines as a single workflow — not as five separate API calls the human has to stitch together.
|
||||
|
||||
<strong>Scale is physical.</strong> A web app's complexity is in business logic. A game's complexity is in geometry — 12km worlds, 155 vegetation types, 2,000 crowd instances. The agent needs to understand spatial systems, GPU memory budgets, and frame timing. "Add more RAM" isn't an answer when you have 8GB of VRAM.
|
||||
|
||||
<strong>The team is small and cross-functional.</strong> Four people. No dedicated DevOps, no dedicated artist, no dedicated PM. The harness fills all those gaps, not just one.
|
||||
|
||||
## The toolchain that makes it work
|
||||
|
||||
Our harness runs on <a href="https://tinqs.com" style="color: var(--c-accent-l);">Tinqs Studio</a>, built on a Gitea fork with game-specific features. The key pieces:
|
||||
|
||||
<strong>The CLI</strong> — a single Go binary. One command (<code>tinqs identity</code>) gives the agent full project context in 100ms. Screenshots, cloud vision, health checks — all subcommands of the same binary.
|
||||
|
||||
<strong>The soul file</strong> — a markdown document in the repo root. The agent reads it on session start. It defines values, scope, and behavioural rules. The same soul file works in Cursor, Claude Code, or any tool that reads markdown.
|
||||
|
||||
<strong>Skills</strong> — markdown playbooks for specific workflows. Image generation, concept art pipeline, 3D model creation, video generation. Each skill is a procedure the agent follows. Write once, use forever.
|
||||
|
||||
<strong>3D preview</strong> — click a <code>.glb</code> file in a PR and rotate the model in your browser. 22 formats supported. This alone transformed our review process — nobody approves a binary diff blind anymore.
|
||||
|
||||
<strong>Guardrails</strong> — agents can file issues, draft announcements, generate assets, and write code. They cannot merge, deploy, or push to public repos without human approval. Branch protection rules enforced at the git platform layer.
|
||||
|
||||
## The cold-start problem, solved
|
||||
|
||||
Every AI agent session starts blank. Most teams solve this with long system prompts — but when your context is 200 markdown files, 15 skills, and 3 years of project history, you can't paste all of that.
|
||||
|
||||
The harness uses staged loading:
|
||||
|
||||
1. <strong>CLI identity call</strong> (100ms) — soul file, company context, machine info, service status
|
||||
2. <strong>Memory file</strong> (instant) — cross-session context from the docs repo
|
||||
3. <strong>Skills</strong> (on demand) — loaded only when the task matches a skill name
|
||||
4. <strong>Repo context</strong> (on demand) — files read as needed, not all upfront
|
||||
|
||||
Agent goes from cold to fully contextual in under a second. No "let me explain the project." No re-reading onboarding docs. Just start working.
|
||||
|
||||
## The bet
|
||||
|
||||
The gap between "I have an AI model" and "I have an AI team member" is infrastructure. Identity, memory, tools, context, guardrails. For game development, that infrastructure needs to understand binary assets, visual pipelines, and spatial systems.
|
||||
|
||||
We're betting that specialised harnesses beat generic ones. A harness built for game dev — with 3D preview, LFS management, and creative pipelines — will outperform a general-purpose agent framework on game dev tasks. Not because the AI is smarter, but because it has the right hands, eyes, and memory for the job.
|
||||
|
||||
—
|
||||
|
||||
<em>Tinqs Studio is an agent harness for game development — git hosting, AI agents, creative pipelines. Open for teams. We're building <a href="https://arikigame.com" style="color: var(--c-accent-l);">Ariki</a> with the same tools.</em></p>
|
||||
|
||||
<div class="post__body">
|
||||
<p>A raw AI model is a brain without hands, eyes, or memory. An <strong>agent harness</strong> is the layer that gives it all three — plus identity, tools, and guardrails. And game development needs one that understands binary assets, visual pipelines, and spatial systems.</p>
|
||||
<h2>What a harness provides</h2>
|
||||
<p>Every agent harness, regardless of domain, needs five things:</p>
|
||||
<p><strong>Identity.</strong> Who the agent is, what it values, how it should behave. Not "you are a helpful assistant" — that's generic and unmoored. A soul file that says "you're working on Ariki, a survival colony sim. The team is four people. Never push to main without review. Prefer existing conventions." Identity creates consistency across sessions.</p>
|
||||
<p><strong>Memory.</strong> What happened last session. What decisions were made. What failed and why. Without memory, every conversation is a cold start — "let me explain the project..." Memory stored as markdown in git means it's version-controlled, diffable, and human-readable. When something goes wrong, you <code>git log</code> instead of debugging a vector database.</p>
|
||||
<p><strong>Tools.</strong> What the agent can actually do beyond generating text. A CLI that takes screenshots, checks service health, and loads project context. API wrappers for git, CI, image generation. Without tools, the agent is a very articulate oracle that can't touch anything.</p>
|
||||
<p><strong>Context.</strong> Which project this is. Who's asking. What machine they're on. What services are reachable. A single CLI call — <code>tinqs identity</code> — returns all of this in 100ms. No re-reading the README. No "what repo are we in?"</p>
|
||||
<p><strong>Guardrails.</strong> What the agent must never do. No merging to main without review. No pushing to public repos without approval. No running destructive commands. The harness enforces these at the platform layer, not in the prompt. Prompts can be ignored. Platform gates cannot.</p>
|
||||
<h2>Why generic harnesses fail for game dev</h2>
|
||||
<p>LangChain, CrewAI, and AutoGen are built for web apps. They assume text-in, text-out. Game development is different in ways that break those assumptions:</p>
|
||||
<p><strong>Assets are binary.</strong> A web PR is a text diff. A game PR is a 150MB GLB file with textures, rigging, and animations. You can't review it without seeing it. Our harness renders 3D models in the browser during code review — rotate, zoom, check materials. The artist pushes, the lead inspects, no downloads required.</p>
|
||||
<p><strong>The pipeline is visual.</strong> Concept art → 3D model → rigged character → in-engine asset. Each step uses different tools. The harness needs to orchestrate image generators, 3D modellers, auto-riggers, and game engines as a single workflow — not as five separate API calls the human has to stitch together.</p>
|
||||
<p><strong>Scale is physical.</strong> A web app's complexity is in business logic. A game's complexity is in geometry — 12km worlds, 155 vegetation types, 2,000 crowd instances. The agent needs to understand spatial systems, GPU memory budgets, and frame timing. "Add more RAM" isn't an answer when you have 8GB of VRAM.</p>
|
||||
<p><strong>The team is small and cross-functional.</strong> Four people. No dedicated DevOps, no dedicated artist, no dedicated PM. The harness fills all those gaps, not just one.</p>
|
||||
<h2>The toolchain that makes it work</h2>
|
||||
<p>Our harness runs on <a href="https://tinqs.com" style="color: var(–c-accent-l);">Tinqs Studio</a>, built on a Gitea fork with game-specific features. The key pieces:</p>
|
||||
<p><strong>The CLI</strong> — a single Go binary. One command (<code>tinqs identity</code>) gives the agent full project context in 100ms. Screenshots, cloud vision, health checks — all subcommands of the same binary.</p>
|
||||
<p><strong>The soul file</strong> — a markdown document in the repo root. The agent reads it on session start. It defines values, scope, and behavioural rules. The same soul file works in Cursor, Claude Code, or any tool that reads markdown.</p>
|
||||
<p><strong>Skills</strong> — markdown playbooks for specific workflows. Image generation, concept art pipeline, 3D model creation, video generation. Each skill is a procedure the agent follows. Write once, use forever.</p>
|
||||
<p><strong>3D preview</strong> — click a <code>.glb</code> file in a PR and rotate the model in your browser. 22 formats supported. This alone transformed our review process — nobody approves a binary diff blind anymore.</p>
|
||||
<p><strong>Guardrails</strong> — agents can file issues, draft announcements, generate assets, and write code. They cannot merge, deploy, or push to public repos without human approval. Branch protection rules enforced at the git platform layer.</p>
|
||||
<h2>The cold-start problem, solved</h2>
|
||||
<p>Every AI agent session starts blank. Most teams solve this with long system prompts — but when your context is 200 markdown files, 15 skills, and 3 years of project history, you can't paste all of that.</p>
|
||||
<p>The harness uses staged loading:</p>
|
||||
<p>1. <strong>CLI identity call</strong> (100ms) — soul file, company context, machine info, service status</p>
|
||||
<p>2. <strong>Memory file</strong> (instant) — cross-session context from the docs repo</p>
|
||||
<p>3. <strong>Skills</strong> (on demand) — loaded only when the task matches a skill name</p>
|
||||
<p>4. <strong>Repo context</strong> (on demand) — files read as needed, not all upfront</p>
|
||||
<p>Agent goes from cold to fully contextual in under a second. No "let me explain the project." No re-reading onboarding docs. Just start working.</p>
|
||||
<h2>The bet</h2>
|
||||
<p>The gap between "I have an AI model" and "I have an AI team member" is infrastructure. Identity, memory, tools, context, guardrails. For game development, that infrastructure needs to understand binary assets, visual pipelines, and spatial systems.</p>
|
||||
<p>We're betting that specialised harnesses beat generic ones. A harness built for game dev — with 3D preview, LFS management, and creative pipelines — will outperform a general-purpose agent framework on game dev tasks. Not because the AI is smarter, but because it has the right hands, eyes, and memory for the job.</p>
|
||||
<hr>
|
||||
<p><em>Tinqs Studio is an agent harness for game development — git hosting, AI agents, creative pipelines. Open for teams. We're building <a href="https://arikigame.com" style="color: var(–c-accent-l);">Ariki</a> with the same tools.</em></p>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
Before
After
|
@@ -286,10 +286,10 @@
|
||||
<p>Agents don't just have instructions. They have <strong>skills</strong> — markdown playbooks that teach specific workflows. When someone says "generate concept art for a character," the agent reads <code>skills/image-generation.md</code> and follows the procedure. No prompt engineering per session. No "let me try a different prompt."</p>
|
||||
<p>We've open-sourced several skills:</p>
|
||||
<ul>
|
||||
<li><a href="../skills/image-generation.md" style="color: var(–c-accent-l);">Image Generation with fal.ai</a> — 4-layer prompt pattern that actually produces usable game art</li>
|
||||
<li><a href="../skills/concept-art-pipeline.md" style="color: var(–c-accent-l);">Concept Art Pipeline</a> — full 2D concept → 3D model workflow</li>
|
||||
<li><a href="../skills/tripo-browser-workflow.md" style="color: var(–c-accent-l);">3D Model Generation</a> — Tripo Studio text-to-3D</li>
|
||||
<li><a href="../skills/sora2-video.md" style="color: var(–c-accent-l);">Video Generation</a> — trailer clips with Sora 2</li>
|
||||
<li><a href="../skills/image-generation.md" style="color: var(--c-accent-l);">Image Generation with fal.ai</a> — 4-layer prompt pattern that actually produces usable game art</li>
|
||||
<li><a href="../skills/concept-art-pipeline.md" style="color: var(--c-accent-l);">Concept Art Pipeline</a> — full 2D concept → 3D model workflow</li>
|
||||
<li><a href="../skills/tripo-browser-workflow.md" style="color: var(--c-accent-l);">3D Model Generation</a> — Tripo Studio text-to-3D</li>
|
||||
<li><a href="../skills/sora2-video.md" style="color: var(--c-accent-l);">Video Generation</a> — trailer clips with Sora 2</li>
|
||||
</ul>
|
||||
<p>Each skill took about 30 minutes to write. After six months, our agents have 15+ skills covering art generation, competitive research, video production, and project management. Skills compound — every playbook you write makes every future session more capable.</p>
|
||||
<h2>What the agents actually do, every day</h2>
|
||||
@@ -317,7 +317,7 @@
|
||||
<p><strong>Skills compound exponentially.</strong> One skill saves 15 minutes per session. Fifteen skills save hours per day across the whole team. The investment curve is absurdly favourable — 30 minutes of writing per skill, compounding returns forever.</p>
|
||||
<p>We're four people. With agents doing the mechanical work, we operate like forty. Not because the AI is magic — because we gave it identity, memory, and the right playbooks, and then got out of its way.</p>
|
||||
<hr>
|
||||
<p><em>We're building <a href="https://arikigame.com" style="color: var(–c-accent-l);">Ariki</a>, a survival colony sim, using the same agent workflow described here. Everything runs on <a href="https://tinqs.com" style="color: var(–c-accent-l);">Tinqs Studio</a> — a game dev platform with built-in AI agents, git hosting, and creative pipelines.</em></p>
|
||||
<p><em>We're building <a href="https://arikigame.com" style="color: var(--c-accent-l);">Ariki</a>, a survival colony sim, using the same agent workflow described here. Everything runs on <a href="https://tinqs.com" style="color: var(--c-accent-l);">Tinqs Studio</a> — a game dev platform with built-in AI agents, git hosting, and creative pipelines.</em></p>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
Before
After
|
@@ -303,7 +303,7 @@ Done.</code></pre>
|
||||
<p><strong>Build systems make CSS changes safe.</strong> Because we never hand-edit <code>.html</code>, every style change is tested by regenerating all pages and grepping for the new selectors. If a rule doesn't ship, you know immediately.</p>
|
||||
<p>Two gaps we'll fill later: blockquote support in <code>build.js</code> (the callout CSS is waiting) and ordered lists (same story). In the meantime, the blog already looks intentional — and it took two template files, one build step, and zero dependencies.</p>
|
||||
<hr>
|
||||
<p><em>The blog is generated by <a href="https://tinqs.com/tinqs/blog" style="color: var(–c-accent-l);">build.js</a> and served by <a href="https://tinqs.com" style="color: var(–c-accent-l);">Tinqs Studio</a>. All styling is self-contained in the templates.</em></p>
|
||||
<p><em>The blog is generated by <a href="https://tinqs.com/tinqs/blog" style="color: var(--c-accent-l);">build.js</a> and served by <a href="https://tinqs.com" style="color: var(--c-accent-l);">Tinqs Studio</a>. All styling is self-contained in the templates.</em></p>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
Before
After
|
@@ -144,11 +144,11 @@ function inline(s) {
|
||||
s = s.replace(/\*(.+?)\*/g, "<em>$1</em>");
|
||||
// Inline code
|
||||
s = s.replace(/`([^`]+)`/g, "<code>$1</code>");
|
||||
// Links
|
||||
s = s.replace(/\[([^\]]+)\]\(([^)]+)\)/g, '<a href="$2" style="color: var(--c-accent-l);">$1</a>');
|
||||
// Em dash
|
||||
// Em dash / en dash — before links so CSS var(--x) in style attr isn't mangled
|
||||
s = s.replace(/---/g, "—");
|
||||
s = s.replace(/--/g, "–");
|
||||
// Links
|
||||
s = s.replace(/\[([^\]]+)\]\(([^)]+)\)/g, '<a href="$2" style="color: var(--c-accent-l);">$1</a>');
|
||||
return s;
|
||||
}
|
||||
|
||||
|
||||
@@ -335,10 +335,10 @@ No extra fingers, no merged limbs, no floating accessories.</code></pre>
|
||||
<p><strong>The design context block is worth more than the rest of the prompt combined.</strong> Without it, every image is a one-off. With it, every image belongs to the same game.</p>
|
||||
<p><strong>Never iterate on expensive models.</strong> Schnell at $0.003/image is for exploration. Flux 2 Pro at $0.03 is for final output. The cheap model does 90% of the creative work.</p>
|
||||
<p><strong>Aggregation beats loyalty.</strong> No single model is best at everything. Flux for art, Ideogram for text, Recraft for design, Nano Banana for edits, BiRefNet for masks. Use the right tool for each job.</p>
|
||||
<p><strong>Let the agent handle prompting.</strong> We encode the 4-layer pattern, art style guide, and model selection rules in an <a href="../skills/image-generation.md" style="color: var(–c-accent-l);">agent skill file</a>. The AI writes the full prompt, generates images, displays them, and asks for scores. The human's job is creative direction.</p>
|
||||
<p><strong>Let the agent handle prompting.</strong> We encode the 4-layer pattern, art style guide, and model selection rules in an <a href="../skills/image-generation.md" style="color: var(--c-accent-l);">agent skill file</a>. The AI writes the full prompt, generates images, displays them, and asks for scores. The human's job is creative direction.</p>
|
||||
<p>AI art isn't magic and it isn't free. But at a penny per image, with the right prompt structure and model strategy, it eliminates the most expensive bottleneck in indie game development: the gap between "I know what this should look like" and "I have an asset I can actually use."</p>
|
||||
<hr>
|
||||
<p><em>Image generation is built into <a href="https://tinqs.com" style="color: var(–c-accent-l);">Tinqs Studio</a>. We've open-sourced the <a href="../skills/image-generation.md" style="color: var(–c-accent-l);">prompt engineering skill</a> and <a href="../skills/concept-art-pipeline.md" style="color: var(–c-accent-l);">concept art pipeline skill</a>. We're building <a href="https://arikigame.com" style="color: var(–c-accent-l);">Ariki</a> with these tools.</em></p>
|
||||
<p><em>Image generation is built into <a href="https://tinqs.com" style="color: var(--c-accent-l);">Tinqs Studio</a>. We've open-sourced the <a href="../skills/image-generation.md" style="color: var(--c-accent-l);">prompt engineering skill</a> and <a href="../skills/concept-art-pipeline.md" style="color: var(--c-accent-l);">concept art pipeline skill</a>. We're building <a href="https://arikigame.com" style="color: var(--c-accent-l);">Ariki</a> with these tools.</em></p>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
Before
After
|
@@ -0,0 +1,354 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>Flows Are Sessions, Not Pipelines: Why We Moved Our Agent Orchestrator from YAML to JavaScript — Tinqs Blog</title>
|
||||
<meta name="description" content="We killed the static YAML DAG and rewrote our agent orchestration in 200 lines of JavaScript. Now a flow IS a session — you chat it, steer it, and it pauses for you at a human gate.">
|
||||
<meta name="robots" content="index, follow">
|
||||
<link rel="canonical" href="https://www.tinqs.com/blog/flows-are-sessions">
|
||||
|
||||
<meta property="og:type" content="article">
|
||||
<meta property="og:url" content="https://www.tinqs.com/blog/flows-are-sessions">
|
||||
<meta property="og:title" content="Flows Are Sessions, Not Pipelines: Why We Moved Our Agent Orchestrator from YAML to JavaScript">
|
||||
<meta property="og:description" content="YAML DAGs are dead. We rewrote our agent orchestration in JavaScript, made every flow a live session, and added a human-in-the-loop gate. The operator is the co-pilot, not the babysitter.">
|
||||
<meta property="og:image" content="https://www.tinqs.com/img/og-cover.jpg">
|
||||
|
||||
<meta name="twitter:card" content="summary_large_image">
|
||||
<meta name="twitter:title" content="Flows Are Sessions, Not Pipelines: Why We Moved Our Agent Orchestrator from YAML to JavaScript">
|
||||
<meta name="twitter:description" content="YAML DAGs are dead. We rewrote our agent orchestration in JavaScript, made every flow a live session, and added a human-in-the-loop gate. The operator is the co-pilot, not the babysitter.">
|
||||
<meta name="twitter:image" content="https://www.tinqs.com/img/og-cover.jpg">
|
||||
|
||||
<script type="application/ld+json">
|
||||
{
|
||||
"@context": "https://schema.org",
|
||||
"@type": "BlogPosting",
|
||||
"headline": "Flows Are Sessions, Not Pipelines: Why We Moved Our Agent Orchestrator from YAML to JavaScript",
|
||||
"datePublished": "2026-06-11",
|
||||
"author": {
|
||||
"@type": "Person",
|
||||
"name": "Ozan Bozkurt"
|
||||
},
|
||||
"publisher": {
|
||||
"@type": "Organization",
|
||||
"name": "Tinqs Limited",
|
||||
"url": "https://www.tinqs.com"
|
||||
},
|
||||
"description": "We killed the static YAML DAG and rewrote our agent orchestration in 200 lines of JavaScript. Now a flow IS a session — you chat it, steer it, and it pauses for you at a human gate."
|
||||
}
|
||||
</script>
|
||||
|
||||
<style>
|
||||
/* ── Self-contained post styles (Studio provides site chrome) ── */
|
||||
|
||||
:root {
|
||||
--c-accent: #c9935a;
|
||||
--c-accent-l: #d4a87c;
|
||||
--c-bg: #0d1117;
|
||||
--c-text: #e6edf3;
|
||||
--c-muted: #9aa7b4;
|
||||
--c-border: #2a3340;
|
||||
--c-blue: #38bdf8;
|
||||
--c-purple: #a855f7;
|
||||
--c-gold: #f59e0b;
|
||||
--c-code-bg: #1c2230;
|
||||
--c-pre-bg: #0a0e14;
|
||||
}
|
||||
|
||||
*, *::before, *::after { box-sizing: border-box; }
|
||||
|
||||
body {
|
||||
margin: 0;
|
||||
padding: 0;
|
||||
background: transparent;
|
||||
color: var(--c-text);
|
||||
font-family: system-ui, -apple-system, 'Segoe UI', Roboto, Helvetica, Arial, sans-serif;
|
||||
line-height: 1.6;
|
||||
-webkit-font-smoothing: antialiased;
|
||||
}
|
||||
|
||||
/* ── Post container ── */
|
||||
.post {
|
||||
max-width: 720px;
|
||||
margin: 0 auto;
|
||||
padding: 40px 24px 48px;
|
||||
}
|
||||
|
||||
/* ── Back link ── */
|
||||
.post__back {
|
||||
color: var(--c-blue);
|
||||
text-decoration: none;
|
||||
font-size: 0.9rem;
|
||||
display: inline-block;
|
||||
margin-bottom: 24px;
|
||||
}
|
||||
.post__back:hover { color: var(--c-purple); }
|
||||
|
||||
/* ── Gradient title ── */
|
||||
.post__title {
|
||||
background: linear-gradient(90deg, #c9935a, #f59e0b 40%, #38bdf8);
|
||||
-webkit-background-clip: text;
|
||||
background-clip: text;
|
||||
color: transparent;
|
||||
font-weight: 800;
|
||||
font-size: 2.2rem;
|
||||
line-height: 1.25;
|
||||
margin: 0 0 16px;
|
||||
}
|
||||
|
||||
/* ── Date pill ── */
|
||||
.post__date {
|
||||
display: inline-block;
|
||||
font-family: ui-monospace, 'SF Mono', 'Cascadia Code', Consolas, monospace;
|
||||
font-size: 0.72rem;
|
||||
letter-spacing: 0.22em;
|
||||
text-transform: uppercase;
|
||||
color: var(--c-blue);
|
||||
border: 1px solid rgba(147, 140, 129, 0.25);
|
||||
border-radius: 999px;
|
||||
padding: 4px 14px;
|
||||
margin-bottom: 16px;
|
||||
}
|
||||
|
||||
/* ── Lead ── */
|
||||
.post__lead {
|
||||
color: var(--c-muted);
|
||||
font-size: 1.08rem;
|
||||
line-height: 1.7;
|
||||
}
|
||||
|
||||
/* ── Body ── */
|
||||
.post__body { font-size: 1rem; line-height: 1.7; }
|
||||
|
||||
.post__body p { margin: 14px 0; }
|
||||
|
||||
.post__body h2 {
|
||||
font-size: 1.7rem;
|
||||
margin: 54px 0 6px;
|
||||
padding-left: 16px;
|
||||
border-left: 4px solid var(--c-accent);
|
||||
line-height: 1.3;
|
||||
}
|
||||
|
||||
.post__body h3 {
|
||||
color: var(--c-purple);
|
||||
font-size: 1.18rem;
|
||||
margin: 30px 0 4px;
|
||||
}
|
||||
|
||||
.post__body h4, .post__body h5, .post__body h6 {
|
||||
margin: 20px 0 4px;
|
||||
}
|
||||
|
||||
/* ── Inline code ── */
|
||||
.post__body code {
|
||||
font-family: ui-monospace, 'SF Mono', 'Cascadia Code', Consolas, monospace;
|
||||
font-size: 0.86em;
|
||||
background: var(--c-code-bg);
|
||||
color: #9fe6c0;
|
||||
padding: 2px 6px;
|
||||
border-radius: 5px;
|
||||
border: 1px solid var(--c-border);
|
||||
}
|
||||
|
||||
/* ── Code blocks ── */
|
||||
.post__body pre {
|
||||
background: var(--c-pre-bg);
|
||||
border: 1px solid var(--c-border);
|
||||
border-radius: 10px;
|
||||
padding: 16px 18px;
|
||||
overflow-x: auto;
|
||||
margin: 14px 0;
|
||||
font-family: ui-monospace, 'SF Mono', 'Cascadia Code', Consolas, monospace;
|
||||
font-size: 0.85rem;
|
||||
line-height: 1.55;
|
||||
color: var(--c-text);
|
||||
}
|
||||
|
||||
.post__body pre code {
|
||||
background: transparent;
|
||||
padding: 0;
|
||||
border: none;
|
||||
font-size: inherit;
|
||||
color: inherit;
|
||||
border-radius: 0;
|
||||
}
|
||||
|
||||
/* ── Blockquote ── */
|
||||
.post__body blockquote {
|
||||
background: rgba(245, 158, 11, 0.08);
|
||||
border: 1px solid rgba(245, 158, 11, 0.25);
|
||||
border-left: 4px solid var(--c-gold);
|
||||
border-radius: 0 12px 12px 0;
|
||||
padding: 16px 18px;
|
||||
margin: 18px 0;
|
||||
color: #f4e3c4;
|
||||
font-size: 0.94rem;
|
||||
}
|
||||
|
||||
/* ── Links ── */
|
||||
.post__body a { color: var(--c-blue); }
|
||||
.post__body a:hover { color: var(--c-purple); }
|
||||
|
||||
/* ── Strong ── */
|
||||
.post__body strong { color: var(--c-gold); }
|
||||
|
||||
/* ── HR ── */
|
||||
.post__body hr {
|
||||
border: none;
|
||||
border-top: 1px solid var(--c-border);
|
||||
margin: 32px 0;
|
||||
}
|
||||
|
||||
/* ── Figures ── */
|
||||
.post__body figure { margin: 20px 0; }
|
||||
.post__body figure img {
|
||||
max-width: 100%;
|
||||
border-radius: 12px;
|
||||
border: 1px solid var(--c-border);
|
||||
}
|
||||
|
||||
.post__body figcaption {
|
||||
color: var(--c-muted);
|
||||
font-size: 0.85rem;
|
||||
margin-top: 6px;
|
||||
}
|
||||
|
||||
/* ── Lists ── */
|
||||
.post__body ul, .post__body ol { padding-left: 1.5em; margin: 10px 0; }
|
||||
.post__body li { margin: 4px 0; }
|
||||
|
||||
/* ── Author ── */
|
||||
.post__author {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: 14px;
|
||||
margin-top: 48px;
|
||||
padding-top: 24px;
|
||||
border-top: 1px solid var(--c-border);
|
||||
}
|
||||
|
||||
.post__author-avatar {
|
||||
width: 48px;
|
||||
height: 48px;
|
||||
border-radius: 50%;
|
||||
background: var(--c-accent);
|
||||
color: var(--c-bg);
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
font-weight: 700;
|
||||
font-size: 0.85rem;
|
||||
flex-shrink: 0;
|
||||
}
|
||||
|
||||
.post__author-info {
|
||||
font-size: 0.85rem;
|
||||
color: var(--c-muted);
|
||||
line-height: 1.4;
|
||||
}
|
||||
|
||||
.post__author-name {
|
||||
color: var(--c-text);
|
||||
font-weight: 600;
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<!-- POST -->
|
||||
<article class="post">
|
||||
<a href="/blog/" class="post__back">← All Posts</a>
|
||||
<span class="post__date">11 June 2026</span>
|
||||
<h1 class="post__title">Flows Are Sessions, Not Pipelines: Why We Moved Our Agent Orchestrator from YAML to JavaScript</h1>
|
||||
<p class="post__lead">Our YAML flow engine had seven bespoke node types just to fake a <code>while</code> loop. We threw it out and rewrote everything in 200 lines of JavaScript. The flow engine is gone. The flow IS the session. Here's what we learned.</p>
|
||||
|
||||
<div class="post__body">
|
||||
<h2>The YAML Was a Compiler for a Language Nobody Wanted</h2>
|
||||
<p>The old system was a static DAG. You defined nodes and edges in YAML, the engine walked them top-to-bottom, and when it finished it was done. No mid-run interaction. No branching. No retry. If you wanted a loop, you didn't use a <code>while</code> statement — you used an <code>agent-loop-decision</code> node type. In YAML.</p>
|
||||
<pre><code class="language-yaml"># The old way: a "loop" was a bespoke node type
|
||||
steps:
|
||||
- agent-task: "generate document"
|
||||
- agent-loop-decision:
|
||||
condition: "check if quality > 0.8"
|
||||
if-true: "continue"
|
||||
if-false: "repeat-step: agent-task"</code></pre>
|
||||
<p>That's not configuration. That's a compiler for a language nobody wanted to write. Every orchestrator ends up here — GitHub Actions expressions, GitLab CI <code>rules</code>, Airflow's <code>BranchPythonOperator</code>, all of them start as "simple YAML config" and grow node types until they're Turing-complete nightmares held together by schema patches.</p>
|
||||
<p>We had seven: <code>agent-task</code>, <code>agent-loop-decision</code>, <code>fork</code>, <code>conditional</code>, <code>agent-join</code>, <code>pipeline-stage</code>, <code>human-review</code>. Each one existed because YAML can't express control flow. You weren't writing a flow. You were filing paperwork to describe a flow.</p>
|
||||
<p>The moment we knew it was wrong: someone asked "can I retry this step three times if it fails?" and the honest answer was "we'd need a new node type." When your config format needs an RFC to add a <code>for</code> loop, you've built a programming language by accident. Delete it.</p>
|
||||
<h2>200 Lines of JavaScript Replaced Seven Node Types</h2>
|
||||
<p>A flow is now an ES module. You export <code>default async (flow) => {}</code> and the runtime calls it. The API surface is five calls:</p>
|
||||
<ul>
|
||||
<li><code>agent(prompt, options)</code> — run one agent with a task</li>
|
||||
<li><code>parallel(thunks)</code> — run many agents concurrently, await all</li>
|
||||
<li><code>pipeline(items, ...stages)</code> — push items through stages</li>
|
||||
<li><code>phase(name)</code> — label progress for the dashboard</li>
|
||||
<li><code>human(config)</code> — pause and wait for a person</li>
|
||||
</ul>
|
||||
<p>Here's a real flow. It reviews a code route change with parallel researchers and a human gate. Ten lines.</p>
|
||||
<pre><code class="language-js">// .pi/flows/flows/review-routes.flow.mjs
|
||||
export const meta = { name: "review-routes", description: "audit routes for missing auth" };
|
||||
export default async (flow) => {
|
||||
const { agent, parallel, phase, human, task } = flow;
|
||||
phase("find");
|
||||
const findings = await parallel(["auth", "input"].map((d) => () =>
|
||||
agent(`Review ${d}: ${task}`, { agent: "researcher", model: "@planning" })
|
||||
));
|
||||
phase("review");
|
||||
const gate = await human({ title: "Eyeball it", prompt: "anything to fix before I finish?" });
|
||||
return { findings, gate };
|
||||
};</code></pre>
|
||||
<p>Why JavaScript wins is boring and fundamental: it has <code>while</code>, <code>if</code>, <code>try/catch</code>, and <code>parallel(thunks)</code> built in. The things our YAML needed custom schema types to fake are just language keywords. Bounded concurrency is a one-liner. Error recovery is a <code>try</code> block. A loop is <code>while (!approved)</code>. No plugin, no RFC, no new node type.</p>
|
||||
<p>We migrated all flows YAML-to-JS on 2026-06-10. One-way conversion script, every flow reviewed and running in 24 hours. The YAML parser was deleted — not deprecated, not kept for backwards compatibility, deleted. There's no config path left to reach for.</p>
|
||||
<p>The plan lives in code, not config. Config is for things that don't change. Agent orchestration changes every run.</p>
|
||||
<h2>A Flow IS a Session</h2>
|
||||
<p>The old model had a phantom problem. A flow was a card. A session was a separate card. The operator watched the flow run from a different window. There was a "New Flow" button that created a flow card, and a "Continue" button that attached a session to it, and the disconnect between "the thing running your work" and "the place you talk to it" was baked into the UI.</p>
|
||||
<p>We killed that architecture. Every spawn is a session.</p>
|
||||
<p>When you call <code>POST /api/flows/spawn {cwd, task, flowName}</code>, the session runs the flow inside itself with the <code>flow_run</code> tool. Steps stream inline into the chat — <code>flow:steps</code> injects progress into the session's own message stream. The session turns purple in the dashboard. It becomes the flow. One card. One identity. Persistent after the run finishes.</p>
|
||||
<p>No "New Flow" button. No "Continue" button. You spawn a session; with a <code>flowName</code> it runs that flow, without one it opens an interactive operator session that designs a flow with you first. The dashboard branding is tinqs Studio. The control surface is the host card, live agent cards, run history, and a chat to steer the run.</p>
|
||||
<p>There's no phantom card. No disconnect between "the thing running your work" and "the place you talk to it." It's one session. You're in the room.</p>
|
||||
<h2>The Human Gate: Pause, Take Over, Approve, Continue</h2>
|
||||
<p>Agents make mistakes. They guess when they shouldn't. They take irreversible actions because the prompt said "proceed." The model gets stuck and you sit there wondering — do I wait or abort?</p>
|
||||
<p><code>flow.human()</code> is our answer.</p>
|
||||
<p>When a flow hits a human gate, it stops. The dashboard shows the gate prompt: what to review, what to decide. The host session switches to takeover mode — coding tools are unblocked (normally the host is hands-off) and the system prompt becomes "flow is paused, help the operator finish this." You open files. You edit. You verify. You run commands.</p>
|
||||
<p>To release the gate, reply <code>approve</code> or <code>done</code> or <code>lgtm</code>. The flow resumes. Any other message is a work instruction — the takeover session executes it but does not release the gate. The flow loops on <code>notes</code> until the human says go.</p>
|
||||
<pre><code class="language-js">let approved = false;
|
||||
while (!approved) {
|
||||
const { notes } = await human({
|
||||
title: "Review before push",
|
||||
prompt: "Check the diff. Approve or tell me what to fix.",
|
||||
});
|
||||
if (notes.match(/^(approve|done|lgtm|looks good)/i)) approved = true;
|
||||
else await agent(`Fix: ${notes}`, { agent: "implementer" });
|
||||
}</code></pre>
|
||||
<p>Two patterns this enables. First: review-approve-before-push gates — nobody ships untested code because nobody set the <code>auto-approve</code> flag to true. Second: the "agent is stuck" hand-off — the flow pauses, you take over the exact same workspace, fix the problem, type <code>continue</code>, and the flow keeps going.</p>
|
||||
<p>The flow waits instead of guessing. This isn't a feature. It's an admission that some decisions shouldn't be automated.</p>
|
||||
<h2>The Operator Is Your Co-Pilot</h2>
|
||||
<p>The old way was a one-shot generator. Paste an objective, click Generate, get a YAML blob, pray it's right, run it, discover it's wrong 20 minutes in with no way to steer. We'd watch flows fail and think "I could have told it that before it started."</p>
|
||||
<p>The new flow operator doesn't write the flow for you and walk away. It designs it with you.</p>
|
||||
<p>Hit New Flow. A DeepSeek session opens — the same model that powers the dashboard, cheap at $0.28/MTok, steerable in natural language. It proposes a draft <code>.flow.mjs</code>, shows you the agents and phases and any human gate, and explains why. You tell it what to change. It does NOT launch until you say go. When you approve, it writes the flow file and spawns a separate host session, then attaches to monitor and report progress.</p>
|
||||
<p>The operator is still in the chat when the human gate fires. It's still there when you want to change the plan mid-run. It doesn't go away after launch. Co-pilot, not autopilot.</p>
|
||||
<p>There are three runner faces for the same engine: <strong>pi/dashboard</strong> (DeepSeek, cheap, steerable — the default), <strong>Claude Code</strong> (Workflow tool, one-shot fan-out for heavy research), and a <strong>cloud agent</strong> (remote deploy, clone, AWS). Pick by granularity and cost. The flow file is the same in all three modes.</p>
|
||||
<h2>What We Learned</h2>
|
||||
<p><strong>Numbers first.</strong> 43 out of 43 unit tests green. All flows migrated. The supervisor inbox — steering messages sent between steps — was silently dropping operator messages before 2026-06-10. You'd type "focus on the auth routes" and the flow never saw it. That's fixed now. Chat reaches the inbox, the inbox drains between <code>agent()</code> calls, and steering works.</p>
|
||||
<p><strong>The inbox rule.</strong> The supervisor inbox is applied between <code>agent()</code> calls, never mid-step. Steering mid-step is undefined behaviour. We learned this the hard way — early versions tried to inject mid-agent and got corrupted state, partial outputs, agents that forgot what they were doing. Between steps is the right boundary. Respect it.</p>
|
||||
<p><strong>Economics matter.</strong> DeepSeek V4 Pro at $0.28/MTok runs per-step. Per-step model override lets you swap in a premium reasoning model ($15/MTok) for the one critical call that needs it. $0.28 for routine, $15 for the hard parts. The three-tier strategy from our agent daemon applies at flow granularity too.</p>
|
||||
<p><strong>What's next.</strong> Richer on-card flow display — a pinned step strip so you can see progress without opening the session. Attachable asset and agent-structure viewers in the flow card. Run replay for finished sessions after a page reload (the session persists, but you can't rewatch the stream yet).</p>
|
||||
<p>But the principle is settled. A flow isn't a pipeline. A pipeline runs blind and reports back later. A flow is a pair-programming session where one of the pair happens to be code.</p>
|
||||
<hr>
|
||||
<p><em><a href="https://tinqs.com" style="color: var(--c-accent-l);">Tinqs Studio</a> is our agent-native development platform — git hosting, AI agents, and the flow engine described here. <a href="https://arikigame.com" style="color: var(--c-accent-l);">Ariki</a> is the survival colony sim we're building with it.</em></p>
|
||||
|
||||
</div>
|
||||
|
||||
<div class="post__author">
|
||||
<div class="post__author-avatar">OB</div>
|
||||
<div class="post__author-info">
|
||||
<span class="post__author-name">Ozan Bozkurt</span><br>
|
||||
CTO & Developer, Tinqs
|
||||
</div>
|
||||
</div>
|
||||
</article>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
After
|
@@ -276,7 +276,7 @@
|
||||
<p>Across three forks, we've never touched more than 0.5% of upstream code. If your fork hits 1%, you're doing too much — either the upstream tool is wrong for the job, or you're not trusting it enough.</p>
|
||||
<h2>Fork 1: Gitea → Tinqs Studio</h2>
|
||||
<p>Gitea is a self-hosted git server. Single Go binary, MIT license, 45k GitHub stars. We used GitHub for two years. It was fine for docs. For the game repo — 12GB in LFS, growing weekly — it was untenable. LFS bandwidth limits, slow clones, $5/50GB pricing. And nobody on the team could <strong>see</strong> what changed. A PR modifying a <code>.glb</code> file showed a binary diff. No preview. The artist pushed, the developer approved blindly, and three days later someone noticed the normals were inverted.</p>
|
||||
<p>We forked Gitea and built <a href="https://tinqs.com" style="color: var(–c-accent-l);">Tinqs Studio</a>. Our changes:</p>
|
||||
<p>We forked Gitea and built <a href="https://tinqs.com" style="color: var(--c-accent-l);">Tinqs Studio</a>. Our changes:</p>
|
||||
<p><strong>3D asset preview.</strong> Click a <code>.glb</code>, <code>.gltf</code>, or <code>.fbx</code> file in a PR and rotate the model in your browser. 22 formats supported via O3DV. This alone transformed our review process — the artist pushes, the lead inspects, nobody downloads anything.</p>
|
||||
<p><strong>HTML file preview.</strong> Sandboxed iframe rendering. Our internal docs and game design pages look like websites, not raw source.</p>
|
||||
<p><strong>Agent API.</strong> Six REST endpoints that let AI agents submit tasks, push code, check CI status, and open PRs. Agents are first-class users of the git platform, not bolt-on tools.</p>
|
||||
@@ -285,7 +285,7 @@
|
||||
<p>Total lines changed: about 2,000 out of Gitea's 500,000. We modify templates, add Go modules, tweak CSS. We <strong>never</strong> touch the database schema — upstream owns that, and we ride their migrations.</p>
|
||||
<p>The alternative was building a git platform from scratch. Multi-year project, multi-million dollar budget. Or using GitHub/GitLab and accepting their limitations. Neither gives you the ability to embed agents directly into the platform.</p>
|
||||
<h2>Fork 2: Pi → Agent Runtime with Game Tools</h2>
|
||||
<p><a href="https://pi.dev" style="color: var(–c-accent-l);">Pi</a> is an open-source coding agent by Mario Zechner. MIT license, TypeScript, minimal by design — four core tools (read, write, edit, bash) and an extension system. 51k stars.</p>
|
||||
<p><a href="https://pi.dev" style="color: var(--c-accent-l);">Pi</a> is an open-source coding agent by Mario Zechner. MIT license, TypeScript, minimal by design — four core tools (read, write, edit, bash) and an extension system. 51k stars.</p>
|
||||
<p>We forked it and added four extensions, each a single TypeScript file:</p>
|
||||
<ul>
|
||||
<li><strong>tinqs-provider</strong> — routes inference through our DeepSeek V4 proxy ($0.28/MTok vs Opus at $15/MTok)</li>
|
||||
@@ -296,7 +296,7 @@
|
||||
<p>The core Pi code is untouched — 900 lines of extensions added to a 15,000-line codebase. Agents get Gitea-native tools without a fork of the entire agent ecosystem.</p>
|
||||
<p>The alternative: building our own agent from scratch — tool-calling logic, context management, streaming, retry handling, conversation threading. Months of work to reinvent what Pi already does.</p>
|
||||
<h2>Fork 3: Godot → Agent-Aware Game Engine</h2>
|
||||
<p><a href="https://godotengine.org" style="color: var(–c-accent-l);">Godot</a> is the open-source game engine powering our survival colony sim. We forked 4.6.2 and added nine C++ modules that give agents direct access to the running game:</p>
|
||||
<p><a href="https://godotengine.org" style="color: var(--c-accent-l);">Godot</a> is the open-source game engine powering our survival colony sim. We forked 4.6.2 and added nine C++ modules that give agents direct access to the running game:</p>
|
||||
<ul>
|
||||
<li><strong>agent_api</strong> — HTTP server inside the engine so agents can query game state</li>
|
||||
<li><strong>agent_vision</strong> — screenshot capture for AI vision pipelines</li>
|
||||
@@ -315,7 +315,7 @@
|
||||
<p>We're building the layer that connects them. The git server that speaks agent. The coding agent that speaks Gitea. The game engine that speaks HTTP. Each fork is a bridge between an existing tool and the agentic future — not a replacement for either.</p>
|
||||
<p>The age of agents doesn't need more agents. It needs better platforms. Platforms that already exist as open-source projects. They just need someone to fork them and add the wiring.</p>
|
||||
<hr>
|
||||
<p><em><a href="https://tinqs.com" style="color: var(–c-accent-l);">Tinqs Studio</a> is our Gitea fork, open for game teams. <a href="https://arikigame.com" style="color: var(–c-accent-l);">Ariki</a> is the game we're building with every tool described here.</em></p>
|
||||
<p><em><a href="https://tinqs.com" style="color: var(--c-accent-l);">Tinqs Studio</a> is our Gitea fork, open for game teams. <a href="https://arikigame.com" style="color: var(--c-accent-l);">Ariki</a> is the game we're building with every tool described here.</em></p>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
Before
After
|
@@ -319,7 +319,7 @@
|
||||
<p><strong>Always measure before optimizing.</strong> We added VRAM logging before writing a single line of optimization code. Half the "problems" we expected were non-issues. The other half were worse than expected. Profiling isn't optional.</p>
|
||||
<hr>
|
||||
<p>Godot 4 can handle open worlds at this scale, but it won't do it for you. You need to build streaming, manage your own caches, audit resource loading, and be disciplined about what runs per frame. The engine gives you the primitives — MultiMesh, <code>LoadThreadedRequest</code>, <code>QueueFree</code>. It's up to you to wire them into a system that scales.</p>
|
||||
<p><em>We're building <a href="https://arikigame.com" style="color: var(–c-accent-l);">Ariki</a>, a survival colony sim, with these systems. The tools we use — git hosting, AI agents, creative pipelines — are part of <a href="https://tinqs.com" style="color: var(–c-accent-l);">Tinqs Studio</a>.</em></p>
|
||||
<p><em>We're building <a href="https://arikigame.com" style="color: var(--c-accent-l);">Ariki</a>, a survival colony sim, with these systems. The tools we use — git hosting, AI agents, creative pipelines — are part of <a href="https://tinqs.com" style="color: var(--c-accent-l);">Tinqs Studio</a>.</em></p>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
Before
After
|
@@ -0,0 +1,343 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>GPU-Skinned Herds: One Draw Call for 1,000 Animated Characters in Godot — Tinqs Blog</title>
|
||||
<meta name="description" content="Godot has no built-in way to render 1,000 skinned characters in one draw call. We built a GPU skinned-instance renderer into Tinqs Engine that does — 25 crocodiles verified, 1,000+ projected. Pre-built binaries for macOS and Windows.">
|
||||
<meta name="robots" content="index, follow">
|
||||
<link rel="canonical" href="https://www.tinqs.com/blog/gpu-skinned-herds">
|
||||
|
||||
<meta property="og:type" content="article">
|
||||
<meta property="og:url" content="https://www.tinqs.com/blog/gpu-skinned-herds">
|
||||
<meta property="og:title" content="GPU-Skinned Herds: One Draw Call for 1,000 Animated Characters in Godot">
|
||||
<meta property="og:description" content="One draw call, 1,000 animated characters. GPU-skinned herd renderer built into the Tinqs Engine fork of Godot.">
|
||||
<meta property="og:image" content="https://www.tinqs.com/img/og-cover.jpg">
|
||||
|
||||
<meta name="twitter:card" content="summary_large_image">
|
||||
<meta name="twitter:title" content="GPU-Skinned Herds: One Draw Call for 1,000 Animated Characters in Godot">
|
||||
<meta name="twitter:description" content="One draw call, 1,000 animated characters. GPU-skinned herd renderer built into the Tinqs Engine fork of Godot.">
|
||||
<meta name="twitter:image" content="https://www.tinqs.com/img/og-cover.jpg">
|
||||
|
||||
<script type="application/ld+json">
|
||||
{
|
||||
"@context": "https://schema.org",
|
||||
"@type": "BlogPosting",
|
||||
"headline": "GPU-Skinned Herds: One Draw Call for 1,000 Animated Characters in Godot",
|
||||
"datePublished": "2026-06-14",
|
||||
"author": {
|
||||
"@type": "Person",
|
||||
"name": "Ozan Bozkurt"
|
||||
},
|
||||
"publisher": {
|
||||
"@type": "Organization",
|
||||
"name": "Tinqs Limited",
|
||||
"url": "https://www.tinqs.com"
|
||||
},
|
||||
"description": "Godot has no built-in way to render 1,000 skinned characters in one draw call. We built a GPU skinned-instance renderer into Tinqs Engine that does — 25 crocodiles verified, 1,000+ projected. Pre-built binaries for macOS and Windows."
|
||||
}
|
||||
</script>
|
||||
|
||||
<style>
|
||||
/* ── Self-contained post styles (Studio provides site chrome) ── */
|
||||
|
||||
:root {
|
||||
--c-accent: #c9935a;
|
||||
--c-accent-l: #d4a87c;
|
||||
--c-bg: #0d1117;
|
||||
--c-text: #e6edf3;
|
||||
--c-muted: #9aa7b4;
|
||||
--c-border: #2a3340;
|
||||
--c-blue: #38bdf8;
|
||||
--c-purple: #a855f7;
|
||||
--c-gold: #f59e0b;
|
||||
--c-code-bg: #1c2230;
|
||||
--c-pre-bg: #0a0e14;
|
||||
}
|
||||
|
||||
*, *::before, *::after { box-sizing: border-box; }
|
||||
|
||||
body {
|
||||
margin: 0;
|
||||
padding: 0;
|
||||
background: transparent;
|
||||
color: var(--c-text);
|
||||
font-family: system-ui, -apple-system, 'Segoe UI', Roboto, Helvetica, Arial, sans-serif;
|
||||
line-height: 1.6;
|
||||
-webkit-font-smoothing: antialiased;
|
||||
}
|
||||
|
||||
/* ── Post container ── */
|
||||
.post {
|
||||
max-width: 720px;
|
||||
margin: 0 auto;
|
||||
padding: 40px 24px 48px;
|
||||
}
|
||||
|
||||
/* ── Back link ── */
|
||||
.post__back {
|
||||
color: var(--c-blue);
|
||||
text-decoration: none;
|
||||
font-size: 0.9rem;
|
||||
display: inline-block;
|
||||
margin-bottom: 24px;
|
||||
}
|
||||
.post__back:hover { color: var(--c-purple); }
|
||||
|
||||
/* ── Gradient title ── */
|
||||
.post__title {
|
||||
background: linear-gradient(90deg, #c9935a, #f59e0b 40%, #38bdf8);
|
||||
-webkit-background-clip: text;
|
||||
background-clip: text;
|
||||
color: transparent;
|
||||
font-weight: 800;
|
||||
font-size: 2.2rem;
|
||||
line-height: 1.25;
|
||||
margin: 0 0 16px;
|
||||
}
|
||||
|
||||
/* ── Date pill ── */
|
||||
.post__date {
|
||||
display: inline-block;
|
||||
font-family: ui-monospace, 'SF Mono', 'Cascadia Code', Consolas, monospace;
|
||||
font-size: 0.72rem;
|
||||
letter-spacing: 0.22em;
|
||||
text-transform: uppercase;
|
||||
color: var(--c-blue);
|
||||
border: 1px solid rgba(147, 140, 129, 0.25);
|
||||
border-radius: 999px;
|
||||
padding: 4px 14px;
|
||||
margin-bottom: 16px;
|
||||
}
|
||||
|
||||
/* ── Lead ── */
|
||||
.post__lead {
|
||||
color: var(--c-muted);
|
||||
font-size: 1.08rem;
|
||||
line-height: 1.7;
|
||||
}
|
||||
|
||||
/* ── Body ── */
|
||||
.post__body { font-size: 1rem; line-height: 1.7; }
|
||||
|
||||
.post__body p { margin: 14px 0; }
|
||||
|
||||
.post__body h2 {
|
||||
font-size: 1.7rem;
|
||||
margin: 54px 0 6px;
|
||||
padding-left: 16px;
|
||||
border-left: 4px solid var(--c-accent);
|
||||
line-height: 1.3;
|
||||
}
|
||||
|
||||
.post__body h3 {
|
||||
color: var(--c-purple);
|
||||
font-size: 1.18rem;
|
||||
margin: 30px 0 4px;
|
||||
}
|
||||
|
||||
.post__body h4, .post__body h5, .post__body h6 {
|
||||
margin: 20px 0 4px;
|
||||
}
|
||||
|
||||
/* ── Inline code ── */
|
||||
.post__body code {
|
||||
font-family: ui-monospace, 'SF Mono', 'Cascadia Code', Consolas, monospace;
|
||||
font-size: 0.86em;
|
||||
background: var(--c-code-bg);
|
||||
color: #9fe6c0;
|
||||
padding: 2px 6px;
|
||||
border-radius: 5px;
|
||||
border: 1px solid var(--c-border);
|
||||
}
|
||||
|
||||
/* ── Code blocks ── */
|
||||
.post__body pre {
|
||||
background: var(--c-pre-bg);
|
||||
border: 1px solid var(--c-border);
|
||||
border-radius: 10px;
|
||||
padding: 16px 18px;
|
||||
overflow-x: auto;
|
||||
margin: 14px 0;
|
||||
font-family: ui-monospace, 'SF Mono', 'Cascadia Code', Consolas, monospace;
|
||||
font-size: 0.85rem;
|
||||
line-height: 1.55;
|
||||
color: var(--c-text);
|
||||
}
|
||||
|
||||
.post__body pre code {
|
||||
background: transparent;
|
||||
padding: 0;
|
||||
border: none;
|
||||
font-size: inherit;
|
||||
color: inherit;
|
||||
border-radius: 0;
|
||||
}
|
||||
|
||||
/* ── Blockquote ── */
|
||||
.post__body blockquote {
|
||||
background: rgba(245, 158, 11, 0.08);
|
||||
border: 1px solid rgba(245, 158, 11, 0.25);
|
||||
border-left: 4px solid var(--c-gold);
|
||||
border-radius: 0 12px 12px 0;
|
||||
padding: 16px 18px;
|
||||
margin: 18px 0;
|
||||
color: #f4e3c4;
|
||||
font-size: 0.94rem;
|
||||
}
|
||||
|
||||
/* ── Links ── */
|
||||
.post__body a { color: var(--c-blue); }
|
||||
.post__body a:hover { color: var(--c-purple); }
|
||||
|
||||
/* ── Strong ── */
|
||||
.post__body strong { color: var(--c-gold); }
|
||||
|
||||
/* ── HR ── */
|
||||
.post__body hr {
|
||||
border: none;
|
||||
border-top: 1px solid var(--c-border);
|
||||
margin: 32px 0;
|
||||
}
|
||||
|
||||
/* ── Figures ── */
|
||||
.post__body figure { margin: 20px 0; }
|
||||
.post__body figure img {
|
||||
max-width: 100%;
|
||||
border-radius: 12px;
|
||||
border: 1px solid var(--c-border);
|
||||
}
|
||||
|
||||
.post__body figcaption {
|
||||
color: var(--c-muted);
|
||||
font-size: 0.85rem;
|
||||
margin-top: 6px;
|
||||
}
|
||||
|
||||
/* ── Lists ── */
|
||||
.post__body ul, .post__body ol { padding-left: 1.5em; margin: 10px 0; }
|
||||
.post__body li { margin: 4px 0; }
|
||||
|
||||
/* ── Author ── */
|
||||
.post__author {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: 14px;
|
||||
margin-top: 48px;
|
||||
padding-top: 24px;
|
||||
border-top: 1px solid var(--c-border);
|
||||
}
|
||||
|
||||
.post__author-avatar {
|
||||
width: 48px;
|
||||
height: 48px;
|
||||
border-radius: 50%;
|
||||
background: var(--c-accent);
|
||||
color: var(--c-bg);
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
font-weight: 700;
|
||||
font-size: 0.85rem;
|
||||
flex-shrink: 0;
|
||||
}
|
||||
|
||||
.post__author-info {
|
||||
font-size: 0.85rem;
|
||||
color: var(--c-muted);
|
||||
line-height: 1.4;
|
||||
}
|
||||
|
||||
.post__author-name {
|
||||
color: var(--c-text);
|
||||
font-weight: 600;
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<!-- POST -->
|
||||
<article class="post">
|
||||
<a href="/blog/" class="post__back">← All Posts</a>
|
||||
<span class="post__date">14 June 2026</span>
|
||||
<h1 class="post__title">GPU-Skinned Herds: One Draw Call for 1,000 Animated Characters in Godot</h1>
|
||||
<p class="post__lead">Godot gives you one <code>Skeleton3D</code> per character. Want 200 animals in a herd? That's 200 skeleton nodes, 200 draw calls, and 200 <code>AnimationPlayer</code> ticks every frame. Want 1,000? Now you're measuring in seconds per frame, not frames per second.</p>
|
||||
|
||||
<div class="post__body">
|
||||
<p>We built a GPU skinned-instance renderer into Tinqs Engine that packs every pose into a single texture, uploads once, and draws every instance in one call. 25 crocodiles on screen right now. 1,000+ projected. Same bone count, same animation fidelity — a tiny fraction of the cost.</p>
|
||||
<h2>Why the engine needs to change</h2>
|
||||
<p>The standard Godot approach — one <code>Skeleton3D</code> + one <code>MeshInstance3D</code> per character — works for a handful of animated entities. It breaks down hard at crowd scale:</p>
|
||||
<ul>
|
||||
<li><strong>CPU bone transforms.</strong> Computing <code>global_pose</code> for 200 skeletons × 100 bones each = 20,000 matrix multiplies per frame, all on the main thread.</li>
|
||||
<li><strong>Draw call explosion.</strong> Each <code>MeshInstance3D</code> is its own draw call. Even with MultiMesh, there's no built-in path for skinned meshes — <code>MultiMeshInstance3D</code> only handles static geometry.</li>
|
||||
<li><strong>AnimationPlayer sprawl.</strong> Each skeleton needs its own <code>AnimationPlayer</code> and its own <code>process()</code> tick.</li>
|
||||
</ul>
|
||||
<p>The alternative — baking animations to vertex textures — works for static crowds but locks you out of per-instance variation. No blending, no phase offsets, no reactive behaviour.</p>
|
||||
<p>What we need is simpler: <strong>share the skeleton, drive per-instance poses from a single animation, batch the draw call.</strong> That's what <code>agent_skinned</code> does.</p>
|
||||
<h2>How it works: two classes, one texture</h2>
|
||||
<p>The module lives in <code>modules/agent_skinned/</code> inside <a href="https://tinqs.com/tinqs/engine" style="color: var(--c-accent-l);">Tinqs Engine</a>. Two classes, one job:</p>
|
||||
<h3><code>MultiSkinnedMeshInstance3D</code> — the data plane</h3>
|
||||
<p>Holds the CPU-side bone matrices. Allocates an <code>ImageTexture</code> of size <code>[4 × max_bones, max_instances]</code> in RGBA32F — each texel is one column of a 4×4 bone matrix. For a 130-bone crocodile with 256 instances:</p>
|
||||
<pre><code>Texture: 520 × 256 RGBA32F ≈ 2 MB</code></pre>
|
||||
<p>That's the entire pose state for 256 animated crocodiles in a single GPU texture. The API is simple:</p>
|
||||
<pre><code class="language-gdscript">var data := MultiSkinnedMeshInstance3D.new()
|
||||
data.set_mesh(crocodile_mesh)
|
||||
data.set_skeleton(skeleton) # rest pose + bone hierarchy
|
||||
data.set_max_instances(256)
|
||||
data.set_max_bones(130)
|
||||
|
||||
# Each frame: push poses from the animated skeleton
|
||||
for instance in herd_positions:
|
||||
data.set_instance_pose_bones(instance.id, bone_transforms)
|
||||
data.update() # upload only dirty instances, not the whole texture</code></pre>
|
||||
<h3><code>MultiSkinnedInstance3D</code> — the renderer</h3>
|
||||
<p>A <code>MultiMeshInstance3D</code> subclass. Set its multimesh with the skinned mesh and instance transforms, point it at the data plane, call <code>refresh()</code> — it uploads the bone texture into the shader material's <code>bone_matrices_tex</code> uniform and the mesh is drawn in one call.</p>
|
||||
<p>The shader does 4-bone linear-blend skinning on the GPU:</p>
|
||||
<pre><code class="language-glsl">mat4 get_bone(int b) {
|
||||
return mat4(
|
||||
texelFetch(bone_matrices_tex, ivec2(b * 4 + 0, INSTANCE_ID), 0),
|
||||
texelFetch(bone_matrices_tex, ivec2(b * 4 + 1, INSTANCE_ID), 0),
|
||||
texelFetch(bone_matrices_tex, ivec2(b * 4 + 2, INSTANCE_ID), 0),
|
||||
texelFetch(bone_matrices_tex, ivec2(b * 4 + 3, INSTANCE_ID), 0)
|
||||
);
|
||||
}</code></pre>
|
||||
<p><code>INSTANCE_ID</code> is a Godot built-in — the GPU already knows which instance it's rendering. We just use it to index into the bone texture. No uniform arrays, no SSBOs, no compute shaders. Just a 2D texture and a custom vertex shader.</p>
|
||||
<h2>Two bugs we shipped and fixed</h2>
|
||||
<p>The module had data-plane doctests from day one — round-trip pose get/set, dirty tracking, size clamping, AABB. All green. Then we put it on screen for the first time and the crocodiles looked... wrong.</p>
|
||||
<p><strong>Bug 1: Shader compile failure.</strong> The default skinning shader compared <code>TANGENT</code> as <code>vec4</code>. Godot 4 exposes it as <code>vec3</code>. Fixed in one line, added <code>albedo_tex</code> uniform so herds texture out of the box.</p>
|
||||
<p><strong>Bug 2: Bone matrices stored transposed.</strong> The data plane wrote basis rows (standard Godot <code>Transform3D.basis</code> is row-major), but the shader unpacked as columns. Every bone matrix was transposed — the mesh crumpled. Not a scale bug, not an orientation bug — a layout mismatch. Fixed by storing column-major, with a doctest to prevent regression.</p>
|
||||
<p>The lesson: doctests catch logic. Rendering catches truth. You need both.</p>
|
||||
<h2>What's driving it</h2>
|
||||
<p>In <a href="https://www.arikigame.com" style="color: var(--c-accent-l);">Ariki</a>, the sim tracks animal migration across a 12km archipelago. <code>AnimalHerdRenderer.cs</code> groups sim <code>ViewerState.animals</code> by type, feeds positions to <code>skinned_herd.gd</code> (a reusable per-type herd backend), which drives the renderer. One <code>AnimationPlayer</code> animates a single driver skeleton; poses propagate to every instance.</p>
|
||||
<p>The crocodile herd scene is 25 instances, one draw call. The same pipeline projects to 200–1,000 before the GPU budget even notices.</p>
|
||||
<h2>What's deliberately not here</h2>
|
||||
<ul>
|
||||
<li><strong>No C# wrapper.</strong> Instantiate from GDScript via <code>ClassDB.instantiate()</code> — the binding surface is small and stable.</li>
|
||||
<li><strong>No automatic <code>AnimationPlayer</code> integration.</strong> You drive poses. We give you the texture. Freedom to animate however you want.</li>
|
||||
<li><strong>No GPU occlusion or LOD.</strong> That's the game's job. The engine provides the tool; the game decides what to draw.</li>
|
||||
</ul>
|
||||
<h2>Get the build</h2>
|
||||
<p>Pre-built editor binaries with <code>agent_skinned</code> baked in — no engine compile required:</p>
|
||||
<p>| Platform | Binary | Engine commit |</p>
|
||||
<p>|———-|——–|—————|</p>
|
||||
<p>| <strong>macOS ARM64</strong> | <a href="https://tinqs.com/tinqs/builds/media/branch/main/engine/macos-arm64/tinqs.macos.editor.arm64.mono" style="color: var(--c-accent-l);"><code>tinqs.macos.editor.arm64.mono</code></a> | <code>4fe1323</code> (4.6.4, Xcode 26.3) |</p>
|
||||
<p>| <strong>Windows x64</strong> | <a href="https://tinqs.com/tinqs/builds/media/branch/main/engine/windows-x64/tinqs.windows.editor.x86_64.mono.exe" style="color: var(--c-accent-l);"><code>tinqs.windows.editor.x86_64.mono.exe</code></a> | <code>64fb5cc</code> (4.6.4, MSVC 2022) |</p>
|
||||
<p>All builds live in the public <a href="https://tinqs.com/tinqs/builds" style="color: var(--c-accent-l);"><code>tinqs/builds</code></a> repo — engine source is private, but the binaries are yours. See <a href="https://tinqs.com/tinqs/builds/src/branch/main/manifest.json" style="color: var(--c-accent-l);"><code>manifest.json</code></a> for checksums and build details.</p>
|
||||
<p>The engine source lives in <a href="https://tinqs.com/tinqs/engine" style="color: var(--c-accent-l);"><code>tinqs/engine</code></a> (private). Module docs: <code>modules/agent_skinned/README.md</code> and <code>.agents/wiki/agent-skinned-gpu-herd.md</code>.</p>
|
||||
<hr>
|
||||
<p><strong>Related:</strong> <a href="fork-dont-build" style="color: var(--c-accent-l);">Fork, Don't Build</a> — why we modify existing platforms instead of building new ones. <a href="godot-optimisation" style="color: var(--c-accent-l);">Streaming a 12km Archipelago in Godot 4</a> — the terrain and vegetation streaming layers that work alongside this.</p>
|
||||
|
||||
</div>
|
||||
|
||||
<div class="post__author">
|
||||
<div class="post__author-avatar">OB</div>
|
||||
<div class="post__author-info">
|
||||
<span class="post__author-name">Ozan Bozkurt</span><br>
|
||||
CTO & Developer, Tinqs
|
||||
</div>
|
||||
</div>
|
||||
</article>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
After
|
+14
@@ -167,6 +167,20 @@
|
||||
<span class="blog-card__read">Read →</span>
|
||||
</a>
|
||||
|
||||
<a href="gpu-skinned-herds" class="blog-card">
|
||||
<span class="blog-card__date">14 June 2026</span>
|
||||
<h2 class="blog-card__title">GPU-Skinned Herds: One Draw Call for 1,000 Animated Characters in Godot</h2>
|
||||
<p class="blog-card__excerpt">Godot can't batch-render 1,000 animated characters. We built a GPU skinned-instance herd renderer into the engine itself — already driving crocodile herds in Ariki. Pre-built editor binaries for macOS and Windows.</p>
|
||||
<span class="blog-card__read">Read →</span>
|
||||
</a>
|
||||
|
||||
<a href="flows-are-sessions" class="blog-card">
|
||||
<span class="blog-card__date">11 June 2026</span>
|
||||
<h2 class="blog-card__title">Flows Are Sessions, Not Pipelines: Why We Moved Our Agent Orchestrator from YAML to JavaScript</h2>
|
||||
<p class="blog-card__excerpt">We killed the static YAML DAG and rewrote our agent orchestration in 200 lines of JavaScript. Now a flow IS a session — you chat it, steer it, and it pauses for you at a human gate.</p>
|
||||
<span class="blog-card__read">Read →</span>
|
||||
</a>
|
||||
|
||||
<a href="voice-missing-input-game-dev" class="blog-card">
|
||||
<span class="blog-card__date">10 June 2026</span>
|
||||
<h2 class="blog-card__title">Why Voice Is the Missing Input for Game Development</h2>
|
||||
|
||||
|
Before
After
|
@@ -264,7 +264,7 @@
|
||||
<h1 class="post__title">Live Ozan Radio: A Personal AI Station in Cursor</h1>
|
||||
<p class="post__lead">I do not want a playlist. I want a station — something that feels like late-night desert dub and Anadolu psych drifting out of a speaker, but every track is composed fresh, never pulled from Spotify or Apple Music. So we built <strong>Live Ozan Radio</strong>: DeepSeek as the on-air DJ, Google Lyria 3 as the music engine, and our own Gitea instance as the host.
|
||||
|
||||
!<a href="https://tinqs.com/tinqs/blog/media/branch/main/img/live-ozan-radio-workspace.png" style="color: var(–c-accent-l);">Live Ozan Radio in Cursor — player dashboard, saved songs, and DJ chat beside the editor</a>
|
||||
!<a href="https://tinqs.com/tinqs/blog/media/branch/main/img/live-ozan-radio-workspace.png" style="color: var(--c-accent-l);">Live Ozan Radio in Cursor — player dashboard, saved songs, and DJ chat beside the editor</a>
|
||||
|
||||
That screenshot is how I actually use it: Cursor on the left with taste notes and vocal cues, the local player on <code>:8787</code> on the right, saved songs in a scrollable library, and a chat box to steer the next generation. It is dogfooding in the truest sense — we run our game studio on the same Gitea fork we sell as Tinqs Studio, and the radio lives in that repo too.
|
||||
|
||||
|
||||
|
Before
After
|
@@ -0,0 +1,133 @@
|
||||
---
|
||||
title: "Flows Are Sessions, Not Pipelines: Why We Moved Our Agent Orchestrator from YAML to JavaScript"
|
||||
slug: flows-are-sessions
|
||||
date: "2026-06-11"
|
||||
description: "We killed the static YAML DAG and rewrote our agent orchestration in 200 lines of JavaScript. Now a flow IS a session — you chat it, steer it, and it pauses for you at a human gate."
|
||||
og_description: "YAML DAGs are dead. We rewrote our agent orchestration in JavaScript, made every flow a live session, and added a human-in-the-loop gate. The operator is the co-pilot, not the babysitter."
|
||||
og_image: "https://www.tinqs.com/img/og-cover.jpg"
|
||||
excerpt: "We killed the static YAML DAG and rewrote our agent orchestration in 200 lines of JavaScript. Now a flow IS a session — you chat it, steer it, and it pauses for you at a human gate."
|
||||
author: "Ozan Bozkurt"
|
||||
author_initials: "OB"
|
||||
author_role: "CTO & Developer, Tinqs"
|
||||
---
|
||||
|
||||
Our YAML flow engine had seven bespoke node types just to fake a `while` loop. We threw it out and rewrote everything in 200 lines of JavaScript. The flow engine is gone. The flow IS the session. Here's what we learned.
|
||||
|
||||
## The YAML Was a Compiler for a Language Nobody Wanted
|
||||
|
||||
The old system was a static DAG. You defined nodes and edges in YAML, the engine walked them top-to-bottom, and when it finished it was done. No mid-run interaction. No branching. No retry. If you wanted a loop, you didn't use a `while` statement — you used an `agent-loop-decision` node type. In YAML.
|
||||
|
||||
```yaml
|
||||
# The old way: a "loop" was a bespoke node type
|
||||
steps:
|
||||
- agent-task: "generate document"
|
||||
- agent-loop-decision:
|
||||
condition: "check if quality > 0.8"
|
||||
if-true: "continue"
|
||||
if-false: "repeat-step: agent-task"
|
||||
```
|
||||
|
||||
That's not configuration. That's a compiler for a language nobody wanted to write. Every orchestrator ends up here — GitHub Actions expressions, GitLab CI `rules`, Airflow's `BranchPythonOperator`, all of them start as "simple YAML config" and grow node types until they're Turing-complete nightmares held together by schema patches.
|
||||
|
||||
We had seven: `agent-task`, `agent-loop-decision`, `fork`, `conditional`, `agent-join`, `pipeline-stage`, `human-review`. Each one existed because YAML can't express control flow. You weren't writing a flow. You were filing paperwork to describe a flow.
|
||||
|
||||
The moment we knew it was wrong: someone asked "can I retry this step three times if it fails?" and the honest answer was "we'd need a new node type." When your config format needs an RFC to add a `for` loop, you've built a programming language by accident. Delete it.
|
||||
|
||||
## 200 Lines of JavaScript Replaced Seven Node Types
|
||||
|
||||
A flow is now an ES module. You export `default async (flow) => {}` and the runtime calls it. The API surface is five calls:
|
||||
|
||||
- `agent(prompt, options)` — run one agent with a task
|
||||
- `parallel(thunks)` — run many agents concurrently, await all
|
||||
- `pipeline(items, ...stages)` — push items through stages
|
||||
- `phase(name)` — label progress for the dashboard
|
||||
- `human(config)` — pause and wait for a person
|
||||
|
||||
Here's a real flow. It reviews a code route change with parallel researchers and a human gate. Ten lines.
|
||||
|
||||
```js
|
||||
// .pi/flows/flows/review-routes.flow.mjs
|
||||
export const meta = { name: "review-routes", description: "audit routes for missing auth" };
|
||||
export default async (flow) => {
|
||||
const { agent, parallel, phase, human, task } = flow;
|
||||
phase("find");
|
||||
const findings = await parallel(["auth", "input"].map((d) => () =>
|
||||
agent(`Review ${d}: ${task}`, { agent: "researcher", model: "@planning" })
|
||||
));
|
||||
phase("review");
|
||||
const gate = await human({ title: "Eyeball it", prompt: "anything to fix before I finish?" });
|
||||
return { findings, gate };
|
||||
};
|
||||
```
|
||||
|
||||
Why JavaScript wins is boring and fundamental: it has `while`, `if`, `try/catch`, and `parallel(thunks)` built in. The things our YAML needed custom schema types to fake are just language keywords. Bounded concurrency is a one-liner. Error recovery is a `try` block. A loop is `while (!approved)`. No plugin, no RFC, no new node type.
|
||||
|
||||
We migrated all flows YAML-to-JS on 2026-06-10. One-way conversion script, every flow reviewed and running in 24 hours. The YAML parser was deleted — not deprecated, not kept for backwards compatibility, deleted. There's no config path left to reach for.
|
||||
|
||||
The plan lives in code, not config. Config is for things that don't change. Agent orchestration changes every run.
|
||||
|
||||
## A Flow IS a Session
|
||||
|
||||
The old model had a phantom problem. A flow was a card. A session was a separate card. The operator watched the flow run from a different window. There was a "New Flow" button that created a flow card, and a "Continue" button that attached a session to it, and the disconnect between "the thing running your work" and "the place you talk to it" was baked into the UI.
|
||||
|
||||
We killed that architecture. Every spawn is a session.
|
||||
|
||||
When you call `POST /api/flows/spawn {cwd, task, flowName}`, the session runs the flow inside itself with the `flow_run` tool. Steps stream inline into the chat — `flow:steps` injects progress into the session's own message stream. The session turns purple in the dashboard. It becomes the flow. One card. One identity. Persistent after the run finishes.
|
||||
|
||||
No "New Flow" button. No "Continue" button. You spawn a session; with a `flowName` it runs that flow, without one it opens an interactive operator session that designs a flow with you first. The dashboard branding is tinqs Studio. The control surface is the host card, live agent cards, run history, and a chat to steer the run.
|
||||
|
||||
There's no phantom card. No disconnect between "the thing running your work" and "the place you talk to it." It's one session. You're in the room.
|
||||
|
||||
## The Human Gate: Pause, Take Over, Approve, Continue
|
||||
|
||||
Agents make mistakes. They guess when they shouldn't. They take irreversible actions because the prompt said "proceed." The model gets stuck and you sit there wondering — do I wait or abort?
|
||||
|
||||
`flow.human()` is our answer.
|
||||
|
||||
When a flow hits a human gate, it stops. The dashboard shows the gate prompt: what to review, what to decide. The host session switches to takeover mode — coding tools are unblocked (normally the host is hands-off) and the system prompt becomes "flow is paused, help the operator finish this." You open files. You edit. You verify. You run commands.
|
||||
|
||||
To release the gate, reply `approve` or `done` or `lgtm`. The flow resumes. Any other message is a work instruction — the takeover session executes it but does not release the gate. The flow loops on `notes` until the human says go.
|
||||
|
||||
```js
|
||||
let approved = false;
|
||||
while (!approved) {
|
||||
const { notes } = await human({
|
||||
title: "Review before push",
|
||||
prompt: "Check the diff. Approve or tell me what to fix.",
|
||||
});
|
||||
if (notes.match(/^(approve|done|lgtm|looks good)/i)) approved = true;
|
||||
else await agent(`Fix: ${notes}`, { agent: "implementer" });
|
||||
}
|
||||
```
|
||||
|
||||
Two patterns this enables. First: review-approve-before-push gates — nobody ships untested code because nobody set the `auto-approve` flag to true. Second: the "agent is stuck" hand-off — the flow pauses, you take over the exact same workspace, fix the problem, type `continue`, and the flow keeps going.
|
||||
|
||||
The flow waits instead of guessing. This isn't a feature. It's an admission that some decisions shouldn't be automated.
|
||||
|
||||
## The Operator Is Your Co-Pilot
|
||||
|
||||
The old way was a one-shot generator. Paste an objective, click Generate, get a YAML blob, pray it's right, run it, discover it's wrong 20 minutes in with no way to steer. We'd watch flows fail and think "I could have told it that before it started."
|
||||
|
||||
The new flow operator doesn't write the flow for you and walk away. It designs it with you.
|
||||
|
||||
Hit New Flow. A DeepSeek session opens — the same model that powers the dashboard, cheap at $0.28/MTok, steerable in natural language. It proposes a draft `.flow.mjs`, shows you the agents and phases and any human gate, and explains why. You tell it what to change. It does NOT launch until you say go. When you approve, it writes the flow file and spawns a separate host session, then attaches to monitor and report progress.
|
||||
|
||||
The operator is still in the chat when the human gate fires. It's still there when you want to change the plan mid-run. It doesn't go away after launch. Co-pilot, not autopilot.
|
||||
|
||||
There are three runner faces for the same engine: **pi/dashboard** (DeepSeek, cheap, steerable — the default), **Claude Code** (Workflow tool, one-shot fan-out for heavy research), and a **cloud agent** (remote deploy, clone, AWS). Pick by granularity and cost. The flow file is the same in all three modes.
|
||||
|
||||
## What We Learned
|
||||
|
||||
**Numbers first.** 43 out of 43 unit tests green. All flows migrated. The supervisor inbox — steering messages sent between steps — was silently dropping operator messages before 2026-06-10. You'd type "focus on the auth routes" and the flow never saw it. That's fixed now. Chat reaches the inbox, the inbox drains between `agent()` calls, and steering works.
|
||||
|
||||
**The inbox rule.** The supervisor inbox is applied between `agent()` calls, never mid-step. Steering mid-step is undefined behaviour. We learned this the hard way — early versions tried to inject mid-agent and got corrupted state, partial outputs, agents that forgot what they were doing. Between steps is the right boundary. Respect it.
|
||||
|
||||
**Economics matter.** DeepSeek V4 Pro at $0.28/MTok runs per-step. Per-step model override lets you swap in a premium reasoning model ($15/MTok) for the one critical call that needs it. $0.28 for routine, $15 for the hard parts. The three-tier strategy from our agent daemon applies at flow granularity too.
|
||||
|
||||
**What's next.** Richer on-card flow display — a pinned step strip so you can see progress without opening the session. Attachable asset and agent-structure viewers in the flow card. Run replay for finished sessions after a page reload (the session persists, but you can't rewatch the stream yet).
|
||||
|
||||
But the principle is settled. A flow isn't a pipeline. A pipeline runs blind and reports back later. A flow is a pair-programming session where one of the pair happens to be code.
|
||||
|
||||
---
|
||||
|
||||
*[Tinqs Studio](https://tinqs.com) is our agent-native development platform — git hosting, AI agents, and the flow engine described here. [Ariki](https://arikigame.com) is the survival colony sim we're building with it.*
|
||||
@@ -0,0 +1,112 @@
|
||||
---
|
||||
title: "GPU-Skinned Herds: One Draw Call for 1,000 Animated Characters in Godot"
|
||||
slug: gpu-skinned-herds
|
||||
date: "2026-06-14"
|
||||
description: "Godot has no built-in way to render 1,000 skinned characters in one draw call. We built a GPU skinned-instance renderer into Tinqs Engine that does — 25 crocodiles verified, 1,000+ projected. Pre-built binaries for macOS and Windows."
|
||||
og_description: "One draw call, 1,000 animated characters. GPU-skinned herd renderer built into the Tinqs Engine fork of Godot."
|
||||
og_image: "https://www.tinqs.com/img/og-cover.jpg"
|
||||
excerpt: "Godot can't batch-render 1,000 animated characters. We built a GPU skinned-instance herd renderer into the engine itself — already driving crocodile herds in Ariki. Pre-built editor binaries for macOS and Windows."
|
||||
author: "Ozan Bozkurt"
|
||||
author_initials: "OB"
|
||||
author_role: "CTO & Developer, Tinqs"
|
||||
---
|
||||
Godot gives you one `Skeleton3D` per character. Want 200 animals in a herd? That's 200 skeleton nodes, 200 draw calls, and 200 `AnimationPlayer` ticks every frame. Want 1,000? Now you're measuring in seconds per frame, not frames per second.
|
||||
|
||||
We built a GPU skinned-instance renderer into Tinqs Engine that packs every pose into a single texture, uploads once, and draws every instance in one call. 25 crocodiles on screen right now. 1,000+ projected. Same bone count, same animation fidelity — a tiny fraction of the cost.
|
||||
|
||||
## Why the engine needs to change
|
||||
|
||||
The standard Godot approach — one `Skeleton3D` + one `MeshInstance3D` per character — works for a handful of animated entities. It breaks down hard at crowd scale:
|
||||
|
||||
- **CPU bone transforms.** Computing `global_pose` for 200 skeletons × 100 bones each = 20,000 matrix multiplies per frame, all on the main thread.
|
||||
- **Draw call explosion.** Each `MeshInstance3D` is its own draw call. Even with MultiMesh, there's no built-in path for skinned meshes — `MultiMeshInstance3D` only handles static geometry.
|
||||
- **AnimationPlayer sprawl.** Each skeleton needs its own `AnimationPlayer` and its own `process()` tick.
|
||||
|
||||
The alternative — baking animations to vertex textures — works for static crowds but locks you out of per-instance variation. No blending, no phase offsets, no reactive behaviour.
|
||||
|
||||
What we need is simpler: **share the skeleton, drive per-instance poses from a single animation, batch the draw call.** That's what `agent_skinned` does.
|
||||
|
||||
## How it works: two classes, one texture
|
||||
|
||||
The module lives in `modules/agent_skinned/` inside [Tinqs Engine](https://tinqs.com/tinqs/engine). Two classes, one job:
|
||||
|
||||
### `MultiSkinnedMeshInstance3D` — the data plane
|
||||
|
||||
Holds the CPU-side bone matrices. Allocates an `ImageTexture` of size `[4 × max_bones, max_instances]` in RGBA32F — each texel is one column of a 4×4 bone matrix. For a 130-bone crocodile with 256 instances:
|
||||
|
||||
```
|
||||
Texture: 520 × 256 RGBA32F ≈ 2 MB
|
||||
```
|
||||
|
||||
That's the entire pose state for 256 animated crocodiles in a single GPU texture. The API is simple:
|
||||
|
||||
```gdscript
|
||||
var data := MultiSkinnedMeshInstance3D.new()
|
||||
data.set_mesh(crocodile_mesh)
|
||||
data.set_skeleton(skeleton) # rest pose + bone hierarchy
|
||||
data.set_max_instances(256)
|
||||
data.set_max_bones(130)
|
||||
|
||||
# Each frame: push poses from the animated skeleton
|
||||
for instance in herd_positions:
|
||||
data.set_instance_pose_bones(instance.id, bone_transforms)
|
||||
data.update() # upload only dirty instances, not the whole texture
|
||||
```
|
||||
|
||||
### `MultiSkinnedInstance3D` — the renderer
|
||||
|
||||
A `MultiMeshInstance3D` subclass. Set its multimesh with the skinned mesh and instance transforms, point it at the data plane, call `refresh()` — it uploads the bone texture into the shader material's `bone_matrices_tex` uniform and the mesh is drawn in one call.
|
||||
|
||||
The shader does 4-bone linear-blend skinning on the GPU:
|
||||
|
||||
```glsl
|
||||
mat4 get_bone(int b) {
|
||||
return mat4(
|
||||
texelFetch(bone_matrices_tex, ivec2(b * 4 + 0, INSTANCE_ID), 0),
|
||||
texelFetch(bone_matrices_tex, ivec2(b * 4 + 1, INSTANCE_ID), 0),
|
||||
texelFetch(bone_matrices_tex, ivec2(b * 4 + 2, INSTANCE_ID), 0),
|
||||
texelFetch(bone_matrices_tex, ivec2(b * 4 + 3, INSTANCE_ID), 0)
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
`INSTANCE_ID` is a Godot built-in — the GPU already knows which instance it's rendering. We just use it to index into the bone texture. No uniform arrays, no SSBOs, no compute shaders. Just a 2D texture and a custom vertex shader.
|
||||
|
||||
## Two bugs we shipped and fixed
|
||||
|
||||
The module had data-plane doctests from day one — round-trip pose get/set, dirty tracking, size clamping, AABB. All green. Then we put it on screen for the first time and the crocodiles looked... wrong.
|
||||
|
||||
**Bug 1: Shader compile failure.** The default skinning shader compared `TANGENT` as `vec4`. Godot 4 exposes it as `vec3`. Fixed in one line, added `albedo_tex` uniform so herds texture out of the box.
|
||||
|
||||
**Bug 2: Bone matrices stored transposed.** The data plane wrote basis rows (standard Godot `Transform3D.basis` is row-major), but the shader unpacked as columns. Every bone matrix was transposed — the mesh crumpled. Not a scale bug, not an orientation bug — a layout mismatch. Fixed by storing column-major, with a doctest to prevent regression.
|
||||
|
||||
The lesson: doctests catch logic. Rendering catches truth. You need both.
|
||||
|
||||
## What's driving it
|
||||
|
||||
In [Ariki](https://www.arikigame.com), the sim tracks animal migration across a 12km archipelago. `AnimalHerdRenderer.cs` groups sim `ViewerState.animals` by type, feeds positions to `skinned_herd.gd` (a reusable per-type herd backend), which drives the renderer. One `AnimationPlayer` animates a single driver skeleton; poses propagate to every instance.
|
||||
|
||||
The crocodile herd scene is 25 instances, one draw call. The same pipeline projects to 200–1,000 before the GPU budget even notices.
|
||||
|
||||
## What's deliberately not here
|
||||
|
||||
- **No C# wrapper.** Instantiate from GDScript via `ClassDB.instantiate()` — the binding surface is small and stable.
|
||||
- **No automatic `AnimationPlayer` integration.** You drive poses. We give you the texture. Freedom to animate however you want.
|
||||
- **No GPU occlusion or LOD.** That's the game's job. The engine provides the tool; the game decides what to draw.
|
||||
|
||||
## Get the build
|
||||
|
||||
Pre-built editor binaries with `agent_skinned` baked in — no engine compile required:
|
||||
|
||||
| Platform | Binary | Engine commit |
|
||||
|----------|--------|---------------|
|
||||
| **macOS ARM64** | [`tinqs.macos.editor.arm64.mono`](https://tinqs.com/tinqs/builds/media/branch/main/engine/macos-arm64/tinqs.macos.editor.arm64.mono) | `4fe1323` (4.6.4, Xcode 26.3) |
|
||||
| **Windows x64** | [`tinqs.windows.editor.x86_64.mono.exe`](https://tinqs.com/tinqs/builds/media/branch/main/engine/windows-x64/tinqs.windows.editor.x86_64.mono.exe) | `64fb5cc` (4.6.4, MSVC 2022) |
|
||||
|
||||
All builds live in the public [`tinqs/builds`](https://tinqs.com/tinqs/builds) repo — engine source is private, but the binaries are yours. See [`manifest.json`](https://tinqs.com/tinqs/builds/src/branch/main/manifest.json) for checksums and build details.
|
||||
|
||||
The engine source lives in [`tinqs/engine`](https://tinqs.com/tinqs/engine) (private). Module docs: `modules/agent_skinned/README.md` and `.agents/wiki/agent-skinned-gpu-herd.md`.
|
||||
|
||||
---
|
||||
|
||||
**Related:** [Fork, Don't Build](fork-dont-build) — why we modify existing platforms instead of building new ones. [Streaming a 12km Archipelago in Godot 4](godot-optimisation) — the terrain and vegetation streaming layers that work alongside this.
|
||||
+81
-50
@@ -262,33 +262,45 @@
|
||||
<a href="/blog/" class="post__back">← All Posts</a>
|
||||
<span class="post__date">25 May 2026</span>
|
||||
<h1 class="post__title">A Pre-Commit Agent That Guards Your Secrets for $0.001</h1>
|
||||
<p class="post__lead">Every small team has the same problem: too many things to remember before <code>git commit</code>. Don't leak API keys. Don't reference the classified AI codename in public posts. Don't link to GitHub repos we deleted six months ago. Don't push a blog post with a 90-character title.</p>
|
||||
<p class="post__lead">Every small team has the same problem: too many things to remember before <code>git commit</code>. Don't leak API keys. Don't reference the classified AI codename in public posts. Don't link to GitHub repos we deleted six months ago. Don't push a blog post with a 90-character title.
|
||||
|
||||
<div class="post__body">
|
||||
<p>A checklist in the README doesn't work. Humans skip checklists. Code review catches some issues but not all — reviewers focus on logic, not whether a URL points to a deleted org.</p>
|
||||
<p>We built a pre-commit hook with two layers: a regex blocklist that's instant and free, and an LLM review that costs $0.001. Together they catch everything.</p>
|
||||
<h2>Layer 1: Regex blocklist (0ms, $0.00)</h2>
|
||||
<p>A text file of patterns, each tagged with scope and message:</p>
|
||||
<pre><code>public|\b<internal-codename>\b|Classified codename — use the public-facing alias
|
||||
A checklist in the README doesn't work. Humans skip checklists. Code review catches some issues but not all — reviewers focus on logic, not whether a URL points to a deleted org.
|
||||
|
||||
We built a pre-commit hook with two layers: a regex blocklist that's instant and free, and an LLM review that costs $0.001. Together they catch everything.
|
||||
|
||||
## Layer 1: Regex blocklist (0ms, $0.00)
|
||||
|
||||
A text file of patterns, each tagged with scope and message:
|
||||
|
||||
``<code>
|
||||
public|\b<internal-codename>\b|Classified codename — use the public-facing alias
|
||||
all|github\.com/(tinqs-ltd|tinqs)/|GitHub repos deleted — use tinqs.com
|
||||
all|sk-[a-zA-Z0-9]{20,}|Possible API key leaked
|
||||
all|AKIA[A-Z0-9]{16}|AWS access key leaked
|
||||
public|admin\.<internal-domain>|Internal admin URL in public content</code></pre>
|
||||
<p>The scope field controls where patterns apply. <code>all</code> means every file. <code>public</code> means only public-facing content — blog posts, website, marketing pages. We <em>want</em> classified codenames in internal architecture docs. We just don't want them in blog posts.</p>
|
||||
<p>The blocklist runs grep against the staged diff. No network call, no API, no latency. Match found → commit blocked immediately with file path and explanation. This catches 80% of issues before the LLM wakes up.</p>
|
||||
<h2>Layer 2: DeepSeek V4 Flash review (~4s, $0.001)</h2>
|
||||
<p>If the commit touches public-facing files, the hook sends the staged diff to DeepSeek V4 Flash. The system prompt tells it exactly what to check:</p>
|
||||
<ul>
|
||||
<li><strong>Leaked secrets</strong> — API keys, tokens, credentials the regex might have missed</li>
|
||||
<li><strong>Classified terms</strong> — codenames not yet in the blocklist</li>
|
||||
<li><strong>Internal URLs</strong> — references to services that shouldn't be public</li>
|
||||
<li><strong>Blog quality</strong> — title length, meta description, slug consistency</li>
|
||||
<li><strong>Broken links</strong> — malformed URLs, obvious typos</li>
|
||||
<li><strong>Announcements</strong> — if it's a new blog post, draft a one-line summary</li>
|
||||
</ul>
|
||||
<p>The model responds with structured JSON: <code>errors</code> (block) or <code>warnings</code> (inform but allow). If the API is unreachable or times out, the commit proceeds — the hook never blocks work for infrastructure reasons.</p>
|
||||
<h2>The architecture</h2>
|
||||
<pre><code>git commit
|
||||
public|admin\.<internal-domain>|Internal admin URL in public content
|
||||
</code>`<code>
|
||||
|
||||
The scope field controls where patterns apply. </code>all<code> means every file. </code>public<code> means only public-facing content — blog posts, website, marketing pages. We <em>want</em> classified codenames in internal architecture docs. We just don't want them in blog posts.
|
||||
|
||||
The blocklist runs grep against the staged diff. No network call, no API, no latency. Match found → commit blocked immediately with file path and explanation. This catches 80% of issues before the LLM wakes up.
|
||||
|
||||
## Layer 2: DeepSeek V4 Flash review (~4s, $0.001)
|
||||
|
||||
If the commit touches public-facing files, the hook sends the staged diff to DeepSeek V4 Flash. The system prompt tells it exactly what to check:
|
||||
|
||||
- <strong>Leaked secrets</strong> — API keys, tokens, credentials the regex might have missed
|
||||
- <strong>Classified terms</strong> — codenames not yet in the blocklist
|
||||
- <strong>Internal URLs</strong> — references to services that shouldn't be public
|
||||
- <strong>Blog quality</strong> — title length, meta description, slug consistency
|
||||
- <strong>Broken links</strong> — malformed URLs, obvious typos
|
||||
- <strong>Announcements</strong> — if it's a new blog post, draft a one-line summary
|
||||
|
||||
The model responds with structured JSON: </code>errors<code> (block) or </code>warnings<code> (inform but allow). If the API is unreachable or times out, the commit proceeds — the hook never blocks work for infrastructure reasons.
|
||||
|
||||
## The architecture
|
||||
|
||||
</code>`<code>
|
||||
git commit
|
||||
↓
|
||||
Phase 0: Collect staged diff + classify files (public vs internal)
|
||||
↓
|
||||
@@ -304,33 +316,52 @@ Phase 3: Parse JSON response
|
||||
→ Errors → BLOCK
|
||||
→ Warnings → print, exit 0
|
||||
→ Announcement → print draft
|
||||
→ API failure → warn, exit 0 (never block on infra)</code></pre>
|
||||
<p>The hook lives in <code>.githooks/</code> — committed, version-controlled, shared by the team. A setup script points <code>git config core.hooksPath</code> there.</p>
|
||||
<h2>What it costs</h2>
|
||||
<p>| | Tokens | Cost |</p>
|
||||
<p>|–|——–|——|</p>
|
||||
<p>| Input (prompt + diff) | ~4,000 | $0.00056 |</p>
|
||||
<p>| Output (JSON response) | ~200 | $0.00006 |</p>
|
||||
<p>| <strong>Per commit</strong> | | <strong>$0.00062</strong> |</p>
|
||||
<p>A tenth of a cent. Twenty commits a day: $0.012/day. About <strong>$0.40/month</strong>. Commits that only touch internal files skip the AI review entirely — zero cost.</p>
|
||||
<h2>What it caught (first week)</h2>
|
||||
<ul>
|
||||
<li><strong>2 classified codename leaks</strong> in draft blog posts — caught by blocklist</li>
|
||||
<li><strong>1 GitHub URL</strong> from an old copy-paste — caught by blocklist</li>
|
||||
<li><strong>3 blog SEO warnings</strong> — titles over 60 chars, missing og_description — caught by AI</li>
|
||||
<li><strong>1 announcement draft</strong> auto-generated when a new post was committed</li>
|
||||
</ul>
|
||||
<p>Zero false positives on the blocklist. Two false positives from the AI — flagged an internal URL in a code example that was clearly illustrative. We added a note to the prompt: ignore URLs inside fenced code blocks.</p>
|
||||
<h2>Setup</h2>
|
||||
<pre><code class="language-bash">bash scripts/setup-hooks.sh # or .\scripts\setup-hooks.ps1 on Windows
|
||||
export TINQS_HOOK_TOKEN=<your-token> # same PAT used for git push</code></pre>
|
||||
<p>That's it. Every <code>git commit</code> runs the two-layer review. Bypass with <code>git commit –no-verify</code> for emergencies.</p>
|
||||
<h2>The pattern: guard rails at the edge</h2>
|
||||
<p>This is the same principle we apply everywhere: put the guard rail where the action happens. Don't rely on a human checklist. Don't wait for code review. Don't hope someone remembers.</p>
|
||||
<p>The pre-commit hook is $0.001 of prevention. A leaked API key in a public post is hours of rotation, revocation, and audit. A classified codename in a blog post is a confidentiality breach. A dead link is a broken experience nobody notices for weeks.</p>
|
||||
<p>The tools exist. DeepSeek V4 Flash is cheap enough to call on every commit. The hook is 150 lines of bash. The blocklist is a text file. Total infrastructure cost: zero — it runs on the developer's machine, calls an API we already pay for, adds 4 seconds to the commit flow.</p>
|
||||
<hr>
|
||||
<p><em>The pre-commit hook is part of <a href="https://tinqs.com" style="color: var(–c-accent-l);">Tinqs Studio</a>. The inference proxy, blocklist patterns, and review prompt are open and reusable. Every commit in <a href="https://arikigame.com" style="color: var(–c-accent-l);">Ariki</a> runs through the same guard.</em></p>
|
||||
→ API failure → warn, exit 0 (never block on infra)
|
||||
</code>`<code>
|
||||
|
||||
The hook lives in </code>.githooks/<code> — committed, version-controlled, shared by the team. A setup script points </code>git config core.hooksPath<code> there.
|
||||
|
||||
## What it costs
|
||||
|
||||
| | Tokens | Cost |
|
||||
|–|——–|——|
|
||||
| Input (prompt + diff) | ~4,000 | $0.00056 |
|
||||
| Output (JSON response) | ~200 | $0.00006 |
|
||||
| <strong>Per commit</strong> | | <strong>$0.00062</strong> |
|
||||
|
||||
A tenth of a cent. Twenty commits a day: $0.012/day. About <strong>$0.40/month</strong>. Commits that only touch internal files skip the AI review entirely — zero cost.
|
||||
|
||||
## What it caught (first week)
|
||||
|
||||
- <strong>2 classified codename leaks</strong> in draft blog posts — caught by blocklist
|
||||
- <strong>1 GitHub URL</strong> from an old copy-paste — caught by blocklist
|
||||
- <strong>3 blog SEO warnings</strong> — titles over 60 chars, missing og_description — caught by AI
|
||||
- <strong>1 announcement draft</strong> auto-generated when a new post was committed
|
||||
|
||||
Zero false positives on the blocklist. Two false positives from the AI — flagged an internal URL in a code example that was clearly illustrative. We added a note to the prompt: ignore URLs inside fenced code blocks.
|
||||
|
||||
## Setup
|
||||
|
||||
</code>`<code>bash
|
||||
bash scripts/setup-hooks.sh # or .\scripts\setup-hooks.ps1 on Windows
|
||||
export TINQS_HOOK_TOKEN=<your-token> # same PAT used for git push
|
||||
</code>`<code>
|
||||
|
||||
That's it. Every </code>git commit<code> runs the two-layer review. Bypass with </code>git commit –no-verify` for emergencies.
|
||||
|
||||
## The pattern: guard rails at the edge
|
||||
|
||||
This is the same principle we apply everywhere: put the guard rail where the action happens. Don't rely on a human checklist. Don't wait for code review. Don't hope someone remembers.
|
||||
|
||||
The pre-commit hook is $0.001 of prevention. A leaked API key in a public post is hours of rotation, revocation, and audit. A classified codename in a blog post is a confidentiality breach. A dead link is a broken experience nobody notices for weeks.
|
||||
|
||||
The tools exist. DeepSeek V4 Flash is cheap enough to call on every commit. The hook is 150 lines of bash. The blocklist is a text file. Total infrastructure cost: zero — it runs on the developer's machine, calls an API we already pay for, adds 4 seconds to the commit flow.
|
||||
|
||||
—
|
||||
|
||||
<em>The pre-commit hook is part of <a href="https://tinqs.com" style="color: var(--c-accent-l);">Tinqs Studio</a>. The inference proxy, blocklist patterns, and review prompt are open and reusable. Every commit in <a href="https://arikigame.com" style="color: var(--c-accent-l);">Ariki</a> runs through the same guard.</em></p>
|
||||
|
||||
<div class="post__body">
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
Before
After
|
Binary file not shown.
|
After Width: | Height: | Size: 518 KiB |
+56
-36
@@ -262,44 +262,64 @@
|
||||
<a href="/blog/" class="post__back">← All Posts</a>
|
||||
<span class="post__date">18 May 2026</span>
|
||||
<h1 class="post__title">One Binary to Rule Them All: Our Studio CLI</h1>
|
||||
<p class="post__lead">Every AI agent session starts the same way: cold. The agent doesn't know what project this is, who's asking, what tools are available, or what happened yesterday. You spend the first five minutes re-explaining context.</p>
|
||||
<p class="post__lead">Every AI agent session starts the same way: cold. The agent doesn't know what project this is, who's asking, what tools are available, or what happened yesterday. You spend the first five minutes re-explaining context.
|
||||
|
||||
Our CLI solves this in 100ms. One command — <code>tinqs identity</code> — and the agent knows everything. The binary is 15MB, has zero runtime dependencies, and runs on every machine in the studio.
|
||||
|
||||
## The identity command (100ms)
|
||||
|
||||
When an agent starts, the first thing it calls is <code>tinqs identity</code>. The output:
|
||||
|
||||
- <strong>Soul file</strong> — the agent's persistent identity, values, operating principles
|
||||
- <strong>Company context</strong> — team members, roles, what the company does
|
||||
- <strong>Machine context</strong> — hostname, OS, which repos are cloned, what services are running
|
||||
- <strong>Ecosystem</strong> — other repos and their purpose
|
||||
- <strong>Service status</strong> — which URLs are live and reachable
|
||||
|
||||
This data lives in markdown files in the docs repo. Any machine on the network can read it. The agent goes from blank to fully contextual in under a second.
|
||||
|
||||
This started as a convenience tool for humans. It became the single most important function in our stack. Every agent session — Cursor, Claude Code, Pi — starts with <code>tinqs identity</code>. Without it, every conversation begins with "let me explain the project." With it, the agent already knows.
|
||||
|
||||
## Screenshots and cloud vision
|
||||
|
||||
The CLI can capture any window from outside the process. No in-game overlay, no rendering pipeline integration. OS-level capture — GDI+ on Windows, screencapture on Mac.
|
||||
|
||||
A <code>photo</code> command sends the screenshot to a cloud vision model. The agent says "take a photo of the game" and gets back: "The player character is standing near a half-built hut. Three palm trees to the left. The terrain has a visible seam between two biomes."
|
||||
|
||||
This is how you file bugs without typing. Look at the game, tell the agent what's wrong. It takes a screenshot, describes what it sees, and creates an issue with both the description and the image attached. Keyboard-free bug reporting.
|
||||
|
||||
## Health checks
|
||||
|
||||
<code>tinqs doctor</code> runs a comprehensive check:
|
||||
|
||||
- Is the git platform reachable and authenticated?
|
||||
- Is the game server running?
|
||||
- Are all expected repos cloned and on the right branch?
|
||||
- Are required tools installed at the right version?
|
||||
|
||||
Output is a green/yellow/red table. Essential for unattended agent sessions — the agent verifies its environment before starting work. No "the build failed because port 3000 was already taken" at 3am.
|
||||
|
||||
## Why Go
|
||||
|
||||
Go compiles to a single static binary. No Python virtualenvs, no Node.js version managers, no DLL hell on Windows. The same binary runs on a gaming PC, a designer's MacBook, and a CI runner in AWS.
|
||||
|
||||
Cross-compilation is trivial. We build Windows, Mac (arm64 + amd64), and Linux binaries from a single CI workflow. Push a tag, CI builds all three, uploads to S3. The binary is 15MB, starts in under 100ms, has zero runtime dependencies.
|
||||
|
||||
## What we learned
|
||||
|
||||
<strong>The CLI is the API for AI agents.</strong> What started as a human convenience tool became the primary interface for agents. Every session starts with <code>tinqs identity</code>. The agent's "hands and eyes" — screenshots, vision, health checks — are subcommands of the same binary.
|
||||
|
||||
<strong>One binary beats ten scripts.</strong> Scripts rot. They have different shells, different PATH assumptions, different error handling. A compiled binary either works or it doesn't. It ships with dependencies baked in. It doesn't care if your Python is 3.9 or 3.12.
|
||||
|
||||
<strong>Cloud vision is underrated for game dev.</strong> Sending a screenshot to a vision model sounds gimmicky. In practice, it's the fastest way to document visual bugs. "The tree is floating 2m above the terrain" is much faster to communicate when the AI is looking at the same screen.
|
||||
|
||||
<strong>Agent cold starts are the real problem.</strong> Without the identity system, every session starts with the agent asking "what project is this?" With it, the agent knows everything in 100ms. That's the difference between an AI assistant and an AI team member.
|
||||
|
||||
—
|
||||
|
||||
<em>The CLI is part of <a href="https://tinqs.com" style="color: var(--c-accent-l);">Tinqs Studio</a>. Every time we find ourselves about to write a script that needs to work on multiple machines, we add a subcommand instead. One binary that makes the studio work — whether the operator is human or AI.</em></p>
|
||||
|
||||
<div class="post__body">
|
||||
<p>Our CLI solves this in 100ms. One command — <code>tinqs identity</code> — and the agent knows everything. The binary is 15MB, has zero runtime dependencies, and runs on every machine in the studio.</p>
|
||||
<h2>The identity command (100ms)</h2>
|
||||
<p>When an agent starts, the first thing it calls is <code>tinqs identity</code>. The output:</p>
|
||||
<ul>
|
||||
<li><strong>Soul file</strong> — the agent's persistent identity, values, operating principles</li>
|
||||
<li><strong>Company context</strong> — team members, roles, what the company does</li>
|
||||
<li><strong>Machine context</strong> — hostname, OS, which repos are cloned, what services are running</li>
|
||||
<li><strong>Ecosystem</strong> — other repos and their purpose</li>
|
||||
<li><strong>Service status</strong> — which URLs are live and reachable</li>
|
||||
</ul>
|
||||
<p>This data lives in markdown files in the docs repo. Any machine on the network can read it. The agent goes from blank to fully contextual in under a second.</p>
|
||||
<p>This started as a convenience tool for humans. It became the single most important function in our stack. Every agent session — Cursor, Claude Code, Pi — starts with <code>tinqs identity</code>. Without it, every conversation begins with "let me explain the project." With it, the agent already knows.</p>
|
||||
<h2>Screenshots and cloud vision</h2>
|
||||
<p>The CLI can capture any window from outside the process. No in-game overlay, no rendering pipeline integration. OS-level capture — GDI+ on Windows, screencapture on Mac.</p>
|
||||
<p>A <code>photo</code> command sends the screenshot to a cloud vision model. The agent says "take a photo of the game" and gets back: "The player character is standing near a half-built hut. Three palm trees to the left. The terrain has a visible seam between two biomes."</p>
|
||||
<p>This is how you file bugs without typing. Look at the game, tell the agent what's wrong. It takes a screenshot, describes what it sees, and creates an issue with both the description and the image attached. Keyboard-free bug reporting.</p>
|
||||
<h2>Health checks</h2>
|
||||
<p><code>tinqs doctor</code> runs a comprehensive check:</p>
|
||||
<ul>
|
||||
<li>Is the git platform reachable and authenticated?</li>
|
||||
<li>Is the game server running?</li>
|
||||
<li>Are all expected repos cloned and on the right branch?</li>
|
||||
<li>Are required tools installed at the right version?</li>
|
||||
</ul>
|
||||
<p>Output is a green/yellow/red table. Essential for unattended agent sessions — the agent verifies its environment before starting work. No "the build failed because port 3000 was already taken" at 3am.</p>
|
||||
<h2>Why Go</h2>
|
||||
<p>Go compiles to a single static binary. No Python virtualenvs, no Node.js version managers, no DLL hell on Windows. The same binary runs on a gaming PC, a designer's MacBook, and a CI runner in AWS.</p>
|
||||
<p>Cross-compilation is trivial. We build Windows, Mac (arm64 + amd64), and Linux binaries from a single CI workflow. Push a tag, CI builds all three, uploads to S3. The binary is 15MB, starts in under 100ms, has zero runtime dependencies.</p>
|
||||
<h2>What we learned</h2>
|
||||
<p><strong>The CLI is the API for AI agents.</strong> What started as a human convenience tool became the primary interface for agents. Every session starts with <code>tinqs identity</code>. The agent's "hands and eyes" — screenshots, vision, health checks — are subcommands of the same binary.</p>
|
||||
<p><strong>One binary beats ten scripts.</strong> Scripts rot. They have different shells, different PATH assumptions, different error handling. A compiled binary either works or it doesn't. It ships with dependencies baked in. It doesn't care if your Python is 3.9 or 3.12.</p>
|
||||
<p><strong>Cloud vision is underrated for game dev.</strong> Sending a screenshot to a vision model sounds gimmicky. In practice, it's the fastest way to document visual bugs. "The tree is floating 2m above the terrain" is much faster to communicate when the AI is looking at the same screen.</p>
|
||||
<p><strong>Agent cold starts are the real problem.</strong> Without the identity system, every session starts with the agent asking "what project is this?" With it, the agent knows everything in 100ms. That's the difference between an AI assistant and an AI team member.</p>
|
||||
<hr>
|
||||
<p><em>The CLI is part of <a href="https://tinqs.com" style="color: var(–c-accent-l);">Tinqs Studio</a>. Every time we find ourselves about to write a script that needs to work on multiple machines, we add a subcommand instead. One binary that makes the studio work — whether the operator is human or AI.</em></p>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
Before
After
|
@@ -262,21 +262,28 @@
|
||||
<a href="/blog/" class="post__back">← All Posts</a>
|
||||
<span class="post__date">10 June 2026</span>
|
||||
<h1 class="post__title">Why Voice Is the Missing Input for Game Development</h1>
|
||||
<p class="post__lead">Every game developer knows this moment. You're playtesting, running through the world, and you see something wrong — a tree floating two meters above the terrain, a UI element clipping, an animation that stutters on frame 14. You make a mental note. Ten minutes later, back at the editor, you try to file it. The coordinates are fuzzy. The exact reproduction steps are gone. You type something vague like "tree floating on west beach maybe" and hope you remember more tomorrow.</p>
|
||||
<p class="post__lead">Every game developer knows this moment. You're playtesting, running through the world, and you see something wrong — a tree floating two meters above the terrain, a UI element clipping, an animation that stutters on frame 14. You make a mental note. Ten minutes later, back at the editor, you try to file it. The coordinates are fuzzy. The exact reproduction steps are gone. You type something vague like "tree floating on west beach maybe" and hope you remember more tomorrow.
|
||||
|
||||
<div class="post__body">
|
||||
<p>Voice changes this entirely. Speak the bug while you're looking at it, and an agent turns your words into a structured issue — with a screenshot, a vision-model description, coordinates, and a severity estimate. No keyboard. No context switch. No memory loss.</p>
|
||||
<h2>The latency that kills bug reports</h2>
|
||||
<p>The distance between seeing a bug and filing it is a memory decay curve. Every second that passes, your recollection loses precision:</p>
|
||||
<p>| Elapsed time | What you remember |</p>
|
||||
<p>|—|—|</p>
|
||||
<p>| 0 seconds | Exact position, camera angle, what you were doing, what's on screen |</p>
|
||||
<p>| 30 seconds | "There was a tree... somewhere west... maybe floating?" |</p>
|
||||
<p>| 5 minutes | "I think there was a rendering issue? Or was it yesterday?" |</p>
|
||||
<p>Typed bug reports are reconstructions from decaying memory. Voice bug reports are real-time captures. The difference in quality isn't marginal — it's the difference between a fix you can act on immediately and a ticket that sits in the backlog for three months while someone tries to reproduce it.</p>
|
||||
<h2>The pipeline: voice → text → structured issue</h2>
|
||||
<p>Here's what actually happens when you speak a bug during playtesting:</p>
|
||||
<pre><code>1. You speak: "There's a tree floating two meters above the terrain
|
||||
Voice changes this entirely. Speak the bug while you're looking at it, and an agent turns your words into a structured issue — with a screenshot, a vision-model description, coordinates, and a severity estimate. No keyboard. No context switch. No memory loss.
|
||||
|
||||
## The latency that kills bug reports
|
||||
|
||||
The distance between seeing a bug and filing it is a memory decay curve. Every second that passes, your recollection loses precision:
|
||||
|
||||
| Elapsed time | What you remember |
|
||||
|—|—|
|
||||
| 0 seconds | Exact position, camera angle, what you were doing, what's on screen |
|
||||
| 30 seconds | "There was a tree... somewhere west... maybe floating?" |
|
||||
| 5 minutes | "I think there was a rendering issue? Or was it yesterday?" |
|
||||
|
||||
Typed bug reports are reconstructions from decaying memory. Voice bug reports are real-time captures. The difference in quality isn't marginal — it's the difference between a fix you can act on immediately and a ticket that sits in the backlog for three months while someone tries to reproduce it.
|
||||
|
||||
## The pipeline: voice → text → structured issue
|
||||
|
||||
Here's what actually happens when you speak a bug during playtesting:
|
||||
|
||||
``<code>
|
||||
1. You speak: "There's a tree floating two meters above the terrain
|
||||
on the west beach, near the big rock formation. Happens after
|
||||
the vegetation culling pass kicks in around sunset."
|
||||
|
||||
@@ -294,39 +301,68 @@
|
||||
5. Agent files a structured issue with all of the above,
|
||||
tags the rendering engineer, and posts the digest to team chat.
|
||||
|
||||
Total latency: under 2 seconds. You keep playing.</code></pre>
|
||||
<p>This isn't theoretical. The pipeline runs on our own game project, and it's caught bugs that would have slipped through playtesting entirely — the ones you see, make a mental note about, and forget by the time you alt-tab.</p>
|
||||
<h2>Why game dev is the perfect voice use case</h2>
|
||||
<p><strong>You're already looking at the screen.</strong> Voice input doesn't require switching windows or breaking flow. You're playtesting — your hands are on the controller or WASD, your eyes are on the game. Speaking is the only input channel that doesn't interrupt the thing you're actually doing.</p>
|
||||
<p><strong>Game bugs are spatial and visual.</strong> "The crafting UI text overflows on items with names longer than 20 characters" is something you see, not something you calculate. Describing it verbally while looking at it produces a far richer bug report than typing from memory.</p>
|
||||
<p><strong>Reproduction is half the battle.</strong> When you speak the bug at the moment of occurrence, you naturally include the context: what you were doing, what just happened, what the game state was. You don't have to reconstruct it later.</p>
|
||||
<p><strong>Voice scales to the whole team.</strong> Artists see visual bugs. Designers see balance issues. Producers see UX friction. Not everyone on a game team is a fast typist or comfortable with issue trackers. Everyone can speak.</p>
|
||||
<h2>What the agent adds beyond transcription</h2>
|
||||
<p>Raw transcription is useful — it's a notepad you don't have to type. But the agent layer is what makes voice input a pipeline rather than a dictation tool:</p>
|
||||
<p><strong>Screenshot coordination.</strong> The agent calls the game engine's HTTP API, captures the current frame, and attaches it to the issue. You don't take screenshots. The agent does.</p>
|
||||
<p><strong>Vision model description.</strong> The screenshot goes through a vision model that writes a text description of what's on screen. Future-you searching the issue tracker for "floating tree" finds it even if the transcription was garbled.</p>
|
||||
<p><strong>Coordinates and context.</strong> The game engine provides the player's world position, camera angle, and current game state. The agent bakes these into the issue. A developer can teleport directly to the bug location.</p>
|
||||
<p><strong>Severity and routing.</strong> The agent estimates severity from context ("floating" is visual, "crash" is critical) and tags the right team member. An artist doesn't get pinged for a shader bug. A rendering engineer doesn't get pinged for a UI text overflow.</p>
|
||||
<h2>The numbers</h2>
|
||||
<p>| Method | Time from observation to filed issue | Information loss |</p>
|
||||
<p>|—|—|—|</p>
|
||||
<p>| Mental note → type later | 5-30 minutes | High (positions, steps, context) |</p>
|
||||
<p>| Alt-tab → type immediately | 30-60 seconds | Medium (screenshots missed, flow broken) |</p>
|
||||
<p>| Voice → agent pipeline | 2 seconds | Low (screenshot + position captured automatically) |</p>
|
||||
<p>The throughput difference compounds. A 30-minute playtest session with keyboard-only bug filing might yield 3-4 issues, half of them vague. The same session with voice-to-agent produces 10-15 issues, all with screenshots, positions, and reproduction context.</p>
|
||||
<h2>Setup is simpler than you think</h2>
|
||||
<p>You need three things, all of which you probably already have:</p>
|
||||
<p>1. <strong>A microphone.</strong> The one in your headset is fine. Transcription models handle suboptimal audio surprisingly well.</p>
|
||||
<p>2. <strong>Transcription.</strong> Whisper runs locally and is free. Cloud APIs are sub-cent per minute. Both work.</p>
|
||||
<p>3. <strong>An agent that speaks your game engine's API.</strong> If your engine has an HTTP interface for screenshots and game state, the agent can wire the rest together. If it doesn't — add one. It's a weekend project.</p>
|
||||
<p>The agent itself doesn't need to be custom-built. Any coding agent with tool access can be told "watch the game, transcribe voice input, file issues in the tracker." It's a skill file, not a product.</p>
|
||||
<h2>What changes when you stop typing bugs</h2>
|
||||
<p>The most surprising effect isn't the speed. It's the coverage. When filing a bug costs two seconds of speaking, you file bugs you would have previously ignored. The minor visual glitch. The slight animation hitch. The UI element that's two pixels misaligned.</p>
|
||||
<p>Individually these are low-priority. Collectively they're the difference between a game that feels polished and one that feels rough. And they only get caught when the cost of reporting approaches zero.</p>
|
||||
<p>The second effect is that playtesting becomes a primary input channel. Instead of structured QA sessions with checklists and forms, you just play the game. The agent captures everything. When you're done, you have a list of filed issues with screenshots and context — generated from your spoken observations in real time.</p>
|
||||
<p>Voice isn't a gimmick for game development. It's the input channel that matches the way we actually work — looking at the screen, noticing things, and talking about them. The tools exist. The latency is sub-second. The cost is negligible. The only thing missing is the habit.</p>
|
||||
<hr>
|
||||
<p><em>We build <a href="https://tinqs.com" style="color: var(–c-accent-l);">Tinqs Studio</a> — a game dev platform with built-in AI agents, git hosting, and creative pipelines. <a href="https://arikigame.com" style="color: var(–c-accent-l);">Ariki</a> is the survival colony sim we're building with every tool described here.</em></p>
|
||||
Total latency: under 2 seconds. You keep playing.
|
||||
</code>``
|
||||
|
||||
This isn't theoretical. The pipeline runs on our own game project, and it's caught bugs that would have slipped through playtesting entirely — the ones you see, make a mental note about, and forget by the time you alt-tab.
|
||||
|
||||
## Why game dev is the perfect voice use case
|
||||
|
||||
<strong>You're already looking at the screen.</strong> Voice input doesn't require switching windows or breaking flow. You're playtesting — your hands are on the controller or WASD, your eyes are on the game. Speaking is the only input channel that doesn't interrupt the thing you're actually doing.
|
||||
|
||||
<strong>Game bugs are spatial and visual.</strong> "The crafting UI text overflows on items with names longer than 20 characters" is something you see, not something you calculate. Describing it verbally while looking at it produces a far richer bug report than typing from memory.
|
||||
|
||||
<strong>Reproduction is half the battle.</strong> When you speak the bug at the moment of occurrence, you naturally include the context: what you were doing, what just happened, what the game state was. You don't have to reconstruct it later.
|
||||
|
||||
<strong>Voice scales to the whole team.</strong> Artists see visual bugs. Designers see balance issues. Producers see UX friction. Not everyone on a game team is a fast typist or comfortable with issue trackers. Everyone can speak.
|
||||
|
||||
## What the agent adds beyond transcription
|
||||
|
||||
Raw transcription is useful — it's a notepad you don't have to type. But the agent layer is what makes voice input a pipeline rather than a dictation tool:
|
||||
|
||||
<strong>Screenshot coordination.</strong> The agent calls the game engine's HTTP API, captures the current frame, and attaches it to the issue. You don't take screenshots. The agent does.
|
||||
|
||||
<strong>Vision model description.</strong> The screenshot goes through a vision model that writes a text description of what's on screen. Future-you searching the issue tracker for "floating tree" finds it even if the transcription was garbled.
|
||||
|
||||
<strong>Coordinates and context.</strong> The game engine provides the player's world position, camera angle, and current game state. The agent bakes these into the issue. A developer can teleport directly to the bug location.
|
||||
|
||||
<strong>Severity and routing.</strong> The agent estimates severity from context ("floating" is visual, "crash" is critical) and tags the right team member. An artist doesn't get pinged for a shader bug. A rendering engineer doesn't get pinged for a UI text overflow.
|
||||
|
||||
## The numbers
|
||||
|
||||
| Method | Time from observation to filed issue | Information loss |
|
||||
|—|—|—|
|
||||
| Mental note → type later | 5-30 minutes | High (positions, steps, context) |
|
||||
| Alt-tab → type immediately | 30-60 seconds | Medium (screenshots missed, flow broken) |
|
||||
| Voice → agent pipeline | 2 seconds | Low (screenshot + position captured automatically) |
|
||||
|
||||
The throughput difference compounds. A 30-minute playtest session with keyboard-only bug filing might yield 3-4 issues, half of them vague. The same session with voice-to-agent produces 10-15 issues, all with screenshots, positions, and reproduction context.
|
||||
|
||||
## Setup is simpler than you think
|
||||
|
||||
You need three things, all of which you probably already have:
|
||||
|
||||
1. <strong>A microphone.</strong> The one in your headset is fine. Transcription models handle suboptimal audio surprisingly well.
|
||||
2. <strong>Transcription.</strong> Whisper runs locally and is free. Cloud APIs are sub-cent per minute. Both work.
|
||||
3. <strong>An agent that speaks your game engine's API.</strong> If your engine has an HTTP interface for screenshots and game state, the agent can wire the rest together. If it doesn't — add one. It's a weekend project.
|
||||
|
||||
The agent itself doesn't need to be custom-built. Any coding agent with tool access can be told "watch the game, transcribe voice input, file issues in the tracker." It's a skill file, not a product.
|
||||
|
||||
## What changes when you stop typing bugs
|
||||
|
||||
The most surprising effect isn't the speed. It's the coverage. When filing a bug costs two seconds of speaking, you file bugs you would have previously ignored. The minor visual glitch. The slight animation hitch. The UI element that's two pixels misaligned.
|
||||
|
||||
Individually these are low-priority. Collectively they're the difference between a game that feels polished and one that feels rough. And they only get caught when the cost of reporting approaches zero.
|
||||
|
||||
The second effect is that playtesting becomes a primary input channel. Instead of structured QA sessions with checklists and forms, you just play the game. The agent captures everything. When you're done, you have a list of filed issues with screenshots and context — generated from your spoken observations in real time.
|
||||
|
||||
Voice isn't a gimmick for game development. It's the input channel that matches the way we actually work — looking at the screen, noticing things, and talking about them. The tools exist. The latency is sub-second. The cost is negligible. The only thing missing is the habit.
|
||||
|
||||
—
|
||||
|
||||
<em>We build <a href="https://tinqs.com" style="color: var(--c-accent-l);">Tinqs Studio</a> — a game dev platform with built-in AI agents, git hosting, and creative pipelines. <a href="https://arikigame.com" style="color: var(--c-accent-l);">Ariki</a> is the survival colony sim we're building with every tool described here.</em></p>
|
||||
|
||||
<div class="post__body">
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
Before
After
|
Reference in New Issue
Block a user