Skip to main content

​
Add platform capabilities to your Summer game

The Summer SDK is the creator-facing platform contract for a Summer game. Your GDScript owns the gameplay, worlds, rules, and presentation. The SDK documents multiplayer, player, persistence, economy, and submission interfaces. An interface being documented does not mean its hosted runtime is production-live. Use only the capabilities your game needs. Templates are examples, not requirements.

​
Lifecycle

1. Build the game contract

Start from the minimal SummerGame lifecycle and manifest.

2. Add SDK capabilities

Select player, teams, score, persistence, economy, UI, and audio surfaces.

3. Test locally

Use Summer Engine first and validate before spending a publish request.

4. Export

Produce a game-only pack and verify its digest and contents.

5. Submit for review

Choose the API or browser path and follow the human review state.

6. Update

Keep the game identity stable, bump the version, retest, and resubmit.

​
What is available now

  • Create a Summer game record.
  • Upload a game-only .pck directly to storage with server-side checksum verification.
  • Enter the manual human review queue.
  • Download releases through the authenticated release endpoint.

​
What remains a contract or planned capability

  • Summer SDK lifecycle, player, sync, persistence, economy, teams, score, UI, and audio interfaces are a creator contract under implementation.
  • Player-facing browser and desktop-shell playback is not live.
  • Hosted dedicated game servers and automatic matchmaking are not live.
  • The automated production runtime sandbox is not live.
  • SummerMultiplayerPeer is a published compatibility contract still being built.
See Product source & platform status for the single canonical status table. Do not infer deployment status from an SDK reference page or example.

​
What You Build

Your game remains responsible for its creative and gameplay layer:
  • Core Gameplay: Your unique mechanics, controls, and game loops.
  • Worlds & Scenes: Environments, levels, and visual rendering.
  • Rules & Logic: Win/loss conditions and genre-specific systems (whether that’s 3D, 2D, RTS, card, or puzzle games).
  • Presentation: UI, audio, and overall game feel.

​
Platform Contract

The minimum integration contract:
  1. extends SummerGame
  2. implement lifecycle hooks (_game_init, _game_start, _game_end, _player_joined, _player_left)
  3. use player synced state (set_synced / get_synced)
  4. keep authority on server paths (Summer.is_server())
  5. provide valid manifest.json and export/upload flow.

​
Templates Are Optional

Templates are examples, not requirements.
  • SummerCharacter3D is the optional 3D character template path.
  • For 2D/RTS/card/turn-based games, extend SummerPlayer directly and sync your own game model.

​
Capability and reference pages

Agent Setup

Point any AI coding agent at one prompt: build, export, and submit through the live API

Summer SDK Naming

Migrating from Crafty: every renamed class, autoload, manifest key, and path

Summer Singleton

Match control, player queries, spawning, server/client checks, subsystem access

SummerGame

Required base class, lifecycle hooks, and practical game structure

SummerPlayer

Minimal player contract: identity, synced vars, input, and optional 3D template path

Subsystems & Signals

Optional platform modules: teams, score, data, economy, UI, audio, and signals

Build Your First Summer Game

Golden-path tutorial from blank project to .pck submission

Multiplayer FFA Guide

Full Coin Collector-style example with timer, collectibles, and scoring

Multiplayer Persistence Guide

RPG/quest example with player saves, progression, and economy

Team-Based Game Guide

Teams, auto-balance, team spawns, and team scoring

2D Multiplayer Guide

Extend SummerPlayer for 2D state sync and server-authoritative logic

Turn-Based/Card Guide

Sync turn order, hand/board state, and validate all actions on server

manifest.json Reference

Every field, required keys, and validated examples

Production Launch Runbook

One linear path for fresh AI/dev sessions: integrate, test, export, submit

Submission Guide

Export .pck, scanner rules, upload flow, review lifecycle, and updates

Testing Your Game Locally

Summer Engine smoke checks, optional loopback testing, and the limits of local validation

Exporting and Uploading Your Game

Game-only PCK export preset, upload pipeline, and update workflow

Banned APIs Reference

Complete blocked pattern list, rationale, and safe alternatives

AI Agent Playbook

Required file contract, banned API rules, and acceptance checklist for AI-generated games

​
Versioning

Games declare a summer_sdk version in manifest.json. SDK changes are intended to be additive and backward-compatible.

Previous: Build your first Summer game

Return to the minimal GDScript and manifest contract.

Next: Test locally

Validate the Summer game with Summer Engine before export.