Creating Games on Summercraft

Introduction to Summercraft

Summercraft is a place where you can play games made by the community in Summer Engine. It’s a platform made to make it easy for developers to make and share their games without having to go through store experiences made +20 years ago. The Summer SDK works similar to Steams steamworks, and aims to make it more easy to build and share your games. Rather than forcing you into a rigid template or specific game type, Summercraft seamlessly integrates with your project to provide robust multiplayer infrastructure and backend services. The mental model is simple: you build your game’s unique design and systems, and plug in the Summer SDK to handle all the complex platform features.

What Summercraft Handles

The Summer SDK provides out-of-the-box support for:

Multiplayer Runtime: Server-authoritative networking and matchmaking infrastructure.
Player Management: Unified player identity and session handling.
Backend Services: Built-in APIs for data persistence and player economy.
Game Utilities: Ready-to-use helpers for score tracking, teams, and match state.
Publishing Pipeline: A streamlined submission, review, and deployment flow.

What You Build

Because Summercraft manages the heavy lifting on the backend, you’re free to focus purely on making a great game:

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:

extends SummerGame
implement lifecycle hooks (_game_init, _game_start, _game_end, _player_joined, _player_left)
use player synced state (set_synced / get_synced)
keep authority on server paths (Summer.is_server())
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.

API Sections

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 Summercraft 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

Two-process local workflow, multiplayer testing, and production-like validation loop

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.