From f01036c646e28a1bfea924d713264eef844205fb Mon Sep 17 00:00:00 2001 From: tinqs-limited Date: Wed, 3 Jun 2026 03:06:41 +0100 Subject: [PATCH] rewrite: refresh all blog posts for public audience MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Merged overlapping posts: - forking-gitea + fork-dont-build → one post about the fork philosophy - fal-image-generation + image-generation-fal → one post about AI art pipeline Rewrote all posts with external/public voice: - Stronger hooks, concrete examples, punchier language - agentic-workflow: restructured around soul files + skills + numbers - agent-harness: clearer framing of 'what an agent harness is' - cloud-harness: tighter narrative about overnight agents - godot-optimisation: same depth, sharper opening - pre-commit-agent: clearer architecture, cost breakdown - studio-cli: reframed around identity/cold-start problem - blog-visual-upgrade: tightened the restyle story 10 posts total (9 markdown + 1 hand-authored HTML) --- agent-harness.html | 192 +++++--------------- agentic-workflow.html | 121 ++++++------- blog-visual-upgrade.html | 215 +++++----------------- cloud-harness.html | 128 +++++-------- fal-image-generation.html | 172 ++++++++---------- fork-dont-build.html | 126 ++++++------- forking-gitea.html | 310 ------------------------------- godot-optimisation.html | 110 +++++------ image-generation-fal.html | 332 ---------------------------------- index.html | 46 ++--- posts/agent-harness.md | 149 ++++----------- posts/agentic-workflow.md | 131 ++++++-------- posts/blog-visual-upgrade.md | 274 +++++----------------------- posts/cloud-harness.md | 129 +++++-------- posts/fal-image-generation.md | 189 +++++++++---------- posts/fork-dont-build.md | 165 ++++++++--------- posts/forking-gitea.md | 77 -------- posts/godot-optimisation.md | 120 +++++------- posts/image-generation-fal.md | 122 ------------- posts/pre-commit-agent.md | 121 +++++-------- posts/studio-cli.md | 72 ++++---- pre-commit-agent.html | 100 +++++----- studio-cli.html | 78 ++++---- 23 files changed, 933 insertions(+), 2546 deletions(-) delete mode 100644 forking-gitea.html delete mode 100644 image-generation-fal.html delete mode 100644 posts/forking-gitea.md delete mode 100644 posts/image-generation-fal.md diff --git a/agent-harness.html b/agent-harness.html index 4c795e4..8d88343 100644 --- a/agent-harness.html +++ b/agent-harness.html @@ -4,27 +4,27 @@ - Tinqs Studio Is an Agent Harness for Game Dev — Tinqs Blog - + What an Agent Harness Is and Why Game Dev Needs One — Tinqs Blog + - - + + - - + + @@ -218,148 +218,44 @@
← All Posts 25 May 2026 -

Tinqs Studio Is an Agent Harness for Game Dev

-

An agent harness is the layer between a raw AI model and a useful team member. It gives the agent identity, memory, tools, and guardrails. Tinqs Studio is an agent harness built specifically for game development. - -## What Is an Agent Harness? - -A raw AI model — Claude, GPT, Gemini — is powerful but stateless. It doesn't know who you are, what project you're working on, what tools are available, or what happened yesterday. Every session is a cold start. Every conversation begins with "let me explain the project..." - -An agent harness solves this. It wraps around the model and provides: - -- Identity — who the agent is, what it values, how it should behave -- Memory — what happened in previous sessions, what was decided, what failed -- Tools — what the agent can actually do beyond generating text -- Context — what project this is, who's asking, what infrastructure exists -- Guardrails — what the agent must never do, what requires human approval - -Without a harness, you have a chatbot. With one, you have a team member. - -## Why Game Dev Needs Its Own Harness - -Generic agent harnesses exist — LangChain, CrewAI, AutoGen. They're built for web apps, data pipelines, and customer support. Game development has different problems: - -Assets are binary. A web developer's PR is a text diff. A game developer's PR is a 150MB GLB file. Generic harnesses don't know how to preview 3D models, manage LFS bandwidth, or review binary assets. - -The pipeline is visual. Game dev goes from concept art to 3D model to rigged character to in-engine asset. Each step uses different tools — image generators, 3D modellers, auto-riggers, game engines. An agent harness for game dev needs to orchestrate this entire chain. - -Scale is physical. A web app's complexity is in business logic. A game's complexity is in geometry — 12km worlds, 155 vegetation prototypes, 576 terrain regions, 2000 crowd instances. The agent needs to understand spatial systems, GPU memory, and frame budgets. - -The team is small and cross-functional. A 4-person game studio has no dedicated DevOps, no dedicated artist, no dedicated PM. The harness needs to fill all those gaps, not just one. - -## How Tinqs Studio Works as a Harness - -Tinqs Studio is a platform built on a Gitea fork with game-specific features layered on top. But the git platform is just the foundation. The harness is everything around it. - -### Identity: Soul Files - -Every agent session starts by loading a soul file — a markdown document that defines the agent's persistent identity. Not just "you are a helpful assistant" but specific values, knowledge scope, and behavioural rules. - -The soul file means the agent behaves consistently whether it's triaging bugs at 9am or generating concept art at midnight. It knows what repos exist, who the team members are, what the game is about, and what decisions have been made. Identity isn't cosmetic — it's the difference between an agent that asks "what project is this?" and one that says "I see the vegetation grid was updated yesterday, want me to check the cache eviction?" - -### Memory: Markdown Files in Git - -Agent memory is plain markdown files in a git repository. No vector databases, no proprietary stores. The agent reads its memory on session start, updates it during work, and commits changes back. - -This is deliberately low-tech. Markdown in git gives you version history, branching, merge conflict resolution, and human readability for free. When memory goes wrong — and it will — you can git log to see what changed and git revert to fix it. - -### Tools: The CLI - -A single Go binary gives every agent access to: - -- Identity loading — full project context in 100ms -- Screenshots — capture any window from outside the process -- Cloud vision — send screenshots to a vision model, get structured descriptions -- Health checks — verify services, repos, and tools are working -- Service status — which URLs are live, what's reachable - -The CLI is the agent's hands and eyes. Without it, the agent can only read and write text. With it, the agent can see the game running, photograph bugs, and verify infrastructure. - -### Skills: Teachable Workflows - -Skills are markdown playbooks that teach agents specific procedures. Instead of hoping the model figures out how to generate concept art or create a 3D model, you write the steps once: - -- Image Generation — generate game art with fal.ai Flux using a 4-layer prompt pattern -- Concept Art Pipeline — from design brief through 2D art to 3D model export -- 3D Model Generation — Tripo Studio text-to-3D and image-to-3D -- Video Generation — trailer clips with OpenAI Sora 2 - -Skills compound. Every playbook you write makes the agent more capable. After six months, our agents handle art generation, competitive research, video production, project management, and code review — all from markdown files. - -### Git Platform: 3D Preview and LFS - -The Gitea fork underneath handles the game-specific git problems: - -- 3D asset preview — rotate GLB/FBX/STL files in the browser during code review -- LFS-first workflows — auto-tracking for game file extensions, storage dashboards -- OAuth2 SSO — one login for git, tools, and the game -- 22 format support — GLB, FBX, OBJ, STL, 3DS, PLY, and more via O3DV - -### Guardrails: Human-in-the-Loop - -The harness defines what agents can and cannot do: - -- Agents can file issues, draft announcements, generate assets, write code -- Agents cannot merge code, deploy builds, push to public repos, or post to external channels without human approval -- The public blog repo requires human-approved merge requests — agents can propose changes but a person must review - -This isn't a limitation — it's a feature. The agent handles volume; the human handles judgement. - -## The Cold Start Problem - -The biggest problem with AI agents in production isn't capability — it's context. Every new session is blank. The agent doesn't know what happened yesterday, what's in progress, or what tools are available. - -Most teams solve this with long system prompts. That works until your context is 200 markdown files, 15 skills, and 3 years of project history. You can't paste all of that into a system prompt. - -The harness solves this with staged loading: - -1. CLI identity call (100ms) — loads soul file, company context, machine info, service status -2. Memory file (instant) — loads cross-session context -3. Skills (on demand) — loaded only when the task matches a skill name -4. Repo context (on demand) — read files as needed, not all upfront - -The agent goes from cold to fully contextual in under a second. No "let me explain..." No re-reading the same onboarding doc. Just start working. - -## What Makes This Different from LangChain - -LangChain, CrewAI, and similar frameworks are code-first. You define agents in Python, chain them with function calls, and deploy them as services. They're powerful for building AI products. - -Tinqs Studio is file-first. Agents are defined in markdown. Skills are markdown. Memory is markdown. Identity is markdown. Everything is in git, readable by humans, editable without code changes, and version-controlled. - -This matters for game teams because: - -- Non-engineers can contribute. The designer writes a skill for concept art. The PM writes a skill for sprint planning. No Python required. -- Everything is auditable. git log shows who changed what, when, and why. Memory changes are commits. Skill updates are diffs. -- It works with any AI tool. The same soul files and skills work in Cursor, Claude Code, or any tool that reads markdown. You're not locked into one framework. - -## The Stack - -| Layer | What | How | -|——-|——|—–| -| Identity | Soul files, company context | Markdown in git, loaded via CLI | -| Memory | Cross-session context | Markdown in git, updated by agents | -| Skills | Teachable workflows | Markdown playbooks, loaded on demand | -| Tools | CLI, screenshots, vision | Go binary, one install per machine | -| Git | 3D preview, LFS, SSO | Gitea fork with game-specific features | -| Creative | Image gen, 3D models, video | fal.ai, Tripo, Sora 2 via skills | -| Guardrails | Human approval gates | Branch protection, MR requirements | - -## Getting Started - -If you want to build your own agent harness for game dev: - -1. Start with a soul file. Write 50 words about your project's identity, values, and scope. Put it in your repo root as SOUL.md. -2. Write one skill. Pick the workflow you repeat most — concept art generation, bug triage, build verification — and write the steps as markdown. -3. Build a CLI identity command. Even a shell script that prints "project name, repos, services" gives your agent a warm start. -4. Put everything in git. Not a database, not a SaaS tool. Git. You already have it. - -The rest — 3D preview, LFS management, OAuth SSO, creative pipelines — you can add as you need it. Or use Tinqs Studio, where we've already built it. - -— - -An agent harness isn't a product category yet. But it should be. 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. That's what we're building.

+

What an Agent Harness Is and Why Game Dev Needs One

+

Open Claude or ChatGPT right now and ask it to review your last PR. It'll say "I don't have access to your repository." Ask it to take a screenshot of your game. It'll say "I can't interact with your operating system." Ask it what you were working on yesterday. It'll say "I don't have memory of previous conversations."

+

A raw AI model is a brain without hands, eyes, or memory. An agent harness 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:

+

Identity. 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.

