Gorest 2D Animation Spritesheet Generator: a no-UI spritesheet workspace driven by Codex
Codex-assisted local 2D animation spritesheet generator and scene compositing workspace.
At a glance
- What is it?
- A local TypeScript app that turns reference images into 12-frame or 16-frame spritesheets and composites them into previewable scenes. The interesting part is not the renderer, it is the workflow: there is no control panel to learn, you describe the change and an agent edits the app.
- Who is it for?
- Adopt it if you are prototyping a 2D side-scroller or a scene-based game and want spritesheets, metadata and a playable preview in one local workspace without paying for a Spine-style pipeline. Skip it if you need a shipped runtime, a documented API surface, or a tool that behaves the same way twice, because the README explicitly frames the app as something an agent rewrites while you work, and no API reference or rollback path is documented.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 42 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: spritesheet work is mostly pipeline plumbing, not drawing
Most 2D animation friction sits between the art and the engine. Someone draws frames, someone else packs them into a grid, a third person writes clip names, trigger types, loop flags and direction metadata, and then a programmer wires all of it into a scene. Every handoff is a place where a filename or a frame count goes wrong.
This project targets that middle layer. According to the README, it is an "open-source, no-UI 2D game and animation generative platform for turning concepts, references, and spritesheets into animation-ready scenes, previews, and reusable game assets." The audience is small teams and solo developers doing early prototyping, not studios shipping a finished title. The README also states the goal plainly: reduce or skip the manual Spine-style workflow for early prototyping.
The unusual part is the delivery model. There is no settings panel to learn. The README describes a combination of "dynamic software and a no-UI workflow": you describe the tool or workflow you need, and the agent changes the tool to match. That is either the best thing about the project or the worst, depending on whether you want a stable artifact or a malleable one.
Architecture: a Vite front end, an Express server, and Codex as the operator
The repository layout is a single TypeScript application, not a library. `src/` holds the React front end, `server.ts` is the Node entry point, and `vite.config.ts` plus `tsconfig.json` cover the build. The `package.json` scripts make the shape clear: `dev` runs `tsx server.ts`, `build` runs `vite build` followed by an esbuild bundle of the server into `dist/server.cjs`, and `start` runs that bundle. `lint` is just `tsc --noEmit`, so there is no separate linter config to fight.
The dependencies confirm the split. React 19 and `motion` handle the canvas and preview animation, `lucide-react` supplies icons, Tailwind 4 is wired through the Vite plugin, and `express` serves the app. The one generation-related dependency is `@google/genai`, which the README ties to optional cloud image generation rather than the core local workflow.
The data flow described in the README runs one way: Codex calls a local agent to produce a spritesheet, the app plays that spritesheet in a live preview, and the result can then be dropped into a game engine. Scenes, layers, assets and animation metadata live in the app and can be saved into a local game asset library. The README lists the editable metadata fields explicitly: asset role, clip name, trigger type, game state, direction, loop mode and tags. That list is the real interface of the project. If your engine needs a field that is not on it, the README's answer is that Codex should add it.
Two files carry the agent contract: `AGENTS.md` at the repository root and `docs/AGENT_WORKFLOW.md`. The README points at both for durable agent instructions and prompt templates, and recommends `gpt-5.5` for the workflow.
Installing it locally and generating a first spritesheet
The README requires Node.js 20 or newer. Clone the repository and install dependencies:
git clone https://github.com/NO6KIKO/gorest-2d-animation-spritesheet-generator.git
cd gorest-2d-animation-spritesheet-generator
npm installThe README states that the current local workflow does not require an API key. The environment file is optional and only matters if you later enable cloud image generation:
cp .env.example .env.localInside `.env.example` there are exactly two keys. `GEMINI_API_KEY` is empty by default, and `PORT` defaults to 3000:
GEMINI_API_KEY=""
PORT=3000Start the development server with the `dev` script from `package.json`. The README does not print the URL, but the port variable in `.env.example` defaults to 3000, so that is the value to expect in the terminal output:
npm run devOnce the app is open, the README's first real task is to create a scene and place layers on it. Open a scene, add a background and a character, then open the `Spritesheets` page, which the README says shows every animation clip used in the current scene. Import or generate a 12-frame or 16-frame spritesheet, edit its metadata (clip name, trigger type, loop mode), and use the side-scroller preview to watch the character move. The README also documents scene-card shortcuts on the `2D Canvas`: `Ctrl+C`, `Ctrl+V`, `Ctrl+D`, `Ctrl+X`, `Delete`, `Backspace`, `Ctrl+Z` and `Ctrl+Y`, with the same actions available from a right-click menu.
If you would rather not run any of this, the README points to a hosted version at `sprite.gorest.ai` that requires no installation, no API keys and no configuration.
The no-UI bet: when an agent editing your tool is a liability
The README is explicit that Codex can "revise the product framework itself while the tool evolves." That is a genuine design position, not marketing filler, and it has a cost the README does not address.
A tool that an agent rewrites on request has no stable interface. If you and a collaborator both point Codex at the same repository with different prompts, you end up with two divergent applications and no migration path between them. The README documents no rollback, no versioned schema for scene files, and no changelog. The repository has no releases, so there is no tagged artifact to pin. The `package.json` version is `0.0.0`, which is consistent with a project that expects to be edited rather than consumed.
There is a second, quieter limitation. The README recommends `gpt-5.5` for this workflow. That means the practical quality of the tool depends on a model you do not control, accessed through a subscription or API you have to maintain. The local app itself needs no key, but the workflow the README describes is not model-free.
Finally, the README does not document a runtime. The preview is a preview. Nothing in the repository description or the file list suggests a shipped player, an engine plugin, or an export format for Unity, Godot or anything else. The README says the result "can be used in a game engine," which is a statement about the spritesheet and metadata, not about an integration. You are expected to wire that part yourself.
Gorest versus Aseprite and TexturePacker for spritesheet work
The obvious comparison is Aseprite for drawing and frame tagging, plus TexturePacker or a similar packer for atlas generation. That combination is deterministic. You get the same atlas from the same inputs, the tag format is documented, and the exporter targets named engines. It is also entirely manual: someone has to draw every frame, name every tag, and re-export when the art changes.
Gorest takes the opposite position on both axes. It assumes you start from a reference image and a prompt rather than from a blank canvas, and it assumes the tool itself is editable. The README's claim is that this removes the manual Spine-style pipeline for early prototyping, not that it replaces a drawing program. If your frames need to be hand-drawn with pixel precision, the generator is the wrong entry point and the README does not pretend otherwise.
The other difference is where metadata lives. TexturePacker writes a data file next to the atlas. Here, metadata lives inside the app's scene and asset library, editable through the `Spritesheets` page or by Codex. That is more convenient during iteration and less convenient the moment you want to diff two versions of a clip's configuration in git.
Maintenance, licence and what you are actually taking on
The repository is not archived. The last push was on 2026-08-09, which is recent enough that the codebase is moving, though the absence of any tagged release means you are tracking `main` by definition. For a tool you intend to modify with an agent, that is arguably fine. For a tool you intend to depend on unchanged, it is not.
The licence is MIT, declared in `LICENSE` and repeated as the `license` field in `package.json`. MIT permits commercial use, modification and redistribution with the copyright notice and permission notice retained. That is the extent of what the repository states; it says nothing about the hosted version at `sprite.gorest.ai`, which is a separate service with its own terms. If you plan to ship generated assets commercially, the generation path matters: the README notes that the local workflow needs no API key, while cloud image generation requires your own `GEMINI_API_KEY`, which brings the provider's terms into play. That is a question for your own legal review, not something the repository answers.
Upgrade cost is the part most teams underestimate. Because there are no releases, upgrading means pulling `main` and reconciling whatever Codex has done to your copy. If you have prompted the agent to change the product framework, that reconciliation is a merge, not a version bump.
Editorial conclusion
Adopt it if you are prototyping a 2D side-scroller or a scene-based game and want spritesheets, metadata and a playable preview in one local workspace without paying for a Spine-style pipeline. Skip it if you need a shipped runtime, a documented API surface, or a tool that behaves the same way twice, because the README explicitly frames the app as something an agent rewrites while you work, and no API reference or rollback path is documented. Verify first that Node 20 or newer is available, that `npm run dev` serves the app on the port you expect, and that the 12-frame or 16-frame grid your artist produces actually matches what the Spritesheets page reads back.
Frequently asked questions
Can ChatGPT make sprite sheets?
The README does not discuss ChatGPT. It describes a Codex-assisted workflow and recommends GPT-5.5 for generating assets, editing scene metadata, and modifying the app itself. The local workflow does not require an API key.
What is the best program to create 2D sprites?
That depends on whether you want to draw frames or generate them. Gorest targets the second case: the README describes prompting Codex with a reference image to produce a game-ready spritesheet, then previewing it in the app. It does not present itself as a drawing program.
How can I animate a sprite sheet?
In this project, you import or generate a 12-frame or 16-frame spritesheet, then open the `Spritesheets` page to see every animation clip used by the current scene. From there you edit clip name, trigger type, game state, direction, loop mode and tags, and the side-scroller preview plays the character moving.
How much does a 20 minute animation cost?
The repository gives no pricing figures for animation work. The README states only that the local workflow needs no API key, and that cloud image generation requires your own `GEMINI_API_KEY`, whose cost is set by the provider rather than by this project.
Community notes