Skip to main content
Glama

ODDBOUT

English | 한국어

Create a fighter with AI. Bring your character into the arena.

ODDBOUT is a fighting game where you play with a character you create. This repository contains the open-source tools for making that character. Work with an AI assistant to turn a description or reference image into artwork, animations, and a fighter package for the game. The tools and docs also use the name AI Fighter.

Play ODDBOUT · Manage your fighters · Site guide · Creation guide · Report a problem

Gameplay preview

ODDBOUT gameplay: two fighters in the arena

Existing ODDBOUT gameplay. The subscription-based character creation workflow is still experimental; this clip does not show a complete creation run.

Watch the 10-second clip · Play ODDBOUT · Questions and feedback

Related MCP server: repo-verifier

What you can make

  • Start with a short idea, reference images, or both.

  • Review the artwork and animations with your assistant. Ask to change what you do not like while keeping the versions you have chosen.

  • Build a package with all 11 required motions, check the files, and register it with your account.

  • Play with your registered fighter directly or let the common AI controller take over.

The kit includes sprite-gen, creation workflows, validation tools, and an MCP server for connecting your assistant to the game. The game engine is maintained separately.

In this kit, "sprite-gen" means the sprite-gen engine and CLI pinned at vendor/sprite-gen, which comes from sprite-gen-agent, our fork of Alex Kim's sprite-gen. Commands, paths and the Python package keep the name sprite-gen.

Ways to make a fighter

Every way registers the fighter to your own Google account, up to three fighters per account. The first two need nothing installed; the third installs the generator from this repository on your PC; the last runs this whole kit. The site guide walks through each.

Way

What you do

Good for

Leave it to ODDBOUT

On My fighters, say in one line what fighter you want (pictures you may use are optional). ODDBOUT draws the look and the motions; you check them, ask for a change if you like, and register.

The quickest start. One fighter per account is free; it is used once its looks are drawn (our own failures give it back). On a full day your request waits its turn.

Talk to your agent

On My agents, connect Codex (ChatGPT · Dots · Codex CLI), Grok, Claude (apps · Claude Code) or Gemini CLI to the hosted ODDBOUT MCP (cloud connection), then ask @ODDBOUT in your chat.

Making and editing fighters from a conversation. Pictures can be attached from ChatGPT only.

Your own PC

On My agents → My PC, create a host and run the three-line command it gives on a Linux PC with your ChatGPT and SuperGrok subscriptions (generation host guide).

More fighters on your own subscriptions: no approval and no limit of one.

Make it yourself

Run this kit with an assistant that can use local tools, and choose every concept and motion (below).

Full control over each frame.

Register from Dots without a PC

For creation in a saved Dots VM, use the Dots VM entry point. The intended flow is one repository URL plus your creation request, using your own Grok subscription. The environment preparer runs the install recipe once; Dots then runs node dots.mjs --install once and node dots.mjs to resume the same pinned workspace. The source and preview-delivery checks remain distinct from login. This 0.5.5 candidate still requires actual saved-VM creation acceptance; unit tests or a parent-container run do not certify it.

Connect the hosted ODDBOUT MCP, sign in with Google, then select @ODDBOUT in your Dots conversation. The ODDBOUT plugin 0.6.0 or later already carries this connection; without the plugin, add it in ChatGPT Plugins as a custom MCP server (adding both shows ODDBOUT twice). Grok and Claude connect the same server from their connector settings, and My agents shows and disconnects every connection. The cloud connector handles account checks, file transfer and registration; no local MCP installation, API key or callback copying is needed. See cloud connection instructions for each host's endpoint and first-time setup. When the hosted generation tools are available, ODDBOUT can make the fighter on its worker at your request. Save the verified account ID, request key and job ID; after a timeout or disconnect, follow hosted job recovery to look up the same job by its ID or original key and refresh preview URLs without resubmitting. A connection or a returned URL does not prove that an image was displayed and reviewed. Creation in your own workspace still uses your selected generation account. The setup below is for running the creation kit in a workspace; it is not required to authenticate the cloud connector.

