summer-engine 4.5.0

4.4.0 was not published to npm. 4.5.0 is the first release with everything in it (the [4.4.0] section below), plus these changes.

New since the first 4.5.0 cut: privacy-safe telemetry v2 with a one-time notice, videos (MP4, MOV, WebM) that convert to .ogv on import, and a game that goes from export to live over MCP with no staff wait.

• The launch-ready skill: get a game ready to launch and take it live. Where release-checklist reports what is missing, launch-ready makes it pass: it exports and uploads the build, captures real gameplay screenshots with summer_capture_gameplay, makes the key art, icons, tall cover and capsules from a real capture under the store-art rules, writes the store text and fills every listing detail from the project (GameSoul, project memory, README, what it saw in play), runs the checklist again until it passes, shows the creator the preview link, every image and all text, and goes live with summer_go_live after one yes. It asks the creator once, before anything is uploaded or spent, for what the project can't tell (price, support contact, developer name, release stage), and has the creator confirm the content rating, the content questionnaire and the AI disclosure. It never invents a fact, never edits a screenshot and picks only true tags, genres and features. Library-only, because the installed-description budget is full: release-checklist, publish-your-game and /summer point to it. It uses only operations the engine profile already has, so the tool count does not change.

• Telemetry: a few more fields and a one-time notice. Every field is listed in the README section "Telemetry". Summer never sends prompts, code, file contents, file names or paths, project names, tool arguments or results. SUMMER_NO_TELEMETRY=1 or DO_NOT_TRACK=1 turns all of it off.

  • First run: the first summer command on a computer (summer mcp too) prints a one-time notice to stderr and sends one anonymous cli_first_run line: a random install id, the command name, the agent app and the operating system. Not in CI. Signing in joins that line to the account.
  • New fields on signed-in tool-call and command lines, when they apply: projectIdHash (the hash of the random project id the engine already uses for routing; never the project name or path), templateId (the catalog template the project started from; on summer create also its library domains), instanceCount (how many game clients engine.play started) and engineState (four yes/no facts on engine_not_running: engine installed, engine running, project open, signed in).

• Videos import as Ogg Theora by themselves. Summer Engine plays video only as .ogv, and an .mp4, .mov or .webm import used to fail and roll back. summer_import_from_url, its batch, summer_import_asset_by_id and summer_import_asset now convert a video on the way in: a video Summer generated or stores imports as its Theora rendition from Summer's media host; any other video converts with ffmpeg on this computer when it has Theora (video quality 8, Vorbis audio, same frame rate, at most 1920x1080), else on summerengine.com (needs the Summer sign-in). The .ogv lands at the requested path with the extension swapped, and the answer says so (videoConversions, note). A generated video saved with out into a Godot project saves as .ogv too. The animated-loop, cinematic-cutscene and trailer-shot skills no longer tell agents to run ffmpeg by hand.

• From export to live over MCP, with no staff wait. A game goes live as soon as Summer's automated checks pass; Summer's staff review it afterwards, and no tool or skill tells a creator to wait for a review any more.

  • summer_go_live (store.go_live, summer store go-live): releases the uploaded Build to every platform that passed its checks and publishes the store page, through the same store routes Studio uses, then watches until players get it. It needs no owner approval link while the person's Agent permissions allow Publish (the default; otherwise needs_permission). Confirm-gated. It answers live, blocked (each failure with its fix), needs_changes (Summer's feedback) or waiting; a hold on Summer's side is reported as Summer's, with nothing to fix. Calling again continues without asking twice.
  • summer_store_set_details (store.set_details): the store page sections store.update_listing does not edit: the content questionnaire, the AI disclosure, genres, features, credits, language support and system requirements.
  • summer_publish_build waits for Summer's automated checks and reports each platform (checks: passed, or failed with code, owner and fix). A running malware scan is a wait, not a failure. Intake refusals the platform names (engine_build_unreleased, malware_detected, verifying_failed and others) come back with a fix.
  • summer.bundle.v2 exports are read. summer_export_game and summer_publish_build refused every export from Summer Engine 0.7.4 and newer (the fixed layout); they now take v2 with its six paths and still take v1. summer_export_game reports the export's paths.
  • The release-checklist skill: before going live, check the export (preset, Summer version, the fixed layout, a server pack for a game with a server), the upload and its checks, the store art per slot and every required listing field, each rule with its MCP check, its fix and the platform rule it comes from.
  • The engine profile leaves out the hosted summer_store_releases and summer_store_version_status, which summer_go_live supersedes, so the two new tools fit its tool limit.

