DEV Community: Hiroshi TK

Delivered Is Not Done in AI-Assisted Software Work

Hiroshi TK — Mon, 24 Aug 2026 07:13:39 +0000

AI coding agents are very good at sounding finished.

A coding session often ends with a message such as:

"Implemented the requested feature. Added tests. Everything is working correctly."

That sounds reassuring.

It may even be true.

But the statement still came from the same system that performed the work.

That should be treated as a delivery report.

It should not automatically be treated as independent verification.

SOFTWARE TEAMS ALREADY UNDERSTAND THIS

Normal software development has always separated implementation from approval.

Developers write code.

Tests check known behavior.

Pull requests expose changes.

Reviewers inspect the implementation.

QA checks important workflows.

CI verifies builds.

Staging catches environment problems.

Deployment checks help confirm whether the release actually worked.

AI-generated code should not remove these distinctions.

If anything, it makes them more important.

THERE ARE MORE STATES THAN "DONE"

Imagine an AI agent finishes a coding task and creates a branch.

What does "done" actually mean?

It could mean the agent attempted the requested work.

It could mean files were changed.

It could mean some tests passed.

It could mean the agent believes the task was completed.

It could mean a human reviewed the result.

It could mean the branch was accepted.

It could mean the code was merged.

It could mean the change was deployed.

It could mean the feature was verified in production.

Those are different events.

Putting all of them under a single status called "Done" hides useful information.

DELIVERY IS A CLAIM

A better delivery message is:

"This is what changed. This is what was tested. This is the evidence. These are the remaining uncertainties."

That is a useful output.

It is also appropriately limited.

The agent may have misunderstood the original requirement.

The tests may not cover the important edge case.

The implementation may work technically while creating a poor user experience.

The development environment may differ from production.

The agent may simply be wrong.

A delivery report should help somebody else review the work.

It should not replace review.

ACCEPTANCE IS A DIFFERENT DECISION

The person or system delivering the work answers one question:

"What did we produce?"

The reviewer answers another:

"Is this acceptable?"

Those are not the same question.

Separating them reduces the risk of turning a confident completion message into automatic approval.

This is especially useful as teams start delegating more work to AI agents.

A task can be executed successfully and still fail review.

That is normal.

It means the workflow is doing its job.

DEFINE ACCEPTANCE BEFORE THE WORK STARTS

Review becomes much easier when the task contains clear acceptance criteria.

Suppose the task involves authentication.

Weak acceptance criteria would be:

"Make sure login still works."

Stronger criteria might specify that existing authentication tests must pass, unauthorized users must still be blocked, expired sessions must return the expected error, no credentials may appear in logs, and the staging flow must be tested manually.

Now the final review has something concrete to compare against.

The reviewer is not trying to guess whether the task feels complete.

They can inspect the evidence against a known standard.

THIS IS WHERE WORKFLOW TOOLS MATTER

Wagglet separates task delivery from task acceptance.

https://wagglet.com

That distinction is important because the person or agent reporting the work does not automatically decide whether the work is good enough.

A task can be prepared, claimed, executed, delivered, reviewed, accepted, or sent back.

Those states preserve information.

They also make it easier to understand what actually happened.

"Delivered" means somebody produced a result.

"Accepted" means somebody with the appropriate responsibility reviewed that result and decided it met the requirement.

That is a much more useful distinction than a generic "Done."

HUMAN REVIEW SHOULD NOT BE CEREMONIAL

There is another common failure mode.

A company adds a human approval button and assumes that automatically creates safe AI oversight.

It does not.

A human clicking "Approve" without enough evidence is not meaningful review.

Good review requires context.

The reviewer needs to understand what the task was supposed to accomplish.

They need evidence showing what happened.

They need enough knowledge or authority to judge whether the result is acceptable.

Without those things, human review becomes a formality.

EVIDENCE SHOULD MATCH THE TASK

Different tasks need different evidence.

A UI task might need screenshots.

A performance task might need before-and-after measurements.

A bug fix might need a reproduction case and test results.

A database migration might need schema output, migration logs, and rollback confirmation.

A documentation task might need the changed files and link checks.

A security-sensitive task might require a qualified reviewer and additional automated checks.

There is no universal delivery package.

The evidence should match the risk and the nature of the task.

SOME REVIEW BELONGS TO MACHINES

Human review does not mean humans should manually check everything.

Machines are better at many deterministic checks.

Tests can verify expected behavior.

Linters can catch structural problems.

Type systems can catch invalid assumptions.

CI can verify builds.

Security scanners can identify known patterns.

Automated checks should handle the parts that are repeatable and objective.

Humans should focus on the parts that require judgment.

Does the workflow make sense?

Does the visual result match the intended design?

Did the implementation preserve the product behavior?

Is this an acceptable tradeoff?

Does the change introduce a risk that the automated tests do not understand?

That is where human review is most valuable.

RISK SHOULD DETERMINE PROCESS

None of this means every AI-generated change needs a complicated approval chain.

A typo in internal documentation does not need the same workflow as a payment authorization change.

Review should match risk.

Low-risk tasks can move quickly.

High-risk tasks should produce stronger evidence and involve more qualified reviewers.

The important part is that the workflow uses truthful states.

Attempted is not delivered.

Delivered is not accepted.

Accepted is not merged.

Merged is not deployed.

Deployed is not automatically successful.

As AI agents perform more implementation work, those distinctions will matter more, not less.

The best AI workflows will not be the ones with the most approval buttons.

They will be the ones where every status has a precise meaning, every important decision has an owner, and an agent cannot declare its own work correct simply because it finished generating code.

The Best AI Tasks Are Written for Two Readers

Hiroshi TK — Mon, 24 Aug 2026 07:12:43 +0000

Most AI-assisted tasks are still written as if there is only one reader. Sometimes the task is written for the developer. Sometimes it is written like a prompt for the AI agent. That approach starts breaking down when a teammate and an AI coding agent are expected to complete the work together. There are actually two readers. They need different information.

THE FIRST READER IS THE AI AGENT
The coding agent needs the detailed working brief.

For a software task, that can include the intended outcome, repository context, relevant files, technical constraints, existing patterns, tests, known edge cases, and things that must not change. This part of the task can be detailed. That is useful. The agent does not need a short motivational summary. It needs enough information to avoid guessing. If there is an existing helper that must be reused, say so. If changing a particular API is outside the scope of the task, say so. If the result must work on mobile as well as desktop, say so. If a specific test suite needs to pass, include it.

Missing context does not make an agent more flexible. It usually makes the result less predictable.

THE SECOND READER IS THE HUMAN
The person supervising the task has a different job. They probably do not need to reread every implementation detail. They need operational instructions. Which environment should they open? Which agent should they use? What should they inspect? What result are they responsible for judging? What should cause them to stop? When should they ask the task author for help? These are human instructions. They are different from the technical prompt sent to the coding agent.

ONE GIANT PROMPT IS USUALLY WORSE
A common approach is to put everything into one large description. That creates a compromise document. The human starts skimming because the task contains too much technical detail. Important supervision instructions become buried. Then task authors start shortening the description because nobody wants to read it. Now the AI agent loses useful context. Both readers receive a worse version of the task. Separating the instructions is cleaner. The agent gets what it needs for execution. The human gets what they need for supervision.

A SIMPLE EXAMPLE
Imagine the task is:

"Add CSV export to the invoice table."

That sentence sounds clear until someone actually starts implementing it. The coding agent may need to know that the export must respect active filters. It may need to use the existing invoice query. It may need to preserve current date formatting. It may need to escape commas and quotation marks correctly. It may need to include invoice IDs. It may need to add tests. It may also need an explicit instruction not to modify invoice calculations. Those are agent instructions. The human runner needs something different. They may need to open the test account. Generate several CSV files. Open them in a spreadsheet. Check totals. Check accented names. Check filtering. Verify that the expected rows are present. Stop if tax calculations appear to have changed. The two instruction sets point toward the same result. They simply describe different responsibilities.

THIS MAKES AI TASKS EASIER TO HAND OFF
Once tasks are structured this way, the original author does not need to supervise every agent session personally. They can put their technical knowledge into the task. Another teammate can run it. That teammate does not need to reconstruct the author's reasoning from Slack messages, old tickets, and repository history. The AI gets the implementation context. The human gets the operating instructions. A reviewer can inspect the evidence afterward. That is much closer to a proper work handoff. Wagglet uses this kind of two-audience approach for AI task handoffs. https://wagglet.com
The idea is useful because it treats the human runner and the AI agent as separate participants instead of assuming they need the same prompt.

HUMAN INSTRUCTIONS SHOULD INCLUDE STOP CONDITIONS
One of the most useful things a task can contain is a clear stopping rule.

For example:

Stop if the migration requires deleting existing records.

Do not change authentication behavior.

Escalate if the required API is undocumented.

Do not use production customer data.

Ask the task author if the implementation needs a new permission.

These rules matter because AI agents are generally optimized to keep moving toward completion.

That can be useful.

It can also create problems when the task reaches an unexpected boundary.

The human supervising the work needs to know when continuing is no longer the correct action.

THE AGENT NEEDS BOUNDARIES TOO
Stop conditions should not exist only in the human instructions.