Create with the local kit

Use the ODDBOUT plugin for creation, review and registration from a PC or a supported Dots workspace. The same connected ODDBOUT account registers the result in either environment. A second AI Fighter Creator plugin is no longer required. See the unified plugin and migration guide.

Send the repository URL to your assistant in the prepared workspace. Add an idea or a reference image. For example:

Make a cat boxer in blue armor for ODDBOUT using this kit. Show me the concept first so we can get the appearance right. Then show me movement, attacks, and reactions in groups for feedback. When I choose the final result, validate it, register it with my account, and check that I can use it in the game.

Your assistant handles setup, generation, packaging, and file checks. You choose how the character looks and moves. Local creation can begin before you sign in to ODDBOUT.

What you need

Requirement

Details

A local execution environment

Your PC or a supported per-user workspace, with Git, Node.js 22.12+, and Python 3.11+. Your assistant can help with setup.

Your own generation account

Image and motion generation use your own supported accounts and subscriptions. The assistant checks actual image/video access and preview delivery before starting.

A Google account for registration

Sign in when you want to upload and register your fighter. No invitation or manual approval is required.

Using the local kit takes setup and several rounds of review. Time, usage limits, and costs depend on your provider and how many changes you make. You choose the provider with your assistant. Switching providers or using a paid API needs your agreement. A browser-only chat needs a connected execution environment for the full workflow.

Make and review, one group at a time

Group

What you review

Appearance

Full-body concept, idle pose, and a face close-up from the same artwork

Movement

Fighting stance, walk, and run at a consistent scale

Attacks

Combo, slam, and dash, including preparation and recovery

Defense and reactions

Block, hit, groggy, fall, and get-up poses

Final review

All 11 motions from the packaged files, plus the name, description, and portrait

Your assistant shows you actual previews and waits for your feedback after each group. It revises the affected assets and keeps your other selections. You can also ask it to handle later groups on its own. Alongside file checks, the assistant reviews character consistency, movement, foot contact, and timing. You review the results before moving on.

See the full creation workflow for generation, revision, and packaging.

Set up the kit yourself

For a Dots VM, start with Dots bootstrap, doctor and resume and the saved-environment Start instructions. The offline entry point is node scripts/dots-workspace.mjs doctor --workspace <absolute-workspace>; installation is explicit with bootstrap --install. A Git URL alone does not authorize generation. Start from main (below) and record its actual commit. The Dots workflow reports unsupported image-output contracts as blocked; it does not read protected Codex sessions or claim that login/installation proves image generation or parent delivery.

Use the main branch, which contains the public service configuration. For a new installation:

git clone --branch main --single-branch https://github.com/jeonghwanko/oddbout-starter.git
cd oddbout-starter
npm ci --ignore-scripts
npm run sprite:setup
npm run sprite:status

Installed before 2026-10-29 from codex/creator-hosting? That branch is frozen, and the kit's readiness check now stops a checkout on it as the wrong branch. Commit or set aside any local changes, then move the checkout to main (a plain git checkout main fails in a single-branch clone):

git remote set-branches origin main
git fetch origin
git switch -C main origin/main
npm ci --ignore-scripts
npm run sprite:setup

Setup downloads the pinned sprite-gen source into this checkout and installs it in a dedicated Python environment. Use Git clone; the GitHub source ZIP does not contain the submodule files. The status command checks installation, not generation access or quota.

Setup also fetches the outside tools sprite-gen needs, without sudo: img2webp with -exact (libwebp 1.6.0, SHA-256 pinned, placed in the kit's environment when your system has none or an older one such as Ubuntu 24.04's 1.3.x) and RIFE for smooth walk and run loops (sprite-gen rife install, about 430 MB download). Install ffmpeg yourself first: sudo apt install ffmpeg (Ubuntu/Debian), brew install ffmpeg (macOS) or winget install --id Gyan.FFmpeg -e (Windows). Setup and sprite:status list each tool as ok, missing or broken with the command that fixes it. A Linux machine without a GPU also needs sudo apt install libvulkan1 mesa-vulkan-drivers for RIFE; without RIFE, loops are cut as filmed with a warning. Keep an in-progress character workspace in place and avoid pulling repository updates during creation.

