Bevy · project planning pack

Bevy · project planning pack

Plan a Bevy game foundation with a playable-slice brief, technology-specific setup guide, proposed tasks, acceptance criteria and the Orqestria game development team.

This planning pack creates a project containing documents and assigns the recommended agents with their existing skills. It contains no external application code or installer and does not start an application. The task lists are proposals in files; no board tasks are created automatically.

Rust 2D/3D engine organized around entities, components, systems and plugins.

Bevy fits a team that wants game architecture expressed in Rust code and composable systems. Its examples help validate scheduling, rendering and input while keeping game state separate from engine services.

First playable slice or technical spike

Spawn an entity, move it through scheduled systems, update an objective and leave/re-enter the game state without retaining old entities.

Runtime state and assets

Entities, components, resources, system ordering, game states, asset handles and plugin compatibility.

Recommended team

Max, Jett, Lumi, Soren, Niko, Vega, Riff, Tessa, Orion, Atlas, Maya, and Cleo

Documents in this pack

Read the gameplay or technical brief, agree on a small observable result and adapt the proposed tasks before implementation. The selected framework's own APIs and toolchain take precedence; Unity-specific agent skills do not make Unity APIs valid in another engine.

• Project brief: planning/en/brief.md
• Proposed initial tasks: planning/en/proposed-tasks.md
• Acceptance criteria: planning/en/acceptance.md
• Create and validate your own game project: planning/en/foundation-selection.md

Selected foundation and official sources

Explore the category recommendations

• Bevy · Recommendation and scope

Official sources checked: Oct 26, 2026. Recheck a stable release, documentation and license before adoption; this source review is not a security audit.

Proposed initial tasks

These are suggested tasks to discuss and add to your board. Installation writes these documents into the project; it does not create work items, run external setup commands or contact the linked services.

Define scope and outcomes

Define the player interaction or technical hypothesis, target devices, controls, accessibility needs, frame/memory budget and what the prototype excludes. Use this observable journey: Spawn an entity, move it through scheduled systems, update an objective and leave/re-enter the game state without retaining old entities.

Validate the foundation choice

Compare this foundation with at least one alternative in the linked collection. Record the supported language, editor needs, target platforms, dependency versions, asset workflow and missing systems. A rendering library, physics engine or backend is one part of the architecture; identify its companion components.

Verify the current upstream and dependencies

Review official source, licenses, edition terms, dependency requirements, maintenance activity and security advisories for the exact revision. Record unresolved findings and necessary changes before adopting it.

Model runtime state and ownership

Define update timing, state transitions, asset/resource ownership and save boundaries for: Entities, components, resources, system ordering, game states, asset handles and plugin compatibility. If the prototype is networked, define server authority, client intent validation and reconnect behavior; otherwise record that networking is outside scope.

Prototype the smallest complete scenario

Create a separate game or integration project through the foundation's documented setup. Use simple licensed assets, implement the whole slice and include restart/reset and one failure case. Keep engine-source modifications separate from the game's code. Do not run installers, generators or external services merely because this pack was installed.

Measure and prepare delivery

Measure frame time and memory on an intended device, or tick latency and load for a backend. Verify the actual target build, save/reconnect behavior where applicable and reproducible asset processing. Record dependency pins, third-party notices, backups, upgrade/rollback owners and any hosting or platform requirements.

Acceptance criteria

These criteria define the first prototype's review, not completed work. Attach evidence and unresolved issues when the team evaluates each item.

• The agreed scenario is demonstrated end to end with representative records: Spawn an entity, move it through scheduled systems, update an objective and leave/re-enter the game state without retaining old entities.
• The selected revision and at least one alternative are documented with official sources, license terms, toolchain compatibility and the missing gameplay/rendering/physics/network components.
• Input and state ownership have explicit boundaries. Networked variants reject invalid client commands and unauthorized player-data access; local variants verify resource ownership and mark networking out of scope.
• Restart/reset, invalid input and a relevant loading, connection or state-transition failure have visible, recoverable outcomes without duplicate sessions or leaked resources.
• Applicable game saves or backend state have a documented recovery procedure; a stateless slice instead proves clean state reset and reproducible asset loading.
• Target build evidence, measured frame/memory or server budgets, dependency pins, required license notices, known gaps and upgrade/rollback responsibilities are recorded.
• A separate Cargo game demonstrates the slice and state cleanup with compatible engine/plugins, a recorded Rust toolchain and a documented upgrade path.

Create and validate your own game project

Follow the official quick start with a compatible stable Rust toolchain. Create a separate Cargo game, pin Bevy, add components and systems, and demonstrate spawning, input and cleanup before adopting extra plugins.

Bevy is evolving and releases can introduce breaking APIs. Pin the engine, Rust toolchain and compatible plugin versions and plan migration work.

The repository is engine source, not a visual-editor project or a finished game. Editor and content workflows need an explicit choice.

• https://github.com/bevyengine/bevy
• https://github.com/bevyengine/bevy/blob/main/LICENSE-APACHE
• https://github.com/bevyengine/bevy/blob/main/LICENSE-MIT
• https://github.com/bevyengine/bevy/blob/main/README.md

Official sources checked: Oct 26, 2026. Recheck a stable release, documentation and license before adoption; this source review is not a security audit.