NixieFX makes one part of game creation AI-ready. Wagglet makes the team AI-ready. An expert prepares a detailed agent brief and a concise human runbook; an eligible teammate claims it and runs it with their own authenticated AI subscription; the human and agent build and test the work together; evidence returns to a qualified reviewer. The task moves. Accounts, API keys, subscriptions, and token balances do not.
NixieFX is one layer of a much bigger game loop
NixieFX can make VFX fast to author, export, and integrate. Three.js or PixiJS can make the game agent-readable. A text-first backend and a web-native mobile shell can shorten the rest of the technical stack. But a studio can own all of those tools and still move slowly because every useful task waits for the same few people to write the prompt, start the agent, answer its questions, test the result, and decide what “done” means.
A game studio does not ship particle files. It ships player outcomes.
One feature can cross game design, economy, backend state, client code, UI, animation, VFX, audio, analytics, device QA, store constraints, and live-ops delivery. Speeding up any one craft is valuable. Speeding up all the tools is better. Neither guarantees that the work will reach the right person with the right context at the right moment.
This is why the technical stack and the operating stack answer different questions:
| Stack | Examples | The question it answers |
|---|---|---|
| Technical stack | Three.js, PixiJS, NixieFX, SpacetimeDB, Capacitor, Capawesome | How do we create, run, and deliver the game? |
| Operating stack | Wagglet, prepared tasks, human-agent handoffs, evidence, review | How does an idea become bounded work, reach an available person-agent pair, and return as a verified outcome? |
The web-native F2P mobile game stack is designed to compress the technical loop. Wagglet sits above that toolchain. It does not render a frame or deploy a build. It carries the context, human role, supervision, proof, and decisions that make the tools useful across the whole studio.
Faster tools move the bottleneck into the team
Imagine a small mobile studio with ten people and excellent AI-ready tools:
- Two engineers are at their Claude Code or Codex limits.
- An artist can judge motion and composition but cannot initialize the project.
- A producer knows exactly how a live event should behave but not what prompt would let an agent implement it safely.
- QA has the right devices and edge-case instincts but no repository setup.
- Several teammates still have plenty of paid AI capacity available.
- Every task waits for one technical lead because only that person can package the context and supervise the run.
The bottleneck is no longer typing code. It is expert attention.
The usual response is to buy more API usage for the busiest people or accept that everyone else is “waiting on a task.” Wagglet offers a different operating model: separate preparing the work from supervising the last mile.
The expert contributes the expensive part—outcome, context, constraints, acceptance criteria, and stop rules. Another teammate contributes access, attention, real-world judgment, device time, and supervision. The agent carries the technical brief through setup and execution.
The expert does not disappear. Their knowledge becomes a prepared task that can travel farther than their calendar.
The new unit of game work is a human-agent pair
Traditional project management writes tasks for people. Prompting writes tasks for models. An AI-native studio needs both at once.
Wagglet keeps two instruction layers inside the same task:
| Reader | What they need |
|---|---|
| Agent | The full technical truth: outcome, project and repository context, existing conventions, allowed scope, dependencies, checks, proof, and stop conditions. |
| Human | A short operating role: which session to start, which access or judgment only they can provide, what to observe, what evidence to capture, and when to escalate. |
Wagglet calls this the Dual Prompt. It is not two secret model prompts. It is one task designed for two different kinds of attention.
The agent helps the human bridge setup and implementation gaps. The human helps the agent bridge reality, authorization, taste, product judgment, and the things a test suite cannot see. Each participant has a job the other cannot silently absorb.
This changes how detailed tasks can be. A task author no longer has to assume a busy human will skim away the important constraints. The agent can carry the full brief while the human sees a focused runbook. Detail becomes operational instead of decorative.
From one game idea to a studio production line
Consider a weekend boss event. It needs a new combat phase, reward state, HUD panel, arena transformation, NixieFX burst, analytics events, and a device QA pass. That is not a VFX task. It is a small cross-functional game feature.
The studio defines the player outcome, packages it into bounded two-audience tasks, routes those tasks to eligible teammates who use their own agent sessions, collects evidence from the current attempts, and returns the results to qualified review. Acceptance, Git merge, and release remain separate decisions.
1. Capture the outcome before prescribing implementation
The producer starts with the player promise: when the boss reaches the new phase, the arena transforms, the dodge warning stays readable, the reward is granted exactly once, and the event is observable in analytics.
That rough request can become prepared work. The owner adds the systems that must not change, supported devices, performance and economy boundaries, existing seams to reuse, required evidence, and questions that must come back to a specialist.
2. Split the feature into work that can actually move
The event can become several bounded tasks rather than one heroic prompt:
- Combat and reward state.
- HUD and player messaging.
- Arena art, animation, and NixieFX.
- Analytics and live-ops configuration.
- Target-device sanity checks.
- Integration and release evidence.
Dependencies remain visible. A private Draft can be refined before it enters the public queue. Published work can be claimed when it is ready. The aim is not to create more cards. It is to create units of work that a person-agent pair can finish and another person can evaluate.
3. Let different people carry different parts
An engineer may prepare the technical instructions for the combat state. A producer can run that handoff while verifying the intended phase behavior. An artist can run the arena and VFX handoff, with the agent handling project setup and integration while the artist judges motion in context. QA can run the device task, with the agent preparing exact states and collecting logs while QA explores the real interaction.
The author does not disappear. Their knowledge remains in the brief and they, or another qualified owner, review the evidence later.
4. Deliver proof, not agent confidence
“The agent says it is done” is not a studio outcome.
A useful delivery can include the branch and changed files, tests and builds, fresh screenshots or video from the current attempt, device and game state, performance measured or explicitly unmeasured, limitations, warnings, and any decision that still needs an expert.
Wagglet can require current-attempt visual proof. It can verify that the proof exists. A human still judges what the proof means.
5. Keep the lifecycle truthful
Delivery records what the pair produced. Acceptance records that a reviewer believes it meets the task. Merge state records what happened in Git. Deployment records what reached an environment.
Those are four different truths. Collapsing them into one green status makes a board look faster while the actual game stays unchanged.
More teammates become useful without becoming interchangeable
The revolutionary claim is not that every employee becomes an engineer, artist, producer, analyst, and QA specialist. They do not.
The change is subtler and more useful: a narrow technical gap no longer has to block the valuable judgment on the other side of it.
- An artist may not know the build system but may be the best person to reject bad timing, composition, readability, and polish.
- An office or operations teammate may not write the fix but may understand the real customer flow better than the engineer who built it.
- A producer may not design the data model but may be the best person to verify that the implemented state matches the feature promise.
- QA may not know the code path but may know the exact device and state combination that exposes the truth.
- A junior engineer may not know the subsystem but may be perfectly capable of supervising an expert-prepared brief and escalating at the named stop conditions.
The agent closes setup and implementation gaps. The human supplies access, attention, taste, domain knowledge, and accountability. A qualified reviewer retains the final authority appropriate to the risk.
That creates a much larger surface where people can contribute real work. It can also make the day feel less like waiting for permission and more like moving something the team values. That is an operating hypothesis to test with voluntary participation and honest feedback—not a promise that every handoff makes every employee happy.
Use more of every AI subscription the studio already pays for
This workflow also changes subscription economics.
In a ten-person company, five people may exhaust their Claude Code or Codex allowance while five use little. Buying API overflow for the first group ignores capacity already sitting inside the team.
Wagglet lets a saturated person prepare a task and an available teammate claim and run it through the provider account already authorized for that teammate. It is closer to carpooling work than pooling tokens.
The thing that moves is the prompt, context, and responsibility. The login, account, API key, subscription, and token balance do not move.
This can recover more output from sunk seat cost and may avoid some incremental spend. It is not automatically cash savings, and there is no honest universal “5x” number. The result depends on spare capacity, eligible tasks, completion rate, coordination overhead, and what the company would otherwise buy. Measure those inputs in a real pilot.
Game developers already understand the power of feedback loops
Games make goals visible. They show progress, reward useful behavior, and give people a reason to complete the next meaningful action. A studio can apply the same design discipline to work without turning colleagues into a manipulative leaderboard.
Wagglet can attach Work Value and bounties to tasks, record contribution, and make completed outcomes visible. Used well, those mechanics answer practical questions: Which work matters? What can I pick up? What did I help finish? Where is the team combo?
The reward must follow a verified outcome, not raw activity. Otherwise the system teaches people to create easy tickets, hoard work, or optimize a score instead of the game. Contribution from creation, collaboration, execution, and review should remain legible; sensitive individual monitoring and fake competition should not become the product.
Clear goal → voluntary claim → human-agent work → visible proof → qualified acceptance → meaningful recognition.
That is gamification in service of flow, not points pasted on top of chaos.
Start with one production line, not a reorganization
Do not migrate the entire studio because this article sounds exciting. Pick one repeatable queue where waiting is obvious and correctness is observable:
- UI polish and reward feedback.
- VFX and animation integration.
- Live-event configuration.
- Small product bugs.
- Device sanity checks.
- Content and localization QA.
Prepare the agent brief and human runbook. Let an eligible teammate claim it with their own AI subscription. Require evidence. Keep qualified acceptance and release authority in place. Then measure:
- Time from request to prepared task.
- Wait time before claim.
- Author, runner, and reviewer attention.
- Accepted outcomes and rework.
- Subscription capacity actually used.
- Failure causes and tasks that should never have been delegated.
- Whether people felt able to contribute useful judgment.
NixieFX makes one part of the game easier to create. Wagglet makes the whole studio's prepared work easier to move. The future game-dev stack needs both: tools that agents can operate, and an operating system where humans and agents can finish trustworthy work together.
Frequently asked questions
What is Wagglet?
Wagglet is a shared AI task queue for teams. It coordinates prepared work, separate agent and human instructions, claiming, evidence, recorded delivery, review, and contribution across a team.
Is Wagglet integrated directly into NixieFX?
No direct integration is required. NixieFX is a particle editor and runtime. Wagglet is the operating layer around the work: who prepares it, who runs it, what the agent receives, what the human checks, and how the result is reviewed.
Does Wagglet share Claude Code or Codex accounts?
No. A teammate runs the task through their own authenticated provider session. Wagglet moves task context, not accounts, logins, API keys, subscriptions, or token balances.
Can anyone safely complete any game-dev task with an agent?
No. Good handoffs are bounded, reversible, observable, role-matched, and reviewable. High-risk security, privacy, payment, player-data, production, and irreversible decisions still need the right specialists and authority.
Does a Wagglet delivery mean the work shipped?
No. Delivery, acceptance, Git merge, and deployment are separate lifecycle facts. A truthful workflow preserves all four.
Build both halves of the stack
- Open Wagglet Prepare, route, verify, and review work across the team.
- The web-native F2P mobile game stack See the technical tools beneath this operating layer.
- Install the NixieFX agent skills Give agents the authoring and runtime procedures.
- Open the NixieFX editor Author and export VFX inside your real game project.
If you are building games with NixieFX, open Wagglet and try one bounded production line with your team.
This article is maintained by the team behind NixieFX, the browser-based HTML5 particle editor for PixiJS and Three.js. NixieFX and Wagglet are complementary tools; neither requires a built-in integration with the other. A machine-readable version is available at /ai-native-game-studio.md, and a site index for LLMs at /llms.txt.