To connect the tools, follow the local Codex plugin guide: npm run plugin:build, then the printed codex plugin marketplace add … and codex plugin add oddbout@ai-fighter-local. The older manual MCP connection (node scripts/print-install.mjs) remains for compatibility. Other local hosts can connect mcp/stdio.mjs with AI_FIGHTER_ROOT set to the checkout.

The unified plugin guide covers the portable source package. A local plugin installation does not mean the plugin is installed in Dots or listed in a public directory.

Register and play

When you choose the final result and ask to register it, your assistant checks the package and registers it through your connected ODDBOUT account: the ODDBOUT plugin, or an agent connected on My agents, signed in with your Google account. You do not need to set up a backend or get service API keys. Older local tools without that connection sign in with npm run login.

The server checks your uploaded files and registers your fighter in production: you can watch it and practise in the arena. Your assistant checks the result to confirm the registration. The queue can take time to process. To let other people play against your fighter in cups and ranked duels, open All motions on its page, check each of the 11 required motions and press Enter ODDBOUT.

Open the creator page with the same Google account to see your fighter; its My agents tab manages your connected agents and your PC. See registration, limits, and profile edits for details. Keep login links, callback URLs, and session files private.

Help and contributions

If setup, generation, sign-in, registration, or gameplay fails, open an issue with the failing step, expected and actual behavior, error message, and tool version or commit. Exclude credentials and private files. For generation or upload timeouts, check existing requests and outputs before retrying.

Bug reports, clearer setup instructions, and reproducible examples are welcome. Read AGENTS.md before using an assistant to change this repository. Pull requests target main and merge only after the test workflow passes; npm test runs the same suite locally, including the strict type check of api/, worker/, mcp/ and scripts/.

Resource

Use it for

Cloud connection · Connection recovery

Connecting ChatGPT, Grok and Claude, Google sign-in, account checks, and cloud registration

Authoring guide

Fighter files and the package contract

Creation UX

Character intake, feedback, and version selection

Game creation context

Current motions, controls, and timing

Gait review

Walk/run quality and contact evidence

Execution environment · Preview delivery

Account isolation, local execution, and actual media display

Hosting · Security

Deployment and security boundaries

Generation host (Korean)

Make your own fighters on your own Linux PC and subscriptions, and, once approved, other creators' requests

Local development checks, after installing dependencies:

npm run spec:check
npm test
npm run validate -- examples/sparring-bot/fighter.json
npm run mcp:smoke

npm run test:fast skips the slow image-packing, proxy and Python-engine suites (npm run test:heavy runs only those); run the full npm test before a release.

The sparring-bot example is a geometric test fixture. These checks do not generate or register a character. Running matches on a self-hosted service requires the separate production game engine bundle.

License

The creator kit is MIT-licensed. The bundled sprite-gen submodule is sprite-gen-agent, our fork of Alex Kim's sprite-gen, with its own Apache-2.0 LICENSE and NOTICE. Generation providers have their own account and usage terms.

Available Tools

2 tools
get_fighter_specA
Read-onlyIdempotent

Read the public AI Fighter authoring contract. Read overview first; request guide, schema, or example as needed.

NameRequiredDescriptionDefault
sectionNooverview

Output Schema