The agent should also understand the task boundaries.

If database schema changes are out of scope, say so.

If introducing a new dependency requires approval, say so.

If existing public API behavior must remain unchanged, make that explicit.

A good task does not only explain what should happen.

It also explains what should not happen.

DELIVERY SHOULD PRODUCE EVIDENCE
A strong AI task should define what the final delivery needs to contain.

"Tell me when it is done" is too vague.

A better delivery might include the files changed, tests run, test results, screenshots, known limitations, and anything the runner could not verify.

This gives the reviewer something concrete to inspect.

It also makes weak task completion easier to spot.

If the task requires screenshots and no screenshots were provided, the delivery is incomplete.

If the task requires a specific test suite and the runner cannot confirm it was executed, that is visible immediately.

THE HUMAN SHOULD HAVE A REAL JOB

There is a bad version of human oversight where the person simply launches the agent and approves whatever comes back.

That is not meaningful supervision.

The human should have a responsibility the AI cannot simply declare complete on its own.

They might inspect a visual result.

Confirm behavior in a real browser.

Check a staging environment.

Judge whether a user flow makes sense.

Review a security-sensitive change.

Compare the result against a design.

The human role should be explicit.

Otherwise "human in the loop" becomes a label rather than an actual control.

BETTER AI WORK STARTS BEFORE THE AGENT RUNS
There is a lot of attention on model choice.

Teams compare coding agents, context windows, benchmarks, and subscription plans.

Those things matter.

But many failures start before the model is ever involved.

The task is vague.

Nobody wrote down the constraints.

The human role is undefined.

Success is subjective.

The reviewer receives a confident completion message instead of useful evidence.

Writing the task for two readers fixes a surprising amount of this.

Give the AI the technical brief.

Give the human the operating instructions.

Give both clear boundaries.

Then define what evidence must exist before the work can be considered complete.

That produces a much stronger unit of AI-assisted work than a prompt pasted into a coding chat.

What AI-Friendly VFX Tooling Actually Looks Like

Hiroshi TK — Mon, 24 Aug 2026 06:33:48 +0000

Coding agents are much better at working with some project structures than others.

Give an agent a TypeScript project with readable files and clear scripts and it can usually navigate the codebase reasonably well.

Give it a proprietary binary project file containing half of the application's important data and things become much harder.

This is especially relevant to game development.

A modern game is not only source code.

It contains:

Scenes
Animations
Materials
Particle effects
Configuration
Maps
Dialogue
UI layouts
Asset references

If those systems are represented as readable data, automation becomes much more useful.

Text Is the Interface

Consider two particle workflows.

Workflow A:

effect.bin

Workflow B:

effects/
  fire.json
  explosion.json
  heal.json

An AI coding tool can read the second structure.

It can inspect the effect.

It can find references.

It can rename files.

It can compare two configurations.

It can generate another effect based on an existing one.

It can run validation afterward.

The format does not have to be designed specifically for AI.

It simply needs to be accessible to normal developer tooling.

Visual Editors Still Matter

This does not mean developers should create particle effects by asking a model to write hundreds of JSON properties.

That would be replacing one bad interface with another.

Some work is inherently visual.

Particle timing is visual.

Color gradients are visual.

Curves are visual.

Material graphs are visual.

The useful workflow combines both approaches.

coding agent
     |
     v
readable project data
     |
     v
visual editor
     |
     v
validation
     |
     v
game

The agent can handle structural tasks.

The developer or artist can handle visual judgment.

CLI Support Makes the Difference

Readable files are only part of the story.

A good tool also needs commands that software can run.

For example:

vfx validate .
vfx export .

Now an agent can make a change and check whether that change is valid.

This creates a closed loop:

inspect
change
validate
fix
export

Without validation, generated changes are mostly guesses.

With validation, tooling can at least detect structural problems automatically.

A tool such as NixieFX is interesting here because this style of VFX workflow fits naturally with the same developer tooling already used for web projects.

The key idea is not "AI-generated particles."

It is making VFX projects readable and operable by the same tools that already understand the rest of your repository.

Deterministic Behavior Helps Too

Particle effects frequently use randomness.

That can make debugging annoying.

You run the effect once and it looks correct.

Run it again and the particles take slightly different paths.

Now imagine an automated test trying to determine whether behavior changed.

Deterministic simulation makes this easier.

Given the same input and seed, you want the same result.

That improves:

Testing
Debugging
Replay systems
Visual comparisons
Automated tooling

Determinism has always been useful in game development.

AI-assisted workflows simply give us another reason to care about it.

Agents Should Not Need Your Editor Open

Another useful test is this:

Can important project operations happen without somebody manually clicking through the editor?

Suppose your CI machine needs to verify every particle effect.

If validation only exists as a button inside a graphical application, automation becomes awkward.

If it exists as:

npm run vfx:validate

you can run it anywhere.

The same applies to exporting.

This is not specifically an AI feature.

It is good tooling design.

AI agents simply benefit from the same interfaces that build servers and shell scripts have used for years.

Tooling Needs Clear Boundaries

An agent should also know which files it is allowed to modify.

A clean project might distinguish between:

particle-data/effects/

and:

out/vfx/

The first is source.

The second is generated output.

That is much safer than having editable and generated files mixed throughout the project.

The same principle applies to ordinary web applications:

src/
dist/

Nobody should be manually editing dist.

VFX pipelines benefit from the same rule.

AI-Friendly Usually Means Developer-Friendly

There is a tendency to add AI-specific features to products and call the result AI-friendly.

The more important work is usually less flashy.

Use text formats.

Expose a CLI.

Return useful errors.

Keep generated files separate.

Make project structure predictable.

Provide documentation.

Allow tools to validate their own output.

Those features make coding agents more capable, but they also make the project better for humans.

If a tool works well from Git, a terminal, an editor, and CI, there is a good chance it will work well with coding agents too.

That is probably the more useful definition of AI-friendly tooling.

How Particle Effects Improve Game Feel in HTML5 Games

Hiroshi TK — Mon, 24 Aug 2026 06:32:10 +0000

A game can be mechanically correct and still feel flat.

The button works.

The enemy loses health.

The coin counter increases.

The level completes.

Everything technically functions, but the player's actions do not seem to have much weight.

Particle effects are one of the cheapest ways to fix that.

Not because every screen needs fireworks, but because particles give actions a visible consequence.

Feedback Should Happen Immediately

Imagine tapping an enemy in a mobile game.

Version A:

tap
enemy HP decreases

Version B:

tap
small flash
impact particles
enemy reacts
HP decreases

The underlying mechanic is almost identical.

The second version communicates the result more clearly.

The player sees exactly where the hit happened.

That matters on mobile screens where fingers frequently cover part of the action.

Particles Can Explain the Game

VFX is not only decoration.

It can communicate state.

Damage

Particles show where an impact happened.

Healing

A slow upward effect can visually separate healing from damage.

Selection

A subtle glow or ring can show which object is active.

Currency

Particles moving toward a counter connect the collected object with the UI value that changed.

Cooldowns

A burst or dissolve can show that an ability has become available.

Danger

Smoke, sparks, or unstable energy can communicate that an object is close to breaking.

Good VFX helps the player understand the game without another label or tutorial popup.

Timing Matters More Than Particle Count

A common mistake is assuming better effects need more particles.

They usually need better timing.

Consider a button press.

You could emit 100 particles over two seconds.

Or you could emit 12 particles exactly when the interaction occurs.

The second effect will often feel better because it reinforces the player's action.

For responsive games, the sequence might look like this:

0 ms      input
0 ms      visual response begins
20 ms     burst expands
80 ms     largest particles appear
200 ms    effect begins disappearing
350 ms    effect is finished

Short effects are particularly useful for interfaces because they provide feedback without blocking the next action.

Layering Small Effects Works Well

One giant particle system does not have to do everything.

A satisfying interaction can combine several tiny effects:

impact flash
+
8 directional sparks
+
small smoke puff
+
screen shake
+
sound

Each component has one job.

This also makes tuning easier.

If the hit feels too noisy, reduce the sparks.

If it lacks weight, adjust the flash or shake.

If it disappears too quickly, extend the smoke.

Build a Reusable Effect Vocabulary

For larger games, it helps to create categories instead of designing every effect from scratch.

For example:

impact-small
impact-medium
impact-heavy

reward-small
reward-medium
reward-large

dust-small
dust-running
dust-landing

ui-success
ui-error
ui-unlock

Then the visual language of the game stays consistent.

A large reward looks related to a small reward, only stronger.

A heavy attack looks related to a light attack.

Players learn those patterns without consciously thinking about them.

Authoring Speed Becomes Important

Once effects are used this often, editing them directly in source code gets annoying.

That is where a dedicated particle editor starts making sense.

For browser games, a tool such as the NixieFX VFX editor is an example of moving particle authoring out of gameplay code while keeping the workflow focused on web rendering.

The exact tool matters less than the workflow.

You want to be able to modify:

Curves
Gradients
Size
Velocity
Emission
Textures
Lifetime

and see the result immediately.

Mobile Performance Still Matters

There is an obvious catch.

Particles are easy to overuse.

A desktop GPU may happily render an effect that causes trouble on an older phone.