+

Memory. 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 git log instead of debugging a vector database.

+

Tools. 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.

+

Context. Which project this is. Who's asking. What machine they're on. What services are reachable. A single CLI call — tstudio identity — returns all of this in 100ms. No re-reading the README. No "what repo are we in?"

+

Guardrails. 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:

+

Assets are binary. 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.

+

The pipeline is visual. 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.

+

Scale is physical. 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.

+

The team is small and cross-functional. 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 Tinqs Studio, built on a Gitea fork with game-specific features. The key pieces:

+

The CLI — a single Go binary. One command (tstudio identity) gives the agent full project context in 100ms. Screenshots, cloud vision, health checks — all subcommands of the same binary.

+

The soul file — 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.

+

Skills — 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.

+

3D preview — click a .glb 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.

+

Guardrails — 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. CLI identity call (100ms) — soul file, company context, machine info, service status

+

2. Memory file (instant) — cross-session context from the docs repo

+

3. Skills (on demand) — loaded only when the task matches a skill name

+

4. Repo context (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.

+
+

Tinqs Studio is an agent harness for game development — git hosting, AI agents, creative pipelines. Open for teams. We're building Ariki with the same tools.

diff --git a/agentic-workflow.html b/agentic-workflow.html index 0764e98..94de2fd 100644 --- a/agentic-workflow.html +++ b/agentic-workflow.html @@ -4,19 +4,19 @@ - How a Small Game Studio Runs on AI Agents — Tinqs Blog - + How a 4-Person Studio Runs on AI Agents — Tinqs Blog + - + - + @@ -24,7 +24,7 @@ { "@context": "https://schema.org", "@type": "BlogPosting", - "headline": "How a Small Game Studio Runs on AI Agents", + "headline": "How a 4-Person Studio Runs on AI Agents", "datePublished": "2026-03-06", "author": { "@type": "Person", @@ -35,7 +35,7 @@ "name": "Tinqs Limited", "url": "https://www.tinqs.com" }, - "description": "Soul files, skill playbooks, and markdown as the universal API. How we built an agentic workflow that lets a 4-person indie studio operate at 10x scale." + "description": "We gave AI agents persistent identities, skill playbooks, and access to our entire knowledge base. Here's how four people ship like forty." } @@ -218,74 +218,63 @@
← All Posts 6 March 2026 -

How a Small Game Studio Runs on AI Agents

-

We gave our AI agents persistent identities, skill playbooks, and access to our entire knowledge base. This is how a 4-person game studio built an agentic workflow that punches above its weight.

+

How a 4-Person Studio Runs on AI Agents

+

Last week one of our agents caught a stale bug at 3am — a vegetation culling issue that had been open for six days. It nudged the team chat, drafted a fix summary, and by morning the issue was resolved. Nobody lost sleep. Nobody context-switched. The agent just handled it.

-

The Problem Every Small Studio Knows

-

When you're four people building a game, there's no room for a dedicated DevOps person, a full-time PM tool chain, or someone whose job it is to "keep things organised." Everyone wears five hats. Documentation drifts. Issues pile up. The left hand doesn't know what the right hand shipped.

-

We tried the usual tools — Notion, Trello, shared Google Docs. They all had the same problem: they're passive. They sit there and wait for a human to update them. In a team of four where the lead developer is also the CTO, that human never has time.

-

So we built something different. We gave AI agents persistent identities, connected them to our entire knowledge base, and let them become working members of the team.

-

The Architecture: Agents with Identity

-

Our primary AI agent runs inside the IDE and has access to the full documentation repository — the game design document, backlog, meeting notes, company operations, everything. It's not a chatbot. It's a persistent team member with a soul file that defines its values and operating principles, and a memory file that persists context across sessions.

-

The key insight: all knowledge lives in markdown files in one repo. No databases, no SaaS dashboards, no proprietary formats. Plain text, version-controlled, readable by humans and agents alike. When anyone on the team opens the docs repo, the agent wakes up with full context of who they are, what machine they're on, and what's been happening.

-

What the agent actually does

+

This is what happens when you stop treating AI as a chatbot and start treating it as a team member with a persistent identity, a memory, and a set of skills it can actually execute.

+

The problem with "just use ChatGPT"

+

Every small studio hits the same wall: four people, forty roles. Nobody has time to keep documentation current. Bugs pile up. The backlog rots. Someone asks "what did we decide about the inventory system?" and three different answers come back.

+

The usual fix is more tools — Notion, Trello, Linear, Slack integrations. But tools are passive. They sit there waiting for humans to update them. In a team where the lead developer is also the CTO, that human is already stretched thin.

+

We tried something different. Instead of adding more tools for humans to maintain, we gave AI agents persistent identities, connected them to our entire knowledge base, and let them do the maintenance.

+

Soul files: giving agents a personality that sticks

+

The core idea is embarrassingly simple. Every agent gets a soul file — a markdown document that defines who it is, what it values, and how it should behave:

+
    +
  • Values — "never break the build," "always verify before acting," "prefer existing patterns over novelty"
    • +
  • Knowledge scope — what repos exist, who's on the team, what the game is about
    • +
  • Behavioural rules — when to act autonomously, when to ask, what requires explicit human approval
    • +
+

This isn't theatre. It's the difference between an agent that asks "what project is this?" every session and one that says "I see the vegetation grid was updated yesterday — want me to check the cache eviction?"

+

The soul file loads in 100ms when the agent starts. No cold starts. No re-explaining.

+

Memory: markdown in git, not a vector database

+

Agent memory lives as plain markdown files in our docs repo. No vector databases, no proprietary stores, no SaaS dashboards. The agent writes to its memory file during work, commits it, and reads it on the next session.

+

This is deliberately low-tech. Markdown in git gives you version history, diffs, branching, and human readability for free. When memory goes wrong — and it will — you git log to see what changed and git revert to fix it. Try debugging a corrupted vector embedding at 11pm.

+

Skills: teachable playbooks, not prompt engineering

+

Agents don't just have instructions. They have skills — markdown playbooks that teach specific workflows. When someone says "generate concept art for a character," the agent reads skills/image-generation.md and follows the procedure. No prompt engineering per session. No "let me try a different prompt."

+

We've open-sourced several skills:

+ +

Each skill took about 30 minutes to write. After six months, our agents have 15+ skills covering art generation, competitive research, video production, and project management. Skills compound — every playbook you write makes every future session more capable.

+

What the agents actually do, every day

+

During the day (interactive, inside the IDE):

  • Triages and grooms the issue backlog
    • -
  • Keeps documentation in sync with the game state
    • -
  • Processes bug reports from testers and creates structured issues
    • -
  • Drafts team announcements, reviews PRs, manages cross-repo coordination
    • -
  • Generates concept art, trailer frames, and UI assets using integrated API skills
    • -
  • Conducts competitive research — analysing Steam pages, player reviews, pricing strategies
    • +
  • Keeps documentation in sync with what's actually in the game
    • +
  • Processes tester bug reports and creates structured issues
    • +
  • Generates concept art, trailer frames, UI icons on demand
    • +
  • Conducts competitive research — Steam pages, player reviews, pricing
-

The team talks to the agent through voice. The IDE's built-in microphone transcribes and auto-translates (multilingual team). The agent is trained to interpret messy voice-to-text artifacts and act on intent, not grammar.

-

Background Automation

-

The interactive agent only runs when someone opens the IDE. But a studio doesn't sleep — bugs get reported at midnight, issues go stale, and the team chat fills up while everyone's away.

-

A background daemon runs 24/7, ticking every 15 minutes. It uses a three-tier model strategy — cheap models for routine checks, medium for analysis, and premium only when it needs deep reasoning. The whole thing costs about $15/day.

-

What it handles

+

The team talks to the agent through voice. The IDE microphone transcribes, and the agent interprets intent from messy voice-to-text. "There's a tree floating two meters above the terrain on the west beach" becomes a filed issue with a screenshot, a vision-model description, and coordinates.

+

At night (background daemon, $15/day):

    -
  • Chat monitoring — polls team chat, responds to commands, acknowledges messages
    • -
  • Bug intake — when a tester reports a bug in chat, creates a structured issue automatically
    • -
  • Stale issue detection — flags issues that haven't been touched, nudges the team
    • -
  • Daily summaries — posts a morning digest of what happened overnight
    • -
  • Self-learning — creates its own skill files when it discovers better approaches
    • -
-

The two agents coordinate through the docs repo itself. One writes, the other reads. No API calls between them, no message queue. Just git.

-

The Skill System

-

Agents don't just have instructions — they have skills. Each skill is a markdown file that teaches the agent a specific workflow: how to generate concept art through a pipeline, how to use image generation APIs, how to conduct competitive research, how to create 3D models from concept art.

-

When someone asks the agent to do something that matches a skill, it reads the skill file and follows the procedure. This means you can teach the agent new capabilities without changing any code — just write a new markdown file.

-

We've open-sourced several of our skills in this repo:

- -

Soul Files: Why Identity Matters

-

Giving the agent a persistent identity isn't theatre. It creates consistency across sessions. The soul file defines:

-
    -
  • Values — what the agent prioritises (e.g., "never break the build," "always verify before acting")
    • -
  • Knowledge scope — what repos, services, and team members exist
    • -
  • Behavioural rules — how to handle ambiguity, when to ask vs act, what requires human approval
    • -
-

The agent remembers what it learned, adapts to who's asking, and maintains the same principles whether it's triaging bugs or drafting a Steam page description. The soul file is the agent's constitution.

-

What We've Learned

-

Plain text is the universal API. Every tool, every agent, every human can read a markdown file. We store everything — design documents, meeting notes, agent memory, team contacts — as .md files in one repository. This sounds almost too simple, but it eliminates an entire class of integration problems.

-

Cheap models for routine, expensive models for thinking. Most of what an autonomous agent does is pattern matching and text formatting — you don't need the most expensive model for that. Save the premium tokens for decisions that actually require reasoning.

-

The human stays in the loop for decisions. The agents can file issues, draft announcements, and generate assets — but they don't merge code, deploy builds, or post to public channels without explicit approval. The workflow is designed so the AI handles the grunt work while humans make the calls that matter.

-

Voice input changes everything. When you can describe a bug while looking at the game screen, and the agent transcribes, interprets, and files an issue — that's a workflow that collapses the distance between noticing a problem and tracking it.

-

Skills compound. Every skill file you write makes the agent more capable. After 6 months, our agents have 15+ skills covering art generation, competitive research, video production, and project management. Each one took 30 minutes to write and saves hours every week.

-

The Numbers

-
    -
  • Team size: 4 humans + AI agents
    • -
  • Background agent cost: ~$15/day (~$450/month)
    • -
  • Knowledge files: 200+ markdown documents
    • -
  • Skills: 15+ agent skill files and growing
    • -
  • Infrastructure: Multiple machines, self-hosted git, zero DevOps engineers
    • +
  • Polls team chat every 15 minutes, responds to commands
    • +
  • When a tester reports a bug in chat, creates a structured issue automatically
    • +
  • Flags stale issues that haven't been touched
    • +
  • Posts a morning digest of what happened overnight
    • +
  • Creates its own skill files when it discovers better approaches
+

What we learned

+

Plain text is the universal API. Every tool, every agent, every human can read a markdown file. We store everything — design docs, meeting notes, agent memory, team contacts — as .md in one repo. It sounds too simple, but it eliminates an entire class of integration problems.

+

Cheap models for routine, expensive models for thinking. Most of what an agent does is pattern matching — "does this look like a bug report?" You don't need DeepSeek Pro for that. Save the premium tokens for decisions that actually require reasoning. Our background daemon costs $15/day with a three-tier model strategy.

+

Voice changes everything. When you can describe a bug while looking at the screen, and the agent transcribes, interprets, and files it — that collapses the distance between noticing a problem and tracking it. Keyboard-free bug reporting is a superpower.

+

Skills compound exponentially. One skill saves 15 minutes per session. Fifteen skills save hours per day across the whole team. The investment curve is absurdly favourable — 30 minutes of writing per skill, compounding returns forever.

+

We're four people. With agents doing the mechanical work, we operate like forty. Not because the AI is magic — because we gave it identity, memory, and the right playbooks, and then got out of its way.

-

We're not claiming this is how every studio should work. But for a small team trying to build something ambitious, having AI agents that actually understand the project — not just answer questions about it — has been transformative. The agents don't replace anyone on the team. They make it possible for four people to do the work of forty.

-

We're building all of this as part of Tinqs Studio — a game development platform that brings git hosting, AI tools, and team workflows together. The blog posts and skills in this repo are part of that journey.

+

We're building Ariki, a survival colony sim, using the same agent workflow described here. Everything runs on Tinqs Studio — a game dev platform with built-in AI agents, git hosting, and creative pipelines.

diff --git a/blog-visual-upgrade.html b/blog-visual-upgrade.html index 2dcf2cf..c384108 100644 --- a/blog-visual-upgrade.html +++ b/blog-visual-upgrade.html @@ -4,27 +4,27 @@ - Our Blog Just Got a Visual Upgrade — Here's How We Did It — Tinqs Blog - + How We Restyled Our Blog with Two Template Files and Zero Dependencies — Tinqs Blog + - - + + - - + + @@ -218,182 +218,49 @@
← All Posts 3 June 2026 -

Our Blog Just Got a Visual Upgrade — Here's How We Did It

-

Until yesterday, the Tinqs blog looked... fine. Readable. Semantic. It had the brand amber accent, proper typography, and all the SEO metadata in the right places. But it didn't have much personality. The code blocks were unstyled. The headings sat flat. And the design said "competent" more than "intentional".

+

How We Restyled Our Blog with Two Template Files and Zero Dependencies

+

Our blog looked fine. Readable, semantic, proper typography. But it didn't have much personality. Code blocks were unstyled. Headings sat flat. The design said "competent" more than "intentional."

-

Then we looked at our own internal team guide — the onboarding doc we keep at docs/team/dev-basics-env-secrets-git.html. It had gradient titles that clip to transparent. Dark, crisp code panels. Callout boxes with coloured left borders. Pill-shaped date labels. A restrained four-colour palette that felt cohesive without screaming.

-

We wanted the blog to feel like it came from the same shop. So we restyled it.

-

The design source

-

Our team guide is a single self-contained HTML file with a dark theme — background #0d1117, panels #161b22, ink #e6edf3. It uses a four-accent palette:

-
    -
  • Green #22c55e — for .env and environment topics
    • -
  • Blue #38bdf8 — secondary links, kickers, syntax table headers
    • -
  • Purple #a855f7 — git topics, hover states
    • -
  • Amber #f59e0b — warnings, emphasis, callouts
    • -
-

The title is the star: an h1 filled with a linear-gradient across all four colours, clipped to the text via -webkit-background-clip: text. Code blocks live in dark #0a0e14 panels with #2a3340 borders. Blockquotes become amber-tinted callouts. The whole thing radiates a "well-maintained developer doc" energy without feeling like a Bootstrap template.

-

We wanted that energy on the public-facing blog.

-

The build system (and why it mattered)

-

The blog is generated by a zero-dependency Node script — build.js — that converts markdown posts into HTML. The pipeline is:

+

Then we looked at our internal team guide — a self-contained HTML doc with gradient titles that clip to transparent, dark code panels, and callout boxes with coloured borders. It radiated a "well-maintained developer doc" energy. We wanted the blog to feel like it came from the same shop.

+

Two template files, one build step, zero external dependencies. Here's what we changed.

+

The build system (why it mattered)

+

The blog is generated by build.js — a zero-dependency Node script that converts markdown to HTML:

posts/*.md  +  _template.html / _index_template.html  →  *.html
-

This means we never touch a generated .html file by hand. Every visual change flows through the two templates. build.js then stamps out all 11 posts plus the index in under a second.

-

The site-wide CSS — navigation, footer, base typography, the brand amber –c-accent: #c9935a — lives in ../style.css, which is served by Git Studio from outside the blog repo. We deliberately did not touch that file. Instead, we injected a self-contained - - - - -

- - - - - -
- ← All Posts - 20 May 2026 -

Why We Forked Gitea and Built Tinqs Studio

-

GitHub is built for web developers. Game studios need something different — LFS that works, 3D asset previews in the browser, and project management that understands sprints and milestones. So we forked Gitea and built Tinqs Studio.

- -
-

The Problem with GitHub for Game Dev

-

We used GitHub for two years. It was fine for docs — small files, text diffs, pull requests. But the game repo was a different story.

-

A single character model with textures and animations is 50–200MB. A terrain heightmap is 16MB. An island's vegetation data is another 10MB. Our game repo was 12GB in LFS alone, growing every week. GitHub's LFS bandwidth limits, slow clone times, and $5/50GB pricing made it untenable.

-

More importantly, nobody on the team could see what changed. A PR that modifies a GLB file shows a binary diff. You can't preview it. You can't compare before and after. The artist pushes a model, the developer approves it blindly, and three days later someone notices the normals are inverted.

-

Why Self-Host, and Why Gitea

-

We evaluated GitLab, Forgejo, Gogs, and Gitea. The decision came down to:

-
    -
  • Single binary. Gitea compiles to one Go binary with SQLite support. No PostgreSQL, no Redis, no Docker compose with 7 services. Just copy the binary, write an app.ini, and run it.
    • -
  • Resource usage. Our instance runs on a single EC2 instance alongside other services. It uses about 200MB RAM. GitLab needs 4GB minimum.
    • -
  • LFS built-in. Gitea includes a full LFS server. No external LFS store, no S3 configuration for basic use. Files are stored locally. We added S3 backend later, but it works out of the box.
    • -
  • Forkable. Gitea is MIT-licensed, written in Go, with a clean codebase. We can modify it without worrying about license restrictions or CLA headaches.
    • -
-

We ran vanilla Gitea for six months. It solved the cost and bandwidth problems immediately. But the UX gaps for game development were still there.

-

What We Built: Tinqs Studio

-

Tinqs Studio is our fork. It tracks upstream Gitea on the main branch and keeps all customisations on a separate branch. We rebase onto upstream releases periodically, fix conflicts, and deploy.

-

3D Asset Preview

-

The headline feature. When you open a PR that contains a .glb, .gltf, or .fbx file, you see a 3D viewer directly in the browser. Rotate, zoom, check materials. No downloads, no external tools. We integrated Online 3D Viewer (O3DV), which supports 22 file formats including STL, OBJ, 3DS, and PLY.

-

This changes the review process fundamentally. The artist pushes a model, the lead rotates it in the browser, leaves a comment about the UV seam on the shoulder, and the artist fixes it — all without leaving the git platform.

-

LFS-First Workflows

-

Vanilla Gitea treats LFS as an afterthought. You configure .gitattributes manually. There's no dashboard showing LFS usage, no way to see which files are tracked, no warnings when someone commits a large file without LFS.

-

Tinqs Studio adds auto-LFS tracking on repository creation. Game file extensions (.fbx, .glb, .png, .wav, .ogg, .tscn, .tres) are tracked by default. An API endpoint exposes LFS storage stats per repo. The goal: LFS should be invisible. It should just work.

-

Platform Integration

-

Tinqs Studio integrates project management — issues, sprints, time tracking — and OAuth2 SSO. One login for git, the game tools, and the team dashboard.

-

The Branching Strategy

-

Staying close to upstream is critical. We don't want to maintain a fork that diverges forever:

-
    -
  • main tracks upstream go-gitea/gitea. We never commit to it directly.
    • -
  • Our production branch holds all customisations.
    • -
  • Feature branches merge into production.
    • -
  • When upstream releases a new version, we merge, resolve conflicts, test, deploy.
    • -
-

We deliberately limit what we touch. We modify templates, locale strings, CSS variables, and a handful of Go packages. We never touch the database models — schema is owned by upstream, and we ride their migrations. This keeps rebasing manageable.

-

What We Learned

-

Self-hosting git is surprisingly easy. The hard part isn't running Gitea — it's convincing yourself that you're allowed to. After years of GitHub being the default, it feels transgressive to host your own git. But a single Go binary on a $10/month server handles a small team with room to spare.

-

LFS changes everything for game repos. Our clone times went from 45 minutes to 3 minutes. Developers only download the LFS objects they need. CI only pulls what changed. The bandwidth savings alone paid for the server.

-

Forking is maintenance, not rebellion. The romantic version is "we forked Gitea and built our own platform." The reality is we changed 200 lines of Go, 50 template strings, and a CSS file. 99.5% of the code is upstream's. We're just customising the last half-percent for our use case.

-

3D preview is a game changer. We expected it to be a nice-to-have. It turned out to be the feature that made the rest of the team actually use git. When the artist can see their work rendered in the browser, they stop asking the developer to "check if it looks right."

-
-

Tinqs Studio is built for game teams that are tired of paying GitHub for LFS bandwidth and reviewing binary diffs blind. We're building it for ourselves first — dogfooding it on our own game — but the plan is to make it available as a platform for other studios. If you're a game team that self-hosts or wants to, we'd love to hear what features you need.

- -
- -
-
OB
-
- Ozan Bozkurt
- CTO & Developer, Tinqs -
-
-
- - - - - - - - diff --git a/godot-optimisation.html b/godot-optimisation.html index 0fe0c89..ef7eb42 100644 --- a/godot-optimisation.html +++ b/godot-optimisation.html @@ -5,19 +5,19 @@ Streaming a 12km Archipelago in Godot 4 — Tinqs Blog - + - + - + @@ -219,74 +219,64 @@ ← All Posts 22 May 2026

Streaming a 12km Archipelago in Godot 4

-

Godot has no built-in asset streaming. Our game is a 12km x 12km archipelago with 9 islands, thousands of trees, hundreds of buildings, and an ocean that never ends. Here's how we made it run.

+

Godot 4 has no terrain streaming, no asset LOD pipeline, and no distance-based loading. Our game is a 12km × 12km archipelago with 9 islands, 155 vegetation prototypes, and 2,000 simulated colonists. If you load everything at startup, you run out of VRAM before the player sees the main menu.

-

The Problem

-

We're building a survival colony sim set across 9 islands. The total world is roughly 12km x 12km. Each island is 4km across with its own terrain heightmap, biome textures, vegetation prototypes, and building grids. The player can travel between islands by canoe.

-

Godot 4 is a fantastic engine, but it wasn't designed for this scale. There's no terrain streaming, no asset LOD pipeline, no distance-based loading. If you load everything at startup, you run out of VRAM before the player sees the main menu. So we built four streaming layers on top of Godot, all in C#.

-

Layer 1: Terrain Regions

-

We use Terrain3D for heightmaps — a GDExtension that gives us a clipmap renderer with 7 LOD levels. Internally, Terrain3D divides each island into 512m x 512m regions. A 4km island has 64 regions. Across 9 islands, that's 576 regions total.

-

The key insight: don't create all 9 terrain nodes at startup. Each node allocates a clipmap mesh, collision structures, and materials even when hidden. Our original code created all 9 in _Ready() and just toggled visibility. This wasted hundreds of megabytes on islands the player hadn't visited yet.

-

The fix was lazy instantiation. We create the current island's terrain on startup and defer the rest. When the player gets in a canoe and sails to a new island, we create that island's terrain node on demand, import the heightmap, and start async texture loading — all while a loading screen covers the transition.

-

Layer 2: Vegetation Chunks (128m Grid)

-

This is the main prop streaming system. Every island's vegetation — trees, rocks, grasses, shrubs — is divided into a spatial grid of 128m x 128m chunks.

-

The camera position is checked every 0.5 seconds. When it crosses a chunk boundary, we calculate which chunks should be active within a 400m radius (roughly 39 chunks in a circle), QueueFree chunks that fell out of range, and build new chunks that entered range.

-

Each chunk groups vegetation instances by prototype, creates a MultiMesh per group, and places instances using height queries. A chunk with 50 palm trees and 30 rocks becomes 2 MultiMesh draw calls, not 80 individual nodes.

-

The cache problem

-

Vegetation meshes and materials are cached in dictionaries keyed by prototype name. The problem: these caches are append-only. Visit all 9 islands and you accumulate every mesh and material variant permanently. With 155 unique prototypes across the archipelago, that's a lot of GPU memory that never gets freed.

-

The fix is island-scoped eviction. When the player leaves an island, we clear the vegetation caches. Meshes and materials for the departed island are released. If the player returns, they reload from disk. The loading screen covers this cost.

-

Layer 3: Async Resource Loading

-

Godot's GD.Load() is synchronous. It blocks the main thread. During gameplay, the frame freezes. We audited the entire codebase and found 26 resource load calls across 13 files, and only 1 was async.

-

The worst offender was GetMeshForProto() in the vegetation grid. As the player walks across an island for the first time, every new vegetation prototype triggers a synchronous load. With 155 prototypes, the first traversal stutters visibly.

-

We fixed this in two ways:

+

Here's how we built four streaming layers on top of Godot, all in C#, to make it work.

+

The scale problem

+

Each island is roughly 4km across with its own terrain heightmap, biome textures, vegetation, and building grids. The player travels between islands by canoe. At any given moment, only a small fraction of the world is visible — but Godot doesn't know that unless you tell it.

+

We built four layers that teach Godot what to load, when to load it, and when to let it go.

+

Layer 1: Terrain regions (lazy instantiation)

+

We use Terrain3D for heightmaps — a GDExtension that provides clipmap rendering with 7 LOD levels. Each island is split into 512m × 512m regions. A 4km island has 64 regions. Nine islands: 576 regions total.

+

The original code created all 9 terrain nodes in _Ready() and toggled visibility. This wasted hundreds of megabytes on islands the player hadn't visited. The fix: create the current island's terrain on startup, defer the rest. When the player sails to a new island, create that island's terrain node on demand, import the heightmap, start async texture loading — all behind a loading screen.

+

Layer 2: Vegetation chunks (128m grid)

+

The main prop streaming system. Every island's vegetation is divided into a spatial grid of 128m × 128m chunks.

+

The camera position is checked every 0.5 seconds. When it crosses a chunk boundary, we calculate which chunks should be active within a 400m radius (~39 chunks), destroy chunks that fell out of range, and build new ones that entered. Each chunk groups vegetation by prototype, creates a MultiMesh per group, and places instances using height queries. A chunk with 50 palm trees and 30 rocks becomes 2 MultiMesh draw calls — not 80 individual nodes.

+

The cache problem: vegetation meshes and materials are cached in dictionaries keyed by prototype name. These caches are append-only by default — visit all 9 islands and you accumulate every mesh variant permanently. The fix is island-scoped eviction. When the player leaves an island, we clear vegetation caches. They reload from disk on return, behind a loading screen.

+

Layer 3: Async resource loading

+

Godot's GD.Load() is synchronous. It blocks the main thread. During gameplay, the frame freezes.

+

We audited the entire codebase and found 26 resource load calls across 13 files — only 1 was async. The worst offender was GetMeshForProto() in the vegetation grid. As the player walks across a new island, every new vegetation prototype triggers a synchronous load. With 155 prototypes, the first traversal stutters visibly.

+

Two fixes:

    -
  • Pre-warm during loading screens. When an island is imported, we kick off background loads for all known prototypes. By the time the player gains control, most meshes are already cached.
    • -
  • Async loading for biome textures. Terrain textures use ResourceLoader.LoadThreadedRequest() with _Process() polling. The terrain renders immediately with autoshader colours, and biome textures pop in when ready. The player never notices.
    • +
  • Pre-warm during loading screens. When an island is imported, kick off background loads for all known prototypes. By the time the player gains control, most meshes are cached.
    • +
  • Async texture loading. Terrain textures use ResourceLoader.LoadThreadedRequest() with _Process() polling. The terrain renders immediately with autoshader colors; biome textures pop in when ready.
-

The ResourceLoader cache trap

-

On top of our own caches, Godot maintains an internal resource cache. Every GD.Load() call caches the result globally. There's no API to query the cache size or evict entries.

-

If you load an FBX as a PackedScene, instantiate it to extract a mesh, then free the instance — the PackedScene stays cached. The mesh you extracted is fine (it's a Resource, not a Node), but the discarded scene wastes memory forever.

-

The rule: use ResourceLoader.Load(path, "", CacheMode.Ignore) for one-shot loads where you extract data and discard the container. Use GD.Load() only for things that should persist (shaders, shared textures).

-

Layer 4: Entity Rendering

-

Dynamic entities — colonists, animals, buildings, VFX — are event-driven, not streamed. They update when the simulation pushes new state, not per frame.

+

The ResourceLoader trap: Godot maintains an internal resource cache. Every GD.Load() caches the result globally. If you load an FBX as a PackedScene, instantiate it to extract a mesh, then free the instance — the PackedScene stays cached. Rule: use ResourceLoader.Load(path, "", CacheMode.Ignore) for one-shot loads where you extract data and discard the container.

+

Layer 4: Entity rendering (event-driven)

+

Dynamic entities — colonists, animals, buildings, VFX — update when the simulation pushes new state, not per frame.

    -
  • Crowd rendering: Single MultiMesh for up to 2000 colonists. Positions lerped per frame from pre-allocated arrays. Labels distance-culled, capped at 20. No individual nodes, no per-frame allocation.
    • -
  • Animals: One MultiMesh per type. Max 500 per type. Updates only on state change, not per frame.
    • -
  • Buildings: Tracked by ID from sim state. QueueFree when removed. Self-cleaning.
    • +
  • Crowd rendering: Single MultiMesh for up to 2,000 colonists. Positions lerped per frame from pre-allocated arrays. Labels distance-culled, capped at 20.
    • +
  • Animals: One MultiMesh per type. Max 500 per type. Updates only on state change.
    • +
  • Buildings: Tracked by ID from sim state. QueueFree when removed.
  • VFX: Capped at 50 active particle systems. Worst case: 10,000 GPU particles.
-

Memory Safety: Zero Leaks

-

We audited every QueueFree() call in the codebase — 47 calls across 17 files. Zero RemoveChild() calls without a corresponding QueueFree(). Three patterns we follow everywhere:

-

Pattern 1: Chunk streaming — Deactivate out-of-range chunks by iterating the active dict, calling QueueFree(), collecting keys to remove, then removing them after iteration. Never modify a dictionary while iterating it.

-

Pattern 2: Extract data from PackedScene — Instantiate a scene, extract the mesh, QueueFree() the temporary instance. The mesh survives because it's a Resource, not a Node.

-

Pattern 3: UI rebuild — QueueFree() all children, then build new content. Safe because QueueFree is deferred — new children are added in the same frame before old ones are freed.

-

What Runs Every Frame

-

We're strict about what goes in _Process():

+

Memory safety: the QueueFree audit

+

We audited every QueueFree() call — 47 calls across 17 files. Zero RemoveChild() calls without a corresponding QueueFree(). Three patterns we follow everywhere:

+

1. Chunk streaming: Iterate active dict, call QueueFree(), collect keys to remove, then remove after iteration. Never modify a dictionary while iterating.

+

2. Extract from PackedScene: Instantiate, extract mesh, QueueFree() the temp instance. The mesh survives because it's a Resource, not a Node.

+

3. UI rebuild: QueueFree() all children, build new content. Safe because QueueFree is deferred — new children added in same frame before old ones freed.

+

What runs every frame (and what doesn't)

+

_Process() is strictly limited:

    -
  • Vegetation grid: Camera chunk check (0.5s throttle, early-exits if same chunk)
    • -
  • Terrain manager: Poll async texture loads (loop pending list, check status)
    • -
  • Crowd renderer: Lerp 2000 colonist positions (math-only, pre-allocated arrays)
    • -
  • Day/night: Rotate sun, adjust light energy
    • -
  • Camera: Follow + zoom smoothing
    • -
  • Sim bridge: Drain WebSocket message queue
    • +
  • Vegetation grid: camera chunk check (0.5s throttle, early-exit if same chunk)
    • +
  • Terrain manager: poll async texture loads
    • +
  • Crowd renderer: lerp 2,000 positions (math-only, pre-allocated arrays)
    • +
  • Day/night: rotate sun
    • +
  • Camera: follow + zoom
    • +
  • Sim bridge: drain WebSocket message queue
-

No heap allocation in any of these. Total per-frame overhead is dominated by the crowd lerp and the message queue drain.

-

Shaders We Watch

-

Two custom shaders are performance-sensitive:

-

Ocean shader — 4 Gerstner wave calculations in the vertex stage, applied to a 12,000m plane. Fragment stage does depth reconstruction, caustics, foam masking, and two normal map lookups. It's the heaviest thing in the render pipeline. We pre-warm it during the loading screen to avoid shader compilation stutter.

-

Wind sway shader — 6 trig ops per vertex on every vegetation mesh within 400m. The sway is invisible beyond 100m but the shader runs at full cost regardless. Future optimisation: disable sway on distant chunks.

-

The Target: RTX 3060

-

Our early access target is an RTX 3060 with 8GB VRAM:

+

No heap allocation in any of these. Per-frame overhead is dominated by the crowd lerp and message queue drain.

+

Two shaders to watch: the ocean shader (4 Gerstner waves, depth reconstruction, caustics, foam — heaviest thing in the pipeline) and the wind sway shader (6 trig ops per vertex on every vegetation mesh within 400m). Future optimization: disable sway on distant chunks.

+

Target: RTX 3060, 8GB VRAM

    -
  • Main island + full vegetation < 4GB VRAM — ship it, we have headroom
    • -
  • Approaching 6–8GB — implement lazy terrain nodes + cache eviction
    • -
  • Exceeding 8GB — implement vegetation LOD and region-level streaming
    • +
  • Main island + full vegetation < 4GB VRAM → ship it
    • +
  • Approaching 6-8GB → implement lazy terrain nodes + cache eviction
    • +
  • Exceeding 8GB → implement vegetation LOD and region-level streaming
-

Always measure before optimising. We added VRAM logging before writing a single line of optimisation code. Half the "problems" we expected turned out to be non-issues. The other half were worse than expected. Profiling isn't optional.

+

Always measure before optimizing. We added VRAM logging before writing a single line of optimization code. Half the "problems" we expected were non-issues. The other half were worse than expected. Profiling isn't optional.

-

Godot 4 can handle open worlds at this scale, but it won't do it for you. You need to build streaming, manage your own caches, audit your resource loading, and be disciplined about what runs per frame. The engine gives you the primitives — MultiMesh, LoadThreadedRequest, QueueFree — and it's up to you to wire them into a system that scales.

-

We're building with these systems and developing the game using Tinqs Studio. If you're building something large-scale in Godot, we hope this is useful.

+

Godot 4 can handle open worlds at this scale, but it won't do it for you. You need to build streaming, manage your own caches, audit resource loading, and be disciplined about what runs per frame. The engine gives you the primitives — MultiMesh, LoadThreadedRequest, QueueFree. It's up to you to wire them into a system that scales.

+

We're building Ariki, a survival colony sim, with these systems. The tools we use — git hosting, AI agents, creative pipelines — are part of Tinqs Studio.

diff --git a/image-generation-fal.html b/image-generation-fal.html deleted file mode 100644 index 63e8779..0000000 --- a/image-generation-fal.html +++ /dev/null @@ -1,332 +0,0 @@ - - - - - - - Image Generation at Every Price Point with fal.ai — Tinqs Blog - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- ← All Posts - 25 May 2026 -

Image Generation at Every Price Point with fal.ai

-

We generate every visual asset for Ariki — concept art, app icons, trailer frames, logo variants, Steam capsules — through a single inference proxy that routes to fal.ai. No Photoshop. No Midjourney subscription. Just API calls at prices that range from $0.002 to $0.09 per image. Here's how we decide which model gets which job.

- -
-

The Setup

-

Our Tinqs Studio platform includes an inference proxy that sits between agents and model providers. When an agent (or a human in Cursor) says "generate an image," the proxy routes the request to fal.ai, handles authentication, tracks usage per user, and persists the result to S3. The caller doesn't care which model runs — they describe what they want, and the proxy picks or the caller specifies.

-
Agent describes what it wants
-  → tinqsProxy receives generate_image call
-  → Routes to fal.ai with the specified model
-  → Image generated, persisted to S3
-  → Permanent URL returned to caller
-

One API key. One billing account. Access to every model fal.ai hosts. That's the pitch of aggregator platforms, and fal.ai delivers on it.

-

The Tiers

-

Not every image needs the best model. A throwaway mockup doesn't justify $0.09. A final logo doesn't deserve $0.002. We split our usage into four tiers.

-

Best Quality — Final Art

-

For images that ship — hero art, app icons, trailer keyframes, print-ready designs — we use three models depending on the content:

-

Flux 2 Pro ($0.03/megapixel, ~15 seconds). Our default. Best all-round quality for concept art, character illustrations, environment paintings, and anything that doesn't need text. Handles complex prompts with multiple elements well. Rarely fails.

-

Ideogram v3 Quality ($0.09, ~12 seconds). The only model that renders text reliably inside images. When we need a poster with a tagline, a sign in a game scene, or a logo with readable letters, this is the only option. The QUALITY tier is expensive but worth it — text at lower tiers gets blurry.

-

Recraft v3 ($0.04 raster, $0.08 vector, ~10 seconds). Built for commercial design. Clean lines, consistent style, and the only model on fal.ai that outputs SVG vectors. When we need brand assets, packaging mockups, or anything that might end up in print, Recraft produces work that doesn't need cleanup.

-

Mid Tier — Everyday Work

-

For images that are good enough for internal review, social posts, or documentation:

-

Ideogram v3 Balanced ($0.06, ~8 seconds). Typography quality between Turbo and Quality. Good for marketing materials where text matters but perfection doesn't.

-

Seedream v4.5 ($0.04, ~8 seconds). Google's model on fal.ai. Photorealistic scenes and product shots. Different aesthetic from Flux — slightly more photographic, less painterly.

-

Flux Dev ($0.025, ~10 seconds). The open-weight Flux variant. Good quality, and the base for LoRA fine-tuning if you want to train on your own style. We use it when we need custom-trained models later.

-

Low Cost — Drafts and Exploration

-

For iteration, A/B testing, and throwing things at the wall:

-

Flux Schnell ($0.003/megapixel, ~3 seconds). The workhorse for exploration. When we're figuring out composition, trying different camera angles, or generating 20 variants to pick one direction — Schnell. A hundred images costs $0.30. You can afford to be wasteful.

-

SDXL Lightning (~$0.002, ~2 seconds). The absolute cheapest option. Lower quality than Schnell, but when you need 50 thumbnails to test a layout grid or generate placeholder textures, quality doesn't matter. Two cents for ten images.

-

Specialised — Editing and Post-Processing

-

For modifying existing images rather than generating new ones:

-

Flux Kontext (~$0.04, ~12 seconds). Context-aware editing. Give it an image and say "change the wood to marble" or "make it sunset lighting." Preserves composition while changing style or material. Useful for quick style transfers without regenerating from scratch.

-

Nano Banana Edit ($0.039, ~12 seconds). Image-to-image restyle. We use this for our logo variant pipeline — take one carved-wood Ariki logo and produce versions in mahogany, pearl, obsidian, coral, gold. It's better than Kontext at preserving fine detail in complex images.

-

BiRefNet ($0.001, ~3 seconds). Background removal. Produces clean alpha cutouts from any image. We pair it with every logo and icon generation — generate with a white background, then cut it out. A dollar gets you a thousand cutouts.

-

How We Actually Use Them

-

The Schnell-to-Pro Pipeline

-

We never start with the expensive model. Every generation session follows the same pattern:

-

1. Explore with Schnell ($0.003) — 10-20 variants, different angles, compositions, color palettes. Total: $0.03-0.06.

-

2. Pick 2-3 directions. Human looks at the grid, picks the promising ones.

-

3. Refine with Flux 2 Pro ($0.03) — regenerate the winners at full quality with refined prompts. Total: $0.06-0.09.

-

4. Post-process — BiRefNet for background removal ($0.001), maybe Recraft for a vector version ($0.08).

-

A full session — from blank canvas to final assets — costs under $0.20. That's the price of a single Midjourney generation on their Pro plan.

-

Logo Variants at Scale

-

Our Ariki logo has 18 material variants — deep mahogany, mother-of-pearl, obsidian, molten lava, bronze with verdigris, tapa cloth, and more. Each one generated with Nano Banana Edit ($0.039) + BiRefNet ($0.001) for transparency. Total cost for 18 variants: $0.72. A designer would quote hundreds of dollars and a week of work for the same output.

-

Typography That Works

-

Every model except Ideogram fails at text. Flux will give you beautiful art with garbled letters. Recraft gets close but isn't consistent. SDXL doesn't try. If the image has words in it, Ideogram v3 is the only answer. We've learned to accept the $0.09 cost for text-heavy images rather than wasting $0.30 on ten failed Flux attempts.

-

The Numbers

-

Over the past month:

-

| Category | Images | Total Cost | Avg Cost/Image |

-

|———-|——–|———–|—————-|

-

| Concept art (flux-2-pro) | ~120 | $3.60 | $0.03 |

-

| Exploration drafts (schnell) | ~400 | $1.20 | $0.003 |

-

| Logo variants (nano-banana) | 18 | $0.72 | $0.04 |

-

| Icons (nano-banana + birefnet) | 30 | $1.20 | $0.04 |

-

| Typography (ideogram) | ~25 | $1.50 | $0.06 |

-

| Background removal (birefnet) | ~80 | $0.08 | $0.001 |

-

| Total | ~673 | $8.30 | $0.012 |

-

Six hundred images for eight dollars. The infrastructure to route, authenticate, and persist them costs more than the generation itself.

-

What We Learned

-

Never iterate on expensive models. The Schnell-to-Pro pipeline saves 10x. Most of the creative work happens at $0.003/image. The expensive model just polishes the decision you already made.

-

Typography is a solved problem — but only on one model. Stop trying to make Flux render text. Use Ideogram v3 Quality for anything with words. Accept the cost.

-

Vector output is underrated. Recraft v3's SVG export means logos and icons scale to any size without artifacts. For anything that might end up on a billboard or a business card, pay the $0.08 for vector.

-

Background removal is basically free. At $0.001 per image, there's no reason to ever manually mask anything. Run BiRefNet on everything, keep both versions.

-

Aggregation beats loyalty. No single model is best at everything. Flux for art, Ideogram for text, Recraft for design, Nano Banana for edits, BiRefNet for masks. The proxy pattern lets us use the right tool for each job without managing five API keys and five billing accounts.

-
-

Image generation is built into Tinqs Studio — our Gitea-based platform for game teams. Every model above is available through the same inference proxy that handles LLM calls, authenticated with the same Gitea token. We're building Ariki with these tools, and every asset in the game touched at least one of them.

- -
- -
-
OB
-
- Ozan Bozkurt
- CTO & Developer, Tinqs -
-
-
- - - - - - - - diff --git a/index.html b/index.html index 9059dc9..9ea13b4 100644 --- a/index.html +++ b/index.html @@ -130,78 +130,64 @@ 3 June 2026 -

Our Blog Just Got a Visual Upgrade — Here's How We Did It

-

We gave the Tinqs blog a visual refresh — borrowing the dark, gradient-heavy look from our internal team docs. Here's why, what we changed, and how the build system made it painless.

+

How We Restyled Our Blog with Two Template Files and Zero Dependencies

+

We gave the Tinqs blog a visual refresh — gradient titles, dark code panels, date pills, amber accent bars. Two template files, one build step, zero external dependencies.

Read → 26 May 2026 -

Building a Cloud Agent Harness with DeepSeek V4 and Pi

-

We forked Pi, merged a browser dashboard into the monorepo, and built a Go orchestrator inside our Gitea fork. Agents code overnight for about $0.80 — and you can watch them from the browser.

+

Agents That Code Overnight: Our $0.80 Cloud Harness with DeepSeek V4 and Pi

+

Every coding agent today runs in your terminal. Close the laptop, it stops. We built a cloud harness where agents code overnight for about $0.80 — and you can watch from a browser dashboard.

Read → 25 May 2026 -

Tinqs Studio Is an Agent Harness for Game Dev

-

An agent harness gives AI agents identity, memory, tools, and guardrails. Tinqs Studio is one built for game development.

+

What an Agent Harness Is and Why Game Dev Needs One

+

A raw AI model is stateless. An agent harness wraps around it and provides identity, memory, tools, context, and guardrails. Here's why game development needs its own.

Read → 25 May 2026 -

AI Art at Scale: Using fal.ai Flux for Game Asset Generation

-

We generate concept art, trailer frames, and UI icons with fal.ai Flux models at $0.01 per image. Here's the prompt engineering pattern that makes it work for game dev.

+

AI Art at Every Price Point: How We Generate Game Assets with fal.ai

+

We generate all visual assets for our game through fal.ai — concept art, icons, logos, trailer frames. Here's the 4-layer prompt pattern that actually works, and how we pick between 12 models spanning two orders of magnitude in cost.

Read → 25 May 2026 -

Fork, Don't Build: The Age of Agents Doesn't Need New Tools

-

Everyone is building new AI developer tools. We forked three existing ones and modified them from the inside. Here's why that's the better bet.

- Read → - - - - 25 May 2026 -

Image Generation at Every Price Point with fal.ai

-

We generate concept art, logos, icons, and trailer frames through a single API proxy. Here's how we pick between 12 models spanning $0.002 to $0.09 per image.

+

Fork, Don't Build: How We Modified Gitea, Pi, and Godot Instead of Starting from Scratch

+

Three forks, less than 0.5% code changed. Why modifying existing platforms beats building new ones — and how we turned Gitea into a game dev platform with 3D preview, AI agents, and LFS-first workflows.

Read → 25 May 2026

A Pre-Commit Agent That Guards Your Secrets for $0.001

-

We built a pre-commit hook that calls DeepSeek V4 Flash to review every commit. It catches leaked secrets, classified terms, and broken URLs --- for a tenth of a cent.

+

Too many things to remember before hitting commit. Don't leak API keys. Don't reference classified codenames. Don't link to deleted repos. We built a two-layer pre-commit hook — regex + LLM — that catches all of it for $0.001.

Read → 22 May 2026

Streaming a 12km Archipelago in Godot 4

-

Four streaming layers, async resource loading, memory-safe caches, and zero leaks. How we built a 12km open world in Godot 4 with C#.

- Read → - - - - 20 May 2026 -

Why We Forked Gitea and Built Tinqs Studio

-

GitHub doesn't understand game dev. We forked Gitea to build Tinqs Studio --- with 3D asset preview, LFS-first workflows, and project management for game teams.

+

Godot has no built-in asset streaming. We built four layers to run a 12km archipelago with 9 islands, 155 vegetation types, and 2,000 crowd instances — on an RTX 3060.

Read → 18 May 2026 -

One Binary to Rule Them All: Building a Studio CLI

-

A single Go binary that gives AI agents context about who you are, what machine you're on, and what services are reachable. Screenshots, cloud vision, health checks --- one install, every machine.

+

One Binary to Rule Them All: Our Studio CLI

+

Every machine in our studio runs the same Go binary. It knows who you are, what machine you're on, and what services are reachable. It takes screenshots, sends them to cloud vision, and runs health checks — in 100ms.

Read → 6 March 2026 -

How a Small Game Studio Runs on AI Agents

-

Soul files, skill playbooks, and markdown as the universal API. How we built an agentic workflow that lets a 4-person indie studio operate at 10x scale.

+

How a 4-Person Studio Runs on AI Agents

+

We gave AI agents persistent identities, skill playbooks, and access to our entire knowledge base. Here's how four people ship like forty.

Read →
diff --git a/posts/agent-harness.md b/posts/agent-harness.md index 126389a..fbe8ffe 100644 --- a/posts/agent-harness.md +++ b/posts/agent-harness.md @@ -1,151 +1,78 @@ --- -title: "Tinqs Studio Is an Agent Harness for Game Dev" +title: "What an Agent Harness Is and Why Game Dev Needs One" slug: agent-harness date: "2026-05-25" -description: "An agent harness gives AI agents identity, memory, tools, and guardrails. Tinqs Studio is one built specifically for game development --- git, 3D preview, image generation, and a CLI that makes every session a warm start." -og_description: "Tinqs Studio is an agent harness for game dev --- identity, skills, vision, git, and creative tools in one platform." +description: "A raw AI model is a brain without hands, eyes, or memory. An agent harness gives it identity, tools, context, and guardrails — and game development needs one built for binary assets, visual pipelines, and spatial systems." +og_description: "Agent harnesses give AI identity, memory, and tools. Game dev needs one that understands 3D assets." og_image: "https://www.tinqs.com/img/og-cover.jpg" -excerpt: "An agent harness gives AI agents identity, memory, tools, and guardrails. Tinqs Studio is one built for game development." +excerpt: "A raw AI model is stateless. An agent harness wraps around it and provides identity, memory, tools, context, and guardrails. Here's why game development needs its own." author: "Ozan Bozkurt" author_initials: "OB" author_role: "CTO & Developer, Tinqs" --- -An agent harness is the layer between a raw AI model and a useful team member. It gives the agent identity, memory, tools, and guardrails. Tinqs Studio is an agent harness built specifically for game development. +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." -## What Is an Agent Harness? +A raw AI model is a brain without hands, eyes, or memory. An **agent harness** 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. -A raw AI model --- Claude, GPT, Gemini --- is powerful but stateless. It doesn't know who you are, what project you're working on, what tools are available, or what happened yesterday. Every session is a cold start. Every conversation begins with "let me explain the project..." +## What a harness provides -An agent harness solves this. It wraps around the model and provides: +Every agent harness, regardless of domain, needs five things: -- **Identity** --- who the agent is, what it values, how it should behave -- **Memory** --- what happened in previous sessions, what was decided, what failed -- **Tools** --- what the agent can actually do beyond generating text -- **Context** --- what project this is, who's asking, what infrastructure exists -- **Guardrails** --- what the agent must never do, what requires human approval +**Identity.** 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. -Without a harness, you have a chatbot. With one, you have a team member. +**Memory.** 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 `git log` instead of debugging a vector database. -## Why Game Dev Needs Its Own Harness +**Tools.** 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. -Generic agent harnesses exist --- LangChain, CrewAI, AutoGen. They're built for web apps, data pipelines, and customer support. Game development has different problems: +**Context.** Which project this is. Who's asking. What machine they're on. What services are reachable. A single CLI call — `tstudio identity` — returns all of this in 100ms. No re-reading the README. No "what repo are we in?" -**Assets are binary.** A web developer's PR is a text diff. A game developer's PR is a 150MB GLB file. Generic harnesses don't know how to preview 3D models, manage LFS bandwidth, or review binary assets. +**Guardrails.** 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. -**The pipeline is visual.** Game dev goes from concept art to 3D model to rigged character to in-engine asset. Each step uses different tools --- image generators, 3D modellers, auto-riggers, game engines. An agent harness for game dev needs to orchestrate this entire chain. +## Why generic harnesses fail for game dev -**Scale is physical.** A web app's complexity is in business logic. A game's complexity is in geometry --- 12km worlds, 155 vegetation prototypes, 576 terrain regions, 2000 crowd instances. The agent needs to understand spatial systems, GPU memory, and frame budgets. +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: -**The team is small and cross-functional.** A 4-person game studio has no dedicated DevOps, no dedicated artist, no dedicated PM. The harness needs to fill all those gaps, not just one. +**Assets are binary.** 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. -## How Tinqs Studio Works as a Harness +**The pipeline is visual.** 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. -Tinqs Studio is a platform built on a [Gitea fork](forking-gitea) with game-specific features layered on top. But the git platform is just the foundation. The harness is everything around it. +**Scale is physical.** 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. -### Identity: Soul Files +**The team is small and cross-functional.** Four people. No dedicated DevOps, no dedicated artist, no dedicated PM. The harness fills all those gaps, not just one. -Every agent session starts by loading a soul file --- a markdown document that defines the agent's persistent identity. Not just "you are a helpful assistant" but specific values, knowledge scope, and behavioural rules. +## The toolchain that makes it work -The soul file means the agent behaves consistently whether it's triaging bugs at 9am or generating concept art at midnight. It knows what repos exist, who the team members are, what the game is about, and what decisions have been made. Identity isn't cosmetic --- it's the difference between an agent that asks "what project is this?" and one that says "I see the vegetation grid was updated yesterday, want me to check the cache eviction?" +Our harness runs on [Tinqs Studio](https://tinqs.com), built on a Gitea fork with game-specific features. The key pieces: -### Memory: Markdown Files in Git +**The CLI** — a single Go binary. One command (`tstudio identity`) gives the agent full project context in 100ms. Screenshots, cloud vision, health checks — all subcommands of the same binary. -Agent memory is plain markdown files in a git repository. No vector databases, no proprietary stores. The agent reads its memory on session start, updates it during work, and commits changes back. +**The soul file** — 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. -This is deliberately low-tech. Markdown in git gives you version history, branching, merge conflict resolution, and human readability for free. When memory goes wrong --- and it will --- you can `git log` to see what changed and `git revert` to fix it. +**Skills** — 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. -### Tools: The CLI +**3D preview** — click a `.glb` 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. -A [single Go binary](studio-cli) gives every agent access to: +**Guardrails** — 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. -- **Identity loading** --- full project context in 100ms -- **Screenshots** --- capture any window from outside the process -- **Cloud vision** --- send screenshots to a vision model, get structured descriptions -- **Health checks** --- verify services, repos, and tools are working -- **Service status** --- which URLs are live, what's reachable +## The cold-start problem, solved -The CLI is the agent's hands and eyes. Without it, the agent can only read and write text. With it, the agent can see the game running, photograph bugs, and verify infrastructure. +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. -### Skills: Teachable Workflows +The harness uses staged loading: -Skills are markdown playbooks that teach agents specific procedures. Instead of hoping the model figures out how to generate concept art or create a 3D model, you write the steps once: +1. **CLI identity call** (100ms) — soul file, company context, machine info, service status +2. **Memory file** (instant) — cross-session context from the docs repo +3. **Skills** (on demand) — loaded only when the task matches a skill name +4. **Repo context** (on demand) — files read as needed, not all upfront -- [Image Generation](../skills/image-generation.md) --- generate game art with fal.ai Flux using a [4-layer prompt pattern](fal-image-generation) -- [Concept Art Pipeline](../skills/concept-art-pipeline.md) --- from design brief through 2D art to 3D model export -- [3D Model Generation](../skills/tripo-browser-workflow.md) --- Tripo Studio text-to-3D and image-to-3D -- [Video Generation](../skills/sora2-video.md) --- trailer clips with OpenAI Sora 2 +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. -Skills compound. Every playbook you write makes the agent more capable. After six months, our agents handle art generation, competitive research, video production, project management, and code review --- all from markdown files. +## The bet -### Git Platform: 3D Preview and LFS +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. -The [Gitea fork](forking-gitea) underneath handles the game-specific git problems: - -- **3D asset preview** --- rotate GLB/FBX/STL files in the browser during code review -- **LFS-first workflows** --- auto-tracking for game file extensions, storage dashboards -- **OAuth2 SSO** --- one login for git, tools, and the game -- **22 format support** --- GLB, FBX, OBJ, STL, 3DS, PLY, and more via O3DV - -### Guardrails: Human-in-the-Loop - -The harness defines what agents can and cannot do: - -- Agents can file issues, draft announcements, generate assets, write code -- Agents **cannot** merge code, deploy builds, push to public repos, or post to external channels without human approval -- The [public blog repo](https://tinqs.com/tinqs/blog) requires human-approved merge requests --- agents can propose changes but a person must review - -This isn't a limitation --- it's a feature. The agent handles volume; the human handles judgement. - -## The Cold Start Problem - -The biggest problem with AI agents in production isn't capability --- it's context. Every new session is blank. The agent doesn't know what happened yesterday, what's in progress, or what tools are available. - -Most teams solve this with long system prompts. That works until your context is 200 markdown files, 15 skills, and 3 years of project history. You can't paste all of that into a system prompt. - -The harness solves this with **staged loading**: - -1. **CLI identity call** (100ms) --- loads soul file, company context, machine info, service status -2. **Memory file** (instant) --- loads cross-session context -3. **Skills** (on demand) --- loaded only when the task matches a skill name -4. **Repo context** (on demand) --- read files as needed, not all upfront - -The agent goes from cold to fully contextual in under a second. No "let me explain..." No re-reading the same onboarding doc. Just start working. - -## What Makes This Different from LangChain - -LangChain, CrewAI, and similar frameworks are **code-first**. You define agents in Python, chain them with function calls, and deploy them as services. They're powerful for building AI products. - -Tinqs Studio is **file-first**. Agents are defined in markdown. Skills are markdown. Memory is markdown. Identity is markdown. Everything is in git, readable by humans, editable without code changes, and version-controlled. - -This matters for game teams because: - -- **Non-engineers can contribute.** The designer writes a skill for concept art. The PM writes a skill for sprint planning. No Python required. -- **Everything is auditable.** `git log` shows who changed what, when, and why. Memory changes are commits. Skill updates are diffs. -- **It works with any AI tool.** The same soul files and skills work in Cursor, Claude Code, or any tool that reads markdown. You're not locked into one framework. - -## The Stack - -| Layer | What | How | -|-------|------|-----| -| **Identity** | Soul files, company context | Markdown in git, loaded via CLI | -| **Memory** | Cross-session context | Markdown in git, updated by agents | -| **Skills** | Teachable workflows | Markdown playbooks, loaded on demand | -| **Tools** | CLI, screenshots, vision | Go binary, one install per machine | -| **Git** | 3D preview, LFS, SSO | Gitea fork with game-specific features | -| **Creative** | Image gen, 3D models, video | fal.ai, Tripo, Sora 2 via skills | -| **Guardrails** | Human approval gates | Branch protection, MR requirements | - -## Getting Started - -If you want to build your own agent harness for game dev: - -1. **Start with a soul file.** Write 50 words about your project's identity, values, and scope. Put it in your repo root as `SOUL.md`. -2. **Write one skill.** Pick the workflow you repeat most --- concept art generation, bug triage, build verification --- and write the steps as markdown. -3. **Build a CLI identity command.** Even a shell script that prints "project name, repos, services" gives your agent a warm start. -4. **Put everything in git.** Not a database, not a SaaS tool. Git. You already have it. - -The rest --- 3D preview, LFS management, OAuth SSO, creative pipelines --- you can add as you need it. Or use [Tinqs Studio](https://tinqs.com), where we've already built it. +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. --- -An agent harness isn't a product category yet. But it should be. 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. That's what we're building. +*Tinqs Studio is an agent harness for game development — git hosting, AI agents, creative pipelines. Open for teams. We're building [Ariki](https://arikigame.com) with the same tools.* diff --git a/posts/agentic-workflow.md b/posts/agentic-workflow.md index d09efc8..b85b9af 100644 --- a/posts/agentic-workflow.md +++ b/posts/agentic-workflow.md @@ -1,103 +1,90 @@ --- -title: "How a Small Game Studio Runs on AI Agents" +title: "How a 4-Person Studio Runs on AI Agents" slug: agentic-workflow date: "2026-03-06" -description: "Soul files, skill playbooks, and markdown as the universal API. How we built an agentic workflow that lets a 4-person indie studio operate at 10x scale." +description: "We gave AI agents persistent identities, skill playbooks, and access to our entire knowledge base. Here's how four people ship like forty." og_description: "Soul files, skill playbooks, and markdown as the universal API for AI agents in game dev." og_image: "https://www.tinqs.com/blog/img/agentic-workflow-architecture.png" -excerpt: "Soul files, skill playbooks, and markdown as the universal API. How we built an agentic workflow that lets a 4-person indie studio operate at 10x scale." +excerpt: "We gave AI agents persistent identities, skill playbooks, and access to our entire knowledge base. Here's how four people ship like forty." author: "Ozan Bozkurt" author_initials: "OB" author_role: "CTO & Developer, Tinqs" --- -We gave our AI agents persistent identities, skill playbooks, and access to our entire knowledge base. This is how a 4-person game studio built an agentic workflow that punches above its weight. +Last week one of our agents caught a stale bug at 3am — a vegetation culling issue that had been open for six days. It nudged the team chat, drafted a fix summary, and by morning the issue was resolved. Nobody lost sleep. Nobody context-switched. The agent just handled it. -## The Problem Every Small Studio Knows +This is what happens when you stop treating AI as a chatbot and start treating it as a team member with a persistent identity, a memory, and a set of skills it can actually execute. -When you're four people building a game, there's no room for a dedicated DevOps person, a full-time PM tool chain, or someone whose job it is to "keep things organised." Everyone wears five hats. Documentation drifts. Issues pile up. The left hand doesn't know what the right hand shipped. +## The problem with "just use ChatGPT" -We tried the usual tools --- Notion, Trello, shared Google Docs. They all had the same problem: they're passive. They sit there and wait for a human to update them. In a team of four where the lead developer is also the CTO, that human never has time. +Every small studio hits the same wall: four people, forty roles. Nobody has time to keep documentation current. Bugs pile up. The backlog rots. Someone asks "what did we decide about the inventory system?" and three different answers come back. -So we built something different. We gave AI agents persistent identities, connected them to our entire knowledge base, and let them become working members of the team. +The usual fix is more tools — Notion, Trello, Linear, Slack integrations. But tools are passive. They sit there waiting for humans to update them. In a team where the lead developer is also the CTO, that human is already stretched thin. -## The Architecture: Agents with Identity +We tried something different. Instead of adding more tools for humans to maintain, we gave AI agents persistent identities, connected them to our entire knowledge base, and let them do the maintenance. -Our primary AI agent runs inside the IDE and has access to the full documentation repository --- the game design document, backlog, meeting notes, company operations, everything. It's not a chatbot. It's a persistent team member with a **soul file** that defines its values and operating principles, and a **memory file** that persists context across sessions. +## Soul files: giving agents a personality that sticks -The key insight: **all knowledge lives in markdown files in one repo**. No databases, no SaaS dashboards, no proprietary formats. Plain text, version-controlled, readable by humans and agents alike. When anyone on the team opens the docs repo, the agent wakes up with full context of who they are, what machine they're on, and what's been happening. +The core idea is embarrassingly simple. Every agent gets a **soul file** — a markdown document that defines who it is, what it values, and how it should behave: -### What the agent actually does +- **Values** — "never break the build," "always verify before acting," "prefer existing patterns over novelty" +- **Knowledge scope** — what repos exist, who's on the team, what the game is about +- **Behavioural rules** — when to act autonomously, when to ask, what requires explicit human approval + +This isn't theatre. It's the difference between an agent that asks "what project is this?" every session and one that says "I see the vegetation grid was updated yesterday — want me to check the cache eviction?" + +The soul file loads in 100ms when the agent starts. No cold starts. No re-explaining. + +## Memory: markdown in git, not a vector database + +Agent memory lives as plain markdown files in our docs repo. No vector databases, no proprietary stores, no SaaS dashboards. The agent writes to its memory file during work, commits it, and reads it on the next session. + +This is deliberately low-tech. Markdown in git gives you version history, diffs, branching, and human readability for free. When memory goes wrong — and it will — you `git log` to see what changed and `git revert` to fix it. Try debugging a corrupted vector embedding at 11pm. + +## Skills: teachable playbooks, not prompt engineering + +Agents don't just have instructions. They have **skills** — markdown playbooks that teach specific workflows. When someone says "generate concept art for a character," the agent reads `skills/image-generation.md` and follows the procedure. No prompt engineering per session. No "let me try a different prompt." + +We've open-sourced several skills: + +- [Image Generation with fal.ai](../skills/image-generation.md) — 4-layer prompt pattern that actually produces usable game art +- [Concept Art Pipeline](../skills/concept-art-pipeline.md) — full 2D concept → 3D model workflow +- [3D Model Generation](../skills/tripo-browser-workflow.md) — Tripo Studio text-to-3D +- [Video Generation](../skills/sora2-video.md) — trailer clips with Sora 2 + +Each skill took about 30 minutes to write. After six months, our agents have 15+ skills covering art generation, competitive research, video production, and project management. Skills compound — every playbook you write makes every future session more capable. + +## What the agents actually do, every day + +**During the day** (interactive, inside the IDE): - Triages and grooms the issue backlog -- Keeps documentation in sync with the game state -- Processes bug reports from testers and creates structured issues -- Drafts team announcements, reviews PRs, manages cross-repo coordination -- Generates concept art, trailer frames, and UI assets using integrated API skills -- Conducts competitive research --- analysing Steam pages, player reviews, pricing strategies +- Keeps documentation in sync with what's actually in the game +- Processes tester bug reports and creates structured issues +- Generates concept art, trailer frames, UI icons on demand +- Conducts competitive research — Steam pages, player reviews, pricing -The team talks to the agent through voice. The IDE's built-in microphone transcribes and auto-translates (multilingual team). The agent is trained to interpret messy voice-to-text artifacts and act on intent, not grammar. +The team talks to the agent through voice. The IDE microphone transcribes, and the agent interprets intent from messy voice-to-text. "There's a tree floating two meters above the terrain on the west beach" becomes a filed issue with a screenshot, a vision-model description, and coordinates. -## Background Automation +**At night** (background daemon, $15/day): -The interactive agent only runs when someone opens the IDE. But a studio doesn't sleep --- bugs get reported at midnight, issues go stale, and the team chat fills up while everyone's away. +- Polls team chat every 15 minutes, responds to commands +- When a tester reports a bug in chat, creates a structured issue automatically +- Flags stale issues that haven't been touched +- Posts a morning digest of what happened overnight +- Creates its own skill files when it discovers better approaches -A background daemon runs 24/7, ticking every 15 minutes. It uses a three-tier model strategy --- cheap models for routine checks, medium for analysis, and premium only when it needs deep reasoning. The whole thing costs about $15/day. +## What we learned -### What it handles +**Plain text is the universal API.** Every tool, every agent, every human can read a markdown file. We store everything — design docs, meeting notes, agent memory, team contacts — as `.md` in one repo. It sounds too simple, but it eliminates an entire class of integration problems. -- **Chat monitoring** --- polls team chat, responds to commands, acknowledges messages -- **Bug intake** --- when a tester reports a bug in chat, creates a structured issue automatically -- **Stale issue detection** --- flags issues that haven't been touched, nudges the team -- **Daily summaries** --- posts a morning digest of what happened overnight -- **Self-learning** --- creates its own skill files when it discovers better approaches +**Cheap models for routine, expensive models for thinking.** Most of what an agent does is pattern matching — "does this look like a bug report?" You don't need DeepSeek Pro for that. Save the premium tokens for decisions that actually require reasoning. Our background daemon costs $15/day with a three-tier model strategy. -The two agents coordinate through the docs repo itself. One writes, the other reads. No API calls between them, no message queue. Just git. +**Voice changes everything.** When you can describe a bug while looking at the screen, and the agent transcribes, interprets, and files it — that collapses the distance between noticing a problem and tracking it. Keyboard-free bug reporting is a superpower. -## The Skill System +**Skills compound exponentially.** One skill saves 15 minutes per session. Fifteen skills save hours per day across the whole team. The investment curve is absurdly favourable — 30 minutes of writing per skill, compounding returns forever. -Agents don't just have instructions --- they have **skills**. Each skill is a markdown file that teaches the agent a specific workflow: how to generate concept art through a pipeline, how to use image generation APIs, how to conduct competitive research, how to create 3D models from concept art. - -When someone asks the agent to do something that matches a skill, it reads the skill file and follows the procedure. This means you can teach the agent new capabilities without changing any code --- just write a new markdown file. - -We've open-sourced several of our skills in this repo: - -- [Image Generation with fal.ai](../skills/image-generation.md) -- [Concept Art Pipeline](../skills/concept-art-pipeline.md) -- [3D Model Generation with Tripo](../skills/tripo-browser-workflow.md) -- [Video Generation with Sora 2](../skills/sora2-video.md) - -## Soul Files: Why Identity Matters - -Giving the agent a persistent identity isn't theatre. It creates consistency across sessions. The soul file defines: - -- **Values** --- what the agent prioritises (e.g., "never break the build," "always verify before acting") -- **Knowledge scope** --- what repos, services, and team members exist -- **Behavioural rules** --- how to handle ambiguity, when to ask vs act, what requires human approval - -The agent remembers what it learned, adapts to who's asking, and maintains the same principles whether it's triaging bugs or drafting a Steam page description. The soul file is the agent's constitution. - -## What We've Learned - -**Plain text is the universal API.** Every tool, every agent, every human can read a markdown file. We store everything --- design documents, meeting notes, agent memory, team contacts --- as .md files in one repository. This sounds almost too simple, but it eliminates an entire class of integration problems. - -**Cheap models for routine, expensive models for thinking.** Most of what an autonomous agent does is pattern matching and text formatting --- you don't need the most expensive model for that. Save the premium tokens for decisions that actually require reasoning. - -**The human stays in the loop for decisions.** The agents can file issues, draft announcements, and generate assets --- but they don't merge code, deploy builds, or post to public channels without explicit approval. The workflow is designed so the AI handles the grunt work while humans make the calls that matter. - -**Voice input changes everything.** When you can describe a bug while looking at the game screen, and the agent transcribes, interprets, and files an issue --- that's a workflow that collapses the distance between noticing a problem and tracking it. - -**Skills compound.** Every skill file you write makes the agent more capable. After 6 months, our agents have 15+ skills covering art generation, competitive research, video production, and project management. Each one took 30 minutes to write and saves hours every week. - -## The Numbers - -- **Team size:** 4 humans + AI agents -- **Background agent cost:** ~$15/day (~$450/month) -- **Knowledge files:** 200+ markdown documents -- **Skills:** 15+ agent skill files and growing -- **Infrastructure:** Multiple machines, self-hosted git, zero DevOps engineers +We're four people. With agents doing the mechanical work, we operate like forty. Not because the AI is magic — because we gave it identity, memory, and the right playbooks, and then got out of its way. --- -We're not claiming this is how every studio should work. But for a small team trying to build something ambitious, having AI agents that actually understand the project --- not just answer questions about it --- has been transformative. The agents don't replace anyone on the team. They make it possible for four people to do the work of forty. - -We're building all of this as part of [Tinqs Studio](https://tinqs.com) --- a game development platform that brings git hosting, AI tools, and team workflows together. The blog posts and skills in this repo are part of that journey. +*We're building [Ariki](https://arikigame.com), a survival colony sim, using the same agent workflow described here. Everything runs on [Tinqs Studio](https://tinqs.com) — a game dev platform with built-in AI agents, git hosting, and creative pipelines.* diff --git a/posts/blog-visual-upgrade.md b/posts/blog-visual-upgrade.md index e2e71e8..84f429f 100644 --- a/posts/blog-visual-upgrade.md +++ b/posts/blog-visual-upgrade.md @@ -1,276 +1,90 @@ --- -title: "Our Blog Just Got a Visual Upgrade — Here's How We Did It" +title: "How We Restyled Our Blog with Two Template Files and Zero Dependencies" slug: blog-visual-upgrade date: "2026-06-03" -description: "We gave the Tinqs blog a visual refresh, borrowing the dark, gradient-heavy aesthetic from our internal team guides. No external CSS tinkering, no framework, no build-step drift — just two template files and a Node script." -og_description: "How we restyled the Tinqs blog with a gradient-first, dark-code-panel aesthetic — using only two template files and a markdown build script." +description: "Gradient titles, dark code panels, amber callouts — we gave the Tinqs blog a visual refresh borrowing our internal team guide aesthetic. Two template files, one Node script, no framework." +og_description: "Blog restyle: gradient titles, dark code panels, amber callouts — two template files, zero deps." og_image: "https://www.tinqs.com/img/og-cover.jpg" -excerpt: "We gave the Tinqs blog a visual refresh — borrowing the dark, gradient-heavy look from our internal team docs. Here's why, what we changed, and how the build system made it painless." +excerpt: "We gave the Tinqs blog a visual refresh — gradient titles, dark code panels, date pills, amber accent bars. Two template files, one build step, zero external dependencies." author: "Ozan Bozkurt" author_initials: "OB" author_role: "CTO & Developer, Tinqs" --- -Until yesterday, the Tinqs blog looked... fine. Readable. Semantic. It had the brand amber accent, proper typography, and all the SEO metadata in the right places. But it didn't have much *personality*. The code blocks were unstyled. The headings sat flat. And the design said "competent" more than "intentional". +Our blog looked fine. Readable, semantic, proper typography. But it didn't have much personality. Code blocks were unstyled. Headings sat flat. The design said "competent" more than "intentional." -Then we looked at our own internal team guide — the onboarding doc we keep at `docs/team/dev-basics-env-secrets-git.html`. It had gradient titles that clip to transparent. Dark, crisp code panels. Callout boxes with coloured left borders. Pill-shaped date labels. A restrained four-colour palette that felt cohesive without screaming. +Then we looked at our internal team guide — a self-contained HTML doc with gradient titles that clip to transparent, dark code panels, and callout boxes with coloured borders. It radiated a "well-maintained developer doc" energy. We wanted the blog to feel like it came from the same shop. -We wanted the blog to feel like it came from the same shop. So we restyled it. +Two template files, one build step, zero external dependencies. Here's what we changed. -## The design source +## The build system (why it mattered) -Our team guide is a single self-contained HTML file with a dark theme — background `#0d1117`, panels `#161b22`, ink `#e6edf3`. It uses a four-accent palette: - -- **Green** `#22c55e` — for `.env` and environment topics -- **Blue** `#38bdf8` — secondary links, kickers, syntax table headers -- **Purple** `#a855f7` — git topics, hover states -- **Amber** `#f59e0b` — warnings, emphasis, callouts - -The title is the star: an `h1` filled with a `linear-gradient` across all four colours, clipped to the text via `-webkit-background-clip: text`. Code blocks live in dark `#0a0e14` panels with `#2a3340` borders. Blockquotes become amber-tinted callouts. The whole thing radiates a "well-maintained developer doc" energy without feeling like a Bootstrap template. - -We wanted that energy on the public-facing blog. - -## The build system (and why it mattered) - -The blog is generated by a zero-dependency Node script — `build.js` — that converts markdown posts into HTML. The pipeline is: +The blog is generated by `build.js` — a zero-dependency Node script that converts markdown to HTML: ``` posts/*.md + _template.html / _index_template.html → *.html ``` -This means **we never touch a generated `.html` file by hand**. Every visual change flows through the two templates. `build.js` then stamps out all 11 posts plus the index in under a second. +This means we never touch a generated `.html` file by hand. Every visual change flows through the templates. The site-wide CSS — nav, footer, base typography, brand accent — lives in `../style.css`, served by Git Studio from outside the repo. We didn't touch it. -The site-wide CSS — navigation, footer, base typography, the brand amber `--c-accent: #c9935a` — lives in `../style.css`, which is served by Git Studio from outside the blog repo. We deliberately **did not** touch that file. Instead, we injected a self-contained `