VibeGame-8B
A prompt, a few source files, a small game you can actually open in Godot.
This repository builds an open-weights Godot fine-tune on free Colab's Tesla T4. The code-focused base is Qwen2.5-Coder-7B-Instruct (7.61B parameters); “8B” is the project name. The goal is prompt-to-play in 60 seconds. That speed and the quality of the model have to be measured, not assumed.
Measured results, October 4: The complete A100 evaluation imported 6/500 projects (1.2%) and ran 5/500 cleanly for 60 seconds (1.0%). Median prompt-to-launch time among successful launches was 282.8 seconds; none launched within 60 seconds. This is a rough research prototype. The original goal of reliably producing playable games in 60 seconds was not achieved.
Training finished on a free T4 using 97 training examples and 11 development examples. After exhausting free GPU access, the owner purchased Colab Pro for evaluation. The earlier partial T4 run remains separate: 72 recorded results, including 64 generations and eight interrupted attempts counted as failures, with one compile/clean-run success. The full A100 run had no infrastructure failures. The adapter, merged FP16 model, GGUF, dataset, complete evaluation evidence, and edited video have been prepared; publication is tracked separately.
The video shows the first three clean successes in frozen prompt order: 56, 436, and 443. It is explicitly unrepresentative. Pong moves, pinball waits for Space, and the rally game is mostly stationary with a running timer. These untouched recordings contain no player input and do not demonstrate working controls or polished gameplay. The 60 seconds describe the edit, not generation time; all 500-prompt results and actual timing stay visible.
Run the notebook
Open notebooks/VibeGame-8b.ipynb in Colab and select T4 GPU with standard RAM. The notebook embeds its source and dataset inputs, so it does not depend on an unpublished GitHub repository. It mounts Drive, installs the pinned tools, admits validated synthetic projects, trains, exports, evaluates, records samples, and publishes when actual artifacts exist.
Every checkpoint and the final adapter are saved to MyDrive/VibeGame-8B. Training uses 4-bit NF4, rank 32, alpha 64, all attention and MLP projection modules, Unsloth gradient checkpointing, FP16 compute, batch size 1 with gradient accumulation 16, a 2e-4 learning rate, cosine decay, and two epochs. The maximum context is 4096 tokens. Oversize projects are rejected whole.
A free runtime may disconnect before the work completes. Resume in a fresh free T4 session using the same Drive run folder; do not change dependencies, data or hyperparameters midway through a run. The scripts never provision paid compute. Merged weights and GGUF use local runtime disk by default because both would exceed an empty free 15 GB Drive once checkpoints are included. Publish or download those exports before disconnecting.
Data and checks
The collector currently retains 180 MIT GDScript files from two commit-pinned repositories, with the original license notices. It fetches source text only, rejects ambiguous license boundaries, and excludes all game assets. The Stack v2 has GDScript, but its gated terms and bulk-download agreement mean it is excluded here.
The in-session Codex assistant wrote 100 distinct complete-project candidates, alongside nine original seeds. Linux admission accepted 108 and discarded one, then split the accepted projects into 97 training and 11 development examples. Each accepted pair passed strict project-format checks, a Godot import, and a full 60-second run with zero script errors. Duplicates and near duplicates are removed before splitting. These are data-admission results, not scores for the fine-tuned model.
An optional local Qwen2.5-Coder-14B-Instruct sampler is also included. Its first pilot produced two failures; the revised pilot completed four attempts with two passes and two failures, then stopped. Its overlapping prompts were superseded by the Codex-authored candidates. The 180 MIT reference scripts remain a separate reference corpus and are not direct SFT examples. Exact batch sources and provenance are linked in docs/data.md.
The 500 blind evaluation prompts are frozen separately. They comprise 25 game families crossed with 20 rule variants; this is a templated compositional benchmark, not 500 independently authored genres. A separate development split supplies training-loss evaluation. The blind set never supplies training targets or checkpoint selection.
The validator uses Linux isolation with no network and no access to Drive outside the individual test directory. Local macOS execution is disabled after the sandbox blocked Godot's loader and caused startup crash dialogs. The supported evaluation environment is Colab Linux.
A clean headless run proves only that the game remained running without detected script errors. It cannot prove fun, good controls, correct objectives or a visible playable scene. The release includes the raw generations and failures; incomplete evaluations do not get final percentages.
The model benchmark evaluates the LoRA adapter on its 4-bit base. It does not establish scores for the merged FP16 or GGUF exports. The original video sample indices 0, 200, and 400 were fixed before evaluation; that mode keeps failures as diagnostic cards. An explicit success-only showcase can instead show the first three clean results in frozen index order after all 500 results finish. This display policy was declared after the A100 run began; it leaves benchmark sampling and scores unchanged. The video labels selected successes as unrepresentative, shows full benchmark rates and actual timing, and requires all three untouched recordings. See docs/demo.md.
A separate warm throughput check on the untrained base, using training prompts, measured 61.045 aggregate output tokens/s at batch 16, versus 13.3997 at batch 1—a 4.556× throughput increase. That measures combined output across the batch, not a single prompt's latency. Each evaluated prompt keeps the full batch generation time, plus its own queue, import, and startup time. The completed A100 measurements above show that the 60-second prompt-to-play target was missed.
Run locally after training
Download the Q4_K_M GGUF, update the FROM path in Modelfile, then:
ollama create vibegame -f Modelfile
python scripts/generate.py --backend ollama --model vibegame \
--prompt "Make a tiny game where I catch falling stars and avoid meteors" \
--output my-game.json
python scripts/extract_project.py my-game.json --output my-game
The generation command writes a JSON file map with project.godot, main.tscn, and GDScript source. The extractor writes those files into an empty directory after checking the source contract. Open the resulting project with Godot 4.5.1. The generator uses local Ollama, or an Unsloth adapter in Colab; details are in docs/evaluation.md.
Release without inference billing
Publishing uses HfApi and an in-memory write token. It never calls an inference provider, creates a paid endpoint, adds billing, or writes the token into the notebook. The publisher checks real weight files and all 500 evaluation records before creating the model, GGUF, adapter and dataset repositories.
The account's Inference Providers limit was saved as $0, with all 18 providers disabled, and verified after reloading the settings page. See docs/hf-safety-evidence.json. Provider mappings must also be checked after publication. inference: false in a model card hides the inference widget; it is not a substitute for account settings.
Contribute
Small, distinct examples and real playtest reports are useful. Include a game's complete source and license, the exact prompt, Godot version, and the failure you observed. Please keep benchmark prompts out of training and preserve upstream attribution.
Original project code and seed examples: Apache-2.0. Collected source keeps its original MIT license and notices. Details are in docs/data.md, docs/training.md, and docs/evaluation.md.