Devtools

Two tools, fourteen addons.

All of it came out of the games. GDAM installs and pins the addons those projects share; gdlint keeps the GDScript around them honest. The tools are one static binary each, with no runtime, no daemon and nothing to sign up for. The addons are what they were built to carry.

GDAM

Godot Addon Manager

Available

Go · MIT · Linux, macOS, Windows

Install, link, remove and publish Godot addons from GitHub release assets, through a small CLI and the public registry at gdam.dev. gdam init writes a manifest into your project; gdam add @user/addon and gdam install keep that manifest in sync with what is actually sitting under the addons directory.

Local development links live in a separate gdam.link.json, so working against an unpublished addon on your disk never edits the manifest you ship. Publishing is authenticated with a secret key scoped to a single user or org; the CLI itself carries no credentials, which is why installing needs no account at all.

go install github.com/aviorstudio/gdam@latest

Or the install script · reads are public, no account needed

gdlint

GDScript hygiene checker

Available

Go · Linux, macOS, Windows

Reads every script in a Godot project — and every scene and autoload entry that could be pointing at one — then reports what nothing references: unused functions, signals, constants, enums and whole files. Leftover print() calls, orphaned .gd.uid files, space indentation and dynamic has_method() calls as well. Run it with -fix and it removes what it found.

Four rules ship enabled and the other twelve wait to be asked for in gdlint.json, because the rest is house style. It is deliberately not an architecture checker: directory naming, import direction and autoload ownership change per project, and a hygiene tool that guessed at them would be wrong everywhere but home.

go install github.com/aviorstudio/gdlint@latest

Run from a Godot project root · exits non-zero on errors

Addons

The fourteen on the registry.

Each one was factored out of a game the third time a project here needed the same thing. They are Godot 4, MIT, and published to gdam.dev, and every one of them draws its boundary in the same place: the addon owns the mechanism, the game owns the policy.

gdam install @aviorstudio/<name>

Same for all fourteen · or copy addon/ in by hand and enable the plugin

gd-audio

Music and pooled sound effects

One GdAudio autoload: configure a looping music stream with fades and a persisted volume, register named samples, then play_sfx("click"). Effects play out of a player pool you size. Volume is written to a config file you name, so the settings UI stays in the game.

Source

gd-env

Environment and config loading

Typed OS environment lookups with defaults, .env parsing, and JSON config from a file or an HTTP endpoint. It deliberately does not decide which source wins when several are present. Client-side config is public either way, so nothing here is a place for secrets.

Source

gd-gesture

Pointer normalization and gestures

Mouse and touch collapse into one typed pointer stream, and a recognizer turns that into tap, double tap, long press, swipe, drag and pinch. Use the global autoload for one shared stream, or the two modules directly when a split-screen or editor scene needs its own thresholds.

Source

gd-network

HTTP, WebSocket and retry primitives

A callback JSON HTTP client that uses HTTPRequest natively and a JavaScriptBridge fetch bridge on web, plus a request pool, token-bucket rate limiting, deterministic retry backoff, ordered delta windows and a shared error catalog. Auth, sessions, matchmaking and reconnect policy are left to the game.

Source

gd-object-pool

Object and node reuse

Acquire and return instances of any class instead of allocating per bullet, card or effect, with warm_pool to pre-allocate before gameplay and counters for created, reused, returned and disposed. Objects come back clean through a reset method or a callable you supply.

Source

gd-observe

Local observability with a terminal dashboard

Timers, gauges and counters alongside logs, events and per-frame traces, all tagged with a context you push and pop. A localhost WebSocket server streams them live to a terminal UI. Metrics are in-memory and local — the point is to see the data before deciding whether any of it should leave the machine.

Ships gdobs, a Go terminal UI

Source

gd-playwright

Named handles for web-export browser tests

The addon writes element positions, events and test state to browser globals during a web run; the CLI reads them over CDP so a test can click start_button instead of a coordinate. The CLI is strictly read-only — it never mutates browser or game state. Disabled builds no-op, so the calls are safe to leave in.

Ships gdpw, a Go CLI

Source

gd-pocketbase

PocketBase auth and session primitives

Normalizes either a native {token, record} response or a backend proxy's {access_token, user} into one shape, then handles JWT expiry, persisted sessions and stable client IDs. Games keep HTTP transport and refresh policy; no superuser credential ever needs to reach the client.

Source

gd-redis

A Redis client over RESP

SET with a TTL, GET, DEL, cursor-based scan_keys rather than KEYS, and both blocking and non-blocking connects — for tools, dedicated servers and local utilities. flushdb stays disabled until dangerous commands are explicitly enabled, and web exports cannot open raw TCP at all.

Source

gd-responsive

Layout that adapts to the viewport

Breakpoint classification, scale, margins and content width computed from a .tres config, plus layout, flex and grid nodes that run as @tool scripts so the result is visible while authoring rather than only at runtime. Take just the scale module if you already have containers of your own.

Source

gd-router

Editor-first screen routing

A GdRouter autoload owns the route table, params and history while a RouteHost node mounts the active screen under a persistent main scene. Routes auto-discover from *_screen/ folders while prototyping, or come from a committed route map so they are inspectable and reviewable in the editor.

Source

gd-serialization

Objects to dictionaries and back

Boundary conversion for saves, HTTP and WebSocket payloads and safe clones, with configurable class resolution, ignored properties and key normalization. It serializes script variables, not scene-tree state; cyclic graphs are unsupported, and reflection costs enough that it does not belong in a hot loop.

Source

gd-supabase

Supabase session helpers

JWT decoding and expiry checks, local session storage, and a stable client ID, without picking an auth UI or an HTTP client for you. It decodes tokens rather than verifying them, so refresh, revoke, encryption and server trust all stay deliberately on your side.

Source

gd-telemetry

Event batching with no vendor attached

Build structured events — timestamp, level, context and subject IDs, message, metadata — queue them, and flush on a size or time threshold into whatever transport you already have. It picks no analytics vendor and opens no sockets, which is the entire design.

Source

Both tools and every addon on this page are used daily on the Godot projects listed under Games — that is the whole reason they exist, and the reason they keep getting fixed.

See the games