require-for-update-gate
Declare a precondition that prevents a system from running when its required singleton or component type is absent, eliminating boilerplate null-checks and reducing unnecessary scheduling cost.
- License 许可
- MIT
- 最近更新
- 2026-07-25
- Stars
- ★ 8
- Forks
- 0
01 前言 Front Matter
- name
- require-for-update-gate
- tags
- [ "core", "query", "gating" ]
- metadata
- { "tier": 3, "internal-only": true }
- description
- Declare a precondition that prevents a system from running when its required singleton or component type is absent, eliminating boilerplate null-checks and reducing unnecessary scheduling cost.
03 SKILL.md 正文
RequireForUpdate Gate
Intent
Declare a precondition that prevents a system from running when its required singleton or component type is absent, eliminating boilerplate null-checks and reducing unnecessary scheduling cost.
Use When
A system only makes sense when a config entity, feature-flag singleton, or scene-scoped marker exists. Multiple requirements can be ANDed.
Avoid When
The condition changes every frame — RequireForUpdate disables the entire system, including any OnUpdate side effects. If you need conditional logic inside an otherwise-always-running system, use a query filter instead.
Senior Pattern
- Call state.RequireForUpdate<T>() in OnCreate, once per required type.
- Pair with GetSingleton<T>() inside OnUpdate — the gate guarantees the singleton exists when OnUpdate runs.
- Multiple RequireForUpdate calls are ANDed.
Code Template
[BurstCompile]
public partial struct SpawnSystem : ISystem
{
[BurstCompile]
public void OnCreate(ref SystemState state)
{
state.RequireForUpdate<SpawnerConfig>();
state.RequireForUpdate<ExecuteSpawn>(); // scene-activation tag
}
[BurstCompile]
public void OnUpdate(ref SystemState state)
{
var config = SystemAPI.GetSingleton<SpawnerConfig>();
// config is guaranteed to exist here
}
}
Anti-Patterns
- Calling RequireForUpdate in OnUpdate (valid but wasteful — it rebuilds the query each call).
- Using RequireForUpdate as the only gate and then calling GetSingleton without it — NullReferenceException if entity not yet created.
- Relying on RequireForUpdate to enforce singleton uniqueness — it only checks existence, not count.
Runtime Risks
- System silently never runs if the required entity is never created — can be hard to debug. Add a log in OnCreate to announce the gate.
- RequireForUpdate with a non-singleton type that has many entities is valid but semantically misleading — prefer WithAll query filter for multi-entity filtering.
Performance Notes
Zero cost when condition is false — OnUpdate is never entered, no job scheduling overhead.
Architecture Guidance
Declare all system preconditions in OnCreate. A system that has no entities to act on should cost nothing.
04 同仓库更多 Skills
dots-update-groups
How to choose the right ECS system group and ordering so per-frame and per-fixed-step work is deterministic and never races its own readers. Covers InitializationSystemGroup / SimulationSystemGroup / PresentationSystemGroup / FixedStepSimulationSystemGroup / VariableRateSimulationSystemGroup, UpdateBefore / UpdateAfter peer ordering, OrderFirst / OrderLast group-boundary placement, RateManager, and the cross-group ordering trap. Use when adding an ISystem, fixing "value visible one frame late" bugs, or coupling simulation to a fixed timestep.
dots-transform-patterns
The Entities 1.x transform model — LocalTransform (writable input) vs LocalToWorld (system-owned matrix), Parent/Child hierarchy, reparenting cost, uniform vs non-uniform scale (PostTransformMatrix), and when to opt out with custom transform systems. Use when designing parent/child hierarchies, runtime reparenting (mount/dismount/socket), or choosing transform components at the Baker boundary.
dots-singleton-patterns
Model cross-system shared configuration and game state as a single-entity component with a strict single-writer contract. Covers RequireForUpdate gating, SystemAPI.GetSingleton / GetSingletonRW / HasSingleton / TryGetSingleton, bake-time vs runtime-created vs ECB-system singletons, the "exactly one entity" runtime invariant, and the single-writer rule. Use when designing frame-stable global config, shared mutable state, or any component intended to exist on exactly one entity.
dots-hybrid-bridge
The one-way bridge between DOTS-owned runtime state and Unity-owned presentation. Covers UnityObjectRef for managed asset refs in components, the DOTS-writes / Unity-reads ownership rule, when to use managed IComponentData vs UnityObjectRef vs CompanionComponent, baker-bridge vs runtime-bridge, and SubScene boundary rules. Use when an entity must reference Unity assets (Mesh, Material, AudioClip, ScriptableObject), a MonoBehaviour view must read entity state, or input/UI must trigger ECS work.
dots-event-driven-ecs
Model one-frame events and external requests in ECS without dual ownership, polling, or persistent state leaks. Covers request-tag pattern with ECB, enableable command components (no structural change), event buffers (IBufferElementData), explicit consumer ownership, one-frame latency rules, and the banned C# event / UnityEvent / static bus anti-patterns. Use when input/UI/network must trigger ECS work, when a one-frame signal fans out to N consumers (damage, hit, collision), or when state changes must be processed exactly once.
valid_skill
A complete, well-formed test fixture skill for SkillHub validation testing. Covers basic task routing and code review for Unity projects.