XCP Studio
Your workspace for Xbox prototypes.
Create, adapt, playtest and improve the same project.
XCP Studio brings Windows development tools and supported Xbox execution into one workspace for indie developers, creators and tool builders. Start from an idea or an existing source project, inspect what the target can support and keep iterating through Guided, Expert or agent workflows.
Studio can be built from the public source on Windows. New development packages still need independent Xbox revalidation.
Windows only — for now. XCP Studio is a native desktop application.
Project authority
One project. One source of truth.
Every interface works against the same authoritative project state. There is no privileged agent-only path, because a second authority would eventually disagree with the first.
The interface can change. The authority does not.
Portability
A Studio that stands on its own.
The Studio uses a self-contained, verified support environment. It does not depend on access to a development source tree to operate.
What portability means
A prepared Studio environment can be used independently of the private development environment.
Compatibility and integrity are checked before the lifecycle begins.
What the Studio provides
- Verified support environment
- Integrity checks before lifecycle work
- Native Windows file and folder selection
- A recent project library with explicit states
- Clear handling for available, missing and relocated projects
- Project relinking with preserved provenance
- No persistent authentication material
The Studio workflow has been validated in an independent environment. Public packaging and distribution remain a separate product step.
Create
Turn an idea into an editable prototype.
Create a project, shape its behaviour and prepare it for a supported Xbox run. Forge explores the procedural creation path using WorldLoop-generated material.
- Create project
- Edit
- Validate
- Build deterministic bundle
- Prepare complete lifecycle
- Receive structured correction
The same checked lifecycle is available to the Studio, command-line work and external agents, so the project remains consistent across interfaces.
Adapt
Explore an existing project on a new target.
Start with source you are authorized to use, assess its behaviour and adapt the supported parts into an editable XCP project. Preserved, changed and unsupported elements are made explicit throughout.
- External source
- Project assessment
- Compatibility review
- Controlled transformation
- Declared outcome
- XCP project
Supported source types are explicitly identified. An unrecognised project stops with a clear result rather than being force-fitted through an assumed conversion path. Coverage expands only when it is measured.
Why an explicit model matters
Adaptation needs an explicit view of the source project so that what is preserved, changed or unsupported can be declared honestly.
This keeps support decisions measurable and avoids claiming a generic converter for work that has not been tested.
Every element gets one disposition
- Preserved directly
- Translated
- Substituted
- Degraded
- Unsupported
- Requires human intervention
Work that cannot cross is named, never hidden inside a readiness score.
A real Godot 2 source project, taken at an exact public revision, was adapted and driven through the complete Xbox lifecycle: 14 of 14 operations and 5 of 5 semantic acceptance assertions, closing honestly as playable with declared degradation. Separate historical trials also established bounded playable reconstructions of Blokki, Minedot and Open RTS with physical-controller checks. These results describe their exact scenarios and declared substitutions. See the adaptation results and explore the public source.
Evolve
A new upstream revision does not discard your work.
A new source revision is assessed against the existing project and its declared decisions, so changes are carried forward explicitly rather than silently overwritten.
- Known version
- Later source revision
- Declared project decisions
- Compatibility review
- New project version
- Verified update and rollback
The result is a new version, not a mutation of the old one. The previous version stays installed and reachable, which is what makes the rollback exact rather than a rebuild that happens to look the same.
Playtest and observe
A verifiable lifecycle, each stage accountable.
Every stage exposes its state, its structured errors, the correction that followed, the evidence produced and the exact version identity it applied to.
- prepareAssess the project and the measured execution environment
- validateCheck that the project remains within its declared boundaries
- executeRun an identified project version on real hardware
- observeRead structured state and outcomes from the run
- correctConnect a correction to the evidence that required it
- restoreReturn to a known version when a change is rejected
Evidence view
Evidence is part of the execution path, not a report written afterward.
Runtime observations
Structured state, logs and counters read from the running project.
Captures
Deterministic frames associated with the measured run.
Receipts
What ran, against which project version, with what outcome.
Project identity
The identified project version the run came from.
Execution identity
The identified environment used for the run.
Evidence provenance
The public material that supports the stated claim.
Correction record
What failed, what changed in response and whether the change worked.
Acceptance results
Semantic assertions, passed or not, per run.
Rollback evidence
Proof that the previous version was restored exactly.