Some practical rules help.

Keep Particle Lifetimes Short

Particles that remain alive for several seconds accumulate quickly.

If you spawn 100 particles per second and each survives for five seconds, you may eventually have around 500 active particles.

Reducing lifetime to one second changes the situation dramatically.

Avoid Unnecessary Transparency

Large overlapping transparent sprites create a lot of overdraw.

This can be expensive on mobile GPUs.

A screen covered in giant transparent smoke particles may hurt performance more than hundreds of tiny sparks.

Cap Device Pixel Ratio

For WebGL games, rendering at the full pixel density of every phone is often unnecessary.

A high-density display can massively increase the number of pixels your effects touch.

Profile the Bad Moments

Do not only test an effect by itself.

Test the moment where:

Five enemies explode
Rewards spawn
The UI animates
The background is moving
Post-processing is active

That is the frame your player actually experiences.

Good VFX Is Information With Style

The best particle effects do several things at once.

They make the game look better.

They tell the player what happened.

They emphasize important actions.

They create rhythm.

They make interactions feel responsive.

For HTML5 games, none of this requires millions of particles or complicated shaders.

A handful of well-timed effects can make a simple mechanic feel far more finished.

Start with feedback.

Add particles where the player needs to see the result of an action.

Then remove anything that is not helping.

A Git-Friendly Particle VFX Workflow for Three.js and PixiJS

Hiroshi TK — Mon, 24 Aug 2026 06:27:19 +0000

Git is great at tracking code.

It is less pleasant when important parts of your game are hidden inside opaque editor files.

That becomes noticeable when you start building a serious VFX library.

An explosion changes.

What changed?

Was it the texture?

The particle lifetime?

The emission shape?

The velocity curve?

The blend mode?

If your effect is stored as readable data, answering those questions becomes much easier.

VFX Works Surprisingly Well as Text

A particle system is mostly structured configuration.

Conceptually, an effect might contain something like this:

{
  "name": "impact",
  "duration": 0.5,
  "emission": {
    "count": 18
  },
  "lifetime": {
    "min": 0.2,
    "max": 0.5
  }
}

Real effects obviously contain more information, but the important point is that most of it can be represented cleanly as data.

Once the source is JSON, normal development tools start working on your visual effects.

You get:

Git history
Diffs
Branches
Pull requests
Code review
Merge tooling
Search
Scripts
CI validation

That is useful even if nobody on the team ever edits the JSON manually.

Reviewing Visual Changes

Suppose someone changes a fire effect.

A Git diff might show that particle lifetime changed from 1.2 seconds to 0.8 seconds and the emission rate changed from 30 to 45.

You still need to preview the effect visually, but the diff gives you useful context.

That is much better than this:

fire_effect.asset changed

with no idea what happened inside it.

Keep Authoring and Runtime Separate

There is another useful pattern here.

Do not make your game load the entire editor project.

Instead, export a runtime bundle.

For example:

vfx-project/
  particle-data/
  source-assets/
  editor-settings/

game/
  public/
    vfx/
      manifest.json
      effects/
      textures/

The first directory exists for authoring.

The second exists for shipping.

This keeps unnecessary editor data out of the production build and gives you an explicit point where validation can happen.

Validation Belongs in the Build Pipeline

Visual tools often encourage a dangerous assumption:

"If it previews correctly, it must be valid."

That is not always true.

An effect might reference a missing texture.

A feature could work in one renderer but not another.

A malformed value might only fail on a specific device.

A command-line validation step catches some of these problems before the game starts.

This is where tools such as NixieFX fit naturally into a web development workflow. A browser-based editor is useful for visual iteration, while CLI-oriented validation and export make it easier to connect particle assets to the rest of your build process.

Conceptually, your package.json could include something like this:

{
  "scripts": {
    "vfx:validate": "your-vfx-tool validate",
    "vfx:export": "your-vfx-tool export",
    "build": "npm run vfx:validate && npm run vfx:export && vite build"
  }
}

Now broken effects can fail a build instead of becoming a runtime surprise.

Why This Helps Three.js Projects

Three.js is deliberately flexible.

That is one of its biggest strengths.

It also means a lot of systems are yours to build.

Scenes, loaders, UI architecture, asset pipelines, animation structure, game logic, and VFX can all be arranged differently depending on the project.

For particle effects, I prefer keeping the Three.js integration fairly thin.

Something like:

effects.play("laser-hit", {
  position: hitPoint
});

The actual particle configuration should live elsewhere.

This prevents effect tuning from spreading through gameplay classes.

The Same Applies to PixiJS

PixiJS games often have similar problems.

You might start with a few sprites:

const spark = new Sprite(texture);

Then add ten.

Then add pooling.

Then lifetime handling.

Then interpolation.

Then random velocity.

Then easing.

At some point, you have accidentally built a particle runtime.

There is nothing wrong with doing that if the game needs something custom.

But if particles are simply one part of the game's presentation, an external authoring format and reusable runtime can save a lot of maintenance.

Text Assets Also Work Better With Automation

Once effects are files, you can operate on them using scripts.

You can check:

Whether every effect has a unique ID
Whether referenced textures exist
Whether file names follow conventions
Whether an effect targets the correct renderer
Whether unused assets remain in the project

You can also generate reports or migrate old formats.

That becomes much harder when all the data is locked behind an editor-specific binary format.

Visual Tools and Developer Tools Do Not Have to Compete

There is sometimes an assumption that visual editing and developer-friendly workflows are opposites.

They are not.

The ideal setup looks something like this:

visual editor
     |
     v
readable source files
     |
     v
validation
     |
     v
export
     |
     v
game runtime

Artists get a visual interface.

Developers get text files and automation.

Git gets something it can understand.

Your game gets a clean runtime bundle.

For web development, that is a much better compromise than hiding the entire VFX pipeline inside application code.

Why Web Game VFX Should Live Outside Your Game Engine

Hiroshi TK — Mon, 24 Aug 2026 06:25:03 +0000

Particle effects tend to start simple.

You need a hit effect, so you write a small emitter. Then you need smoke. Then sparks. Then a level-up burst. Before long, the game has a folder full of particle code, textures, constants, random functions, timing hacks, and renderer-specific logic.

At that point, VFX has quietly become its own system.

For web games, treating it as one is usually the better approach.

Particle Code Is Not Really Gameplay Code
A particle effect has a lot of values:

Spawn rate
Lifetime
Velocity
Scale
Rotation
Color
Opacity
Gravity
Noise
Emission shape
Texture
Blending
Trails
Sub-emitters

You can define all of this in JavaScript or TypeScript.

That does not mean you should.

The problem is not whether code can represent an effect. Of course it can. The problem is iteration.

Imagine tuning an explosion like this:

const explosion = {
  spawnRate: 40,
  lifetime: 0.45,
  speed: 120,
  gravity: 30,
  startScale: 0.8,
  endScale: 0.1
};

Change a number. Reload. Check the effect. Change another number. Reload again.

It works, but it is a poor interface for visual work.

A visual editor gives you a much faster feedback loop while your game only needs to understand the resulting data.

Treat Effects as Assets

Textures are assets.

Audio files are assets.

Maps are assets.

Particle effects can be assets too.

A useful VFX workflow can look something like this:

particle-data/
  explosion.json
  smoke.json
  level-up.json
  coin-burst.json

The game loads an effect and tells the particle runtime when to play it.

vfx.play("coin-burst", {
  x: player.x,
  y: player.y
});

That creates a cleaner boundary.

Gameplay decides when something happens.

The VFX system decides what the visual response looks like.

JSON Has an Underrated Advantage

Text-based particle assets work particularly well in web projects.

They can be committed to Git, reviewed in pull requests, copied between projects, generated by tools, inspected by scripts, and changed without editing application code.

This is one reason tools such as NixieFX are interesting for web game development. The idea is to keep particle authoring separate from the game itself while still producing data that can be loaded by a runtime.

That separation is much closer to how I want VFX to behave in a web project.

Renderer Independence Matters

Web game stacks change surprisingly often.

One project might use PixiJS.

Another might use Three.js.

A third might start with a 2D interface and later add a 3D world.

If the effect itself is completely tied to renderer-specific code, moving it means rewriting it.

An asset-based system creates another option.

The effect description stays separate while a renderer integration figures out how to draw it.

Not every feature will translate perfectly between renderers, but separating the simulation and effect definition from gameplay code is already a large improvement.

It Also Improves Collaboration

Consider a team with one gameplay developer and one technical artist.

If effects live directly inside game classes, both people are editing the same application code.

If effects are separate assets, the workflow becomes simpler.

The developer exposes something like:

playEffect("enemy-death", position);

The person working on VFX can change the actual enemy death effect without touching combat logic.

Even on a solo project this matters.

You are separating your programmer work from your visual work, which reduces unnecessary context switching.

Exporting Is Better Than Loading Editor Data Directly

There is one additional boundary worth keeping.

Your editor project and your shipped game data do not have to be the same thing.

An authoring project may contain source textures, metadata, temporary files, editor settings, and effects that are still being tested.

The game only needs the final files required at runtime.

A good pipeline therefore looks like this:

authoring files
      |
      v
validation
      |
      v