From adding Summer to an agent to editing a good-looking scene with one OK: summer dev installs the engine (with the person's yes), creates a starter project and opens it; the MCP opens the project itself; agents with no shell use projects.create_local and projects.open_local; Claude Code Desktop's Browser pane shows the game; and summer preview serves the running game to the agent's own browser.

• painted-25d-world plug-in characters are public: SummerEngine/painted-characters (man, woman, man with a sword, old man; 8 directions; idle, walk, run), pinned in the skill with raw-URL imports.
• painted-25d-world: a 1.8 m/s default walk, and a walk clip whose stride fits it. Cozy, exploration and RPG games walk at about 1.8 m/s and run on Shift at about 4 m/s. The walk cycle's playback stays within about 1.5x its natural speed: when a clip's natural walk is too slow, regenerate it with the brisk long-stride prompt (now the skill's walk prompt, word for word) instead of over-speeding a short-step clip. Stride examples updated to the plug-in sheets (walk 0.94 m per cycle at 1.8 m).
• painted-25d-world after a blind test run and a gait rule.
  • A first-time agent built a harbour from the skill alone. Its findings are in:
    • a project step;
    • seedream-5-pro at 2048x1152 (no Summer image model returns 4K), plus a tiled 4K detail pass;
    • idempotencyKey and numImages: 1 on every generation;
    • a lit blockout capture, and the player set up in capture mode;
    • no CSG;
    • the .tscn paint camera line;
    • two-part gable roofs;
    • water blockers and two-sided ground;
    • a 14 m room frame;
    • the upload fields;
    • the plug-in character paths.
  • New building blocks: blockout_builder.gd (a JSON blockout spec), paintcam_check.gd, and tools/ (cam.py pixel-to-ground, preview.py wireframe over the concept, overlay.py alignment check, detail4k.py tiled 4K pass).
  • Gait: cozy, exploration and RPG games walk by default (about 2 m/s, walk cycle) and run on Shift (about 4 m/s, run cycle). Action games may run by default. Playback stays speed / natural speed.
• summer dev shows the game in Claude Code Desktop's Browser pane. It adds the summer-preview entry to .claude/launch.json in the folder it runs in (only adds; never in the home folder; cwd set when the project sits below that folder; --no-launch-json skips it), so Desktop starts summer preview and checks the game after each edit. The Connected: line ends with the preview URL (http://localhost:5199) and, outside Desktop, npx -y summer-engine@latest preview --open. projects.open_local does the same for the folder the agent session runs in and answers preview.url.
• Launches and installs, follow-ups from review. An editor that exits cleanly (code 0) before its API answers is followed when a new editor takes the project over within 5 s (it restarted itself); otherwise it is reported as closed early, never as a broken install. A stale install lock is taken over by one waiter only (an atomic rename, checked). A second projects.create_local with no name makes my-game-2, my-game-3, ... instead of returning the first game.
• summer dev [template] [dir]: from nothing to an editor your agent can drive, in one command. npx -y summer-engine@latest dev installs Summer Engine when it is missing (only with --yes or the person's yes at a terminal; an agent without --yes gets needs_confirmation and the question to ask), creates a starter project (the built-in 3d-basic unless you name a template) in the project this folder is in, else in this folder when it is empty or only has dotfiles (never the home folder or a filesystem root), else in ./my-game, opens it in the background with summer run's launch and waits up to 3 minutes for the editor's local API, with a progress line every 10 s. It ends with one Connected: line naming the project and the next step. A folder that already holds project.godot is just opened, so running it again is safe.
• The MCP opens the project itself. When a tool needs the engine and no editor runs, the engine is installed and the session has a project (the agent's folder or --project), the local MCP launches it in the background, waits and retries; a slow first open answers "call again in 30 seconds". It never starts a second editor while one is registered for the project, was launched on it and still runs, or does not answer (busy); an editor that exits at once ends the wait, and Linux with no display answers at once. When the agent's folder has no project, it uses the project the last summer dev opened from that folder (or below it) while that editor runs, for up to 10 minutes. Otherwise engine_not_running names the one step for the case: not installed, ask the person first, then npx -y summer-engine@latest dev --yes; no project, summer dev; another project open, that project. SUMMER_AUTO_LAUNCH=0 turns the launch off. The engine-free note names the 4.x tools (summer_docs_search, summer_assets_generate_*, summer_jobs_get, ...).
• New local operations projects.create_local and projects.open_local: summer dev for agents with no shell (Claude Desktop, chat apps). summer_projects_create_local writes a project from a template (3d-basic by default) to dir, or to <name> next to the session's project, in the session's folder (one of the person's own inside home), or in ~/Documents/Summer (a chat app's server starts in an app folder); never inside another project. A folder that already holds project.godot is left as it is, and a slow template download answers "still creating, call again". summer_projects_open_local opens a project in Summer Engine in the background, waits until it connects and binds the session to it; a missing engine is installed only with install: true, after the person's yes, and a long install or first open answers "call again in 30 seconds". Both are listed on the v4 surface in the full profile (new toolset projects; the capped engine profile reaches them through summer_call), and run from a shell as summer projects create-local / open-local. engine_not_running now names them next to summer dev.
• 3d-basic looks like a game: a procedural sky on a real Environment (ACES tonemapping, ambient light and reflections from the sky), a sun with soft shadows, a tinted ground and one lit hero the camera frames. Before, the sky material was never attached and the scene was a grey box.
• Pinned templates download without git. summer create (and summer dev) fetch the pinned commit's GitHub tarball, compute the same tree digest from the archive and refuse a mismatch, then fall back to git only when the tarball path fails. On a Mac without the Command Line Tools this no longer opens their install dialog.
• summer install names why it failed: release_info, download, checksum, disk_space, mount, copy, permission, app_running, needs_confirmation, installer or unsupported_platform, in the message (with one next step) and in the usage line, instead of exit_1. A busy DMG detach no longer fails a finished install, one install runs at a time (~/.summer/install.lock, shared by summer install, summer dev --yes and projects.open_local), a non-admin Mac installs to ~/Applications, a running engine is never replaced, free space is checked before the download, and the size printed is the real one.
• Sign-in is off the build path. The README first run, /summer:start and the setup prompt build without signing in (engine tools never needed it) and sign in only when a cloud operation answers not_signed_in. /summer:start asks one question ("I'll install Summer Engine (about 660 MB, free) if needed and open a starter project in <folder>. OK?") and runs summer dev.
• summer engine <action> takes 3.x names (summer engine summer_get_scene_tree, camera-bookmark, search_library) and a miss names the closest actions as commands.
• painted-25d-world: hard rules from a playtest of the detailed run. Hero scale from door height (2.5 m doors, 2.15 m hero), speeds from each sheet's natural cycle speeds (move on the jog cycle at about 4.2 m/s, Shift sprint up to 1.8x natural, Alt stroll on the walk cycle, never a walk above 1.5x natural) with speed_scale = speed / natural so the feet do not slide, a 16 m outdoor view clamped with the real viewport aspect and the painting's edge colour as the clear colour, rooms framed whole, at least one enterable building per village (cut-away room, own paint-over, doors both ways), eight facings by 45 degree sectors (mirroring only where every frame holds up), dormers on the roof slope and door/step slabs hidden in game, contact shadows only in the paint, and a --shots=<dir> run that walks the hero through the level and saves frames from the real window. New building blocks: painted_location.gd (one painted frame) and painted_door.gd; painted_world.gd now manages locations, doors and shots; painted_player.gd does eight facings, jog, sprint and stroll at natural-speed-matched animation speed.
• The summer-cli skill teaches summer preview, so agents use it: run it in the background from the session's folder to watch the game in their own browser (Claude Code Desktop's Browser pane, the Codex app's in-app browser), with Refresh for a game frame now and keys and clicks going to the running game.
• summer preview: the running game in the agent's own browser. A local page at http://127.0.0.1:5199 shows the running game, or the editor viewport when no game runs, with the project and scene and a status line that says what to do ("Editor not running: run npx -y summer-engine@latest dev"). It shows only the editor of the project it was started for. It adds a summer-preview entry to .claude/launch.json in the folder it runs in, so Claude Code Desktop's Browser pane starts it and checks the game after each edit, the way it checks a web app; other entries, settings and the file's indentation stay as they are. The Codex app can open the same URL in its in-app browser. The pace follows the measured capture time: the editor up to 5 frames a second while it changes and 2 when it does not; a game frame about every 20 s, since reading one stalls the game, and a fresh one on load, on Refresh or with ?fresh=1. A hidden tab costs nothing. Keys and clicks on the frame reach the running game, and key releases always do. The page is loopback only, makes no outside request, holds no token, and its API refuses requests from other sites. viewportSnapshot and gameSnapshot take {saveFile: false} so the preview never writes frames to the temp folder.
• summer_game_input names the right arrow key code: 4194321 (it said 4194320, which is the up arrow).
• painted-25d-world updated from the second, detailed lab run.
  • The paint-over no longer passes the whole concept: frontier edit models copied it even over a one-to-one blockout. It passes a 2x2 sheet of material close-ups cropped from the concept, marked style-only, and adds a colour key to the prompt.
  • New rule: paint richness follows blockout density (low blocks for flower beds, crates, barrels, benches, window boxes).
  • The camera is 30 degrees down, the dimetric angle image models draw as "isometric". The skill shows how to read footprints off the concept by inverting the orthographic camera.
  • The follow camera clamps with the real viewport aspect (the editor's game view is not 16:9).
  • A 4K painting over a 40 m frame stays sharp at a 2x zoom.
• painted-25d-world: painted_player.gd reads an fps dictionary by kind ({"idle": 6, "walk": 10, "run": 14}) as well as by row or one number, so the painted plug-in character sheets (idle, walk and run in four directions) drop in unchanged.
• New skill painted-25d-world: 2D and 2.5D games as a painted world. Build the level from cheap blocks under one fixed orthographic camera (35 degrees down, 45 around), render the blockout, have an image model paint over it strictly image to image, then project the painting back onto the blocks with a shader (paint_projection.gdshader: UV from the paint camera's frame, unshaded). The game camera keeps that direction and only translates; characters are sprite sheets on Y-billboards. Covers concept, one-to-one blockout, the paint-over prompt and alignment check, the 4K rule, interiors as cut-away rooms, characters (turnaround, in-place clips, sheet), weapons and side-scrollers. Building blocks: the shader, painted_world.gd, painted_player.gd, capture_paint_view.gd and an optional Blender route. Library-only (the installed-description budget is full); make-game and new-project now route every 2D or 2.5D request to it instead of a Node2D root or a 2D template.
• The MCP says agents may open the editor and play the game in a window. The server instructions (v4 and 3.x), the agent playbook and the summer_play, summer_screenshot and summer_frame_shot texts say it is allowed and expected: play, then look with a screenshot or frame shot, close what you opened, one editor at a time. headless-scripting now scopes its --headless rule to engine processes started from a shell, and navigate-summer no longer reads as "do not open the editor". No behavior changes.

[4.4.0] - 2026-10-18

Not published to npm: these changes ship in 4.5.0.

The store skills say how an item really becomes buyable and name items by slug, area commands answer --help, and summer content make follows the live make-request ops.

• summer-store says how an item becomes buyable today. After the owner approves a sync plan, Summer reviews each item, then the owner activates each approved item in Studio (Review activation), and players can buy it only while the Game is live: it stops while the Game is unlisted and sells again when it is listed. Editing a live item makes a new revision, reviewed and activated again, while the live one keeps selling. It notes the coming change (items go on sale without waiting for Summer's review; staff review afterwards and can take one down) without claiming it has shipped. Slugs: the platform sends StoreItem.slug and InventoryItem.definition_slug since 2026-10-16; the in-game getters come with the next Summer Engine release that carries them (0.7.4, in progress). Staging: a separate sign-in and Games, and sandbox Sparks from test payments.

• in-game-purchases names items by slug (has_owned_slug, get_slug) instead of hard-coded item_sword definition ids, which differ between staging and production, and sends the rest of the store to summer-store.

• --help works on area commands. summer economy sync-items --help prints the command's fields as flags, what it does, who approves and the sign-in it needs (it answered "help: not a field of this operation"), and summer economy --help lists the area's actions. Both work signed out and offline.

• ops describe says which local operations need a sign-in. economy.sync_items, store.upload_file, apps.publish_folder and content.make answer auth: account (they said none); sync and upload need the store sign-in, summer login or summer login --store.

• Store tool texts name 4.x operations. The summer_sync_items and summer_publish_build descriptions and the upload, export and sync recovery steps say games.list, games.create, store.publish, store.update_listing, store.set_art and assets.upload_begin instead of the 3.x summer_store_* tools.

• summer_sync_items blocks a Passport collectible with the same slug instead of planning an update to it; Passport items are never synced.

• The shipped operation catalog matches PublicSummerEngine main again: the content area's make-request ops (content.make, content.claim_make, content.get_make, content.update_make, content.today, content.skip, content.delete_learning) and the current inputs of nine more, and store.upload_begin's targetPlatforms text.

• summer content make follows the live make-request ops (PublicSummerEngine #1151). It opens its own request with content.make {contentGameId, referenceId, note, footage} and claims it by requestId. claim takes the named request (requestId), else the team's oldest open one. Stages report as pick, study, footage, plan, voice, render, checks, compare and upload, with state running, done or failed, a plain message, and on failure the one missing thing; done on upload carries the piece. note replaces brief, and key, source and worker are gone, matching the hosted op's input. Before this, --claim always answered nothing_queued and the stage reports were refused.

• summer content make (content.make, MCP summer_content_make): one finished piece of content for a game, made on this computer and saved to the team's Review. It picks the reference from Summer's library that fits today (a format the game has not posted, what changed in the repo's recent commits, its breakout), studies it (hard cuts, finer cuts for card and page flips, black beats, its caption look), measures the footage folders (motion and brightness per half second, notes from shots.json or <clip>.json), maps each reference shot to a clip window with motion (one lead clip moving forward in time; no repeats on fast cuts; no frozen stretches, black screens or white flashes), cuts to the reference's timings, draws captions in its style with ImageMagick (held, per beat, or word by word from a voice-over's Whisper word times), starts a song where the most cuts land on its accents, mixes at -14 LUFS, then checks the hook, motion per shot, safe zones, length, loudness and gameplay seconds, swaps still shots for moving ones, renders the reference side by side (synced on every beat, our sound only) with a contact sheet, uploads everything and saves the piece (a draft when the hook, motion or safe-zone check fails). It never writes words: the first call answers needs_words with the beats; the caller sends our lines. A reference that speaks also needs voiceFile, the lines in the team's own voice (needs_voice). Every stage keeps its record in the work folder, so the same workDir continues where a run stopped, and each file is uploaded once. It runs directly (its own make request, keyed by HEAD and reference, or key) or with claim takes the oldest queued make request (the daily scheduler's, a Change pressed on Today: needs_changes with what the team asked, then content.update_piece), and reports every stage to Today through content.update_make (picking_reference ... saving; cannot_make names the one missing thing). content.save_piece gets why (the reference, one line on why it fits today with the commit it saw, the reference's numbers), checks with measured values (hook_time, lowest_motion, safe_zones, loudness, length, gameplay_seconds), sideBySideItemId, contactSheetItemId, learningIds (the kit learnings the caller applied, listed in needs_words), makeId and tomorrow (the next best reference). A reference's study is kept on this computer and reused by every piece that copies it. Needs ffmpeg and ImageMagick; yt-dlp fetches a reference video that is not cached; Whisper only for a voice-over.

• The shipped operation catalog matches PublicSummerEngine main again. registry/operations/public-catalog.json now lists store.set_bundles, store.set_sales, economy.propose_items and the content area, so summer ops search and ops describe find them signed out. legacy-names.json maps summer_store_set_bundles and summer_store_set_sales to them, and summer-store's "From a shell" table lists summer store set-bundles and summer store set-sales. content make-video --dry-run replaces the deprecated marketing make-video --dry-run in the commands an agent may run without asking.

• Search: a query that is an operation's title, word for word, puts that operation first. "list my games" finds games.list ("List my games") before the content area's content.list_games ("List the team's games"): the phrase bonus doubles when the query is the whole title.

• summer-store describes how creators set bundles and sales. Studio's store page now has Bundles and Sales cards and a "Sold only in bundles" toggle (PublicSummerEngine #1086, live on summerengine.com), so the skill walks through them instead of saying Studio cannot set them yet. It adds the agent path, store.set_bundles and store.set_sales: each replaces the whole list, store.get_listing returns itemStore with the totals, Save %, sale prices and the Game's Items, and a refusal names the field. Saving never publishes; players see them after the owner publishes the store page.

• summer-store knows the store that shipped on 2026-10-16. Game code names items by slug (Studio's "Item key"), which is the same in staging and production, with definition ids as the fallback. The skill says plainly that the slug getters need a Summer version newer than 0.7.3, and that hosted reads return "" until slugs are delivered; it shows how to check both. It replaces "code never creates items" with the real rule: game code never creates items at runtime, and creators define them in Studio or through summer.items.json and summer_sync_items (dry-run plan, then the owner's approval, at most 50 items per approval, an image for every new item, staging and production through the gateway settings and summer login --store --force). It also covers unique items, maxOwned and the already_owned refusal ("Owned" instead of Buy); bundles with "Save N%", the lower price for players who already own some of a bundle's items, timed sales, "This offer ended" and bundle-only items, including what an in-game shop sees of them; and Local Play slugs through catalog_item_slugs.

• New skill: make-content. Ask your agent for content for your game and it makes a finished, postable video: it picks one real reference video from the reference library and copies it beat for beat with your game (same cuts, text pattern and voice structure), captures real gameplay, cuts one version per platform (TikTok, Reels, Shorts, X, YouTube), checks it side by side with the reference and with a fresh critic, and saves it to the team's Today view with content.save_piece, with why it fits and its measured checks. It follows every Change note and Skip reason the team left (the kit's learnings) without being told.