BEAF

Banana Editor and Framework

A genre-neutral game framework and live editor, in TypeScript and PixiJS, built for rapid prototyping. A new game quickly becomes something playable, and the editor then lets a developer, artist or producer make their own changes and see them straight away. That streamlines the process, raises efficiency and reduces waste.

I led its development with AI agents, working inside the Vault and Trellis, with a person setting each goal and signing off the result. An agent backed by the Vault and Trellis knows how to build with it, and every session adds to what it knows, so it gets better the more it is used.

How it is built

Games

Each game is its own package: an arcade game, a turn-based card game, a match-3 puzzle and a slot demo so far. Games cannot reach into one another.

Presets

One call starts a game with the modules it needs.

Modules

Optional building blocks a game installs only if it needs them: input, physics, tweens, Spine animation, grids, cascades and saving. Slots, wagering and regulation are modules too, so a casino game adds them and any other game leaves them out.

Kernel

The core every game runs on: rendering, scenes, assets, text, audio, view, game flow, simulation and lifecycle. It knows nothing about any one genre.

Editor

A live editor for every game: a scene tree, an inspector, picking on the canvas, assets, config, a sequence logger, undo, and device frames in landscape and portrait. Modules add their own tools. It is left out of every shipped build.

One flow engine of steps and sequences sits underneath every game, and each game writes its own loop on it, so a real-time game and a turn-based one are built the same way. One gate runs type checks, tests, a boundary check, lint and a production-file check before anything is committed.

Rapid prototyping, changes by anyone

Its first games, an arcade game, a card game and a match-3 puzzle, were each built from a written design before any slot existed. Once a game is playable, the people making it can shape it themselves in the editor.

Scenes and layout

Pick anything on the canvas, change it in the inspector, and lay it out per orientation.

Assets and animation

Browse the game’s assets with a preview, and choose Spine skins and animations.

Game flow

Follow each step of the game’s flow as it runs in the sequence logger.

Module tools

Modules bring their own tools into the editor, such as a physics body’s shape, speed and bounce in the inspector.

Fine-tuning

Feel, animation timing and performance stay with a person. Routine code and tests go to the agent.

An agent that knows how to use it

The Vault

The memory. Small, linked notes on how the framework works, decisions with their reasons, and fixes filed by symptom. The agent reads it before it acts and writes to it when it finishes.

Trellis

The rulebook. It sets the steps a session follows, who may change what, and which checks must pass. Nothing merges without a person’s go.

Task guides

Short guides in the Vault, one for each kind of task, so an agent reads only what its task needs.

Checks

A boundary check blocks forbidden imports, and an independent verifier plants faults that the tests must catch.

Better the more it is used

  1. Read the Vault
  2. Build inside Trellis
  3. Checks pass
  4. A person approves
  5. Write back

Each session ends by writing back what it learned and what went wrong. Decisions are kept in a design log with their reasons, and fixes are filed so the next person finds them in one question. The next session starts where the last one stopped, so the framework, the Vault and the agent’s work all improve with use.