post: merge into single GPU-skinned herds article
This commit is contained in:
+35
-66
@@ -277,74 +277,43 @@
|
|||||||
<a href="/blog/" class="post__back">← All Posts</a>
|
<a href="/blog/" class="post__back">← All Posts</a>
|
||||||
<span class="post__date">25 May 2026</span>
|
<span class="post__date">25 May 2026</span>
|
||||||
<h1 class="post__title">What an Agent Harness Is and Why Game Dev Needs One</h1>
|
<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 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>
|
||||||
|
|
||||||
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-lime);">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-lime);">Ariki</a> with the same tools.</em></p>
|
|
||||||
|
|
||||||
<div class="post__body">
|
<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-lime);">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-lime);">Ariki</a> with the same tools.</em></p>
|
||||||
|
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
|||||||
|
Before
After
|
@@ -1,367 +0,0 @@
|
|||||||
<!DOCTYPE html>
|
|
||||||
<html lang="en">
|
|
||||||
<head>
|
|
||||||
<meta charset="UTF-8">
|
|
||||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
|
||||||
|
|
||||||
<title>Zero-CPU Crowd Animation: 1,000 Animals, One Draw Call, No Skeletons — Tinqs Blog</title>
|
|
||||||
<meta name="description" content="We built a GPU-driven crowd animation platform into Tinqs Engine that renders 1,000 animated animals at 60 FPS with zero per-frame CPU cost. Each agent plays its own clip, speed, and phase — no live skeletons, no lockstep, no compromises.">
|
|
||||||
<meta name="robots" content="index, follow">
|
|
||||||
<link rel="canonical" href="https://www.tinqs.com/blog/gpu-driven-crowd-animation">
|
|
||||||
|
|
||||||
<meta property="og:type" content="article">
|
|
||||||
<meta property="og:url" content="https://www.tinqs.com/blog/gpu-driven-crowd-animation">
|
|
||||||
<meta property="og:title" content="Zero-CPU Crowd Animation: 1,000 Animals, One Draw Call, No Skeletons">
|
|
||||||
<meta property="og:description" content="1,000 animated agents, zero live skeletons, zero per-frame CPU. A GPU-driven crowd animation platform in 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="Zero-CPU Crowd Animation: 1,000 Animals, One Draw Call, No Skeletons">
|
|
||||||
<meta name="twitter:description" content="1,000 animated agents, zero live skeletons, zero per-frame CPU. A GPU-driven crowd animation platform in 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": "Zero-CPU Crowd Animation: 1,000 Animals, One Draw Call, No Skeletons",
|
|
||||||
"datePublished": "2026-06-15",
|
|
||||||
"author": {
|
|
||||||
"@type": "Person",
|
|
||||||
"name": "Ozan Bozkurt"
|
|
||||||
},
|
|
||||||
"publisher": {
|
|
||||||
"@type": "Organization",
|
|
||||||
"name": "Tinqs Limited",
|
|
||||||
"url": "https://www.tinqs.com"
|
|
||||||
},
|
|
||||||
"description": "We built a GPU-driven crowd animation platform into Tinqs Engine that renders 1,000 animated animals at 60 FPS with zero per-frame CPU cost. Each agent plays its own clip, speed, and phase — no live skeletons, no lockstep, no compromises."
|
|
||||||
}
|
|
||||||
</script>
|
|
||||||
|
|
||||||
<link rel="preconnect" href="https://fonts.googleapis.com">
|
|
||||||
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
|
|
||||||
<link href="https://fonts.googleapis.com/css2?family=Space+Grotesk:wght@400;500;600;700&family=JetBrains+Mono:wght@400;500&family=Inter:wght@400;500;600;700&display=swap" rel="stylesheet">
|
|
||||||
|
|
||||||
<style>
|
|
||||||
/* ── Tinqs Studio brand — post styles ── */
|
|
||||||
|
|
||||||
:root {
|
|
||||||
/* Studio near-black base */
|
|
||||||
--c-bg: #0B0C0E;
|
|
||||||
--c-bg-raised: #15171A;
|
|
||||||
/* Foreground */
|
|
||||||
--c-fg: #ECEEF1;
|
|
||||||
--c-muted: #8A95A3;
|
|
||||||
/* Family accents */
|
|
||||||
--c-lime: #B6FF3C;
|
|
||||||
--c-violet: #7C5CFF;
|
|
||||||
/* Borders */
|
|
||||||
--c-border: rgba(255,255,255,.07);
|
|
||||||
--c-border-strong: rgba(255,255,255,.12);
|
|
||||||
}
|
|
||||||
|
|
||||||
*, *::before, *::after { box-sizing: border-box; }
|
|
||||||
|
|
||||||
html { background: var(--c-bg); }
|
|
||||||
|
|
||||||
body {
|
|
||||||
margin: 0;
|
|
||||||
padding: 0;
|
|
||||||
background: var(--c-bg);
|
|
||||||
color: var(--c-fg);
|
|
||||||
font-family: 'Inter', system-ui, -apple-system, sans-serif;
|
|
||||||
font-size: 16px;
|
|
||||||
line-height: 1.6;
|
|
||||||
-webkit-font-smoothing: antialiased;
|
|
||||||
}
|
|
||||||
|
|
||||||
/* ── Post container ── */
|
|
||||||
.post {
|
|
||||||
background: var(--c-bg);
|
|
||||||
max-width: 720px;
|
|
||||||
margin: 0 auto;
|
|
||||||
padding: 48px 24px 60px;
|
|
||||||
}
|
|
||||||
|
|
||||||
/* ── Back link ── */
|
|
||||||
.post__back {
|
|
||||||
color: var(--c-muted);
|
|
||||||
text-decoration: none;
|
|
||||||
font-size: 0.875rem;
|
|
||||||
display: inline-block;
|
|
||||||
margin-bottom: 24px;
|
|
||||||
transition: color 0.15s;
|
|
||||||
}
|
|
||||||
.post__back:hover { color: var(--c-lime); }
|
|
||||||
|
|
||||||
/* ── Gradient title — lime → violet ── */
|
|
||||||
.post__title {
|
|
||||||
font-family: 'Space Grotesk', system-ui, -apple-system, sans-serif;
|
|
||||||
background: linear-gradient(90deg, var(--c-lime), var(--c-violet));
|
|
||||||
-webkit-background-clip: text;
|
|
||||||
background-clip: text;
|
|
||||||
color: transparent;
|
|
||||||
font-weight: 700;
|
|
||||||
font-size: 2.2rem;
|
|
||||||
line-height: 1.2;
|
|
||||||
margin: 0 0 16px;
|
|
||||||
}
|
|
||||||
|
|
||||||
/* ── Date pill ── */
|
|
||||||
.post__date {
|
|
||||||
display: inline-block;
|
|
||||||
font-family: 'JetBrains Mono', ui-monospace, 'SF Mono', Consolas, monospace;
|
|
||||||
font-size: 0.72rem;
|
|
||||||
letter-spacing: 0.18em;
|
|
||||||
text-transform: uppercase;
|
|
||||||
color: var(--c-muted);
|
|
||||||
border: 1px solid var(--c-border);
|
|
||||||
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-family: 'Space Grotesk', system-ui, -apple-system, sans-serif;
|
|
||||||
font-weight: 600;
|
|
||||||
font-size: 1.6rem;
|
|
||||||
margin: 54px 0 6px;
|
|
||||||
padding-left: 16px;
|
|
||||||
border-left: 4px solid var(--c-lime);
|
|
||||||
line-height: 1.3;
|
|
||||||
}
|
|
||||||
|
|
||||||
.post__body h3 {
|
|
||||||
font-family: 'Space Grotesk', system-ui, -apple-system, sans-serif;
|
|
||||||
font-weight: 500;
|
|
||||||
color: var(--c-violet);
|
|
||||||
font-size: 1.15rem;
|
|
||||||
margin: 30px 0 4px;
|
|
||||||
}
|
|
||||||
|
|
||||||
.post__body h4, .post__body h5, .post__body h6 {
|
|
||||||
margin: 20px 0 4px;
|
|
||||||
}
|
|
||||||
|
|
||||||
/* ── Inline code ── */
|
|
||||||
.post__body code {
|
|
||||||
font-family: 'JetBrains Mono', ui-monospace, 'SF Mono', Consolas, monospace;
|
|
||||||
font-size: 0.84em;
|
|
||||||
background: var(--c-bg-raised);
|
|
||||||
color: var(--c-lime);
|
|
||||||
padding: 2px 6px;
|
|
||||||
border-radius: 4px;
|
|
||||||
border: 1px solid var(--c-border);
|
|
||||||
}
|
|
||||||
|
|
||||||
/* ── Code blocks ── */
|
|
||||||
.post__body pre {
|
|
||||||
background: var(--c-bg);
|
|
||||||
border: 1px solid var(--c-border);
|
|
||||||
border-radius: 8px;
|
|
||||||
padding: 16px 18px;
|
|
||||||
overflow-x: auto;
|
|
||||||
margin: 14px 0;
|
|
||||||
font-family: 'JetBrains Mono', ui-monospace, 'SF Mono', Consolas, monospace;
|
|
||||||
font-size: 0.83rem;
|
|
||||||
line-height: 1.55;
|
|
||||||
color: var(--c-fg);
|
|
||||||
}
|
|
||||||
|
|
||||||
.post__body pre code {
|
|
||||||
background: transparent;
|
|
||||||
padding: 0;
|
|
||||||
border: none;
|
|
||||||
font-size: inherit;
|
|
||||||
color: inherit;
|
|
||||||
border-radius: 0;
|
|
||||||
}
|
|
||||||
|
|
||||||
/* ── Blockquote ── */
|
|
||||||
.post__body blockquote {
|
|
||||||
background: rgba(124, 92, 255, 0.06);
|
|
||||||
border: 1px solid rgba(124, 92, 255, 0.15);
|
|
||||||
border-left: 4px solid var(--c-violet);
|
|
||||||
border-radius: 0 8px 8px 0;
|
|
||||||
padding: 16px 18px;
|
|
||||||
margin: 18px 0;
|
|
||||||
color: var(--c-fg);
|
|
||||||
font-size: 0.94rem;
|
|
||||||
}
|
|
||||||
|
|
||||||
/* ── Links ── */
|
|
||||||
.post__body a { color: var(--c-lime); text-decoration: underline; text-underline-offset: 3px; }
|
|
||||||
.post__body a:hover { color: var(--c-violet); }
|
|
||||||
|
|
||||||
/* ── Strong ── */
|
|
||||||
.post__body strong { color: var(--c-lime); font-weight: 600; }
|
|
||||||
|
|
||||||
/* ── 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-violet);
|
|
||||||
color: #fff;
|
|
||||||
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-fg);
|
|
||||||
font-weight: 600;
|
|
||||||
}
|
|
||||||
</style>
|
|
||||||
</head>
|
|
||||||
<body>
|
|
||||||
|
|
||||||
<!-- POST -->
|
|
||||||
<article class="post">
|
|
||||||
<a href="/blog/" class="post__back">← All Posts</a>
|
|
||||||
<span class="post__date">15 June 2026</span>
|
|
||||||
<h1 class="post__title">Zero-CPU Crowd Animation: 1,000 Animals, One Draw Call, No Skeletons</h1>
|
|
||||||
<p class="post__lead">Godot gives you one <code>Skeleton3D</code> per character. Want 200 animated animals? That's 200 skeleton nodes, 200 draw calls, and 200 <code>AnimationPlayer</code> ticks every frame. Want 1,000? You're measuring in seconds per frame.</p>
|
|
||||||
|
|
||||||
<div class="post__body">
|
|
||||||
<p>We built a GPU-driven crowd animation platform into Tinqs Engine that doesn't use skeletons at all. It bakes every animation frame into a bone-matrix palette texture once, and the GPU drives every instance's playback from then on. 1,000 animals at 60 FPS on integrated graphics. Each plays its own clip at its own speed and phase. Zero per-frame CPU cost. This is how AAA engines do crowds — and now it runs in our Godot fork.</p>
|
|
||||||
<h2>Why not skeletons?</h2>
|
|
||||||
<p>The standard approach — one skeleton per character, one <code>AnimationPlayer</code>, one draw call — breaks at crowd scale. Computing <code>global_pose</code> for 1,000 skeletons at 60 bones each is 60,000 matrix multiplications per frame on the main thread. Each is its own draw call. Each <code>AnimationPlayer</code> ticks independently. No CPU can keep up.</p>
|
|
||||||
<p>Vertex animation textures (VAT) can solve this — bake every vertex position into a texture and sample it in the shader. But that stores <strong>vertices × frames</strong>, not bones × frames. A 2,500-vertex animal with 500 animation frames needs 14 MB of VAT data. For 30 animal types: 426 MB. That doesn't fit on a Steam Deck. And VAT can't blend frames for smooth playback, can't skin normals for correct lighting, and locks you into one animation per bake.</p>
|
|
||||||
<p>Our answer: <strong>bone-matrix palette.</strong> Bake every bone pose into a texture, keep the skinning in the shader. The GPU samples the bone matrices and skins the mesh itself — same 4-bone linear blend as a real skeleton, same correct normals and tangents. But the CPU never touches a bone.</p>
|
|
||||||
<h2>How it works</h2>
|
|
||||||
<p>At load time, we play every animation clip on a temporary skeleton and record the bone matrices for every frame into a single texture. A Goat with 9 clips at 30 fps produces 496 frames:</p>
|
|
||||||
<pre><code>Texture: 212 × 496 pixels, RGBA32F
|
|
||||||
VRAM: 212 × 496 × 16 bytes = 1.6 MB</code></pre>
|
|
||||||
<p>That's every frame of every clip — walk, run, idle, attack, death, eat, sleep — in 1.6 MB. Across 30 animal types: 48 MB total. Compare to VAT at 426 MB. Bone-matrix is 9× smaller because bones ≪ vertices.</p>
|
|
||||||
<p>After the bake, the skeleton is destroyed. It never runs again.</p>
|
|
||||||
<p>Each MultiMesh instance gets 4 numbers packed into <code>INSTANCE_CUSTOM</code>:</p>
|
|
||||||
<pre><code>.x = which clip (start row in the palette)
|
|
||||||
.y = how many frames in this clip
|
|
||||||
.z = playback rate (baked-fps × ground speed — foot-sync)
|
|
||||||
.w = phase offset (golden-ratio spread — no two adjacent animals share the same frame)</code></pre>
|
|
||||||
<p>The vertex shader computes each instance's current frame from TIME:</p>
|
|
||||||
<pre><code class="language-glsl">float fpos = mod(TIME * INSTANCE_CUSTOM.z + INSTANCE_CUSTOM.w * INSTANCE_CUSTOM.y,
|
|
||||||
INSTANCE_CUSTOM.y);
|
|
||||||
int f0 = int(fpos);
|
|
||||||
int f1 = int(mod(float(f0) + 1.0, INSTANCE_CUSTOM.y));
|
|
||||||
float fr = fpos - float(f0);
|
|
||||||
|
|
||||||
// Blend between two adjacent frames for smooth playback
|
|
||||||
int r0 = int(INSTANCE_CUSTOM.x + 0.5) + f0;
|
|
||||||
int r1 = int(INSTANCE_CUSTOM.x + 0.5) + f1;
|
|
||||||
|
|
||||||
// For each bone, reconstruct mat4 from 4 texels, blend, weight by skin influence
|
|
||||||
mat4 m0 = mat4(texelFetch(tex, ivec2(b*4+0, r0), 0), /* ... 3 more columns */);
|
|
||||||
mat4 m1 = mat4(texelFetch(tex, ivec2(b*4+1, r1), 0), /* ... */);
|
|
||||||
skin += (m0 * (1.0 - fr) + m1 * fr) * weight;</code></pre>
|
|
||||||
<p>The blend between two adjacent frames means we can bake at a low fps and stay smooth — the shader interpolates. The golden-ratio phase spread means every animal in a herd reads a different frame. One draw call per animal type. Zero CPU. Per-instance clip, speed, and phase — all in the GPU.</p>
|
|
||||||
<h2>The numbers</h2>
|
|
||||||
<p>Measured on an M1 Pro MacBook Pro (integrated GPU), not a desktop gaming rig:</p>
|
|
||||||
<p>| Agent count | FPS |</p>
|
|
||||||
<p>|————|—–|</p>
|
|
||||||
<p>| 100 | <strong>60</strong> |</p>
|
|
||||||
<p>| 500 | <strong>60</strong> |</p>
|
|
||||||
<p>| 1,000 | <strong>60</strong> |</p>
|
|
||||||
<p>| 10,000 | 8 (with CPU-side culling, pre-optimization) |</p>
|
|
||||||
<p><strong>VRAM:</strong> 1.6 MB per animal type. 30 types = 48 MB total. A Steam Deck with 1 GB shared memory fits the entire roster with room for colonists, terrain, vegetation, and UI.</p>
|
|
||||||
<p><strong>Draw calls:</strong> One per animal type. 30 types = 30 draw calls for every animated animal on screen. Add colonists, same deal — one draw call per colonist look.</p>
|
|
||||||
<h2>The engine change</h2>
|
|
||||||
<p>The module lives in <code>modules/agent_skinned/</code> inside Tinqs Engine — our fork of Godot 4.6. The core is two classes:</p>
|
|
||||||
<p><strong><code>MultiSkinnedMeshInstance3D</code></strong> — the data plane. Holds the bone-matrix palette. API: <code>set_max_bones()</code>, <code>set_max_instances()</code>, <code>set_instance_pose_bones()</code>. At bake time, we fill one row per animation frame. At render time, it sits idle — the texture is static.</p>
|
|
||||||
<p><strong><code>MultiSkinnedInstance3D</code></strong> — the renderer. A <code>MultiMeshInstance3D</code> subclass. Points its multimesh at the skinned mesh and its <code>data_source_path</code> at the data plane. <code>refresh()</code> uploads the bone texture into the shader's uniform once. The MultiMesh handles instance transforms. The shader handles the rest.</p>
|
|
||||||
<p>The shader uses <code>INSTANCE_CUSTOM</code> to pick the palette row — not <code>INSTANCE_ID</code>. This is the key: the texture's rows are baked animation frames, not per-instance slots. Many instances share the same rows (a synchronized airborne flock) or each pick their own (a varied herd). One abstraction, two behaviors.</p>
|
|
||||||
<p>The engine change is 40 lines of shader code in <code>multi_skinned_instance_3d.cpp</code>. Engine version: <strong>4.6.5.</strong></p>
|
|
||||||
<h2>The production pipeline</h2>
|
|
||||||
<p>In Ariki, <code>AnimalHerdRenderer.cs</code> groups sim <code>ViewerState.animals</code> by type, feeds world positions and yaw rotations to <code>skinned_herd.gd</code> — the reusable per-type herd backend. The herd bakes the palette once at setup, then <code>set_positions()</code> updates transforms each sim tick. <code>set_clip_for_state()</code> switches the active clip block in the custom data when the sim FSM changes state (idle → walk → flee → attack). <code>set_speed_scale()</code> adjusts the per-instance playback rate to match ground speed — feet stay planted.</p>
|
|
||||||
<p>Bird flocks use the same system. <code>BirdFlock.cs</code> runs boid flocking on top of <code>skinned_herd</code>, sharing the palette with synchronized phases (airborne flapping in unison is intentional). 25 bird species migrated from the Low Poly Bird Ultimate Pack, each a single draw call.</p>
|
|
||||||
<p>The sim owns all behavior — 30 data-driven animals with per-animal senses, diet, combat stats, and FSM states. The client just renders. The same system will drive thousands of colonists at launch.</p>
|
|
||||||
<h2>Where we stand vs the industry</h2>
|
|
||||||
<p>The bone-matrix palette technique is the same architecture used by Assassin's Creed Unity, Total War: Warhammer, and Hitman for their crowd systems. We're using the same core idea, in a Godot fork, with smaller VRAM (our low-poly animals keep textures tiny).</p>
|
|
||||||
<p>The platform supports three tiers by distance:</p>
|
|
||||||
<ul>
|
|
||||||
<li><strong>Crowd tier (palette)</strong> — baked poses, GPU-driven, zero CPU. Thousands of agents.</li>
|
|
||||||
<li><strong>Hero tier (real rigs)</strong> — <code>AnimationTree</code> + <code>SkeletonIK3D</code> + <code>PhysicalBone3D</code> for the nearest few. Smooth gait blends, foot-lock, look-at, ragdoll.</li>
|
|
||||||
<li><strong>Impostor tier (2D billboards)</strong> — sprite atlas indexed by view-angle and animation-frame, driven by the same <code>(clip, frame, speed, phase)</code> packet. For very far agents.</li>
|
|
||||||
</ul>
|
|
||||||
<p>The same abstraction — <code>(clip, count, speed, phase)</code> — drives every tier. One packet, three detail levels.</p>
|
|
||||||
<h2>Get the build</h2>
|
|
||||||
<p>Pre-built editor binaries with <code>agent_skinned</code> and the GPU-driven palette baked in:</p>
|
|
||||||
<p>| Platform | Binary |</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-lime);"><code>tinqs.macos.editor.arm64.mono</code></a> |</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-lime);"><code>tinqs.windows.editor.x86_64.mono.exe</code></a> |</p>
|
|
||||||
<p>All builds at <a href="https://tinqs.com/tinqs/builds" style="color: var(--c-lime);"><code>tinqs/builds</code></a>. Engine source at <a href="https://tinqs.com/tinqs/engine" style="color: var(--c-lime);"><code>tinqs/engine</code></a> (private).</p>
|
|
||||||
<p>The game's <code>animal_perf_test.tscn</code> spawns 10/100/1,000/10,000 animals and reports live FPS. The <code>animal_viewer.tscn</code> lets you inspect any animal type, toggle clips, and switch between single and herd mode.</p>
|
|
||||||
<hr>
|
|
||||||
<p><strong>Related:</strong> <a href="gpu-skinned-herds" style="color: var(--c-lime);">GPU-Skinned Herds</a> — the original <code>agent_skinned</code> module design. <a href="fork-dont-build" style="color: var(--c-lime);">Fork, Don't Build</a> — why we modify existing platforms. <a href="godot-optimisation" style="color: var(--c-lime);">Streaming a 12km Archipelago in Godot 4</a> — the terrain and vegetation layers.</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>
|
|
||||||
|
Before
|
+103
-49
@@ -5,19 +5,19 @@
|
|||||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
<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>
|
<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="description" content="Godot has no built-in way to render 1,000 skinned characters in one draw call. We built a GPU-driven crowd animation platform into Tinqs Engine that does — 1,000 animals at 60 FPS, each with its own clip and phase, zero per-frame CPU. Pre-built binaries for macOS and Windows.">
|
||||||
<meta name="robots" content="index, follow">
|
<meta name="robots" content="index, follow">
|
||||||
<link rel="canonical" href="https://www.tinqs.com/blog/gpu-skinned-herds">
|
<link rel="canonical" href="https://www.tinqs.com/blog/gpu-skinned-herds">
|
||||||
|
|
||||||
<meta property="og:type" content="article">
|
<meta property="og:type" content="article">
|
||||||
<meta property="og:url" content="https://www.tinqs.com/blog/gpu-skinned-herds">
|
<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: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:description" content="One draw call, 1,000 animated characters, zero CPU. GPU-driven crowd animation platform built into the Tinqs Engine fork of Godot.">
|
||||||
<meta property="og:image" content="https://www.tinqs.com/img/og-cover.jpg">
|
<meta property="og:image" content="https://www.tinqs.com/img/og-cover.jpg">
|
||||||
|
|
||||||
<meta name="twitter:card" content="summary_large_image">
|
<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: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:description" content="One draw call, 1,000 animated characters, zero CPU. GPU-driven crowd animation platform built into the Tinqs Engine fork of Godot.">
|
||||||
<meta name="twitter:image" content="https://www.tinqs.com/img/og-cover.jpg">
|
<meta name="twitter:image" content="https://www.tinqs.com/img/og-cover.jpg">
|
||||||
|
|
||||||
<script type="application/ld+json">
|
<script type="application/ld+json">
|
||||||
@@ -25,7 +25,7 @@
|
|||||||
"@context": "https://schema.org",
|
"@context": "https://schema.org",
|
||||||
"@type": "BlogPosting",
|
"@type": "BlogPosting",
|
||||||
"headline": "GPU-Skinned Herds: One Draw Call for 1,000 Animated Characters in Godot",
|
"headline": "GPU-Skinned Herds: One Draw Call for 1,000 Animated Characters in Godot",
|
||||||
"datePublished": "2026-06-14",
|
"datePublished": "2026-06-15",
|
||||||
"author": {
|
"author": {
|
||||||
"@type": "Person",
|
"@type": "Person",
|
||||||
"name": "Ozan Bozkurt"
|
"name": "Ozan Bozkurt"
|
||||||
@@ -35,7 +35,7 @@
|
|||||||
"name": "Tinqs Limited",
|
"name": "Tinqs Limited",
|
||||||
"url": "https://www.tinqs.com"
|
"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."
|
"description": "Godot has no built-in way to render 1,000 skinned characters in one draw call. We built a GPU-driven crowd animation platform into Tinqs Engine that does — 1,000 animals at 60 FPS, each with its own clip and phase, zero per-frame CPU. Pre-built binaries for macOS and Windows."
|
||||||
}
|
}
|
||||||
</script>
|
</script>
|
||||||
|
|
||||||
@@ -275,70 +275,124 @@
|
|||||||
<!-- POST -->
|
<!-- POST -->
|
||||||
<article class="post">
|
<article class="post">
|
||||||
<a href="/blog/" class="post__back">← All Posts</a>
|
<a href="/blog/" class="post__back">← All Posts</a>
|
||||||
<span class="post__date">14 June 2026</span>
|
<span class="post__date">15 June 2026</span>
|
||||||
<h1 class="post__title">GPU-Skinned Herds: One Draw Call for 1,000 Animated Characters in Godot</h1>
|
<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>
|
<p class="post__lead">Godot gives you one <code>Skeleton3D</code> per character. Want 200 animated animals? That's 200 skeleton nodes, 200 draw calls, and 200 <code>AnimationPlayer</code> ticks every frame. Want 1,000? You're measuring in seconds per frame.</p>
|
||||||
|
|
||||||
<div class="post__body">
|
<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 confirmed first. Then we threw 1,000 animals — 12 types mixed, random-walking — at it and the GPU didn't flinch. Same bone count, same animation fidelity, a tiny fraction of the cost.</p>
|
<p>We built a GPU-driven crowd animation platform into Tinqs Engine that doesn't use skeletons at all. It bakes every animation frame into a bone-matrix palette texture once, and the GPU drives every instance's playback from then on. 1,000 animals at 60 FPS on integrated graphics. Each plays its own clip at its own speed and phase. Zero per-frame CPU cost. This is how AAA engines do crowds — and now it runs in our Godot fork.</p>
|
||||||
<h2>Why the engine needs to change</h2>
|
<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>
|
<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>
|
<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>CPU bone transforms.</strong> Computing <code>global_pose</code> for 1,000 skeletons × 60 bones each = 60,000 matrix multiplications 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>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>
|
<li><strong>AnimationPlayer sprawl.</strong> Each skeleton needs its own <code>AnimationPlayer</code> and its own <code>process()</code> tick.</li>
|
||||||
</ul>
|
</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>Vertex animation textures (VAT) can solve this — bake every vertex position into a texture and sample it in the shader. But that stores <strong>vertices × frames</strong>, not bones × frames. A 2,500-vertex animal with 500 animation frames needs 14 MB of VAT data. For 30 animal types: 426 MB. That doesn't fit on a Steam Deck. And VAT can't blend frames for smooth playback, can't skin normals for correct lighting, and locks you into one animation per bake.</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>
|
<p>Our answer: <strong>bone-matrix palette.</strong> Bake every bone pose into a texture, keep the skinning in the shader. The GPU samples the bone matrices and skins the mesh itself — same 4-bone linear blend as a real skeleton, same correct normals and tangents. But the CPU never touches a bone.</p>
|
||||||
<h2>How it works: two classes, one texture</h2>
|
<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-lime);">Tinqs Engine</a>. Two classes, one job:</p>
|
<p>The module lives in <code>modules/agent_skinned/</code> inside <a href="https://tinqs.com/tinqs/engine" style="color: var(--c-lime);">Tinqs Engine</a>. Two classes, one job.</p>
|
||||||
<h3><code>MultiSkinnedMeshInstance3D</code> — the data plane</h3>
|
<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>
|
<p>Holds the bone-matrix palette. Allocates an <code>ImageTexture</code> of size <code>[4 × max_bones, total_frames]</code> in RGBA32F — each texel is one column of a 4×4 bone matrix, each row is one baked animation frame. At load time, we play every animation clip on a temporary skeleton and record the bone matrices for every frame:</p>
|
||||||
<pre><code>Texture: 520 × 256 RGBA32F ≈ 2 MB</code></pre>
|
<pre><code>Goat: 53 bones × 9 clips × 496 frames
|
||||||
<p>That's the entire pose state for 256 animated crocodiles in a single GPU texture. The API is simple:</p>
|
Texture: 212 × 496 pixels, RGBA32F
|
||||||
|
VRAM: 212 × 496 × 16 bytes = 1.6 MB</code></pre>
|
||||||
|
<p>That's every frame of every clip — walk, run, idle, attack, death, eat, sleep — in 1.6 MB. Across 30 animal types: <strong>48 MB total.</strong> Compare to VAT at 426 MB. Bone-matrix is 9× smaller because bones ≪ vertices.</p>
|
||||||
|
<p>After the bake, the skeleton is destroyed. It never runs again. The API is straightforward:</p>
|
||||||
<pre><code class="language-gdscript">var data := MultiSkinnedMeshInstance3D.new()
|
<pre><code class="language-gdscript">var data := MultiSkinnedMeshInstance3D.new()
|
||||||
data.set_mesh(crocodile_mesh)
|
data.set_max_bones(53)
|
||||||
data.set_skeleton(skeleton) # rest pose + bone hierarchy
|
data.set_max_instances(496) # palette rows = baked frames
|
||||||
data.set_max_instances(256)
|
|
||||||
data.set_max_bones(130)
|
|
||||||
|
|
||||||
# Each frame: push poses from the animated skeleton
|
# Bake: play each clip, seek to each frame, record bone matrices
|
||||||
for instance in herd_positions:
|
for clip in clips:
|
||||||
data.set_instance_pose_bones(instance.id, bone_transforms)
|
for frame in clip.frames:
|
||||||
data.update() # upload only dirty instances, not the whole texture</code></pre>
|
skeleton.seek(frame.time)
|
||||||
|
data.set_instance_pose_bones(row, bone_transforms)</code></pre>
|
||||||
|
<p>The data plane stores matrices column-major — 4 texels per bone = 4 columns of a 4×4 transform. The getter matches the layout, and a doctest asserts it so a transpose can't silently regress.</p>
|
||||||
<h3><code>MultiSkinnedInstance3D</code> — the renderer</h3>
|
<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>A <code>MultiMeshInstance3D</code> subclass. Set its multimesh with the skinned mesh and instance transforms, point its <code>data_source_path</code> at the data plane. Call <code>refresh()</code> once — it uploads the bone texture into the shader material's <code>bone_matrices_tex</code> uniform.</p>
|
||||||
<p>The shader does 4-bone linear-blend skinning on the GPU:</p>
|
<p>Each MultiMesh instance carries 4 numbers in <code>INSTANCE_CUSTOM</code> (enable <code>multimesh.use_custom_data</code>):</p>
|
||||||
<pre><code class="language-glsl">mat4 get_bone(int b) {
|
<p>| Channel | Meaning |</p>
|
||||||
return mat4(
|
<p>|———|———|</p>
|
||||||
texelFetch(bone_matrices_tex, ivec2(b * 4 + 0, INSTANCE_ID), 0),
|
<p>| <code>.x</code> | Which clip (start row in the palette) |</p>
|
||||||
texelFetch(bone_matrices_tex, ivec2(b * 4 + 1, INSTANCE_ID), 0),
|
<p>| <code>.y</code> | How many frames in this clip |</p>
|
||||||
texelFetch(bone_matrices_tex, ivec2(b * 4 + 2, INSTANCE_ID), 0),
|
<p>| <code>.z</code> | Playback rate (baked-fps × ground speed — foot-sync) |</p>
|
||||||
texelFetch(bone_matrices_tex, ivec2(b * 4 + 3, INSTANCE_ID), 0)
|
<p>| <code>.w</code> | Phase offset (golden-ratio spread — no two adjacent animals share the same frame) |</p>
|
||||||
);
|
<p>The vertex shader derives each instance's current frame from TIME:</p>
|
||||||
}</code></pre>
|
<pre><code class="language-glsl">float fpos = mod(TIME * INSTANCE_CUSTOM.z + INSTANCE_CUSTOM.w * INSTANCE_CUSTOM.y,
|
||||||
<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>
|
INSTANCE_CUSTOM.y);
|
||||||
<h2>Two bugs we shipped and fixed</h2>
|
int f0 = int(fpos);
|
||||||
<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>
|
int f1 = int(mod(float(f0) + 1.0, INSTANCE_CUSTOM.y));
|
||||||
<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>
|
float fr = fpos - float(f0);
|
||||||
<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>
|
// Blend between two adjacent frames for smooth playback at low bake fps
|
||||||
|
int r0 = int(INSTANCE_CUSTOM.x + 0.5) + f0;
|
||||||
|
int r1 = int(INSTANCE_CUSTOM.x + 0.5) + f1;
|
||||||
|
|
||||||
|
// For each bone (up to 4 per vertex), reconstruct mat4 from 4 texels, blend, weight
|
||||||
|
mat4 m0 = mat4(
|
||||||
|
texelFetch(bone_matrices_tex, ivec2(b*4 + 0, r0), 0),
|
||||||
|
texelFetch(bone_matrices_tex, ivec2(b*4 + 1, r0), 0),
|
||||||
|
texelFetch(bone_matrices_tex, ivec2(b*4 + 2, r0), 0),
|
||||||
|
texelFetch(bone_matrices_tex, ivec2(b*4 + 3, r0), 0));
|
||||||
|
mat4 m1 = mat4( /* same for r1 */ );
|
||||||
|
skin += (m0 * (1.0 - fr) + m1 * fr) * weight;
|
||||||
|
|
||||||
|
// Apply skin to vertex, normal, tangent
|
||||||
|
VERTEX = (skin * vec4(VERTEX, 1.0)).xyz;
|
||||||
|
NORMAL = normalize((skin * vec4(NORMAL, 0.0)).xyz);</code></pre>
|
||||||
|
<p>The shader uses <code>INSTANCE_CUSTOM</code> to pick the palette row — not <code>INSTANCE_ID</code>. This is the key: the texture's rows are baked animation frames, not per-instance slots. Many instances share the same rows (a synchronized airborne flock) or each pick their own (a varied herd). One abstraction, two behaviors.</p>
|
||||||
|
<p>The blend between two adjacent frames means we can bake at a low fps and stay smooth — the shader interpolates. The golden-ratio phase spread means every animal in a herd reads a different frame. One draw call per animal type. Zero CPU. Per-instance clip, speed, and phase — all in the GPU.</p>
|
||||||
|
<p>The shader ships as the default material on <code>MultiSkinnedInstance3D</code>. It includes an <code>albedo_tex</code> uniform — the caller sets it from the source mesh's material so herds texture out of the box. No <code>ShaderMaterial</code> assembly required unless you want custom shading.</p>
|
||||||
|
<h2>The numbers</h2>
|
||||||
|
<p>Measured on an M1 Pro MacBook Pro (integrated GPU):</p>
|
||||||
|
<p>| Agent count | FPS |</p>
|
||||||
|
<p>|————|—–|</p>
|
||||||
|
<p>| 100 | <strong>60</strong> |</p>
|
||||||
|
<p>| 500 | <strong>60</strong> |</p>
|
||||||
|
<p>| 1,000 | <strong>60</strong> |</p>
|
||||||
|
<p>| 10,000 | 8 (with CPU-side culling, pre-optimization) |</p>
|
||||||
|
<p><strong>VRAM:</strong> 1.6 MB per animal type. 30 types = 48 MB total. A Steam Deck with 1 GB shared memory fits the entire roster.</p>
|
||||||
|
<p><strong>Draw calls:</strong> One per animal type. 30 types = 30 draw calls for every animated animal on screen. Future colonists share the same architecture — one draw call per colonist look.</p>
|
||||||
<h2>What's driving it</h2>
|
<h2>What's driving it</h2>
|
||||||
<p>In <a href="https://www.arikigame.com" style="color: var(--c-lime);">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>In <a href="https://www.arikigame.com" style="color: var(--c-lime);">Ariki</a>, the sim tracks animal migration across a 12km archipelago. <code>AnimalHerdRenderer.cs</code> groups sim <code>ViewerState.animals</code> by type, feeds world positions and yaw rotations to <code>skinned_herd.gd</code> — the reusable per-type herd backend. The herd bakes the palette once at setup, then <code>set_positions()</code> updates transforms each sim tick. <code>set_clip_for_state()</code> switches the active clip block in the custom data when the sim FSM changes state. <code>set_speed_scale()</code> adjusts the per-instance playback rate to match ground speed — feet stay planted.</p>
|
||||||
<p>The crocodile herd scene was 25 instances, one draw call. The perf test scene does 1,000 animals across 12 types — Boar, Cow, Crab, Crocodile, Deer, Fish, Goat, Hen, Pig, Rabbit, Sheep, Tiger — each type its own GPU herd, all mixed, all random-walking, FPS holding steady.</p>
|
<p>The sim owns all behavior — 30 data-driven animals with per-animal senses, diet, combat stats, and FSM states (graze, drink, sleep, hunt, flee, scavenge, die). The client just renders. This is the same code in single-player and multiplayer — the sim is the host.</p>
|
||||||
|
<p>Bird flocks use the same system. <code>BirdFlock.cs</code> runs boid flocking on top of <code>skinned_herd</code>, sharing the palette with synchronized phases (airborne flapping in unison is intentional). 25 bird species migrated from the Low Poly Bird Ultimate Pack, each a single draw call.</p>
|
||||||
|
<p>Per-instance custom data means a walking Boar, a running Boar, an idle Boar, and an attacking Boar all share the same baked palette — they just point at different rows. The renderer groups by type, not by state. One palette, one draw call, any number of states.</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, column-major layout. All green. Then we put it on screen and two things were 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 initial data plane wrote basis rows (standard Godot <code>Transform3D.basis</code> is row-major), but the shader reads <code>mat4(c0,c1,c2,c3)</code> 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>The engine change</h2>
|
||||||
|
<p>The module is 40 lines of shader code and ~500 lines of C++ in the engine's <code>modules/agent_skinned/</code>. The critical detail is in the shader: the bone-matrix texture is indexed by a <strong>pose slot</strong> computed from <code>INSTANCE_CUSTOM</code>, not by <code>INSTANCE_ID</code>. This is what decouples the palette from the instance count — the texture stores animation frames, the MultiMesh stores instance transforms, and the shader bridges them.</p>
|
||||||
|
<p>Engine version: <strong>4.6.5.</strong></p>
|
||||||
|
<p>No C# wrapper is generated — instantiate from GDScript via <code>ClassDB.instantiate()</code> and call the bound methods. The binding surface is small and stable. See <code>ariki-game/scenes/animals/skinned_herd.gd</code> for the reference backend.</p>
|
||||||
|
<h2>The production pipeline</h2>
|
||||||
|
<p>The <code>migrate_animals.py</code> tool converts polyperfect FBX packs to game-ready GLBs — imports, cleans hierarchy, rebuilds named NLA clips from frame ranges, strips duplicate meshes, bakes into the flat <code>assets/models/glbs/</code> directory. Each animal gets a catalog entry in <code>animals_catalog.json</code> with clip metadata, default state mapping, and an <code>animSpeedRef</code> for foot-sync.</p>
|
||||||
|
<p>At runtime, <code>AnimalHerdRenderer</code> spawns one <code>skinned_herd</code> per animal type. The herd bakes the palette from the catalog GLB's clips. <code>AnimalAnimationLogic</code> maps sim FSM states to clip keywords (attack → "attack"/"bite", flee → "run"/"gallop", wander → "walk"). The renderer lerps positions between sim ticks for smooth motion and writes per-instance custom data each frame. Zero per-frame CPU on the animation path.</p>
|
||||||
|
<h2>Where we stand vs the industry</h2>
|
||||||
|
<p>The bone-matrix palette technique is the same architecture used by Assassin's Creed Unity, Total War: Warhammer, and Hitman for their crowd systems. We're using the same core idea, in a Godot fork, with smaller VRAM — our low-poly animals keep textures tiny.</p>
|
||||||
|
<p>The platform supports three tiers by distance, all driven by the same <code>(clip, count, speed, phase)</code> packet:</p>
|
||||||
|
<ul>
|
||||||
|
<li><strong>Crowd tier (palette)</strong> — baked poses, GPU-driven, zero CPU. Thousands of agents.</li>
|
||||||
|
<li><strong>Hero tier (real rigs)</strong> — <code>AnimationTree</code> + <code>SkeletonIK3D</code> + <code>PhysicalBone3D</code> for the nearest few. Smooth gait blends, foot-lock, look-at, ragdoll.</li>
|
||||||
|
<li><strong>Impostor tier (2D billboards)</strong> — sprite atlas indexed by view-angle and animation-frame. For very far agents.</li>
|
||||||
|
</ul>
|
||||||
|
<p>One abstraction, three detail levels. The same code that drives 30 animals today will drive thousands of colonists at launch.</p>
|
||||||
<h2>What's deliberately not here</h2>
|
<h2>What's deliberately not here</h2>
|
||||||
<ul>
|
<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 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 automatic <code>AnimationPlayer</code> integration.</strong> You drive poses at bake time. 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>
|
<li><strong>No GPU occlusion culling.</strong> That's the game's job. The engine provides the tool; the game decides what to draw.</li>
|
||||||
</ul>
|
</ul>
|
||||||
<h2>Get the build</h2>
|
<h2>Get the build</h2>
|
||||||
<p>Pre-built editor binaries with <code>agent_skinned</code> baked in — no engine compile required. The game's <code>animal_perf_test.tscn</code> lets you toggle 10 / 100 / 1000 animals and read live FPS:</p>
|
<p>Pre-built editor binaries with <code>agent_skinned</code> and the GPU-driven palette baked in — no engine compile required. The game's <code>animal_perf_test.tscn</code> lets you spawn 10/100/1,000/10,000 animals and read live FPS:</p>
|
||||||
<p>| Platform | Binary | Engine commit |</p>
|
<p>| Platform | Binary |</p>
|
||||||
<p>|———-|——–|—————|</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-lime);"><code>tinqs.macos.editor.arm64.mono</code></a> | <code>4fe1323</code> (4.6.4, Xcode 26.3) |</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-lime);"><code>tinqs.macos.editor.arm64.mono</code></a> |</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-lime);"><code>tinqs.windows.editor.x86_64.mono.exe</code></a> | <code>64fb5cc</code> (4.6.4, MSVC 2022) |</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-lime);"><code>tinqs.windows.editor.x86_64.mono.exe</code></a> |</p>
|
||||||
<p>All builds live in the public <a href="https://tinqs.com/tinqs/builds" style="color: var(--c-lime);"><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-lime);"><code>manifest.json</code></a> for checksums and build details.</p>
|
<p>All builds at <a href="https://tinqs.com/tinqs/builds" style="color: var(--c-lime);"><code>tinqs/builds</code></a> — 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-lime);"><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-lime);"><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>
|
<p>The engine source lives in <a href="https://tinqs.com/tinqs/engine" style="color: var(--c-lime);"><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>
|
<hr>
|
||||||
<p><strong>Related:</strong> <a href="fork-dont-build" style="color: var(--c-lime);">Fork, Don't Build</a> — why we modify existing platforms instead of building new ones. <a href="godot-optimisation" style="color: var(--c-lime);">Streaming a 12km Archipelago in Godot 4</a> — the terrain and vegetation streaming layers that work alongside this.</p>
|
<p><strong>Related:</strong> <a href="fork-dont-build" style="color: var(--c-lime);">Fork, Don't Build</a> — why we modify existing platforms instead of building new ones. <a href="godot-optimisation" style="color: var(--c-lime);">Streaming a 12km Archipelago in Godot 4</a> — the terrain and vegetation streaming layers that work alongside this.</p>
|
||||||
|
|||||||
|
Before
After
|
+2
-9
@@ -187,17 +187,10 @@
|
|||||||
<span class="blog-card__read">Read →</span>
|
<span class="blog-card__read">Read →</span>
|
||||||
</a>
|
</a>
|
||||||
|
|
||||||
<a href="gpu-driven-crowd-animation" class="blog-card">
|
|
||||||
<span class="blog-card__date">15 June 2026</span>
|
|
||||||
<h2 class="blog-card__title">Zero-CPU Crowd Animation: 1,000 Animals, One Draw Call, No Skeletons</h2>
|
|
||||||
<p class="blog-card__excerpt">Our crowd renderer bakes every animation frame into a bone-matrix palette once, then the GPU drives every instance itself — 1,000 animals at 60 FPS, each with its own clip and phase. This is how AAA does crowds. Now it runs in our Godot fork.</p>
|
|
||||||
<span class="blog-card__read">Read →</span>
|
|
||||||
</a>
|
|
||||||
|
|
||||||
<a href="gpu-skinned-herds" class="blog-card">
|
<a href="gpu-skinned-herds" class="blog-card">
|
||||||
<span class="blog-card__date">14 June 2026</span>
|
<span class="blog-card__date">15 June 2026</span>
|
||||||
<h2 class="blog-card__title">GPU-Skinned Herds: One Draw Call for 1,000 Animated Characters in Godot</h2>
|
<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>
|
<p class="blog-card__excerpt">Godot can't batch-render 1,000 animated characters. We built a GPU-driven crowd renderer into the engine itself — bake every animation frame into a texture once, let the GPU drive every instance. 1,000 animals, 60 FPS, zero skeletons. Pre-built editor binaries.</p>
|
||||||
<span class="blog-card__read">Read →</span>
|
<span class="blog-card__read">Read →</span>
|
||||||
</a>
|
</a>
|
||||||
|
|
||||||
|
|||||||
|
Before
After
|
+31
-50
@@ -277,58 +277,39 @@
|
|||||||
<a href="/blog/" class="post__back">← All Posts</a>
|
<a href="/blog/" class="post__back">← All Posts</a>
|
||||||
<span class="post__date">7 June 2026</span>
|
<span class="post__date">7 June 2026</span>
|
||||||
<h1 class="post__title">Live Ozan Radio: A Personal AI Station in Cursor</h1>
|
<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.
|
<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.</p>
|
||||||
|
|
||||||
!<a href="https://tinqs.com/tinqs/blog/media/branch/main/img/live-ozan-radio-workspace.png" style="color: var(--c-lime);">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.
|
|
||||||
|
|
||||||
## No catalog, ever
|
|
||||||
|
|
||||||
The rule is simple: <strong>nothing pre-recorded from the outside world</strong>. Every MP3 is generated by Lyria from a prompt that DeepSeek writes using <code>settings.json</code> (taste profile) and <code>taste_seeds.json</code> (built from Spotify screenshots in Cursor — no Spotify API). Shuffle mode mixes saved tracks with new compositions until the daily cap hits.
|
|
||||||
|
|
||||||
The stack:
|
|
||||||
|
|
||||||
| Layer | What it does |
|
|
||||||
|——-|—————-|
|
|
||||||
| <strong>DeepSeek</strong> | DJ brain — mood, Lyria prompts, chat |
|
|
||||||
| <strong>Lyria 3 Pro</strong> | Full songs (~1–2 min), vocals optional |
|
|
||||||
| <strong>FastAPI player</strong> | Stream, library, cost dashboard, vocal booth |
|
|
||||||
| <strong>Git LFS</strong> | Committed songs + rich metadata |
|
|
||||||
|
|
||||||
## Curating every generation like a real DJ
|
|
||||||
|
|
||||||
Raw MP3s are not enough. Each track gets an extensive <code>*.meta.json</code>: rating (<code>love</code> / <code>keeper</code> / <code>skip</code>), what I loved, what I hated, <code>clone_prompt_hints</code> for successors, BPM, skip-intro timestamps, and instrument tags. A <code>library_index.json</code> rolls that up so the DJ knows, for example, that <strong>Sahara's Saz</strong> is the gold standard (saz + ney + sub bass by twenty seconds) and that <strong>fuzz electric guitar on vocal tracks</strong> is a hard avoid.
|
|
||||||
|
|
||||||
That metadata feeds back into every <code>plan_next</code> call. When I said Caravan of the Night was "not bad" but I hated the electric guitar bit, that went into <code>disliked</code> and <code>avoid_in_successors</code> — the next griot-vocal generation should keep the Sahel chants and drop the Tinariwen-style guitar.
|
|
||||||
|
|
||||||
## Public auto-play on tinqs.com
|
|
||||||
|
|
||||||
The full dashboard (<code>python -m ozan_radio serve</code> → <code>http://127.0.0.1:8787/player</code>) needs the API for Lyria compose, settings, and chat. But listening-only is static: <strong><code>gateway/index.html</code></strong> in the repo embeds the playlist and auto-plays from Git LFS media URLs when you open it on Git Studio:
|
|
||||||
|
|
||||||
<strong>https://tinqs.com/tinqs/live-radio/src/branch/main/gateway/index.html</strong>
|
|
||||||
|
|
||||||
Commit, push, share the link — no server required for listeners. New tracks run <code>export-web</code> (or auto-export on save) to refresh the embedded playlist.
|
|
||||||
|
|
||||||
## Vocal booth in the browser
|
|
||||||
|
|
||||||
For instrumentals where I want my own layer (deep chest / throat-sync over Nomad's Saz when the saz kicks in at ~0:30), the player includes a <strong>Chrome vocal booth</strong>: cue sheet with timestamps, skip-to-saz, <code>MediaRecorder</code> for takes, download as WebM. Lyria cannot remix an existing MP3 — but I can record over it locally while the track plays in headphones.
|
|
||||||
|
|
||||||
## Lyria settings in the web UI
|
|
||||||
|
|
||||||
The player settings panel talks to <code>/api/lyria</code> and adapts from the real Gemini API: model (Pro vs 30s Clip), vocal mode (instrumental / mix / full vocals), lyric language, singer profile, WAV vs MP3. Changes persist to <code>settings.json</code> and shape both the Lyria suffix and the DJ system prompt.
|
|
||||||
|
|
||||||
## Repo
|
|
||||||
|
|
||||||
Open source on our Gitea: <strong>https://tinqs.com/tinqs/live-radio</strong>
|
|
||||||
|
|
||||||
Clone, add your taste via Cursor + screenshots, run the server, or just hit the gateway link and let it shuffle. If you are building on Tinqs Studio, this is the kind of small, weird, personal tool that belongs in the same forge as your docs and your game — not on someone else's CDN.
|
|
||||||
|
|
||||||
—
|
|
||||||
|
|
||||||
<em>Inspired by Google's Magenta RealTime 2 segment on AI Search — we wanted the Lyria full-song path first; optional live MRT2 layer on Apple Silicon is on the roadmap.</em></p>
|
|
||||||
|
|
||||||
<div class="post__body">
|
<div class="post__body">
|
||||||
|
<figure>
|
||||||
|
<img src="https://tinqs.com/tinqs/blog/media/branch/main/img/live-ozan-radio-workspace.png" alt="Live Ozan Radio in Cursor — player dashboard, saved songs, and DJ chat beside the editor">
|
||||||
|
<figcaption>Live Ozan Radio in Cursor — player dashboard, saved songs, and DJ chat beside the editor</figcaption>
|
||||||
|
</figure>
|
||||||
|
<p>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.</p>
|
||||||
|
<h2>No catalog, ever</h2>
|
||||||
|
<p>The rule is simple: <strong>nothing pre-recorded from the outside world</strong>. Every MP3 is generated by Lyria from a prompt that DeepSeek writes using <code>settings.json</code> (taste profile) and <code>taste_seeds.json</code> (built from Spotify screenshots in Cursor — no Spotify API). Shuffle mode mixes saved tracks with new compositions until the daily cap hits.</p>
|
||||||
|
<p>The stack:</p>
|
||||||
|
<p>| Layer | What it does |</p>
|
||||||
|
<p>|——-|—————-|</p>
|
||||||
|
<p>| <strong>DeepSeek</strong> | DJ brain — mood, Lyria prompts, chat |</p>
|
||||||
|
<p>| <strong>Lyria 3 Pro</strong> | Full songs (~1–2 min), vocals optional |</p>
|
||||||
|
<p>| <strong>FastAPI player</strong> | Stream, library, cost dashboard, vocal booth |</p>
|
||||||
|
<p>| <strong>Git LFS</strong> | Committed songs + rich metadata |</p>
|
||||||
|
<h2>Curating every generation like a real DJ</h2>
|
||||||
|
<p>Raw MP3s are not enough. Each track gets an extensive <code>*.meta.json</code>: rating (<code>love</code> / <code>keeper</code> / <code>skip</code>), what I loved, what I hated, <code>clone_prompt_hints</code> for successors, BPM, skip-intro timestamps, and instrument tags. A <code>library_index.json</code> rolls that up so the DJ knows, for example, that <strong>Sahara's Saz</strong> is the gold standard (saz + ney + sub bass by twenty seconds) and that <strong>fuzz electric guitar on vocal tracks</strong> is a hard avoid.</p>
|
||||||
|
<p>That metadata feeds back into every <code>plan_next</code> call. When I said Caravan of the Night was "not bad" but I hated the electric guitar bit, that went into <code>disliked</code> and <code>avoid_in_successors</code> — the next griot-vocal generation should keep the Sahel chants and drop the Tinariwen-style guitar.</p>
|
||||||
|
<h2>Public auto-play on tinqs.com</h2>
|
||||||
|
<p>The full dashboard (<code>python -m ozan_radio serve</code> → <code>http://127.0.0.1:8787/player</code>) needs the API for Lyria compose, settings, and chat. But listening-only is static: <strong><code>gateway/index.html</code></strong> in the repo embeds the playlist and auto-plays from Git LFS media URLs when you open it on Git Studio:</p>
|
||||||
|
<p><strong>https://tinqs.com/tinqs/live-radio/src/branch/main/gateway/index.html</strong></p>
|
||||||
|
<p>Commit, push, share the link — no server required for listeners. New tracks run <code>export-web</code> (or auto-export on save) to refresh the embedded playlist.</p>
|
||||||
|
<h2>Vocal booth in the browser</h2>
|
||||||
|
<p>For instrumentals where I want my own layer (deep chest / throat-sync over Nomad's Saz when the saz kicks in at ~0:30), the player includes a <strong>Chrome vocal booth</strong>: cue sheet with timestamps, skip-to-saz, <code>MediaRecorder</code> for takes, download as WebM. Lyria cannot remix an existing MP3 — but I can record over it locally while the track plays in headphones.</p>
|
||||||
|
<h2>Lyria settings in the web UI</h2>
|
||||||
|
<p>The player settings panel talks to <code>/api/lyria</code> and adapts from the real Gemini API: model (Pro vs 30s Clip), vocal mode (instrumental / mix / full vocals), lyric language, singer profile, WAV vs MP3. Changes persist to <code>settings.json</code> and shape both the Lyria suffix and the DJ system prompt.</p>
|
||||||
|
<h2>Repo</h2>
|
||||||
|
<p>Open source on our Gitea: <strong>https://tinqs.com/tinqs/live-radio</strong></p>
|
||||||
|
<p>Clone, add your taste via Cursor + screenshots, run the server, or just hit the gateway link and let it shuffle. If you are building on Tinqs Studio, this is the kind of small, weird, personal tool that belongs in the same forge as your docs and your game — not on someone else's CDN.</p>
|
||||||
|
<hr>
|
||||||
|
<p><em>Inspired by Google's Magenta RealTime 2 segment on AI Search — we wanted the Lyria full-song path first; optional live MRT2 layer on Apple Silicon is on the roadmap.</em></p>
|
||||||
|
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
|||||||
|
Before
After
|
@@ -1,129 +0,0 @@
|
|||||||
---
|
|
||||||
title: "Zero-CPU Crowd Animation: 1,000 Animals, One Draw Call, No Skeletons"
|
|
||||||
slug: gpu-driven-crowd-animation
|
|
||||||
date: "2026-06-15"
|
|
||||||
description: "We built a GPU-driven crowd animation platform into Tinqs Engine that renders 1,000 animated animals at 60 FPS with zero per-frame CPU cost. Each agent plays its own clip, speed, and phase — no live skeletons, no lockstep, no compromises."
|
|
||||||
og_description: "1,000 animated agents, zero live skeletons, zero per-frame CPU. A GPU-driven crowd animation platform in the Tinqs Engine fork of Godot."
|
|
||||||
og_image: "https://www.tinqs.com/img/og-cover.jpg"
|
|
||||||
excerpt: "Our crowd renderer bakes every animation frame into a bone-matrix palette once, then the GPU drives every instance itself — 1,000 animals at 60 FPS, each with its own clip and phase. This is how AAA does crowds. Now it runs in our Godot fork."
|
|
||||||
author: "Ozan Bozkurt"
|
|
||||||
author_initials: "OB"
|
|
||||||
author_role: "CTO & Developer, Tinqs"
|
|
||||||
---
|
|
||||||
Godot gives you one `Skeleton3D` per character. Want 200 animated animals? That's 200 skeleton nodes, 200 draw calls, and 200 `AnimationPlayer` ticks every frame. Want 1,000? You're measuring in seconds per frame.
|
|
||||||
|
|
||||||
We built a GPU-driven crowd animation platform into Tinqs Engine that doesn't use skeletons at all. It bakes every animation frame into a bone-matrix palette texture once, and the GPU drives every instance's playback from then on. 1,000 animals at 60 FPS on integrated graphics. Each plays its own clip at its own speed and phase. Zero per-frame CPU cost. This is how AAA engines do crowds — and now it runs in our Godot fork.
|
|
||||||
|
|
||||||
## Why not skeletons?
|
|
||||||
|
|
||||||
The standard approach — one skeleton per character, one `AnimationPlayer`, one draw call — breaks at crowd scale. Computing `global_pose` for 1,000 skeletons at 60 bones each is 60,000 matrix multiplications per frame on the main thread. Each is its own draw call. Each `AnimationPlayer` ticks independently. No CPU can keep up.
|
|
||||||
|
|
||||||
Vertex animation textures (VAT) can solve this — bake every vertex position into a texture and sample it in the shader. But that stores **vertices × frames**, not bones × frames. A 2,500-vertex animal with 500 animation frames needs 14 MB of VAT data. For 30 animal types: 426 MB. That doesn't fit on a Steam Deck. And VAT can't blend frames for smooth playback, can't skin normals for correct lighting, and locks you into one animation per bake.
|
|
||||||
|
|
||||||
Our answer: **bone-matrix palette.** Bake every bone pose into a texture, keep the skinning in the shader. The GPU samples the bone matrices and skins the mesh itself — same 4-bone linear blend as a real skeleton, same correct normals and tangents. But the CPU never touches a bone.
|
|
||||||
|
|
||||||
## How it works
|
|
||||||
|
|
||||||
At load time, we play every animation clip on a temporary skeleton and record the bone matrices for every frame into a single texture. A Goat with 9 clips at 30 fps produces 496 frames:
|
|
||||||
|
|
||||||
```
|
|
||||||
Texture: 212 × 496 pixels, RGBA32F
|
|
||||||
VRAM: 212 × 496 × 16 bytes = 1.6 MB
|
|
||||||
```
|
|
||||||
|
|
||||||
That's every frame of every clip — walk, run, idle, attack, death, eat, sleep — in 1.6 MB. Across 30 animal types: 48 MB total. Compare to VAT at 426 MB. Bone-matrix is 9× smaller because bones ≪ vertices.
|
|
||||||
|
|
||||||
After the bake, the skeleton is destroyed. It never runs again.
|
|
||||||
|
|
||||||
Each MultiMesh instance gets 4 numbers packed into `INSTANCE_CUSTOM`:
|
|
||||||
|
|
||||||
```
|
|
||||||
.x = which clip (start row in the palette)
|
|
||||||
.y = how many frames in this clip
|
|
||||||
.z = playback rate (baked-fps × ground speed — foot-sync)
|
|
||||||
.w = phase offset (golden-ratio spread — no two adjacent animals share the same frame)
|
|
||||||
```
|
|
||||||
|
|
||||||
The vertex shader computes each instance's current frame from TIME:
|
|
||||||
|
|
||||||
```glsl
|
|
||||||
float fpos = mod(TIME * INSTANCE_CUSTOM.z + INSTANCE_CUSTOM.w * INSTANCE_CUSTOM.y,
|
|
||||||
INSTANCE_CUSTOM.y);
|
|
||||||
int f0 = int(fpos);
|
|
||||||
int f1 = int(mod(float(f0) + 1.0, INSTANCE_CUSTOM.y));
|
|
||||||
float fr = fpos - float(f0);
|
|
||||||
|
|
||||||
// Blend between two adjacent frames for smooth playback
|
|
||||||
int r0 = int(INSTANCE_CUSTOM.x + 0.5) + f0;
|
|
||||||
int r1 = int(INSTANCE_CUSTOM.x + 0.5) + f1;
|
|
||||||
|
|
||||||
// For each bone, reconstruct mat4 from 4 texels, blend, weight by skin influence
|
|
||||||
mat4 m0 = mat4(texelFetch(tex, ivec2(b*4+0, r0), 0), /* ... 3 more columns */);
|
|
||||||
mat4 m1 = mat4(texelFetch(tex, ivec2(b*4+1, r1), 0), /* ... */);
|
|
||||||
skin += (m0 * (1.0 - fr) + m1 * fr) * weight;
|
|
||||||
```
|
|
||||||
|
|
||||||
The blend between two adjacent frames means we can bake at a low fps and stay smooth — the shader interpolates. The golden-ratio phase spread means every animal in a herd reads a different frame. One draw call per animal type. Zero CPU. Per-instance clip, speed, and phase — all in the GPU.
|
|
||||||
|
|
||||||
## The numbers
|
|
||||||
|
|
||||||
Measured on an M1 Pro MacBook Pro (integrated GPU), not a desktop gaming rig:
|
|
||||||
|
|
||||||
| Agent count | FPS |
|
|
||||||
|------------|-----|
|
|
||||||
| 100 | **60** |
|
|
||||||
| 500 | **60** |
|
|
||||||
| 1,000 | **60** |
|
|
||||||
| 10,000 | 8 (with CPU-side culling, pre-optimization) |
|
|
||||||
|
|
||||||
**VRAM:** 1.6 MB per animal type. 30 types = 48 MB total. A Steam Deck with 1 GB shared memory fits the entire roster with room for colonists, terrain, vegetation, and UI.
|
|
||||||
|
|
||||||
**Draw calls:** One per animal type. 30 types = 30 draw calls for every animated animal on screen. Add colonists, same deal — one draw call per colonist look.
|
|
||||||
|
|
||||||
## The engine change
|
|
||||||
|
|
||||||
The module lives in `modules/agent_skinned/` inside Tinqs Engine — our fork of Godot 4.6. The core is two classes:
|
|
||||||
|
|
||||||
**`MultiSkinnedMeshInstance3D`** — the data plane. Holds the bone-matrix palette. API: `set_max_bones()`, `set_max_instances()`, `set_instance_pose_bones()`. At bake time, we fill one row per animation frame. At render time, it sits idle — the texture is static.
|
|
||||||
|
|
||||||
**`MultiSkinnedInstance3D`** — the renderer. A `MultiMeshInstance3D` subclass. Points its multimesh at the skinned mesh and its `data_source_path` at the data plane. `refresh()` uploads the bone texture into the shader's uniform once. The MultiMesh handles instance transforms. The shader handles the rest.
|
|
||||||
|
|
||||||
The shader uses `INSTANCE_CUSTOM` to pick the palette row — not `INSTANCE_ID`. This is the key: the texture's rows are baked animation frames, not per-instance slots. Many instances share the same rows (a synchronized airborne flock) or each pick their own (a varied herd). One abstraction, two behaviors.
|
|
||||||
|
|
||||||
The engine change is 40 lines of shader code in `multi_skinned_instance_3d.cpp`. Engine version: **4.6.5.**
|
|
||||||
|
|
||||||
## The production pipeline
|
|
||||||
|
|
||||||
In Ariki, `AnimalHerdRenderer.cs` groups sim `ViewerState.animals` by type, feeds world positions and yaw rotations to `skinned_herd.gd` — the reusable per-type herd backend. The herd bakes the palette once at setup, then `set_positions()` updates transforms each sim tick. `set_clip_for_state()` switches the active clip block in the custom data when the sim FSM changes state (idle → walk → flee → attack). `set_speed_scale()` adjusts the per-instance playback rate to match ground speed — feet stay planted.
|
|
||||||
|
|
||||||
Bird flocks use the same system. `BirdFlock.cs` runs boid flocking on top of `skinned_herd`, sharing the palette with synchronized phases (airborne flapping in unison is intentional). 25 bird species migrated from the Low Poly Bird Ultimate Pack, each a single draw call.
|
|
||||||
|
|
||||||
The sim owns all behavior — 30 data-driven animals with per-animal senses, diet, combat stats, and FSM states. The client just renders. The same system will drive thousands of colonists at launch.
|
|
||||||
|
|
||||||
## Where we stand vs the industry
|
|
||||||
|
|
||||||
The bone-matrix palette technique is the same architecture used by Assassin's Creed Unity, Total War: Warhammer, and Hitman for their crowd systems. We're using the same core idea, in a Godot fork, with smaller VRAM (our low-poly animals keep textures tiny).
|
|
||||||
|
|
||||||
The platform supports three tiers by distance:
|
|
||||||
- **Crowd tier (palette)** — baked poses, GPU-driven, zero CPU. Thousands of agents.
|
|
||||||
- **Hero tier (real rigs)** — `AnimationTree` + `SkeletonIK3D` + `PhysicalBone3D` for the nearest few. Smooth gait blends, foot-lock, look-at, ragdoll.
|
|
||||||
- **Impostor tier (2D billboards)** — sprite atlas indexed by view-angle and animation-frame, driven by the same `(clip, frame, speed, phase)` packet. For very far agents.
|
|
||||||
|
|
||||||
The same abstraction — `(clip, count, speed, phase)` — drives every tier. One packet, three detail levels.
|
|
||||||
|
|
||||||
## Get the build
|
|
||||||
|
|
||||||
Pre-built editor binaries with `agent_skinned` and the GPU-driven palette baked in:
|
|
||||||
|
|
||||||
| Platform | Binary |
|
|
||||||
|----------|--------|
|
|
||||||
| **macOS ARM64** | [`tinqs.macos.editor.arm64.mono`](https://tinqs.com/tinqs/builds/media/branch/main/engine/macos-arm64/tinqs.macos.editor.arm64.mono) |
|
|
||||||
| **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) |
|
|
||||||
|
|
||||||
All builds at [`tinqs/builds`](https://tinqs.com/tinqs/builds). Engine source at [`tinqs/engine`](https://tinqs.com/tinqs/engine) (private).
|
|
||||||
|
|
||||||
The game's `animal_perf_test.tscn` spawns 10/100/1,000/10,000 animals and reports live FPS. The `animal_viewer.tscn` lets you inspect any animal type, toggle clips, and switch between single and herd mode.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
**Related:** [GPU-Skinned Herds](gpu-skinned-herds) — the original `agent_skinned` module design. [Fork, Don't Build](fork-dont-build) — why we modify existing platforms. [Streaming a 12km Archipelago in Godot 4](godot-optimisation) — the terrain and vegetation layers.
|
|
||||||
+123
-47
@@ -1,109 +1,185 @@
|
|||||||
---
|
---
|
||||||
title: "GPU-Skinned Herds: One Draw Call for 1,000 Animated Characters in Godot"
|
title: "GPU-Skinned Herds: One Draw Call for 1,000 Animated Characters in Godot"
|
||||||
slug: gpu-skinned-herds
|
slug: gpu-skinned-herds
|
||||||
date: "2026-06-14"
|
date: "2026-06-15"
|
||||||
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."
|
description: "Godot has no built-in way to render 1,000 skinned characters in one draw call. We built a GPU-driven crowd animation platform into Tinqs Engine that does — 1,000 animals at 60 FPS, each with its own clip and phase, zero per-frame CPU. 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_description: "One draw call, 1,000 animated characters, zero CPU. GPU-driven crowd animation platform built into the Tinqs Engine fork of Godot."
|
||||||
og_image: "https://www.tinqs.com/img/og-cover.jpg"
|
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."
|
excerpt: "Godot can't batch-render 1,000 animated characters. We built a GPU-driven crowd renderer into the engine itself — bake every animation frame into a texture once, let the GPU drive every instance. 1,000 animals, 60 FPS, zero skeletons. Pre-built editor binaries."
|
||||||
author: "Ozan Bozkurt"
|
author: "Ozan Bozkurt"
|
||||||
author_initials: "OB"
|
author_initials: "OB"
|
||||||
author_role: "CTO & Developer, Tinqs"
|
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.
|
Godot gives you one `Skeleton3D` per character. Want 200 animated animals? That's 200 skeleton nodes, 200 draw calls, and 200 `AnimationPlayer` ticks every frame. Want 1,000? You're measuring in seconds per frame.
|
||||||
|
|
||||||
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 confirmed first. Then we threw 1,000 animals — 12 types mixed, random-walking — at it and the GPU didn't flinch. Same bone count, same animation fidelity, a tiny fraction of the cost.
|
We built a GPU-driven crowd animation platform into Tinqs Engine that doesn't use skeletons at all. It bakes every animation frame into a bone-matrix palette texture once, and the GPU drives every instance's playback from then on. 1,000 animals at 60 FPS on integrated graphics. Each plays its own clip at its own speed and phase. Zero per-frame CPU cost. This is how AAA engines do crowds — and now it runs in our Godot fork.
|
||||||
|
|
||||||
## Why the engine needs to change
|
## 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:
|
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.
|
- **CPU bone transforms.** Computing `global_pose` for 1,000 skeletons × 60 bones each = 60,000 matrix multiplications 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.
|
- **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.
|
- **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.
|
Vertex animation textures (VAT) can solve this — bake every vertex position into a texture and sample it in the shader. But that stores **vertices × frames**, not bones × frames. A 2,500-vertex animal with 500 animation frames needs 14 MB of VAT data. For 30 animal types: 426 MB. That doesn't fit on a Steam Deck. And VAT can't blend frames for smooth playback, can't skin normals for correct lighting, and locks you into one animation per bake.
|
||||||
|
|
||||||
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.
|
Our answer: **bone-matrix palette.** Bake every bone pose into a texture, keep the skinning in the shader. The GPU samples the bone matrices and skins the mesh itself — same 4-bone linear blend as a real skeleton, same correct normals and tangents. But the CPU never touches a bone.
|
||||||
|
|
||||||
## How it works: two classes, one texture
|
## 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:
|
The module lives in `modules/agent_skinned/` inside [Tinqs Engine](https://tinqs.com/tinqs/engine). Two classes, one job.
|
||||||
|
|
||||||
### `MultiSkinnedMeshInstance3D` — the data plane
|
### `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:
|
Holds the bone-matrix palette. Allocates an `ImageTexture` of size `[4 × max_bones, total_frames]` in RGBA32F — each texel is one column of a 4×4 bone matrix, each row is one baked animation frame. At load time, we play every animation clip on a temporary skeleton and record the bone matrices for every frame:
|
||||||
|
|
||||||
```
|
```
|
||||||
Texture: 520 × 256 RGBA32F ≈ 2 MB
|
Goat: 53 bones × 9 clips × 496 frames
|
||||||
|
Texture: 212 × 496 pixels, RGBA32F
|
||||||
|
VRAM: 212 × 496 × 16 bytes = 1.6 MB
|
||||||
```
|
```
|
||||||
|
|
||||||
That's the entire pose state for 256 animated crocodiles in a single GPU texture. The API is simple:
|
That's every frame of every clip — walk, run, idle, attack, death, eat, sleep — in 1.6 MB. Across 30 animal types: **48 MB total.** Compare to VAT at 426 MB. Bone-matrix is 9× smaller because bones ≪ vertices.
|
||||||
|
|
||||||
|
After the bake, the skeleton is destroyed. It never runs again. The API is straightforward:
|
||||||
|
|
||||||
```gdscript
|
```gdscript
|
||||||
var data := MultiSkinnedMeshInstance3D.new()
|
var data := MultiSkinnedMeshInstance3D.new()
|
||||||
data.set_mesh(crocodile_mesh)
|
data.set_max_bones(53)
|
||||||
data.set_skeleton(skeleton) # rest pose + bone hierarchy
|
data.set_max_instances(496) # palette rows = baked frames
|
||||||
data.set_max_instances(256)
|
|
||||||
data.set_max_bones(130)
|
|
||||||
|
|
||||||
# Each frame: push poses from the animated skeleton
|
# Bake: play each clip, seek to each frame, record bone matrices
|
||||||
for instance in herd_positions:
|
for clip in clips:
|
||||||
data.set_instance_pose_bones(instance.id, bone_transforms)
|
for frame in clip.frames:
|
||||||
data.update() # upload only dirty instances, not the whole texture
|
skeleton.seek(frame.time)
|
||||||
|
data.set_instance_pose_bones(row, bone_transforms)
|
||||||
```
|
```
|
||||||
|
|
||||||
|
The data plane stores matrices column-major — 4 texels per bone = 4 columns of a 4×4 transform. The getter matches the layout, and a doctest asserts it so a transpose can't silently regress.
|
||||||
|
|
||||||
### `MultiSkinnedInstance3D` — the renderer
|
### `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.
|
A `MultiMeshInstance3D` subclass. Set its multimesh with the skinned mesh and instance transforms, point its `data_source_path` at the data plane. Call `refresh()` once — it uploads the bone texture into the shader material's `bone_matrices_tex` uniform.
|
||||||
|
|
||||||
The shader does 4-bone linear-blend skinning on the GPU:
|
Each MultiMesh instance carries 4 numbers in `INSTANCE_CUSTOM` (enable `multimesh.use_custom_data`):
|
||||||
|
|
||||||
|
| Channel | Meaning |
|
||||||
|
|---------|---------|
|
||||||
|
| `.x` | Which clip (start row in the palette) |
|
||||||
|
| `.y` | How many frames in this clip |
|
||||||
|
| `.z` | Playback rate (baked-fps × ground speed — foot-sync) |
|
||||||
|
| `.w` | Phase offset (golden-ratio spread — no two adjacent animals share the same frame) |
|
||||||
|
|
||||||
|
The vertex shader derives each instance's current frame from TIME:
|
||||||
|
|
||||||
```glsl
|
```glsl
|
||||||
mat4 get_bone(int b) {
|
float fpos = mod(TIME * INSTANCE_CUSTOM.z + INSTANCE_CUSTOM.w * INSTANCE_CUSTOM.y,
|
||||||
return mat4(
|
INSTANCE_CUSTOM.y);
|
||||||
texelFetch(bone_matrices_tex, ivec2(b * 4 + 0, INSTANCE_ID), 0),
|
int f0 = int(fpos);
|
||||||
texelFetch(bone_matrices_tex, ivec2(b * 4 + 1, INSTANCE_ID), 0),
|
int f1 = int(mod(float(f0) + 1.0, INSTANCE_CUSTOM.y));
|
||||||
texelFetch(bone_matrices_tex, ivec2(b * 4 + 2, INSTANCE_ID), 0),
|
float fr = fpos - float(f0);
|
||||||
texelFetch(bone_matrices_tex, ivec2(b * 4 + 3, INSTANCE_ID), 0)
|
|
||||||
);
|
// Blend between two adjacent frames for smooth playback at low bake fps
|
||||||
}
|
int r0 = int(INSTANCE_CUSTOM.x + 0.5) + f0;
|
||||||
|
int r1 = int(INSTANCE_CUSTOM.x + 0.5) + f1;
|
||||||
|
|
||||||
|
// For each bone (up to 4 per vertex), reconstruct mat4 from 4 texels, blend, weight
|
||||||
|
mat4 m0 = mat4(
|
||||||
|
texelFetch(bone_matrices_tex, ivec2(b*4 + 0, r0), 0),
|
||||||
|
texelFetch(bone_matrices_tex, ivec2(b*4 + 1, r0), 0),
|
||||||
|
texelFetch(bone_matrices_tex, ivec2(b*4 + 2, r0), 0),
|
||||||
|
texelFetch(bone_matrices_tex, ivec2(b*4 + 3, r0), 0));
|
||||||
|
mat4 m1 = mat4( /* same for r1 */ );
|
||||||
|
skin += (m0 * (1.0 - fr) + m1 * fr) * weight;
|
||||||
|
|
||||||
|
// Apply skin to vertex, normal, tangent
|
||||||
|
VERTEX = (skin * vec4(VERTEX, 1.0)).xyz;
|
||||||
|
NORMAL = normalize((skin * vec4(NORMAL, 0.0)).xyz);
|
||||||
```
|
```
|
||||||
|
|
||||||
`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.
|
The shader uses `INSTANCE_CUSTOM` to pick the palette row — not `INSTANCE_ID`. This is the key: the texture's rows are baked animation frames, not per-instance slots. Many instances share the same rows (a synchronized airborne flock) or each pick their own (a varied herd). One abstraction, two behaviors.
|
||||||
|
|
||||||
## Two bugs we shipped and fixed
|
The blend between two adjacent frames means we can bake at a low fps and stay smooth — the shader interpolates. The golden-ratio phase spread means every animal in a herd reads a different frame. One draw call per animal type. Zero CPU. Per-instance clip, speed, and phase — all in the GPU.
|
||||||
|
|
||||||
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.
|
The shader ships as the default material on `MultiSkinnedInstance3D`. It includes an `albedo_tex` uniform — the caller sets it from the source mesh's material so herds texture out of the box. No `ShaderMaterial` assembly required unless you want custom shading.
|
||||||
|
|
||||||
**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.
|
## The numbers
|
||||||
|
|
||||||
**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.
|
Measured on an M1 Pro MacBook Pro (integrated GPU):
|
||||||
|
|
||||||
The lesson: doctests catch logic. Rendering catches truth. You need both.
|
| Agent count | FPS |
|
||||||
|
|------------|-----|
|
||||||
|
| 100 | **60** |
|
||||||
|
| 500 | **60** |
|
||||||
|
| 1,000 | **60** |
|
||||||
|
| 10,000 | 8 (with CPU-side culling, pre-optimization) |
|
||||||
|
|
||||||
|
**VRAM:** 1.6 MB per animal type. 30 types = 48 MB total. A Steam Deck with 1 GB shared memory fits the entire roster.
|
||||||
|
|
||||||
|
**Draw calls:** One per animal type. 30 types = 30 draw calls for every animated animal on screen. Future colonists share the same architecture — one draw call per colonist look.
|
||||||
|
|
||||||
## What's driving it
|
## 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.
|
In [Ariki](https://www.arikigame.com), the sim tracks animal migration across a 12km archipelago. `AnimalHerdRenderer.cs` groups sim `ViewerState.animals` by type, feeds world positions and yaw rotations to `skinned_herd.gd` — the reusable per-type herd backend. The herd bakes the palette once at setup, then `set_positions()` updates transforms each sim tick. `set_clip_for_state()` switches the active clip block in the custom data when the sim FSM changes state. `set_speed_scale()` adjusts the per-instance playback rate to match ground speed — feet stay planted.
|
||||||
|
|
||||||
The crocodile herd scene was 25 instances, one draw call. The perf test scene does 1,000 animals across 12 types — Boar, Cow, Crab, Crocodile, Deer, Fish, Goat, Hen, Pig, Rabbit, Sheep, Tiger — each type its own GPU herd, all mixed, all random-walking, FPS holding steady.
|
The sim owns all behavior — 30 data-driven animals with per-animal senses, diet, combat stats, and FSM states (graze, drink, sleep, hunt, flee, scavenge, die). The client just renders. This is the same code in single-player and multiplayer — the sim is the host.
|
||||||
|
|
||||||
|
Bird flocks use the same system. `BirdFlock.cs` runs boid flocking on top of `skinned_herd`, sharing the palette with synchronized phases (airborne flapping in unison is intentional). 25 bird species migrated from the Low Poly Bird Ultimate Pack, each a single draw call.
|
||||||
|
|
||||||
|
Per-instance custom data means a walking Boar, a running Boar, an idle Boar, and an attacking Boar all share the same baked palette — they just point at different rows. The renderer groups by type, not by state. One palette, one draw call, any number of states.
|
||||||
|
|
||||||
|
## 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, column-major layout. All green. Then we put it on screen and two things were 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 initial data plane wrote basis rows (standard Godot `Transform3D.basis` is row-major), but the shader reads `mat4(c0,c1,c2,c3)` 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.
|
||||||
|
|
||||||
|
## The engine change
|
||||||
|
|
||||||
|
The module is 40 lines of shader code and ~500 lines of C++ in the engine's `modules/agent_skinned/`. The critical detail is in the shader: the bone-matrix texture is indexed by a **pose slot** computed from `INSTANCE_CUSTOM`, not by `INSTANCE_ID`. This is what decouples the palette from the instance count — the texture stores animation frames, the MultiMesh stores instance transforms, and the shader bridges them.
|
||||||
|
|
||||||
|
Engine version: **4.6.5.**
|
||||||
|
|
||||||
|
No C# wrapper is generated — instantiate from GDScript via `ClassDB.instantiate()` and call the bound methods. The binding surface is small and stable. See `ariki-game/scenes/animals/skinned_herd.gd` for the reference backend.
|
||||||
|
|
||||||
|
## The production pipeline
|
||||||
|
|
||||||
|
The `migrate_animals.py` tool converts polyperfect FBX packs to game-ready GLBs — imports, cleans hierarchy, rebuilds named NLA clips from frame ranges, strips duplicate meshes, bakes into the flat `assets/models/glbs/` directory. Each animal gets a catalog entry in `animals_catalog.json` with clip metadata, default state mapping, and an `animSpeedRef` for foot-sync.
|
||||||
|
|
||||||
|
At runtime, `AnimalHerdRenderer` spawns one `skinned_herd` per animal type. The herd bakes the palette from the catalog GLB's clips. `AnimalAnimationLogic` maps sim FSM states to clip keywords (attack → "attack"/"bite", flee → "run"/"gallop", wander → "walk"). The renderer lerps positions between sim ticks for smooth motion and writes per-instance custom data each frame. Zero per-frame CPU on the animation path.
|
||||||
|
|
||||||
|
## Where we stand vs the industry
|
||||||
|
|
||||||
|
The bone-matrix palette technique is the same architecture used by Assassin's Creed Unity, Total War: Warhammer, and Hitman for their crowd systems. We're using the same core idea, in a Godot fork, with smaller VRAM — our low-poly animals keep textures tiny.
|
||||||
|
|
||||||
|
The platform supports three tiers by distance, all driven by the same `(clip, count, speed, phase)` packet:
|
||||||
|
- **Crowd tier (palette)** — baked poses, GPU-driven, zero CPU. Thousands of agents.
|
||||||
|
- **Hero tier (real rigs)** — `AnimationTree` + `SkeletonIK3D` + `PhysicalBone3D` for the nearest few. Smooth gait blends, foot-lock, look-at, ragdoll.
|
||||||
|
- **Impostor tier (2D billboards)** — sprite atlas indexed by view-angle and animation-frame. For very far agents.
|
||||||
|
|
||||||
|
One abstraction, three detail levels. The same code that drives 30 animals today will drive thousands of colonists at launch.
|
||||||
|
|
||||||
## What's deliberately not here
|
## What's deliberately not here
|
||||||
|
|
||||||
- **No C# wrapper.** Instantiate from GDScript via `ClassDB.instantiate()` — the binding surface is small and stable.
|
- **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 automatic `AnimationPlayer` integration.** You drive poses at bake time. 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.
|
- **No GPU occlusion culling.** That's the game's job. The engine provides the tool; the game decides what to draw.
|
||||||
|
|
||||||
## Get the build
|
## Get the build
|
||||||
|
|
||||||
Pre-built editor binaries with `agent_skinned` baked in — no engine compile required. The game's `animal_perf_test.tscn` lets you toggle 10 / 100 / 1000 animals and read live FPS:
|
Pre-built editor binaries with `agent_skinned` and the GPU-driven palette baked in — no engine compile required. The game's `animal_perf_test.tscn` lets you spawn 10/100/1,000/10,000 animals and read live FPS:
|
||||||
|
|
||||||
| Platform | Binary | Engine commit |
|
| Platform | Binary |
|
||||||
|----------|--------|---------------|
|
|----------|--------|
|
||||||
| **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) |
|
| **macOS ARM64** | [`tinqs.macos.editor.arm64.mono`](https://tinqs.com/tinqs/builds/media/branch/main/engine/macos-arm64/tinqs.macos.editor.arm64.mono) |
|
||||||
| **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) |
|
| **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) |
|
||||||
|
|
||||||
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.
|
All builds at [`tinqs/builds`](https://tinqs.com/tinqs/builds) — 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`.
|
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`.
|
||||||
|
|
||||||
|
|||||||
+50
-81
@@ -277,45 +277,33 @@
|
|||||||
<a href="/blog/" class="post__back">← All Posts</a>
|
<a href="/blog/" class="post__back">← All Posts</a>
|
||||||
<span class="post__date">25 May 2026</span>
|
<span class="post__date">25 May 2026</span>
|
||||||
<h1 class="post__title">A Pre-Commit Agent That Guards Your Secrets for $0.001</h1>
|
<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 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>
|
||||||
|
|
||||||
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.
|
<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>
|
||||||
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>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>
|
||||||
## Layer 1: Regex blocklist (0ms, $0.00)
|
<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 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|github\.com/(tinqs-ltd|tinqs)/|GitHub repos deleted — use tinqs.com
|
||||||
all|sk-[a-zA-Z0-9]{20,}|Possible API key leaked
|
all|sk-[a-zA-Z0-9]{20,}|Possible API key leaked
|
||||||
all|AKIA[A-Z0-9]{16}|AWS access key leaked
|
all|AKIA[A-Z0-9]{16}|AWS access key leaked
|
||||||
public|admin\.<internal-domain>|Internal admin URL in public content
|
public|admin\.<internal-domain>|Internal admin URL in public content</code></pre>
|
||||||
</code>`<code>
|
<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>
|
||||||
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.
|
<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>
|
||||||
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.
|
<ul>
|
||||||
|
<li><strong>Leaked secrets</strong> — API keys, tokens, credentials the regex might have missed</li>
|
||||||
## Layer 2: DeepSeek V4 Flash review (~4s, $0.001)
|
<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>
|
||||||
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:
|
<li><strong>Blog quality</strong> — title length, meta description, slug consistency</li>
|
||||||
|
<li><strong>Broken links</strong> — malformed URLs, obvious typos</li>
|
||||||
- <strong>Leaked secrets</strong> — API keys, tokens, credentials the regex might have missed
|
<li><strong>Announcements</strong> — if it's a new blog post, draft a one-line summary</li>
|
||||||
- <strong>Classified terms</strong> — codenames not yet in the blocklist
|
</ul>
|
||||||
- <strong>Internal URLs</strong> — references to services that shouldn't be public
|
<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>
|
||||||
- <strong>Blog quality</strong> — title length, meta description, slug consistency
|
<h2>The architecture</h2>
|
||||||
- <strong>Broken links</strong> — malformed URLs, obvious typos
|
<pre><code>git commit
|
||||||
- <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)
|
Phase 0: Collect staged diff + classify files (public vs internal)
|
||||||
↓
|
↓
|
||||||
@@ -331,52 +319,33 @@ Phase 3: Parse JSON response
|
|||||||
→ Errors → BLOCK
|
→ Errors → BLOCK
|
||||||
→ Warnings → print, exit 0
|
→ Warnings → print, exit 0
|
||||||
→ Announcement → print draft
|
→ Announcement → print draft
|
||||||
→ API failure → warn, exit 0 (never block on infra)
|
→ API failure → warn, exit 0 (never block on infra)</code></pre>
|
||||||
</code>`<code>
|
<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>
|
||||||
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>| | Tokens | Cost |</p>
|
||||||
|
<p>|–|——–|——|</p>
|
||||||
## What it costs
|
<p>| Input (prompt + diff) | ~4,000 | $0.00056 |</p>
|
||||||
|
<p>| Output (JSON response) | ~200 | $0.00006 |</p>
|
||||||
| | Tokens | Cost |
|
<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>
|
||||||
| Input (prompt + diff) | ~4,000 | $0.00056 |
|
<h2>What it caught (first week)</h2>
|
||||||
| Output (JSON response) | ~200 | $0.00006 |
|
<ul>
|
||||||
| <strong>Per commit</strong> | | <strong>$0.00062</strong> |
|
<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>
|
||||||
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.
|
<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>
|
||||||
## What it caught (first week)
|
</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>
|
||||||
- <strong>2 classified codename leaks</strong> in draft blog posts — caught by blocklist
|
<h2>Setup</h2>
|
||||||
- <strong>1 GitHub URL</strong> from an old copy-paste — caught by blocklist
|
<pre><code class="language-bash">bash scripts/setup-hooks.sh # or .\scripts\setup-hooks.ps1 on Windows
|
||||||
- <strong>3 blog SEO warnings</strong> — titles over 60 chars, missing og_description — caught by AI
|
export TINQS_HOOK_TOKEN=<your-token> # same PAT used for git push</code></pre>
|
||||||
- <strong>1 announcement draft</strong> auto-generated when a new post was committed
|
<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>
|
||||||
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>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>
|
||||||
## Setup
|
<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>
|
||||||
</code>`<code>bash
|
<p><em>The pre-commit hook is part of <a href="https://tinqs.com" style="color: var(--c-lime);">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-lime);">Ariki</a> runs through the same guard.</em></p>
|
||||||
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-lime);">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-lime);">Ariki</a> runs through the same guard.</em></p>
|
|
||||||
|
|
||||||
<div class="post__body">
|
|
||||||
|
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
|||||||
|
Before
After
|
+36
-56
@@ -277,64 +277,44 @@
|
|||||||
<a href="/blog/" class="post__back">← All Posts</a>
|
<a href="/blog/" class="post__back">← All Posts</a>
|
||||||
<span class="post__date">18 May 2026</span>
|
<span class="post__date">18 May 2026</span>
|
||||||
<h1 class="post__title">One Binary to Rule Them All: Our Studio CLI</h1>
|
<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 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>
|
||||||
|
|
||||||
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-lime);">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">
|
<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-lime);">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>
|
</div>
|
||||||
|
|
||||||
|
|||||||
|
Before
After
|
@@ -277,28 +277,21 @@
|
|||||||
<a href="/blog/" class="post__back">← All Posts</a>
|
<a href="/blog/" class="post__back">← All Posts</a>
|
||||||
<span class="post__date">10 June 2026</span>
|
<span class="post__date">10 June 2026</span>
|
||||||
<h1 class="post__title">Why Voice Is the Missing Input for Game Development</h1>
|
<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 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>
|
||||||
|
|
||||||
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.
|
<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>
|
||||||
## The latency that kills bug reports
|
<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>
|
||||||
The distance between seeing a bug and filing it is a memory decay curve. Every second that passes, your recollection loses precision:
|
<p>| Elapsed time | What you remember |</p>
|
||||||
|
<p>|—|—|</p>
|
||||||
| Elapsed time | What you remember |
|
<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>
|
||||||
| 0 seconds | Exact position, camera angle, what you were doing, what's on screen |
|
<p>| 5 minutes | "I think there was a rendering issue? Or was it yesterday?" |</p>
|
||||||
| 30 seconds | "There was a tree... somewhere west... maybe floating?" |
|
<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>
|
||||||
| 5 minutes | "I think there was a rendering issue? Or was it yesterday?" |
|
<h2>The pipeline: voice → text → structured issue</h2>
|
||||||
|
<p>Here's what actually happens when you speak a bug during playtesting:</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.
|
<pre><code>1. You speak: "There's a tree floating two meters above the terrain
|
||||||
|
|
||||||
## 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
|
on the west beach, near the big rock formation. Happens after
|
||||||
the vegetation culling pass kicks in around sunset."
|
the vegetation culling pass kicks in around sunset."
|
||||||
|
|
||||||
@@ -316,68 +309,39 @@ Here's what actually happens when you speak a bug during playtesting:
|
|||||||
5. Agent files a structured issue with all of the above,
|
5. Agent files a structured issue with all of the above,
|
||||||
tags the rendering engineer, and posts the digest to team chat.
|
tags the rendering engineer, and posts the digest to team chat.
|
||||||
|
|
||||||
Total latency: under 2 seconds. You keep playing.
|
Total latency: under 2 seconds. You keep playing.</code></pre>
|
||||||
</code>``
|
<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>
|
||||||
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><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>
|
||||||
## Why game dev is the perfect voice use case
|
<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>
|
||||||
<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.
|
<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>
|
||||||
<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><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>
|
||||||
<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><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>
|
||||||
<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.
|
<h2>The numbers</h2>
|
||||||
|
<p>| Method | Time from observation to filed issue | Information loss |</p>
|
||||||
## What the agent adds beyond transcription
|
<p>|—|—|—|</p>
|
||||||
|
<p>| Mental note → type later | 5-30 minutes | High (positions, steps, context) |</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>| 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>
|
||||||
<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>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>
|
||||||
<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>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>
|
||||||
<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>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>
|
||||||
<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>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>
|
||||||
## The numbers
|
<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>
|
||||||
| Method | Time from observation to filed issue | Information loss |
|
<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>
|
||||||
| Mental note → type later | 5-30 minutes | High (positions, steps, context) |
|
<hr>
|
||||||
| Alt-tab → type immediately | 30-60 seconds | Medium (screenshots missed, flow broken) |
|
<p><em>We build <a href="https://tinqs.com" style="color: var(--c-lime);">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-lime);">Ariki</a> is the survival colony sim we're building with every tool described here.</em></p>
|
||||||
| 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-lime);">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-lime);">Ariki</a> is the survival colony sim we're building with every tool described here.</em></p>
|
|
||||||
|
|
||||||
<div class="post__body">
|
|
||||||
|
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
|||||||
|
Before
After
|
Reference in New Issue
Block a user