export
      |
      v
runtime bundle

That is the same basic pattern used by larger game engines, but there is no reason web games cannot use it too.

The Main Benefit Is Boring, and That Is Good

Separating VFX from gameplay is not a revolutionary architecture.

It simply removes friction.

Your game code becomes easier to read.

Effects become easier to tune.

Assets become easier to version.

Renderer integrations become easier to replace.

Once your project contains more than a handful of particle effects, those small improvements start adding up.

Web games already have good tooling for code, assets, builds, and deployment.

VFX deserves the same treatment.

How we hand off AI coding tasks without sharing accounts

Hiroshi TK — Wed, 19 Aug 2026 05:42:37 +0000

AI coding agents are increasingly part of team workflows, but their work is often still coordinated through private chats and copied prompts.

We ran into a simple failure mode: one developer would prepare a detailed task, begin working with an agent, and then hit a subscription limit. Another teammate might have capacity, but transferring the work meant manually reconstructing the prompt, constraints, context, and expected result.

We built a Wagglet workflow around the task rather than the provider account.

The process is:

The developer asks Cursor to publish the exact prompt.
The Wagglet plugin creates a normal team draft.
The developer reviews and publishes it.
A coworker claims the task.
That coworker runs the prepared instructions in their own agent session.
The result is delivered through the original task.

No AI provider account, subscription, API key, or credential is shared. Each person continues using their own tools.

Under the hood, the Cursor plugin combines an MCP connection with a focused delegation skill. The task remains an ordinary Wagglet task, so it can use the same projects, permissions, discussion, and delivery process as other work.

This is still an evolving workflow, but it has made one distinction much clearer for us: teams should transfer work, not access.

Wagglet: https://wagglet.com/

Cursor plugin:
https://github.com/azakhary/wagglet-cursor-plugin

The invisible conversation: feedback, friction, and why players stay

Hiroshi TK — Thu, 25 Jun 2026 07:08:30 +0000

We argue endlessly about engines, ECS, shaders, netcode. But the thing players actually feel isn't your architecture. It's the loop.
You know it the instant it works. Doom Eternal never explains why combat feels good; your hands already know. Tetris needs no tutorial. And you know the inverse just as fast: you load in, try to move, something's off, and you close the game in ten minutes without being able to say why. A broken loop kills games faster than bad writing or bad art ever could, and players never report it as a broken loop. They just say "boring" or "clunky" and churn.
Here's how I think about it, with the implementation bits where they matter. Curious how you all handle this, because nobody seems to agree.
The loop is seven links

intent -> input -> interpretation -> outcome -> feedback -> perception -> prediction
   ^                                                                          |
   +--------------------------- next input <---------------------------------+

Seven links. The last feeds the next. Most teams obsess over two or three and ignore the rest, which is how you ship a game with gorgeous hit feedback and laggy input, or pin-sharp input feeding opaque outcomes. Every link has to carry its weight.

Feedback is communication, not juice

Feedback is any signal (visual, audio, haptic, systemic) that confirms an input and says what it did. Chris Crawford's old point still holds: this isn't decoration, it's communication. Juice is decorative; communication is functional.

Two things separate feedback that works from feedback that's just present:

Discernibility — can the player tell exactly what happened, not approximately? In a 6-enemy fight, which hit landed on which target, for how much, with what effect?
Integration — does the outcome change the rest of the game? A hit that deals damage but never staggers or interrupts feels weaker than one that visibly bends the fight.

Friction: the tax players pay to act

Some friction is the point: a hard boss, a weighty decision, a tense reload. That's where meaning lives. Dark Souls is brutal on purpose and every death teaches you something.

Avoidable friction is the tax players pay for nothing: the 3-press menu that should be 1, the inventory that buries the potion under 40 items, the 90-second unskippable cutscene before every boss retry.

The trap: intentional and avoidable friction look identical on paper. Both make the game "harder." The difference is whether the player gets mastery back or just annoyance. A Dark Souls with input delay has the same difficulty and is unplayable.

Four buckets of friction

Most frustration falls into one of four buckets. Name the bucket and you can usually name the fix:

