Playtesting and Debugging

This guide explains how to validate your game while keeping the editor in the loop.

Two Complementary Modes

Sendama development works best with both:

• the editor for authoring and inspection
• the runtime for real play sessions

Do not treat them as interchangeable. Each is strongest at different things.

Using The Editor's Play State

Press Shift+5 to toggle the editor into play state.

This does a few useful things:

• focuses the Main panel
• switches to the Game tab
• puts the editor into its play-oriented visual state
• auto-refreshes the Console panel

This is useful when you want live log feedback without leaving the editor.

Running The Full Game

For actual gameplay validation, run:

sendama play

Or:

sendama play --directory /path/to/project

Use this when you need to verify:

• input responsiveness
• scene flow
• timings and pacing
• pooling behavior
• collisions and triggers
• title screens and menus

Console Panel Reference

The console reads from:

• logs/debug.log
• logs/error.log

Tabs:

• Debug
• Error

Useful console controls:

• Tab: next tab
• Shift+Tab: previous tab
• Up / Down: scroll when not in play state
• Shift+R: refresh manually
• Shift+F: change the active log filter
• Shift+C: rotate and clear the active log

A Good Debug Loop

For day-to-day work, this loop is reliable:

1. Make a content or code change.
2. Press Ctrl+S if the scene changed.
3. Run sendama play.
4. Keep the editor open beside the game.
5. Watch the console panel and inspect objects or prefabs as needed.
6. Repeat.

What To Log

Use logging to make state visible while features are still moving.

Good logging targets include:

• active scene loads
• spawn and despawn events
• pool indexes
• input actions
• collision contacts
• score and health transitions

Do not leave noisy logs in hot loops forever. Keep the logs intentional enough that the console stays readable.

Practical Debugging Tips

• If something visible is missing, check the object's renderer path, crop rectangle, active state, and parent hierarchy.
• If collisions feel wrong, confirm the object has a collider-capable component and a valid sprite rectangle.
• If a serialized field behaves oddly, inspect the prefab or scene metadata and confirm the value is stored in the expected shape.
• If asset renames seem correct in memory but break after restart, save the scene before leaving the editor.

When To Leave The Editor

Leave the editor and inspect the source files directly when you need to:

• repair invalid metadata quickly
• resolve namespace or autoloading issues
• compare generated output with the runtime expectations
• make wider code changes across scripts or engine classes

For long-term maintainability, pair this guide with Project Organization.