NameRequiredDescription
okYes
dataNo
stageYes
errorsNo
pendingNo
assetBytesNo
errorCountNo
decodedPixelsNo

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this a safe, idempotent, closed-world read (readOnlyHint, idempotentHint, openWorldHint=false), so the burden is lower. The description adds the fact that the contract is 'public', hinting no auth is required, plus a read-ordering recommendation, but nothing about latency, caching, or pagination behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short, front-loaded sentences with no filler. The core purpose leads, and the operational advice follows immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not describe return shapes, and the annotations cover the safety profile. What remains is an unusually simple single-enum tool, and the description handles it adequately, though it could say a bit more about how the sections relate to each other.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden, but the enum values (overview, guide, schema, example) are fairly self-describing. The description does name three of the four values and implies overview should be read first, adding light ordering semantics beyond the raw enum.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Read') and a specific resource ('the public AI Fighter authoring contract'), which is clearly distinct from the sibling validate_fighter_manifest. It does not explicitly name the sibling, but the resource is precise enough to distinguish them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete sequencing guidance ('Read overview first; request guide, schema, or example as needed'), which tells the agent how to consume the sections incrementally. It stops short of explicitly naming when not to use this tool or pointing at the sibling as an alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

validate_fighter_manifestA
Read-onlyIdempotent

Validate raw fighter.json text. Reject duplicates, unknown fields, invalid references and over-budget data. Does not read files or grant registration.

NameRequiredDescriptionDefault
manifestJsonYes

Output Schema

NameRequiredDescription
okYes
dataNo
stageYes
errorsNo
pendingNo
assetBytesNo
errorCountNo
decodedPixelsNo

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world) and the description is consistent with them. It adds genuine behavioral detail beyond the annotations by naming the rejection conditions (duplicates, unknown fields, invalid references, over-budget data) and the deliberate refusal to read files or register anything.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the core verb, then failure modes, then scope limits. No filler or restated title, and every clause adds information an agent can act on.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the annotations already carry the safety profile. Combined with the enumerated rejection reasons and the no-file/no-registration exclusions, the definition is nearly self-sufficient for a one-parameter validator; only the input document's expected shape is left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single parameter with 0% schema description coverage, so the description carries the burden. 'Raw fighter.json text' does tell the agent the string is inline JSON content rather than a filename, which is the key ambiguity, but it says nothing about the maxLength ceiling or the expected document shape.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Validate raw fighter.json text') and enumerates the failure classes it checks for. It never names the sibling get_fighter_spec, but the explicit 'raw ... text' framing does imply the non-file, non-registration scope, giving an agent enough to distinguish it without reading the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The closing clause 'Does not read files or grant registration' functions as a clear when-not: pass inline JSON text rather than a path, and expect validation only, not side effects. It stops short of naming alternatives or stating positively when to reach for this tool versus get_fighter_spec.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.2.0
    • First observedget_fighter_spec
    • First observedvalidate_fighter_manifest

TDQS

A3.9/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one reads the authoring contract/spec, the other validates a manifest. There is no overlap in intent or workflow, and the descriptions reinforce the boundary (validate explicitly does not read files or register).

Naming Consistency5/5

Both names follow a clean verb_noun snake_case pattern (get_fighter_spec, validate_fighter_manifest). The convention is fully predictable and self-describing.

Tool Count3/5

With only 2 tools, the surface is thin even for a narrow authoring/validation helper. The spec tool does multiplex several documents, but the set still feels minimal for the domain.

Completeness3/5

Reading and validating are covered, but there is no way to register, submit, or persist a fighter, and get_fighter_spec is the only read path. The tools acknowledge registration is out of scope, leaving a notable lifecycle gap.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    B
    maintenance
    Provides MCP tools for local code validation with execution evidence, enabling users to run planned checks on projects and receive JSON results that distinguish passing, failing, and incomplete outcomes.
    173 npm
    MIT
  • A
    license
    A
    quality
    A
    maintenance
    Enables agents to author, validate, inspect, patch, and render editable JSON pixel-art and animation recipes through local tools, producing PNG contact sheets, APNGs, sprite atlases, and related export bundles.
    8
    437 npm
    14
    MIT
  • F
    license
    A
    quality
    A
    maintenance
    Enables converting layered PSD or PhotoshopToSpine exports into validated Spine 2D rigs, animations, atlases, previews, runtime JSON, and optionally editable .spine projects. It provides MCP tools and an OpenAI/Codex workflow for rigging, animation generation, validation, preview auditing, and batch processing.
    14
    -