Manual

Project Organization

This guide describes how to keep a Sendama project clean as it grows.

Recommended Folder Roles

Use the project root for configuration and entrypoints, and keep game content under Assets.

Recommended layout:

my-game/
├── sendama.json
├── preferences.json
├── game.php
├── config/
│   └── input.php
├── docs/
├── logs/
└── Assets/
    ├── Scenes/
    ├── Prefabs/
    ├── Scripts/
    ├── Events/
    ├── Textures/
    └── Maps/

Naming Conventions

Use names that explain intent instead of implementation detail.

Good examples:

  • Player
  • EnemySpawner
  • HudRoot
  • ScoreLabel
  • player-bullet.prefab.php
  • level01.scene.php

Less helpful examples:

  • Object1
  • Thing
  • TestPrefab2

Keep Scenes Thin

Scene files should mostly describe:

  • layout
  • hierarchy
  • prefab placement
  • tuned values

Put logic in scripts, not inline scene PHP, unless the scene file truly needs a small expression or constant reference.

Keep Prefabs Reusable

When an object appears more than once or may be spawned later, make it a prefab.

That keeps:

  • scene files smaller
  • runtime spawning consistent
  • serialized behavior settings centralized

Separate Authoring From Runtime Concerns

A healthy division is:

  • editor content in scenes, prefabs, textures, and maps
  • gameplay behavior in scripts
  • game startup and scene loading in the project entry file

This makes it much easier to replace or migrate tooling later without rewriting game logic.

Keep sendama.json Focused

Use sendama.json for project metadata and editor/runtime configuration such as:

  • name
  • description
  • version
  • main entry file
  • debug flags
  • editor active scene list
  • console refresh configuration

Avoid turning it into a general gameplay datastore.

Organize Scripts By Domain

As the game grows, group scripts by feature or role.

Examples:

  • Assets/Scripts/Player
  • Assets/Scripts/Weapon
  • Assets/Scripts/Level
  • Assets/Scripts/UI
  • Assets/Scripts/Enemy

This becomes especially important once prefabs start referencing many custom behaviors.

Store Examples And Docs Intentionally

This repository already contains engine, console, example games, and now a root docs set.

For an individual game project, it helps to keep:

  • gameplay-facing docs in the game's own docs/
  • design notes outside scene files
  • reusable art assets grouped by purpose

Suggested Team Workflow

  1. Use the editor for content authoring.
  2. Keep PHP scripts under source control with the rest of the project.
  3. Save scenes explicitly after hierarchy or inspector changes.
  4. Prefer prefabs for reusable gameplay objects.
  5. Review generated metadata when debugging unusual runtime behavior.

If you need exact command names, file formats, or engine class details next, jump to the API Reference.