Skip to main content

​
Use This When You Need A Reliable End-To-End Path

This page is the shortest safe route from “new game” to “submitted for review.”

​
Current Publishing Checklist (Most Important)

  • Build your creator gameplay scripts in GDScript for the current Summercraft publishing flow.
  • Recommended release API: submit a game-only .pck containing manifest.json; size must be 1 KiB–512 MiB.
  • Browser submission: upload the .pck and a separate manifest.json; the browser path accepts up to 2 GB and runs the static scanner at upload time.
  • Choose one path before exporting. A 2 GB browser limit does not raise the release API’s 512 MiB limit.

​
Step 1: Validate Project Contract

  • main.gd extends SummerGame.
  • manifest.json includes required keys.
  • player_scene points to a valid scene.
  • gameplay scripts are authored in GDScript.
  • choose player model:
    • SummerCharacter3D (3D template), or
    • custom script extending SummerPlayer.

​
Step 2: Validate Authority Boundaries

  • gameplay outcomes run under if not Summer.is_server(): return.
  • clients render synced state (get_synced) only.
  • no score/economy/data writes on client paths.

​
Step 3: Validate Scanner Safety

  • no blocked APIs in scripts/resources.
  • no reserved infrastructure paths in export scope.
  • no blocked binary/native resource extensions in pack.
Reference:

​
Step 4: Local Runtime Validation

Run the canonical Summer Engine smoke checks. If the starter project includes the optional loopback runner, run that separately and confirm:
  • local server starts + local client connects,
  • player join/leave stable,
  • gameplay loop runs for 10+ minutes,
  • reconnect path works.
This is local loopback validation only. It does not prove production ticket redemption, platform hosting, matchmaking, or the runtime sandbox. Reference:

​
Step 5: Export Validation

  • use game-only .pck preset.
  • update include filter to game folder.
  • confirm exported .pck includes only intended content.
  • for the recommended release API, confirm package size is 1 KiB–512 MiB and that manifest.json is inside the pack;
  • for browser submission, confirm the .pck is at most 2 GB and keep the matching manifest.json as the second upload;
  • if neither path fits, contact founders@summerengine.com before spending a submission attempt.
Reference:

​
Step 6: Submission Validation

Choose one submission path:
  • Release API: create game → mint upload URL → PUT .pck → finalize; expect pending_review.
  • Browser: upload .pck + separate manifest.json; expect status review, a submission id, and no static-analysis violations.
Neither path makes the game playable. Follow the canonical platform capability status. Reference:

​
Top 10 Failure Modes (And Fixes)

  1. entry_scene invalid
    • Fix manifest.json path and re-export.
  2. player_scene invalid
    • Fix scene path, confirm script setup, re-export.
  3. Client-authoritative logic
    • Move outcome logic to server path.
  4. Missing synced fields
    • Use set_synced for client-visible state.
  5. Scanner blocked pattern
    • Remove blocked API usage.
  6. Reserved path in pack
    • Correct include/exclude export filters.
  7. File too large
    • Optimize assets and remove unused files.
  8. Manifest type mismatch
    • Enforce required key types.
  9. Template mismatch
    • 3D helper methods used without SummerCharacter3D.
  10. Reconnect instability
    • Reinitialize player synced state on join.

​
Launch Ready Criteria

  • Contract checks pass
  • Authority checks pass
  • Scanner checks pass
  • Local runtime checks pass
  • Export checks pass
  • Submission accepted into review
If all are true, the build is ready for production review launch.