Use this skill to decide whether Bevy data belongs on each entity as a Component or once across the app as a Resource. It explains how systems access and schedule that data, including shared time and timers.
Bevy ECS skill for components and resources as data. Keywords: Bevy, Resource, Res, Component, data.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
Load this when you are deciding where a piece of data lives: on many entities, or once for the whole app. The Resources page and the ECS page are the source for the names below.
Component, Query). Use them when many things carry the same kind of fields.Resource). The Resources page names elapsed time, asset collections, and renderers as examples. Access them with Res<T> (read) and ResMut<T> (write).insert_resource places a resource on the App. The page's sample derives Resource on GreetTimer(Timer) and inserts Timer::from_seconds(2.0, TimerMode::Repeating).Time is inserted by add_plugins(DefaultPlugins). time.delta() is the elapsed time since the last update. Timer::tick and just_finished are the page's timer methods.Res<Time> and ResMut<GreetTimer> inside an Update system. Startup versus update is on the ECS page.Check the asset docs for loader APIs before writing them. "Asset collections" on the Resources page is an example of what a resource might hold, not a loader type.
| Godot idea | Bevy idiom |
|---|---|
| Data on one gameplay thing | A Component |
| One copy for the whole app | A Resource inserted with insert_resource |
| Shared clock | Time from DefaultPlugins, or your own Resource |
| Authored data file | Check the asset docs before naming a file format or loader. |
insert_resource call inside Plugin::build.Target: Bevy 0.20+.
Core ECS types: Component, Resource, Query, Commands, Startup, Update, Fixed / FixedMain (bevy::time), .chain(), Plugin, DefaultPlugins, MinimalPlugins. Messages and observers are an ownership slot. See bevy-events-messaging for their APIs. Systems run in parallel unless .chain() orders the ones that conflict.
| Piece | Owner | Who may mutate | Schedule |
|---|---|---|---|
| Data on one entity | Component | One system via Query | Update or FixedMain |
| One value for the whole app | Resource | One system | Startup to insert, then the schedule that reads it |
| Spawn | Commands | The spawning system | Startup for the initial world; later schedules for runtime spawn |
| Order that must not race | .chain() | The chained systems only | Same schedule |
| Plugin boundary | Plugin | build registers systems and resources | Before the app runs |
Borrow rule: two systems that both mutably query the same component must be ordered (.chain()) or split so only one writes. Unrelated systems stay parallel. That is the ECS page rule, not a guess at a system-set API.
| If you need | Do this | Do not |
|---|---|---|
| Per-entity data | Component + Query | A Godot node script |
| App-wide config or clock | Resource | Copy the value onto every entity |
| Stable simulation step | FixedMain and the Fixed clock | Tie simulation to raw frame Update |
| Startup spawn | Commands in Startup | Spawn from a render system |
| Cross-system notice that is not shared state | Message or observer slot in bevy-events-messaging | A new event type invented in this file |
| An API outside the documented set | Check the official docs first | A made-up crate or API |
Load references/ecs-ownership.md for the ownership table.
Do not pin /0.20.0/ in docs URLs. WHY: links stay on latest; the 0.20 target is stated once in prose.
Do not mutably query the same component from two unordered systems. WHY: the schedule runs systems in parallel unless .chain() orders them.
Do not invent a physics, navigation, networking, or XR crate here. WHY: this skill only names documented Bevy crates and modules.
No Godot resource, packed-scene, or data-file types. WHY: Bevy code stays idiomatic ECS and uses only documented Bevy APIs.
No invented asset or serialization APIs. WHY: Bevy code stays idiomatic ECS and uses only documented Bevy APIs.
No third-party crates. WHY: Bevy code stays idiomatic ECS and uses only documented Bevy APIs.
docs.rs links use the unversioned latest permalink. The library pin on bevy-master stays 0.20.0.
Resource, Res, ResMut, insert_resource, Time, Timer, TimerMode.Component and Query for per-entity data.World.latest branch.No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Set up 2D sprite animation in Bevy by linking animation clips and players to sprite entities. The skill identifies the engine-owned systems for advancing animations and points to a related skill when clips need blending.
Set up lighting for 3D scenes in Bevy 0.20 and later. Get guidance on spawning directional, point, and spot lights, and on locating the documented APIs for related options such as fog, shadows, and light probes.
Use this Bevy guide when a 3D mesh needs a physically based rendering (PBR) surface. It explains where StandardMaterial and ExtendedMaterial fit, points to relevant documentation, and helps keep ECS ownership and scheduling in view.
Plan how to assemble a 3D level in Bevy by placing entities with transforms and rendering components. The skill clarifies where meshes, lights, scenes, and physics fit, and flags APIs that need documentation checks before use.
Structure gameplay abilities in Bevy using ECS components for ability identifiers, charges, and cooldown timers. The skill outlines how systems update ability state on a fixed timestep and send accepted casts as messages, while combat resolution belongs elsewhere.
Use this Bevy guide when adapting a 2D game design to 3D. It explains how gameplay components can stay in place while sprites, cameras, and motion representations change, and points to camera, world-building, and movement guidance. It does not provide an automatic conversion helper.