Cognitive — "I don't know what to do." Too many choices (Hick's Law) or heavy state tracking. The silent killer in strategy games and RPGs: players drown in options and stop, not because the game is bad but because thinking became work.
Mechanical — "Controls feel sticky or slippery." Tiny hitboxes (Fitts's Law) or missing forgiveness windows. It's why some platformers feel like silk and others like wading through jello with identical-looking mechanics.
Social — "My team is falling apart." Poor signaling tools or misaligned incentives. It's why so many MOBA matches end in a rage-quit: not the gameplay, but no good way to agree on a plan.
Technical — "It's laggy and unresponsive." Latency, frame drops, or long loads.

Technical friction is the one teams fix last and should fix first. 100ms of input lag makes every other system feel worse, and no player will ever tell you that's the reason.

Playbook (with code)

Externalize state. Recognition over recall. Every cooldown, buff, and resource that lives in the UI is one less thing in the player's head. Into the Breach shows every enemy's next move and becomes pure tactics. Surfacing info doesn't break immersion; hiding it just makes players take notes.
Forgiveness windows. Celeste's coyote time lets you jump a few frames after leaving a ledge. Physically impossible, feels perfect. The correct pattern is a single per-frame update that combines coyote time (grace after leaving the ground) with an input buffer (grace for a jump pressed slightly before landing):

js
const COYOTE_FRAMES = 6;   // grace after walking off a ledge
const BUFFER_FRAMES = 6;   // grace for an early jump press

let coyote = 0;
let jumpBuffer = 0;

// call once per fixed update, before moving the player
function updateJump(grounded, jumpPressedThisFrame) {
  // refill coyote time while grounded, otherwise count it down
  coyote = grounded ? COYOTE_FRAMES : Math.max(0, coyote - 1);

  // remember a jump press for a few frames
  jumpBuffer = jumpPressedThisFrame ? BUFFER_FRAMES : Math.max(0, jumpBuffer - 1);

  // jump if we have a buffered press AND we're grounded or still within coyote time
  if (jumpBuffer > 0 && coyote > 0) {
    jump();
    jumpBuffer = 0;
    coyote = 0; // consume it so we can't double-jump off one window
  }
}

The point: widen the execution window (the how) so players spend attention on the decision (the why). Fighting games buffer inputs, shooters add bullet magnetism, rhythm games run timing windows wider than they admit. None of it is cheating.

Layer your feedback. No critical event should ride on one channel. Sound might be off, the player might be colorblind, they might be watching the minimap. Fire several at once (names here are placeholders for your own systems):

js
function onHit(target, dmg) {
  spawnHitSpark(target.position); // visual
  flinch(target);                 // visual / systemic
  playSfx('hit', { volume: scaleByDamage(dmg) }); // audio
  rumble({ strength: 0.6, ms: 80 });              // haptic
  popDamageNumber(target.position, dmg);          // systemic
}

If any two channels fail, the player should still get the message. Overwatch's kill confirmation does this; plenty of shooters ship hit feedback so subtle the weapon feels broken even when the numbers are right.
You can measure "feel"
Treat each design as a hypothesis. Track:

Time to first meaningful action— how long after load before the player does something?
Input-to-response latency— ms between press and on-screen response.
Error recovery time — after a misinput, how fast can they retry?

You don't need frame-perfect numbers on a single-player game, but you do need to catch when your "smooth" build is quietly running 120ms input-to-action. Players feel it; they just say it's "off."

So how do you tune yours?

What forgiveness windows do you ship, and do you tell players they exist?
How do you catch input latency before players do?
Any game you bounced off in 10 minutes and only later worked out why?

Drop it below.

I wrote the longer version with the full loop diagram and the feedback/friction breakdown on my blog: The invisible conversation: feedback, friction, and why players stay. More on game feel over there.

How to Build a Reward Economy for a Mobile Game

Hiroshi TK — Mon, 01 Jun 2026 09:34:45 +0000

Rewards are the language mobile games use to talk to players. Every coin drop, every chest, every daily login bonus is the game saying: "You did something. Here's what you get." Get that language right and players feel seen, motivated, and loyal. Get it wrong and rewards feel arbitrary, cheap, or manipulative — and players leave.

Building a reward economy for a mobile game means designing every reward type, what it gives, when it appears, and how it connects to the larger economy. This guide walks through the full reward stack: daily rewards, missions, battle pass rewards, level rewards, ad rewards, gacha, and event rewards — and how to build them into a coherent system.

Key Takeaways

A mobile reward economy is the complete system of reward types in a game — how they're structured, timed, and connected.
Each reward type serves a specific behavioral purpose: driving return visits, rewarding skill, monetizing attention, or sustaining long-term engagement.
Reward types need to be balanced against each other — stacking too many high-value rewards devalues all of them.
The reward schedule (when and how often players receive rewards) matters as much as the reward value.
Simulate your reward economy before shipping — reward cadence problems are invisible in static math.

What Is a Mobile Reward Economy?

A reward economy is the network of all reward systems in a game — the sources of positive feedback that players receive for taking actions. It includes everything from a coin drop at the end of a level to a monthly milestone reward to the item pulled from a gacha banner.

The reward economy is distinct from the currency economy, though they're closely linked. The currency economy is the system of what currencies exist and how they're balanced. The reward economy is the system of delivery — how players receive value, when, and in response to what behavior.

Designing the reward economy means answering: for every moment a player does something in your game, what do they get? And does what they get feel proportional, motivating, and consistent with the overall design intent?

The 7 Core Reward Types in Mobile Games

1. Daily Rewards (Login Rewards)

What they are: Resources given to players simply for opening the game each day. Usually on a rotating schedule — day 1 gives coins, day 3 gives a small gem amount, day 7 gives something more valuable.

What they're for: Driving daily return visits. The reward is the reason to open the game on days when the player wasn't otherwise planning to.

Design rules:

The day 7 (or end-of-cycle) reward should be meaningfully better than day 1. Players should feel the streak is worth maintaining.
Don't reset the streak to zero on a miss — forgiveness mechanics (skip one day and continue) dramatically improve the behavioral outcome.
The daily reward should not be so valuable that it substitutes for gameplay rewards. It's an invitation, not the main course.

2. Mission and Quest Rewards

What they are: Resources earned for completing specific tasks. Daily missions, weekly challenges, achievement systems.

What they're for: Directing player behavior. Missions are how you get players to try mechanics they might otherwise ignore, engage with content they'd skip, and come back for specific sessions.

Design rules:

Missions should feel achievable in a single session for daily tasks, and in 2–3 sessions for weekly tasks.
Mission rewards should be meaningfully higher than passive earn rates — if completing a mission gives the same as just playing normally, there's no incentive to follow the mission.
Variety matters. Missions that always point at the same activity become invisible.

3. Battle Pass Rewards

What they are: Tiered rewards unlocked by earning XP through gameplay over a season. Usually split into a free track (available to all players) and a premium track (unlocked by purchase).

What they're for: Long-term engagement anchor. The battle pass is the reason a player comes back every day for six weeks. It's the highest-leverage retention mechanic in modern mobile game design.

Design rules:

The free track should feel genuinely rewarding — not a demo. Players who don't pay should still want to complete it.
Premium track rewards should feel clearly better than free track, but the free track shouldn't feel like punishment for not paying.
Reward pacing matters enormously. Big rewards clustered only at the end create the wrong motivation shape — spread high-value rewards throughout the track.
Simulate your XP pacing across casual, mid-core, and power player profiles. A battle pass that only completable for players who play 90+ minutes daily is a design problem.

4. Level Rewards

What they are: One-time rewards for reaching a specific player level or account milestone.

What they're for: Celebrating progress. Level rewards punctuate the progression curve — they're the exclamation marks that make leveling feel significant.

Design rules:

Level rewards at early levels should be frequent and exciting — the early game should feel like constant reward.
Major level thresholds (level 10, 25, 50) should have noticeably better rewards that feel like they mark a genuine milestone.
Don't let level rewards become entirely predictable. A surprise high-value reward at a non-obvious level (level 23, not 25) creates delight.

5. Ad Rewards (Rewarded Video)

What they are: Optional rewards — usually a currency bonus, extra life, or speed boost — given in exchange for watching a short advertisement.

What they're for: Soft monetization and session extension. Rewarded ads let non-paying players access small amounts of value in exchange for attention, while generating ad revenue.

Design rules:

Ad rewards should feel optional, not mandatory. If the game requires watching ads to stay competitive, it's coercive — which damages long-term trust.
The ad reward value should be lower than an equivalent IAP value. Players who pay should feel their money was worth more than watching videos.
Offer limits (e.g., 5 rewarded ads per day) prevent ad rewards from substituting for premium currency in ways that undermine monetization.

6. Gacha Rewards

What they are: Randomized rewards from a pull mechanic — spending currency (keys, crystals, gems) to receive a random item from a pool.

What they're for: High-engagement acquisition of rare items. Gacha systems are the primary source of rare or powerful items in many F2P games, and a significant monetization driver.

Design rules:

Publish drop rates. This is both ethically correct and increasingly required by platform policies in many markets.
Implement a pity system. After a defined number of pulls without a rare drop, guarantee one. This protects players from extreme bad luck and makes the expected value feel trustworthy.
The currency cost of pulls should feel within reach for free players — occasionally. If free players can never meaningfully engage with the gacha, it becomes purely a whale feature and loses the aspirational pull for the broader player base.
Avoid duplicate traps without a conversion system. Getting the same rare item 5 times with no way to convert duplicates is a trust-destroying experience.

7. Event Rewards

What they are: Rewards earned during limited-time events — seasonal content, tournaments, special missions.

What they're for: Re-engaging lapsed players, driving high-activity windows, and creating the sense that the game is alive and changing.

Design rules:

Event rewards should include at least one item or currency type that's exclusive to the event — this is what creates FOMO-driven return.
Event reward volume needs to be scoped carefully. Events that inject large amounts of currency without commensurate sinks cause post-event inflation.
Event reward pacing should account for varying player availability. A player who can only play on weekends should still be able to earn meaningful event rewards.

Building a Coherent Reward Stack

The individual reward types above need to work together as a system. Here's what a coherent stack looks like in practice:

Daily rewards bring players into the session.

Mission rewards direct what they do in the session.

Session rewards (level rewards, gameplay drops) make the session feel productive.

Battle pass gives them a long-term goal that spans the season.

Gacha gives them something to aspire to and occasionally spend on.

Events give them a reason to come back during otherwise quiet periods.

The failure mode is reward cannibalization — when too many reward systems fire at once, the value of each individual reward drops. If players are getting coins from daily login, missions, level completion, a pop-up ad offer, and a bonus event simultaneously, the coins feel like background noise rather than meaningful reward.

The fix: think about the reward schedule as a whole. What rewards appear in what sessions? What's the total reward value per session? Is there enough variation — and enough silence — between reward peaks for the peaks to feel meaningful?

Reward Economy and Monetization

Every reward type has a relationship with monetization:

Reward type	Monetization relationship
Daily reward	Minimal — supports retention, not direct spend
Mission reward	Indirect — drives engagement that leads to spend
Battle pass	Direct — premium track is a purchase
Level reward	Minimal — supports retention
Ad reward	Revenue from ad impressions; reduces premium spend pressure
Gacha	Direct — premium currency spend driver
Event reward	Mixed — exclusive rewards drive FOMO-based purchases

Balancing the reward economy with monetization means making sure rewards feel generous enough to build trust without being so generous that they remove purchase motivation.

Simulate Your Reward Economy

Reward economies are hard to balance in static math because the feel of a reward is contextual — it depends on when it appears, how often, and what the player expects. A 100-coin reward feels great on day 1 and meaningless by day 30 when players have 50,000 coins in reserve.

itembase lets you model your full reward economy and simulate how it feels across the player lifecycle — identifying where reward cadence goes thin, where currency accumulates beyond useful levels, and where the battle pass XP pacing goes wrong for different player profiles.

Try itembase → itembase.dev

Frequently Asked Questions

What is a mobile game reward economy?

A mobile game reward economy is the complete system of reward types — daily logins, missions, battle pass tiers, level rewards, ad rewards, gacha pulls, and event rewards — that defines how players receive value from the game. It encompasses what rewards exist, what they give, when they appear, and how they work together as a retention and monetization system.

How do you design a daily reward system for a mobile game?

Daily reward systems should offer escalating value across the reward cycle (day 7 meaningfully better than day 1), include streak forgiveness to prevent single misses from resetting progress, and be valuable enough to motivate a return visit without replacing gameplay-earned rewards.

What is a gacha pity system?

A pity system guarantees a rare reward after a set number of pulls without receiving one. For example, if a player makes 90 pulls without a 5-star item, the 90th pull guarantees a 5-star. Pity systems protect players from extreme bad luck, make the economics of gacha feel trustworthy, and are increasingly standard practice in ethical F2P design.

How do battle pass rewards work?

Battle pass rewards are unlocked by earning XP through gameplay over a season. A free track is available to all players; a premium track requires purchase. Reward pacing — how quickly players earn XP and how rewards are distributed across tiers — is critical to the retention value of a battle pass.

How do event rewards affect a game economy?

Event rewards inject currency and items at a higher-than-baseline rate during a limited time window. Without adequate sinks, this causes post-event inflation — players have more currency than they can spend, and the value of that currency drops. Event reward design needs to include event-specific sinks (exclusive items, limited exchanges) to contain the economic impact.

Build a Reward Economy That Keeps Players Coming Back

Model and simulate your mobile game reward economy in itembase → itembase.dev

Game Economy Simulator: Why You Should Simulate Before You Ship

Hiroshi TK — Fri, 29 May 2026 07:03:04 +0000

Every game designer has shipped something that looked balanced on paper and broke in production. The math checked out. The spreadsheet said players would earn roughly what they spent. Then real players got into the game and the economy fell apart in a way nobody anticipated.

This isn't a design failure. It's a tooling failure. The spreadsheet was never capable of catching what went wrong — because what went wrong wasn't a math error. It was a behavioral dynamic that only shows up when you model players moving through the economy over time.

That's what a game economy simulator does. This article explains what economy simulation is, what it catches, and why it should be a standard step in your design process — not an afterthought.

Key Takeaways

A game economy simulator models how player behavior interacts with your economy over time — not just what the numbers say in theory.
Simulation catches four major problem classes: broken progression, inflation, reward imbalance, and content exhaustion.
These problems are expensive to fix after launch and cheap to fix in design.
Spreadsheets calculate. Simulators simulate. Both are useful; only one validates behavioral dynamics.
itembase is a game economy simulator built for F2P, mobile, and live service game designers.

What Is a Game Economy Simulator?

A game economy simulator is a tool that models how a game's economy behaves when players move through it — not just how it's structured on paper.

The difference from a spreadsheet: a spreadsheet gives you static values. It tells you the expected value of a chest, the cost of an upgrade, the daily earn rate assuming one session. It doesn't model variance. It doesn't account for players who play more or less than average. It doesn't show you what happens to currency supply after 10,000 players complete week 3 of your battle pass.

A simulator takes your economy design — currencies, earn rates, costs, drop probabilities, progression gates — and runs it forward through time with modeled player behavior. The output isn't a single number. It's a picture of how the economy evolves: where currency accumulates, where players get stuck, where rewards feel too thin, where progression deserts form.

What Simulation Catches That Math Misses

Broken Progression

The most common economy failure. A point in the game where upgrade costs escalate faster than earn rates, and players hit a wall.

On paper, it's invisible. Your spreadsheet shows the upgrade costs and the earn rates in separate columns, and both look reasonable in isolation. What the spreadsheet doesn't show: that a player earning at the mid-game rate would need to play for 12 days straight to afford the next upgrade — and that by day 4, they've already churned.

A simulator shows you this. Run a 30-day player simulation at your target session frequency and you'll see exactly where the earn curve and cost curve diverge. That's the cliff. Fix it before it ships.

Inflation

Inflation happens when sources produce more currency than sinks consume. Players accumulate, prices feel meaningless, monetization collapses because there's nothing left that feels worth paying for.

The tricky part about inflation: it's time-dependent. Your economy might be perfectly balanced for the first two weeks and inflate badly in week 4, once high-engagement players have completed all the primary sinks and are still earning passively. A spreadsheet with static assumptions won't catch this. A simulation that runs player behavior for 60+ days will.

Reward Imbalance

Your session rewards feel thin. Or your gacha feels terrible. Or your battle pass feels padded. These are perceptual problems — they're not about whether the numbers add up, they're about whether the rewards feel right relative to player effort.

Simulation surfaces reward imbalance by modeling the reward history of a player over time. If a player completes 50 sessions and the distribution of meaningful rewards is clustered in the first 10 and nearly absent in sessions 20–50, the reward cadence is broken even if the total value is technically correct.

Content Exhaustion

You designed your battle pass to last 6 weeks. Your simulator tells you that a player who plays 45 minutes per day completes it in 3 weeks. You have a content exhaustion problem — and it would have shown up in your live game as a spike in churn around week 3 followed by a sharp drop in battle pass conversion for the next season.

Content exhaustion is particularly dangerous in live games because it compounds: once players learn they can exhaust your season content quickly, they start timing their engagement to avoid the dead period, which shows up as activity spikes at launch and steep drop-offs after.

Why Post-Launch Analytics Isn't the Answer

The obvious question: why simulate before launch when you can just look at analytics after?

Two reasons.

Cost. Fixing an economy problem in design takes hours. Fixing it in a live game takes an update cycle, player communication, potential rollback, and damage control for the players who already experienced the broken version. The later you find the problem, the more expensive it is.

Trust. Economy problems erode player trust in ways that are hard to reverse. Inflation that made your premium currency feel worthless. A broken gacha run that felt exploitative. A battle pass that turned out to take twice as long to complete as advertised. Players who experience these don't just churn — they leave reviews, post in communities, and poison organic acquisition.

Analytics is essential for post-launch tuning. It is not a substitute for pre-launch validation. You want both.

What a Game Economy Simulation Looks Like in Practice

Here's a simplified example. You're designing the first season of a battle pass for a mobile RPG.

Your design specs:

50 tiers
Players earn XP from daily quests (200 XP/day) and matches (50 XP per match, ~5 matches/day)
Total daily XP for average player: ~450
XP per tier: 1,000
Season length: 6 weeks (42 days)
At average earn rate: 42 days × 450 XP = 18,900 XP = 18.9 tiers completed

Wait — players only complete 18 out of 50 tiers on your "average" earn rate? That's a problem. Tier 50 is supposed to feel achievable for engaged players, not just whales.

You run a simulation with three player profiles:

Casual: 1 session/day, 3 matches → 350 XP/day → 14 tiers in 6 weeks
Mid-core: 2 sessions/day, 6 matches → 650 XP/day → 27 tiers in 6 weeks
Power: 4 sessions/day, 12 matches → 1,100 XP/day → 46 tiers in 6 weeks

Now you can see the full picture. The power player nearly completes the pass. The mid-core player doesn't get halfway. The casual player gets less than a third. Is that what you intended? Probably not — you need to either reduce the total tier count, increase the XP earn rate, add bonus XP sources, or accept that the full pass is designed for power players only and price the premium track accordingly.

That's simulation in practice. You found the problem in the design phase, not in the post-launch analytics dashboard.

Who Should Use a Game Economy Simulator

F2P mobile game designers. This is the primary use case. Any game with soft currency, hard currency, energy, progression gates, or monetization mechanics benefits from simulation before launch.

Idle and clicker game designers. Idle economies grow exponentially and break in ways that are nearly impossible to predict without simulation. Prestige loops, inflation, bottlenecks — simulation is close to mandatory here.

Battle pass designers. Season length, XP pacing, reward density — all of these need to be validated against realistic player behavior before the season launches.

Gacha designers. Pull rate probabilities, pity system behavior, currency earn rate vs pull rate ratio — the math of gacha is deceptive. Simulation at percentile extremes (the unlucky 10% of players) often reveals problems the expected value calculation hides.

LiveOps designers. Before any significant event, balance change, or bundle launch — simulating the economy impact prevents the surprises that show up in next week's dashboard.

itembase: A Game Economy Simulator for Designers

itembase is a game economy design and simulation platform built specifically for game designers — not data scientists or engineers.

It's designed around the way game economies actually work: items, currencies, progression systems, events, player behavior profiles. You model your economy in the tool the same way you'd describe it to a developer, and then simulate how it behaves over time.

What you can do in itembase:

Build a visual model of your economy (items, currencies, sources, sinks)
Define player behavior profiles (casual, mid-core, power)
Simulate economy behavior over days, weeks, and seasons
Identify progression cliffs, inflation risks, and reward gaps
Test LiveOps changes before they go live

It's the tool that sits between your spreadsheet and your launch — the validation step that catches what static math misses.

Try itembase → itembase.dev

Frequently Asked Questions

What is a game economy simulator?

A game economy simulator is a tool that models how a game's economy behaves when players move through it over time. Unlike spreadsheets, which calculate static expected values, a simulator runs player behavior against the economy design and shows how currencies accumulate, where progression stalls, and how different player types experience the economy differently.

Why should you simulate a game economy before launch?

Simulation catches economy problems — broken progression, inflation, reward imbalance, content exhaustion — at the design stage, when they're cheap to fix. Post-launch economy problems are expensive to fix, erode player trust, and show up in churn data and reviews. Simulating before launch prevents problems that analytics can only diagnose after they've already hurt your game.

What does a game economy simulator catch that spreadsheets miss?

Spreadsheets calculate theoretical values for individual transactions. Simulators model behavioral dynamics over time: where currency accumulates beyond what players can spend (inflation), where upgrade costs outpace session earn rates (progression cliffs), where reward cadence becomes too thin (reward imbalance), and where players complete all content too quickly (content exhaustion).

What is the best game economy simulator?

itembase is a purpose-built game economy design and simulation platform for F2P, mobile, and live service game designers. It models real game items and currencies, supports multiple player behavior profiles, and simulates economy behavior over extended time periods.

When should you simulate your game economy?

Ideally, at two points: during design (to validate the economy structure before implementation) and before major LiveOps updates (to test the impact of events, balance changes, or new content before they go live). Post-launch analytics complements simulation but doesn't replace it.

Simulate First. Ship Confident.

The gap between "the math looks right" and "the economy works" is where most economy mistakes live. Simulation is how you close that gap.

Simulate your game economy in itembase → itembase.dev

Game Economy Balancing: How to Tune Rewards, Costs, and Progression

Hiroshi TK — Mon, 18 May 2026 11:43:07 +0000

An economy can be well-designed and still badly balanced. The design tells you what the currencies are, what the loops are, how players earn and spend. Balance determines whether any of that feels right in practice.

Game economy balancing is the process of tuning earn rates, upgrade costs, session rewards, and progression curves until the game hits the target pace. Too fast and nothing feels earned. Too slow and the game feels like a chore. The sweet spot is a moving target — different for different player segments, different at different stages of the game, different before and after a live update.

This guide gives you a practical framework for approaching balance, the key variables you need to control, and the mistakes that make balance work collapse.

Key Takeaways

Balancing is tuning, not designing — it happens after the economy structure is in place.
The two core ratios to maintain: earn rate vs upgrade cost, and session reward vs session goal.
Progression curves define how quickly players feel powerful — linear, exponential, and milestone-based curves all produce different player experiences.
Balance for multiple player segments: casual, mid-core, and power players experience the same numbers very differently.
Simulation is the only way to validate balance across time and player types — math alone isn't enough.

What Is Game Economy Balancing?

Game economy balancing is the process of adjusting the numerical values in a game economy — earn rates, costs, drop probabilities, progression multipliers — until the player experience matches the design intent.

Balancing happens at two levels:

Micro-balance: Individual values. How many coins does this quest give? How much does this upgrade cost? What's the drop probability on this chest? These are the granular numbers that make up the economy.

Macro-balance: The overall feel. Does progression move at the right pace? Do players feel rewarded? Are there points where the game feels too easy, too hard, or too grindy? Macro-balance is the emergent result of all the micro-balance decisions combined.

Getting micro-balance right doesn't guarantee macro-balance is right. You can have perfectly calibrated individual numbers that produce a broken overall experience — usually because you didn't account for how the numbers compound over time.

The Key Variables in Economy Balancing

Earn Rate

What it is: How much currency (soft, hard, event tokens, materials) a player earns per session, per day, per week.

How to set it: Start from the player goal, not the other way around. If you want players to be able to upgrade their main item every 2 sessions, work backward from the upgrade cost to determine the required earn rate.

Segment it. A player who plays 3 sessions a day earns 3x what a player who plays 1 session does. Your earn rate should make sense for both. Design your base earn rate around the casual player — the one who plays once a day for 20 minutes — then make sure the economy doesn't break for power players who play much more.

Upgrade Cost

What it is: How much currency a player spends to advance — to level up a unit, unlock a building, progress through a tier.

The basic rule: Upgrade cost should feel proportional to the upgrade's impact. Small quality-of-life upgrades cost small amounts. Transformative upgrades cost significantly more. If costs feel arbitrary, players stop caring about the economy.

The escalation question: Should costs go up as players advance? Almost always yes — but the question is at what rate.

Session Reward

What it is: The currency or items a player earns in a single play session.

The target feeling: Players should end each session feeling like they made progress. The session reward doesn't need to complete an upgrade — but it should visibly advance toward one. If players play for 15 minutes and can't see any change in their resource total, the session reward is too low.

The cap question: Session rewards that scale infinitely with time-in-session create problems (power players hoard). Session rewards that don't scale at all create a different problem (players feel capped). Most games use a soft cap: good rewards for the first 20–30 minutes, diminishing returns after that.

Progression Curves

A progression curve defines how the relationship between player effort and player advancement changes over time. There are three main types:

Linear curve: Each upgrade costs the same amount. Level 1→2 costs 100 coins; level 19→20 costs 100 coins. Simple, transparent, but provides no sense of escalating challenge or achievement.

Exponential curve: Each upgrade costs significantly more than the last. Level 1→2 costs 100 coins; level 19→20 costs 100,000 coins. Creates a sense of meaningful progress but can produce brutal late-game walls if the earn rate doesn't scale proportionally.

Milestone-based curve: Costs escalate in tiers, not continuously. Levels 1–5 cost roughly the same; levels 6–10 are more expensive; levels 11–15 jump again. Easier to balance than pure exponential, and creates natural breakpoints that feel like progression milestones.

Most F2P games use a hybrid: mild exponential with milestone jumps at key progression points (equipment tier changes, content unlocks, power thresholds).

Balancing for Player Segments

The biggest mistake in economy balancing is balancing for a single player type. Your economy is played by at least three meaningfully different player segments:

Casual players: Play once a day, 15–20 minutes per session. Low total earn rate. Need to feel the economy working for them even with limited play time. If your economy only makes sense for players who play an hour a day, casual players will churn.

Mid-core players: Play 2–4 sessions a day, 30–45 minutes each. Your median engaged user. The economy should feel most natural to this segment — this is who you're primarily designing for.

Power/whale players: Play many sessions a day, long sessions. High earn rates. The risk here is that your economy breaks for them — they accumulate too fast, exhaust your progression content, and lose motivation.

To balance across segments, calculate the daily earn rate for each segment type and check:

Does the casual player feel meaningful progression? (Goal: yes)
Does the power player exhaust the economy? (Goal: no — there should always be a valuable goal out of reach)
Does the mid-core player feel the economy is well-paced? (Goal: yes — this is your primary signal)

Common Balance Mistakes

The level 15 cliff. A sudden jump in upgrade cost that isn't matched by a jump in earn rate. Players hit the wall, session rewards feel meaningless, and churn spikes. This shows up in analytics as a sharp retention drop at a specific progression point.

Front-loaded generosity. Giving new players too much, too fast. The first few levels feel amazing; then the earn rate normalizes and the game feels like it got harder. Players experience this as "bait and switch" even if it's not intentional.

Back-loaded stinginess. Mid-game earn rates that don't keep up with upgrade cost escalation. Players who've been engaged for weeks suddenly feel stuck. This is the most common cause of mid-game churn in F2P games.

Power player exhaustion. No meaningful content for the top 5% of players. They've completed everything, they have max resources, there's nothing left to do. These players leave and sometimes never come back — even when new content launches.

Ignoring material sinks. Adding upgrade materials as a mechanic but not enough sinks for them. Players accumulate materials they can't use, the inventory fills up, and the materials become meaningless noise.

How to Actually Tune the Numbers

Balancing is iterative. There's no formula that produces a balanced economy on the first pass. Here's a practical process:

Step 1: Define target pacing. What should the average player experience at day 1, day 7, day 30? Write this out explicitly. "By day 7, a player who plays once daily should be able to upgrade their main item to tier 3." That's a spec, not just a vibe.

Step 2: Work backward from goals. If day-7 tier 3 is the target, how much does tier 3 cost? How much should a player earn per day? Set the earn rate from there.

Step 3: Check the curve. Plot upgrade costs and daily earn rates on the same chart. Do they move together? Is there a point where costs spike above earn rate? That's a cliff — adjust it.

Step 4: Simulate, don't just calculate. Run a simulation of player behavior over 30 days for casual, mid-core, and power player profiles. Does each segment experience the economy the way you intended? Where do they diverge from your targets?

Step 5: Iterate on bottlenecks. Identify the points where progression stalls and whether those stalls are intentional (designed friction) or accidental (balance errors). Adjust costs or earn rates at those specific points.

Step 6: Test with real players. Playtest data will always surface things simulation doesn't catch — feel, perception of fairness, emotional response to randomness. Use both.

Where itembase Fits in Balancing

Steps 4 and 5 — simulation and bottleneck identification — are where spreadsheets fail and a proper tool becomes essential. itembase lets you model your earn rates, upgrade costs, and progression curves, define player behavior profiles, and simulate the economy over days and weeks of play.

Instead of guessing where the level 15 cliff is, you see it in the simulation. Instead of calculating whether your casual player can upgrade by day 7, you run it and see exactly what they have at the end of day 7 with 1 session per day.

That's the difference between balancing on paper and balancing with confidence.

Try itembase → itembase.dev

Frequently Asked Questions

What is game economy balancing?

Game economy balancing is the process of tuning numerical values — earn rates, upgrade costs, drop rates, progression multipliers — to produce a player experience that matches design intent. A balanced economy feels rewarding, progresses at the right pace, and works well across different player types (casual, mid-core, power players).

What is a progression curve in games?

A progression curve defines how the cost of advancement changes as players go deeper into a game. Linear curves keep costs constant; exponential curves escalate costs rapidly; milestone-based curves escalate in tiers. Most F2P games use a hybrid of exponential and milestone-based curves to create a sense of meaningful progression without producing unmanageable late-game walls.

How do you balance earn rates and upgrade costs?

Start from your target pacing — how quickly you want players to progress — and work backward. If players should upgrade every two days, and they earn 200 coins per day, the upgrade should cost around 400 coins. Then check that the ratio holds as costs escalate: the earn rate should scale roughly in parallel with upgrade costs to avoid mid-game cliffs.

Why do games feel grindy?

Games feel grindy when upgrade costs escalate faster than earn rates — players spend more time working toward the same upgrade than they did earlier in the game, but the reward feels proportionally smaller. Grind is usually a symptom of unbalanced earn/cost ratios at specific progression points, often in the mid-game.

How do you balance an economy for multiple player types?

Calculate daily earn rates for casual (1 session/day), mid-core (3–4 sessions/day), and power players (many sessions/day). Check that the economy feels meaningful for the casual player, is primary-tuned for the mid-core player, and doesn't allow power players to exhaust all content. Adjust earn rate caps, session reward decay, and high-end progression goals accordingly.

Balance It Before You Ship It

The best time to find a balance problem is in simulation, not in your live player data.

Balance and simulate your game economy in itembase → itembase.dev

Game Economy Design for Free-to-Play Games: A Beginner’s Guide

Hiroshi TK — Mon, 18 May 2026 09:18:14 +0000

Free-to-play is the dominant business model in mobile games, and it lives or dies on its economy. The game is free to download. Revenue comes from players choosing to spend inside it. That choice — whether a player spends, how much, and how often — is almost entirely determined by how the economy is designed.

This guide is for designers who are new to F2P economy design. No jargon assumed. By the end, you'll understand the building blocks: currencies, monetization pressure, progression pacing, reward loops, and why getting the economy wrong is one of the fastest ways to kill retention.

Key Takeaways

F2P economies are designed to generate revenue from voluntary in-game spending — but only work if the game is worth playing for free.
Soft currency and hard currency serve different roles and need separate balance logic.
Monetization pressure should be felt as motivation, not frustration — the line between them is pacing.
Reward loops are the engine that keeps players coming back. Break the loop and you lose the player.
Economy design directly affects retention — not just revenue.

What Makes F2P Economy Design Different

In a paid game, the economy exists to serve the player's enjoyment. In a free-to-play game, the economy has to do two things at once: create a great experience for players who never spend a cent, while also creating meaningful reasons for players who want to spend to do so.

That's a harder design problem than it sounds. Too generous with free rewards and nobody has a reason to pay. Too aggressive with monetization pressure and players feel exploited — and leave.

The best F2P economies feel fair. Players who don't pay still progress, still have fun, still feel rewarded. Players who pay feel like they're getting something genuinely valuable — time, cosmetics, or power — without making the game feel broken for those who don't.

The Two Core Currencies

Almost every F2P game runs on a two-currency system. Understanding these two currencies — what they're for and how they interact — is the foundation of F2P economy design.

Soft Currency

What it is: The primary earned currency. Coins, gold, credits, stars — whatever your game calls it. Players earn it through gameplay: completing levels, winning matches, finishing quests, watching ads.

What it does: Covers frequent, low-stakes purchases. Upgrading common items, buying consumables, accessing standard content. The soft currency transaction should feel like a routine decision, not a weighty one.

How to balance it: Players should always have enough to make regular purchases but never so much that upgrades feel trivially cheap. The goal is motivated abundance — enough to keep progressing, not enough to buy everything at once.

Common mistake: Over-rewarding soft currency early, then under-rewarding it mid-game. Players feel rich at the start, hit an upgrade cliff mid-game, and churn.

Hard Currency

What it is: The premium currency. Gems, diamonds, crystals, rubies. Earned very slowly through gameplay — or purchased with real money.

What it does: Covers high-value decisions: rare item pulls, time skips, premium content access, exclusive bundles. The hard currency transaction should feel meaningful. If hard currency is too abundant, it loses its premium feel. If it's too scarce for free players, it feels extractive.

How to balance it: Free players should earn enough hard currency to make occasional premium purchases — just enough to feel included, not enough to eliminate purchase motivation. The rate for free players is typically 10–20% of what a modest spender would access.

Common mistake: Making hard currency feel mandatory for basic progression. The moment a player feels they have to pay to continue, the game's reputation tanks and organic acquisition dries up.

Monetization Pressure: The Line Between Motivation and Frustration

Monetization pressure is the design tension that makes a player consider spending. Done right, it feels like an opportunity. Done wrong, it feels like a wall.

The factors that determine which side of the line you're on:

Pacing. If players encounter a hard paywall 10 minutes into the game, they feel trapped. If they encounter it after 10 hours of free progression, they've already invested — and the spend feels like a natural continuation.

Optionality. Cosmetic purchases create zero pressure — players choose to spend, not because they need to. Power purchases (pay to progress faster or be stronger) create more pressure, and the ethics depend heavily on whether the game is competitive.

Transparency. Players tolerate monetization they understand. Hidden conversion rates, obscured odds, and confusing currency layers feel manipulative.

Fairness. Players who don't pay should still feel like they're playing the real game. If the free version is a demo and the full experience is paywalled, the economy is designed for extraction, not retention.

Progression Pacing: The Engine of Retention

In F2P games, progression is the primary reason players return. The feeling of getting stronger, unlocking new content, reaching the next milestone — that's the loop that drives daily retention.

Pacing that progression well is one of the hardest things in F2P economy design.

The early game

Progress should feel fast. Players should reach meaningful milestones in their first session and their first week. The economy should be generous early — this is where players decide whether the game is worth continuing.

Early-game economy: high earn rates, low upgrade costs, fast unlock cadence.

The mid game

Progress should slow — but not stop. This is where the economy starts mattering. Upgrades take longer. Resources take more sessions to accumulate. Players start making meaningful decisions about what to upgrade and what to save for.

This is also where monetization starts appearing in earnest. Time-skip offers, resource bundles, battle pass introductions. The pacing here should feel like a natural deepening, not a sudden wall.

Mid-game economy: moderate earn rates, escalating upgrade costs, first meaningful soft currency decisions.

The late game

Progress is slow by design. The late game is for highly engaged players — the ones who've been playing for weeks or months. Upgrade costs are high, resources take dedicated effort to accumulate, and LiveOps content (events, seasonal updates) carries the retention load.

This is where whale monetization happens. Big bundles, exclusive content, significant time saves. The late-game economy doesn't need to be generous — but it needs to feel worth the investment for players who've already chosen to commit.

Late-game economy: low earn rates relative to costs, high-stakes decisions, LiveOps content as primary engagement driver.

Reward Loops: Why Players Come Back

A reward loop is the cycle of action, reward, and motivation that keeps a player engaged. In F2P games, reward loops are the economy's delivery mechanism — they're how players feel the economy rather than just seeing it in numbers.

The session loop (minutes)

Short cycle. Do something → get rewarded → feel good about doing more. Completing a level, earning coins, getting a drop. The session loop keeps players engaged within a play session.

Design goal: The session should end with the player feeling like they made progress. They spent resources on an upgrade, they earned resources from a quest, they got a drop worth keeping.

The daily loop (hours/days)

Medium cycle. Log in → complete daily content → accumulate toward a goal → return tomorrow. Daily missions, login rewards, energy replenishment, daily shop rotation. The daily loop is what makes a game part of a player's routine.

Design goal: Coming back tomorrow should feel rewarding from the moment the player opens the game.

The progression loop (weeks)

Long cycle. Level up, unlock new content, complete a battle pass tier, build toward a major upgrade. This is the backbone of long-term retention.

Design goal: Players should always have a goal that's 1–2 weeks away. Close enough to feel achievable, far enough to keep them coming back.

Why Economy Design Affects Retention

Here's the connection that most beginners miss: economy design and retention are not separate concerns.

Every churn event is an economy event. Players who churn at the upgrade cliff churn because the economy made them feel stuck. Players who churn after maxing out soft currency churn because the economy gave them nothing to spend on. Players who churn after a "bad" gacha run churn because the economy felt unfair.

Good economy design creates a game that feels worth playing every day, worth spending on occasionally, and worth recommending. That's not a monetization optimization — that's a retention architecture. And it's set at the design stage, before the first line of code.

Getting It Right: Simulate Before You Ship

F2P economy design is genuinely hard to get right on paper. The math can look balanced and still produce a broken player experience. The reason: player behavior doesn't follow expected values. Different players spend at different frequencies, have different risk tolerances for gacha, and progress at wildly different paces.

Simulation — running player behavior models against your economy before launch — is how F2P designers validate their work. It catches the soft currency cliff at level 15 that your spreadsheet missed. It shows you that your battle pass is only completable for players who play 90 minutes a day, not 30.

itembase is built for this. It's a game economy design and simulation platform designed specifically for F2P and live service games — model your currencies, reward loops, and progression systems, then simulate how different player types move through them.

Try itembase → itembase.dev

Frequently Asked Questions

What is F2P game economy design?

Free-to-play game economy design is the practice of designing a virtual economy that generates revenue through voluntary in-game purchases while keeping the game accessible and enjoyable for non-paying players. It involves designing currencies, reward structures, progression pacing, and monetization mechanics that balance player experience with business sustainability.

What is the difference between soft currency and hard currency in F2P games?

Soft currency is the primary gameplay-earned currency — used for frequent, low-stakes purchases like upgrades and consumables. Hard currency is the premium currency earned slowly or purchased with real money — used for high-value purchases like rare items, time skips, and premium content. The two-currency system allows F2P games to serve both paying and non-paying players simultaneously.

How does economy design affect game retention?

Economy design directly drives retention because it controls the pacing and feeling of progression. Economies that progress players too slowly create frustration and churn. Economies that progress players too quickly create nothing to work toward. Well-paced economies keep players in a state of motivated scarcity — always progressing, always with a goal in sight, always with a reason to return.

What is monetization pressure in F2P games?

Monetization pressure is the design tension that makes a player consider spending real money. Healthy monetization pressure feels like an opportunity — spending would be nice, but not spending is still a good experience. Unhealthy monetization pressure feels like a wall — not spending means significant friction or blocked progression. The line between them is mostly a function of pacing and optionality.

How do you design progression pacing in a F2P game?

F2P progression pacing should be fast in the early game (frequent milestones, generous rewards), moderate in the mid-game (escalating costs, meaningful decisions), and slow in the late game (high-effort goals, LiveOps-driven engagement). The key is that progress should always feel possible — even if it's slow — so players stay motivated rather than hitting walls that cause churn.

Start Designing Your F2P Economy

Understanding the principles is step one. Testing them against real simulated player behavior is step two.

Design and simulate your F2P game economy in itembase → itembase.dev