Developers
Submit a game
SDK CHANGELOG

What’s new in the SDK.

Every release of https://hoplobby.com/sdk/v1/hoplobby.js. Releases inside v1 only add things: games built on an older one keep working. New releases are posted in #sdk-changelog on the HopLobby Discord, and served at GET /api/v1/changelog.

  1. v1.7.0 · latest

    Game sessions: HopLobby’s pre-match lobby, rounds and rematch

    Every lobby is now a game session: players launch the game, land in HopLobby’s pre-match lobby, press Ready, and HopLobby counts down and starts the round; when it ends, a rematch window lets everyone ready up again. HopLobby runs all of it. By default nothing changes for your game: HopLobby loads it fresh for each round. Opt in with session: true and your game stays loaded through the pre-match lobby and every round, following HopLobby.session.

    Added

    • HopLobby.session: get() returns { phase: 'lobby' | 'countdown' | 'playing' | 'results', round, since, deadline, now, roster, you: { inGame, ready, inRoster }, players, winners }, and on('session', (session, previous) => {}) fires on every change. Start your match when phase becomes 'playing' with a new round and you’re in roster; a higher round is a rematch.
    • HopLobby.session.ready(ready = true): Ready (or not) for the next round from your own UI, as HopLobby’s Ready button does. HopLobby.ready() keeps its meaning: your game finished loading.
    • HopLobby.session.end(results): the host finishes the round with your results, like endGame(results), into the results screen and the rematch window. Rejects with code 'not_host' for everyone else.
    • The session: true flag (hoplobby.json, the submission form, prepare_submission; Dev Mode: Test setup or prepare_dev_mode). With it, your frame loads once and HopLobby draws its pre-match lobby over your game. context.session has the session at init.
    • The local simulator (npx hoplobby-dev) has session controls: phase buttons, the round counter and per-player Ready toggles.

    Changed

    • Rematches are run by HopLobby for every game: after a round, players ready up in the rematch window and the next round starts with whoever is ready. Games without session: true are reloaded for each round, so they need no changes.
    Read the docs
  2. v1.6.0

    Your settings in HopLobby’s menu, lobby options from your game, graphics presets

    Put your game’s settings, key list and buttons into HopLobby’s Esc menu with HopLobby.menu.set(): no settings screen of your own needed, and players can change them in the lobby before launch too. Declare lobby options from your game with init({ lobbyOptions }) in Dev Mode. Every game now follows the player’s graphics preset: HopLobby.graphics gives you the numbers.

    Added

    • HopLobby.menu.set({ settings, controls, actions, shared }): your personal settings (a “Game” tab, or lines under Graphics, Audio or Controls), your key list on the Controls page, and up to 4 buttons under Resume. Read the values from HopLobby.prefs and on('prefs'); buttons fire on('menuAction', id). HopLobby.menu.open('settings') opens the menu from your own button.
    • Players see your menu settings in the lobby’s You tab too (from the last time they played your game), with HopLobby’s graphics, audio and controls.
    • init({ lobbyOptions }): declare your lobby options from the game. A Dev Mode lobby shows them in Match settings for the host; a published game keeps the options on its submission, and the console warns when the two differ. on('options') fires when they change mid-game.
    • HopLobby.graphics: the player’s graphics preset (potato, low, medium, high, ultra) as numbers (pixel ratio, shadows, effects, particles, draw distance, texture scale), with Auto resolved for the device. settings.graphicsLevel and on('graphics') too.

    Changed

    • Graphics presets are a platform rule: every game renders at the player’s Graphics quality and stays playable on potato. The submission checklist has a new line for it, and the Graphics quality picker is always in your game’s menu.

    Fixed

    • The Esc menu’s Settings and Controls pages were empty in community games and Dev Mode. They now show HopLobby’s settings and whatever your game declares.
    Read the docs
  3. v1.5.0

    Send updates for your published games

    Published games get a “Send an update” button on the portal: send the new source, the demo address where it runs and what changed. Players keep the live build until HopLobby has reviewed and built the update, then switch over. No changes to the SDK calls.

    Added

    • Send an update on a published game’s page: a public GitHub repo or a zip, the demo address and what changed. One update waits at a time; sending another replaces it.
    • Your game’s page shows the update waiting for review, and the reviewer’s note if an update is turned down.

    Changed

    • get_submission_status in the MCP server shows a waiting update.
    Read the docs
  4. v1.4.0

    HopLobby hosts your game: submit a demo and your source

    Submissions now come with a demo address and the game’s source (a zip or a public GitHub repo). Once your game is approved, HopLobby builds that source and hosts it for you, and it goes live on the Community tab with your name. No changes to the SDK calls: games keep working as they are.

    Added

    • Source on every submission: link a public GitHub repository (we pin the commit you submitted) or upload a zip of up to 95 MB on the form.
    • A build section in hoplobby.json (output folder, optional build command and Node version) and the Packaging docs: relative paths, everything bundled, a lockfile, no secrets.
    • npm run pack in the SDK starter, and package_submission in the local MCP server: they check your source and build with HopLobby’s own rules and make the zip to upload. check_build now checks the hosting rules too.
    • Optional cover.webp / cover.png / cover.jpg at the root of your build: your game’s art on the Community tab.

    Changed

    • The game address is now a demo address: a test build on your own https domain that reviewers play in Dev Mode. Players get the build HopLobby hosts, served from its own games domain.
    • Updates are reviewed and built from source like the first version. Your game’s page shows which build is live.
    • The submission checklist’s hosting item is now about sending your source.
    Read the docs
  5. v1.3.0

    HopLobby for AI assistants: MCP servers, game templates and a review check

    Your AI assistant (Claude Code, Cursor, VS Code, Claude Desktop) can now work with HopLobby directly: read the docs, debug your live game’s errors, test multiplayer in the simulator and check your game before you submit it. No changes to the SDK calls: games keep working as they are.

    Added

    • Hosted MCP server at https://developers.hoplobby.com/mcp: docs search, your games’ errors and analytics (with what stands out), manifest checks, Dev Mode setup links, submission drafts, player data and leaderboard moderation, earnings, and ready-made prompts.
    • Sign in with HopLobby (OAuth) from your AI tool, or use a personal MCP token (hlp_…) from the portal’s new AI assistants page. Read-only or read and write, revocable, developer plan members only.
    • Local MCP server in the SDK starter: npx hoplobby-mcp. Your assistant can start the simulator, read the relay, add players, change hosts, reload players, take screenshots, and run a review readiness check mapped to the review checklist.
    • Four game templates to start from: turn-based board game, real-time arena, drawing party game and a 3D table with HopLobby avatars. Scaffold one with the local MCP or copy it from templates/.
    • check_build and upgrade_check: build size against the budgets, and suggestions for newer SDK features in your code.
    • create_game_key writes a new game key straight into your project’s .env, never into the chat.

    Changed

    • Submissions prepared by an AI assistant are drafts: you review them on the portal, tick the checklist and press Submit yourself.
    • A game id stays yours for good once you’ve used it, even after a withdrawal: no other developer can take it, because your players’ data and game keys belong to it.
    Read the docs
  6. v1.2.0

    Cloud saves, leaderboards, achievements, analytics and performance telemetry

    Keep player progress without running a server, rank your players, reward them with achievements on their HopLobby profile, and see how your game is doing. Everything is additive: check HopLobby.supports(feature) before using the new parts.

    Added

    • Cloud saves: HopLobby.storage.get / set / remove / list keep small JSON values per player for your game (signed-in players, 128 KB each). Keys starting with "server." are written only by your own server. Standalone, saves go to localStorage.
    • Leaderboards: declare them on your submission, then HopLobby.leaderboards.top(id, { around: "me" }) and submit(id, score). Boards can be "server"-only, so scores can’t be faked from a browser.
    • Achievements: declare them, unlock with HopLobby.achievements.unlock(id). HopLobby shows an "Achievement unlocked" toast and lists them on the player’s profile, with rarity.
    • Game keys (Authorization: Bearer hlk_…) for your own server: write protected saves, submit scores, unlock achievements and moderate leaderboards through /api/v1. Make and revoke them on the portal’s Keys page.
    • Analytics page on the portal: sessions, players, new vs returning, session length, finish rate, late joins, sales and errors per day.
    • Performance telemetry: load time, frame rate (median and slowest 10%), long tasks and memory from real players, by device and by build. HopLobby.init({ build: "1.4.2" }) labels your builds; init({ telemetry: false }) turns it off.
    • Dev Mode test setup takes your leaderboards and achievements too, and keeps Dev Mode data separate from your published game.
    • on("achievement") event, and the "forbidden" and "limit" error codes.
    Read the docs
  7. v1.1.1

    Store rules and terms now match HopLobby.store

    No code changes for your game: this release brings the content policy, the submission terms and the portal in line with the store that shipped in 1.1.0. Thanks to Dylan for spotting the mismatch.

    Added

    • Content policy: fair-selling rules. Your game must be fun and complete without buying anything, nothing bought may help a player beat others in multiplayer, and no countdown offers, nagging pop-ups or shop prompts in the middle of play. Real-money gambling and loot boxes are still not allowed.

    Changed

    • Content policy: "Don’t sell anything" is now "Sell only through HopLobby.store". Items on your submission are reviewed with your game, and nothing else in a game may take money.
    • Submission terms: store sales pay you 70% after tax and payment fees, shown on your Earnings page. Refunds and chargebacks come off your balance. This replaces "revenue sharing is not offered".
    • The submission checklist and the reviewers’ list now say "no outside payments" instead of "no payments".
    • Content policy: for chat, use HopLobby.chat (the lobby’s own chat, already filtered) instead of building your own.

    Fixed

    • The portal no longer says HopLobby hosts your game servers: you host your game, and HopLobby runs the lobbies, accounts and real-time relay.
    Read the docs
  8. v1.1.0

    Results, lobby options, server clock, state hand-over, chat and the in-game store

    The biggest SDK update so far. Everything is additive: games built on 1.0 keep working without changes. Check HopLobby.supports(feature) to use the new parts.

    Added

    • endGame({ title, entries }): the host sends placements, scores and labels, and HopLobby shows a results card in the lobby.
    • Lobby options: declare choices, toggles and ranges (on your submission, or in Dev Mode). The host sets them in the lobby and your game reads HopLobby.options.
    • HopLobby.now() (the server clock, the same for every player), HopLobby.latency and HopLobby.ping(playerId).
    • Late join and rejoin: syncState(() => state) on the host, and on("state") for players who join or reload mid-game. Opt in with lateJoin so people can join a running game.
    • on("join"), on("leave") and on("host") events, so you no longer have to compare player lists yourself.
    • HopLobby.device (touch, mobile, gamepad, screen size, reduced motion) and HopLobby.settings (volumes, mute, graphics level, sensitivity, invert Y, field of view, camera shake), with on("settings") when the player changes them.
    • Error reporting: uncaught errors and rejected promises in your game are sent to your portal’s Errors page. Send your own with reportError(error). Turn it off with init({ captureErrors: false }).
    • Lobby chat: HopLobby.chat.send(text), on("chat"), chat.open() and chat.button(false) if you draw your own chat.
    • HopLobby.store: sell items through HopLobby checkout (items(), owned(), purchase(id)). You get 70% after tax and payment fees. Your server can check purchases with GET /api/v1/entitlements.
    • HopLobby.release, HopLobby.supports(feature), and errors with a code (unsupported, sign_in_required, unavailable…) on every failed request.
    • Local simulator: npx hoplobby-dev in the SDK starter opens 2 to 8 players of your game in one tab, with no account or tunnel.
    • GET /api/v1/changelog and this changelog, also posted to #sdk-changelog on the HopLobby Discord.
    Read the docs
  9. v1.0.0

    HopLobby SDK 1.0

    Host your game anywhere and play it inside HopLobby: the lobby’s players, a message relay, HopLobby avatars and signed player tokens.

    Added

    • HopLobby.init(), players, host, progress() and ready().
    • send(data, to?) and on("message") over the HopLobby relay (16 KB per message, 60 a second).
    • avatar(): portraits, and rigged GLB characters with idle, walk, run, jump, fall, wave, cheer, shrug, sit and sit-table.
    • playerToken() and the public API: /api/v1/jwks, /api/v1/verify and /api/v1/games/:id.
    • Dev Mode test lobbies, including Share with friends for localhost builds.
    Read the docs