Developer documentation
Everything needed to build a game for Bananai and get it accepted. A game is a self-contained folder that runs in an iframe; there is no engine to adopt and no framework to learn.
- Publishing guide Start here. What a submission looks like, end to end. markdown
- Submission rules What a game has to satisfy to be accepted. Checked automatically. markdown
- Arcade SDK Reference for the SDK: loading, gameplay signals, scores, ads. markdown
- Virtual controls On-screen controls the shell provides for keyboard-only games. markdown
- QA checklist The manual review pass. Published so it can be run before submitting. markdown
- Common failures How submissions are actually rejected, with the code that causes it. markdown
The starter
A complete, working game, running at that URL as you read this. It is a valid submission as it stands, and the sizing, the SDK lifecycle, the storage guards and the touch handling in it are already correct — which is what submissions are sent back for. Copy the folder, change the id, replace the game.
index.html— the sizing contract, in eight CSS declarationsjs/game.js— the lifecycle, storage and input, commentedbananai.json— a valid manifest to edit
For coding agents
Every page above is also served as its markdown source, and the whole set is available in one request. Point your assistant at these rather than at the rendered pages:
/llms.txt— index of the documentation, with links/llms-full.txt— every document, concatenated
The submission rules and the QA checklist are the two worth reading in full before writing code: they are what a submission is judged against, and both are phrased as conditions that can be checked.
Each page ends with a short Document history — what changed on it and when, not a full changelog.
Getting in touch
Submissions, questions and revenue share terms: hello@bananai.games.