Introducing the RUN.game SDK: Direct Platform Access for Developer-Creators
Discover the RUN.game SDK: Direct platform access for developer-creators. Connect ads, purchases, multiplayer, AI, leaderboards, and more through one simple API—no infrastructure setup required.
By RUN.team · June 26, 2026
If you build games with code, the RUN.game SDK gives your game direct access to everything RUN.game offers (ads, purchases, multiplayer, AI, leaderboards, and more) through one connection point, so you never have to build or run that infrastructure yourself.
Note: This post describes RUN.game SDK v5.22.0, current as of June 2026. Newer versions may add or change features, so always check the docs for the latest.
INTRO
RUN.game is a platform for creators. But developers, the people who reach for their code editor before their mouse, can get to a deeper level of control than the visual, drag-and-drop studio exposes.
The RUN.game SDK is how developer-creators reach that layer: making money, saving player data, real-time multiplayer, AI generation, notifications, and live experiments. You bring your own game engine, such as Phaser, React, Three.js, whatever you prefer, and the SDK handles everything that sits between your game and the platform.
WHAT IT IS
An SDK, software development kit, is a ready-made toolbox you drop into your project so you don't have to build common features from scratch. The RUN.game SDK installs like any standard web package (its name is @series-inc/rundot-game-sdk) and works with any game that runs in a web browser, no matter what tools you built it with.
You reach everything the platform can do through a single connection point in your code, called RundotGameAPI. One predictable place to call for every feature, instead of wiring up and tracking a dozen separate services.
The SDK covers seven areas:
- MONETIZATION: Earn from your game with rewarded video ads (players choose to watch one in exchange for a bonus), interstitial ads (full-screen ads shown between moments of play), and in-game purchases paid for with RunBucks, the platform's currency, plus a shop to list items and run the purchase flow, and entitlements to track and consume what players own (items, passes, power-ups). You can also check and spend a player's credit balance directly from your game, with clean handling for when they run out. The ad and payment systems already exist; you just connect your game to them.
- MESSAGING: Bring players back and keep them current. Schedule notifications (the reminders that appear on a player's device), and show quick pop-up messages and alerts inside the game. Drop in platform-native like and comment dialogs (and read whether the current player has liked your game) without building that UI yourself. And publish game update channels that ship release notes to players through their inbox and push notifications.
- ASSETS: Load and manage your game's files: images, sound, and the like, quickly and reliably from RUN.game's global delivery network. Files cache so they don't re-download every time. You can load files in advance before they're needed, share common bundles across several of your games, use libraries the platform supplies, and control the loading screen players see while large files load.
- GAME SYSTEMS: The deeper building blocks behind game design and live operations. Run A/B experiments (show different versions to different players to see what performs better) and turn features on or off without publishing an update. Handle the enormous numbers that idle and incremental games pile up, without rounding errors creeping in.
- For richer systems, the Simulation API lets the server, not the player's device, keep the official record, which helps prevent cheating. That covers energy and stamina meters, gacha and loot drops, and timed building upgrades, all set up through simple configuration files. This area also includes competitive leaderboards, real-time multiplayer (with easier room listing, matchmaking options, and room setup), video playback (handed off to the device's native picture-in-picture, iOS only), and sharing: links, QR codes, and the information carried along when someone opens your game from a shared link. You can also update, delete, and de-duplicate content shared across several of your games.
- Note: Multiplayer, Leaderboards, Video, the Simulation API, and all its sub-features (Config Reference, Energy, Gacha, Building Timers) are currently in BETA, available to try, but still being finalized.
- DATA, STORAGE & TIME: Save and read player data (progress, settings, scores) kept on a single device, across your whole game, or shared everywhere. See how people actually play with analytics: what they do, and where they drop off. Read the current player's RUN.game profile. Track and persist player stats (beta). Let players go from anonymous to signed-in mid-game without losing their session or progress. And sync to the platform's clock, so timers and daily events stay consistent no matter a player's time zone or device.
- AI: Generate text, images, audio, video, sprites, and 3D models with AI right inside your game. RUN.game runs the AI models for you, so there's nothing for you to set up or maintain. Reasoning models now return their full thinking, instead of dropping it.
- DEVICE & ENVIRONMENT: Adapt to whatever device a player is on. Keep your game clear of notches and rounded screen corners (safe areas), detect whether they're on a phone, tablet, or desktop, trigger vibration feedback (haptics), respond when the game is paused or resumed, and record logs that make debugging and support easier. Add gamepad support for controller input that works across surfaces (opt in when your game needs it), and use launch intents to handle how players arrive into your game.
The full API reference (the complete menu of everything you can call) is where you'll want to spend time once you've got the basics running.
-> Full API Reference: https://series-1.gitbook.io/rundot-docs
WHO IT'S FOR
The SDK is for developer-creators: people who build games with code and want platform-level features without building those features themselves. Think of the indie developer who wants a working ad system without months of setup and paperwork, the studio engineer wiring a custom game engine into RUN.game, or the creator who has outgrown the drag-and-drop studio and wants hands-on control over how their game behaves.
HOW TO GET STARTED
The full setup walkthrough lives in the official docs: installing Node.js (the runtime that lets these tools run on your computer, version 20 or higher), the RUN.game CLI (a command-line tool for setting up and publishing games), and the SDK itself, then choosing a starter template, setting up your project, and publishing it.
-> Getting Started Guide: https://series-1.gitbook.io/rundot-docs/readme/getting-started
The short version, once the tools are installed: add the SDK to your project, pick a starter template (2D Phaser, 3D React, or a UI-heavy 2D React layout), and start building. The exact commands are in the guide above.
A FEW THINGS TO KNOW (v5.22.0)
- AI and multiplayer now ask players to sign in. Streaming AI calls and real-time multiplayer now require a signed-in (18+) player; anonymous players will see a sign-in prompt. If your game offered these to logged-out players, give those flows a quick test.
- The config folder is now rundot/ (previously .rundot/). Your existing .rundot/ folder keeps working, so nothing breaks, but rundot/ is the new home going forward.
- Rooms V1 is winding down. It's still fully functional; you'll just see a one-time console notice nudging you toward the newer multiplayer APIs.
- Bookmark the SDK docs, drop into the RUN.game Discord with questions, and go build something.
-> SDK Docs: https://series-1.gitbook.io/rundot-docs
Build on RUN · Join the Discord