DEV Community

Cover image for What AI-Friendly VFX Tooling Actually Looks Like
Hiroshi TK
Hiroshi TK

Posted on

What AI-Friendly VFX Tooling Actually Looks Like

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
Enter fullscreen mode Exit fullscreen mode

Workflow B:

effects/
  fire.json
  explosion.json
  heal.json
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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 .
Enter fullscreen mode Exit fullscreen mode

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

This creates a closed loop:

inspect
change
validate
fix
export
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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/
Enter fullscreen mode Exit fullscreen mode

and:

out/vfx/
Enter fullscreen mode Exit fullscreen mode

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/
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)