Skip to main content

Introduction to Crafty

Crafty 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 Crafty 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, Crafty 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 Crafty SDK to handle all the complex platform features.

What Crafty Handles

The Crafty 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 Crafty 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:
  1. extends CraftyGame
  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 (Crafty.is_server())
  5. provide valid manifest.json and export/upload flow.

Templates Are Optional

Templates are examples, not requirements.
  • CraftyCharacter3D is the optional 3D character template path.
  • For 2D/RTS/card/turn-based games, extend CraftyPlayer directly and sync your own game model.
  1. CraftyGame and Crafty basics
  2. CraftyPlayer contract and set_synced
  3. subsystem modules you need (data, economy, teams, score)
  4. local test runner flow
  5. export/upload and banned API constraints.

API Sections

Crafty Singleton

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

CraftyGame

Required base class, lifecycle hooks, and practical game structure

CraftyPlayer

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 Crafty 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 CraftyPlayer 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 crafty_sdk version in manifest.json. SDK changes are intended to be additive and backward-compatible.