XCP — Chapter 5
In the previous chapters, I wrote about turning an Xbox Series X into a programmable execution target, building a virtual machine inside its sandbox, connecting AI coding agents to real hardware, and measuring the memory and GPU capabilities available in Developer Mode.
Those articles explained individual parts of XCP. This final chapter is about what they were all leading toward.
The goal was never simply to run AI-generated code on an Xbox. The goal was to build a development platform around the console, one that independent developers could eventually extend with familiar tools, engines and frameworks.
That distinction matters because XCP now contains considerably more than the compute worker that started the experiment.
It includes a programmable runtime, a desktop development environment, an execution and evidence system, Godot adaptation research, a native graphics pipeline and procedural worlds generated from WorldLoop.
Each of those components grew out of a practical experiment. Together, they suggest a different way of approaching console development.
From hardware research to a development platform
The first question was relatively simple: how much useful computation could we perform on an Xbox Series X without bypassing its security model?
XCP began inside the supported Developer Mode application sandbox. We explored memory allocation, persistent storage, CPU execution, GPU compute, graphics rendering and communication with a development PC.
Those experiments produced measurable results, including a 5 GiB application memory budget in one tested configuration and more than 7.7 TFLOP/s in a bounded FP32 shader workload. We also built XVM, a verifiable execution environment capable of running admitted programs and returning structured execution evidence.
But the more interesting possibility emerged after those foundations were working.
We already had a console that could receive structured work, execute it, report its state and preserve a history of what happened. The next logical step was to use that infrastructure for complete software projects rather than isolated compute workloads.
That decision changed XCP from a hardware research project into a creative-platform project.
Three Godot games, three different problems
One of the most important parts of the original XCP research was adapting existing Godot projects into bounded, playable experiences on the Xbox.
Rather than using a single demonstration designed specifically for the platform, we worked with three substantially different games.
Blokki — a 2D puzzle
Blokki gave us a compact starting point for testing scene interpretation, grid interaction, controller input and gameplay feedback.
The adaptation translated pointer-based interactions into a controller-driven grid, replaced some presentation elements with procedural drawing and preserved a bounded playable puzzle loop.
The Xbox playability checks covered rendering, controller response, valid and invalid action feedback, and the usability of the interaction loop.
Minedot — a 3D voxel-style sandbox
Minedot introduced a different class of problems: a 3D environment, camera navigation, spatial interaction and mining or placing blocks.
Its playable reconstruction used the left stick for movement, the right stick for looking around and bounded controller actions for interacting with the world.
Some source dependencies were incomplete, so the Xbox implementation used declared substitutions rather than pretending that the original game had been reproduced completely.
The resulting bounded experience was tested on physical hardware, including movement, camera control, interaction feedback and visual usability.
Open RTS — a more complex 3D strategy game
Open RTS pushed the experiment further.
This time the adaptation involved a strategy environment with unit selection, movement, combat, interface visibility and a victory condition.
The first physical test exposed presentation problems. Rather than simply accepting a successful launch, we corrected the interface behavior and performed another test.
The revised version passed its bounded playability checks, including selection, movement, combat and victory feedback.
Across these three projects, the research recorded 3/3 bounded playable reconstructions, 15/15 human playability checks and 17 captures.
These results do not establish full source equivalence or universal Godot compatibility. The reconstructions used explicit substitutions, and additional work remains before an arbitrary Godot project can pass through the system without project-specific adaptation.
What they do establish is that the approach was exercised across a 2D puzzle, a voxel-style 3D sandbox and a more complex 3D strategy game on real Xbox hardware.
That is a useful foundation for developing reusable engine adapters instead of continuing to create isolated ports.
Forge: when WorldLoop met Xbox
Godot adaptation was not the only creative experiment.
Another branch of the original research connected XCP with WorldLoop, my procedural CAD and world-generation project.
WorldLoop was originally developed around procedural construction and scene generation. Buildings, structural relationships and larger environments could be generated from structured rules rather than manually assembled one object at a time.
I wanted to see whether that same approach could produce content for a completely different execution environment.
This led to Forge Protocol, a native Xbox graphics and gameplay experiment using Direct3D 11.
The important architectural decision was to keep generation on the development PC. WorldLoop produced structured environments, which were then compiled into bounded native assets that the Xbox application could load and render.
The console did not need to run the original generator or its development dependencies.
The pipeline was approximately:
WorldLoop procedural generation
|
v
Structured world + geometry
|
v
PC-side asset compilation
|
v
Forge scene bundle
|
v
Xbox native D3D11 runtime
|
v
Rendering + gameplay
The experiments progressed beyond simple geometry.
Orbital Forge Alpha demonstrated a WorldLoop-generated scene on Xbox, while Orbital Forge Beta expanded the environment into thousands of render parts, multiple placed structures, roads, structural relationships and a larger native scene bundle.
The Beta world contained 2,364 render parts and compiled into 56,736 vertices and 28,368 triangles. It was installed and launched on the physical Xbox, with further iterations addressing scene scale, composition and gameplay readability.
This mattered for a reason beyond the visual result.
The same console execution target was receiving content from a procedural world generator that had not originally been designed for Xbox.
Forge was not proof that every procedural engine could automatically run on the platform. It demonstrated one workable boundary between external generation and a native console runtime.
For XCP, that boundary is important. Different authoring environments should not necessarily require completely separate execution infrastructures.
XCP Studio: one project, shared by humans and agents
The next part of the platform was the development experience.
XCP Studio was designed as a Windows desktop environment where a developer, a visual interface and an AI coding agent can operate against the same project representation.
Rather than giving each interface its own interpretation of the software, the project has a shared structure and explicit contracts.
A project can declare its modules, assets, required capabilities and runtime configuration. XCP validates these declarations against the capabilities actually exposed by the execution target.
The development cycle is:
Developer / coding agent
|
v
Editable XCP project
|
v
Validate + build bundle
|
v
Install on Xbox
|
v
Launch + interact
|
v
Observe + capture evidence
|
v
Revise or rollback
|
+------> Next iteration
The desktop environment is not merely a dashboard for a worker.
It is intended to become the place where software is created, adapted, tested and evolved.
The original research has already measured an end-to-end XCP Studio Technical Preview workflow on physical Xbox hardware, including project validation, installation, activation, launch, interaction and capture.
The packaged preview still requires further clean-machine validation and release preparation. It should not be confused with a generally available finished product.
Nevertheless, the essential development loop has been exercised.
Why this could matter commercially
There is a practical audience for a platform like this: independent developers, small studios, technical artists, researchers and people who want to experiment with interactive software on real console hardware.
For many of them, the difficult part is not necessarily writing the first prototype. It is managing the gap between a familiar development environment and the constraints of a different execution target.
A useful platform could reduce that gap.
Imagine creating a small project with an existing engine, adapting it through a community-maintained integration, running it on an Xbox in Developer Mode and receiving structured feedback from the actual device.
The developer could then revise the same project and repeat the cycle without rebuilding a separate workflow for every experiment.
That would be particularly useful during early prototyping, when ideas change frequently and fast iteration is often more valuable than elaborate release infrastructure.
There are already official development paths for engines such as Godot and Unreal Engine. XCP is not intended to replace Microsoft's commercial publishing programs, nor does it grant access to restricted console capabilities.
Its proposed value is different: an open, reusable prototyping and execution environment built around the capabilities available to it.
The long-term ambition is to support increasingly complex projects and established frameworks through reusable adapters and runtime components.
Godot is a natural starting point because we have already conducted adaptation experiments. Unreal Engine and other major frameworks represent possible future integration work, not compatibility that XCP can currently claim.
And I do not think this requires waiting until every feature of a major engine is supported before the platform becomes useful.
A carefully defined subset that developers can actually build, execute and test may already provide value.
Why I made XCP open source
The original repository grew into a laboratory containing hardware probes, multiple generations of runtime experiments, creative projects, integration prototypes, successful tests and failed approaches.
It was useful for research, but it was not a particularly good starting point for external contributors.
That is why I extracted a separate public XCP repository around the reusable components: project contracts, XVM, source adapters, semantic infrastructure, execution evidence, conformance tests and development tools.
The public repository is not a complete copy of the original laboratory. Third-party game sources and assets are excluded, and historical Xbox results must not be presented as fresh verification of newly reconstructed binaries.
The next stage also cannot depend entirely on me building every integration.
For XCP to become a genuine platform, the community needs to be able to extend it.
That could mean implementing another source adapter, contributing rendering functionality, improving Godot support, building conformance tests, introducing a different runtime or exploring another execution target.
The project deliberately separates source interpretation, execution contracts and target-specific capabilities because those are the areas in which independent contributions could eventually make the largest difference.
I am not assuming that every abstraction is already general enough. In fact, one of the reasons to involve outside developers is to discover where the architecture still contains assumptions inherited from the original Xbox experiments.
A platform becomes interesting when people can build things its original author did not anticipate.
What remains to be done
The historical research demonstrates several important capabilities, but turning those capabilities into a broadly usable development platform requires another kind of engineering.
The public toolchain needs reproducible validation against the hardware. The desktop application needs a straightforward installation and onboarding experience. Framework adapters need to become more general, and new projects must be tested without relying on prior knowledge of their structure.
That last point is especially important.
We have demonstrated bounded playable reconstructions of three Godot games. The next significant result would be an independent developer taking a previously unseen project through the adaptation and execution process, with a clear record of which features work, which require substitutions and which remain unsupported.
That would measure something different from the historical experiments: the usefulness of XCP as an extensible development tool.
There is also substantial room for the community to explore beyond games. Interactive scenes, simulations, procedural environments, educational software and GPU-driven experiments all fit the same general direction.
The platform should grow according to what can actually be implemented and measured, rather than a fixed list of promises.
The bigger idea behind XCP
Looking back, the development of XCP followed a somewhat unusual path.
It started with an Xbox and a question about its computational capabilities.
That led to memory and GPU experiments, a virtual machine, verified execution, AI-agent integration, a creative runtime, Godot adaptation, procedural worlds and finally a desktop development environment.
None of those individual components tells the whole story.
XVM is not the final product. GPU compute is not the final product. Forge and the Godot experiments are not separate destinations.
They are different parts of a larger effort to make real hardware available as a practical, programmable and verifiable development target.
The long-term vision is an open platform where developers can bring familiar tools, the community can expand the supported capabilities, and AI agents can participate in development without replacing the developer's authority over the project.
The Xbox Series X is the first physical target because that is where the experiment began and where the current evidence exists.
It does not have to be the last.
And that is why I think XCP has a meaningful future beyond its original hardware research.
Not because it already supports every engine or solves every problem in console development, but because it has established several working pieces of an environment that independent developers could help turn into something substantially larger.
The next interesting result will not be another benchmark produced by me. It will be something built by somebody else using XCP.
That is what I would like to see the project become.
XCP is open source
GitHub: https://github.com/Daniele-Cangi/xcp-xbox
XCP Studio: https://xcpstudio.com/
The XcpStudio series: https://dev.to/danielecangi/series/44781
The public repository contains the extracted platform, reference implementations, contracts and verification tooling. The original Xbox research provides historical hardware evidence, while new builds require validation against their own exact artifacts.
Contributions, experiments and technical discussion are welcome.
This is the final chapter of the XCP introduction series. The development itself continues.
Top comments (0)