What happened
In a post dated October 28, 2026, Hugo Duprez describes making pixel-art visual effects for his game and effects library. He argues that code is a flexible medium for this work: image sprites felt too rigid and limiting for the variations he wanted. His approach uses a frontier coding agent such as Claude Code or Codex, but he says the work does not require extra tools or paid services beyond such an agent.
The first step is to treat code as “clay.” A developer describes an effect idea loosely, including its art direction, and asks the agent for five to ten initial drafts. The drafts are rendered as short videos in a /records directory so the developer can inspect them. Rather than trying to specify a perfect result in a single prompt, the developer uses the range of drafts to discover a promising direction, chooses one, and iterates on its details. Code-driven effects make it easy to try variations and adjust them.
Duprez’s second recommendation is to trust the human eye and set a demanding quality bar. The agent can produce an acceptable first version, but “acceptable” is not necessarily ready to ship. For his game *Destroy Any Website*, he says the first version of a MIRV rocket launcher came together quickly, then took hours of iteration to reach the result he wanted. His suggested review questions are about whether the effect feels right, and whether its balance, motion, and timing could be improved. The developer should request specific changes and continue the back-and-forth until the result matches the intended vision.
The third ingredient is references. Duprez recommends studying design, film, photography, art, and games to build a vocabulary for judging what works. He cites examining the visual effects in *Path of Exile 2* and destruction and fire in *Arc Raiders* as sources of inspiration. This is presented as time invested in developing judgment, even when it is not time spent directly working on the game.
To give readers a starting point, the post links to open-source pixel-art effects they can use as references, modify, or build on. The examples named are Dash & Blink, with afterimages and light; Black Hole, with a lensed disk; Rain, with splashes, ripples, and mist; and Ice, with spikes, crystals, shattering blocks, and frozen characters. The supplied material does not specify a license, installation steps, agent skill file, or compatibility requirements for these assets.
What the archive adds
This is a new, specific example in a broader creative-coding thread. Claude Motion treated motion design as a workflow an agent can execute and inspect; Duprez’s guide applies a similar inspect-and-refine idea to game effects, with the artist explicitly choosing and correcting drafts. EffectCraft takes a different route by building an editor rather than layering an agent workflow over one. This is a new fact on a related creative-tooling thread, not a release of a new agent platform.
Trend signal
No supplied archive assumption or directly supplied pattern link can be applied here without extending the provided record.
Why it matters
For a team building with coding agents, this is a reminder to design work around reviewable artifacts rather than assuming that a capable model makes iteration unnecessary. Short rendered videos turn code changes into something a designer can compare and critique. Producing several candidates before committing to one can expose directions that a narrowly specified first prompt might miss, while keeping final selection with the person who understands the intended style.
The method is most immediately useful where outputs can be rendered cheaply and judged visually. It also implies a practical division of labor: delegate variation and implementation to the agent, but make the acceptance criteria and review loop explicit. That does not guarantee quality, and it may take substantial human time—as Duprez’s hours spent refining one effect illustrate. The open examples can reduce the effort needed to start experimenting, though their practical value depends on their code, license, and fit with a project.
Limits and uncertainty
This is one developer’s account, not a controlled comparison of coding agents, workflows, or production outcomes. The post does not give the agents’ model versions, prompts, code, time or cost measurements, or a measure of how often generated drafts were usable. It says the effects are open-source but the supplied material does not state a license or provide technical setup details. The examples therefore cannot be assumed to work with every engine or project. Nor does the account establish that code is better than sprite-based approaches for other kinds of art, or that visual review alone is sufficient for performance, accessibility, or gameplay requirements.
Skill to build now
Try the loop on one small effect this week: describe the visual direction, ask your coding agent for five distinct code-based drafts, render each as a short video, and compare them before choosing one to refine. Keep the candidates and the revisions together so the review is visible. Write down the visual criteria you use—such as timing, balance, and motion—then ask for targeted changes rather than restarting with a broad prompt.
Reader takeaway
The transferable lesson is to treat a coding agent as a fast source of variations, not as the final art director. Render the work into reviewable form, use references to sharpen your judgment, and keep iterating until a person is willing to approve the result. Duprez’s open effects offer a starting point, but the quality bar remains the builder’s responsibility.