• Performance
• Lightweight
• No allocations
• Low memory footprint
• No Unsafe in core
• Based on statics and structures
• Type-safe
• Free abstractions
• Powerful query engine with parallelism support
• Batch entity operations
• Component and tag change tracking
• Entity grouping by types and clusters
• Entity relations system
• World snapshot serialization
• Event system
• No boilerplate
• Compatibility with Unity with support for Il2Cpp and Burst
• Compatibility with other C# engines
• Compatible with Native AOT

• Contacts
• Installation
• Concept
• Quick start
• Features
  • Entity
  • Entity global ID
  • Component
  • Tag
  • MultiComponent
  • Relations
  • World
  • Systems
  • Resources
  • Query
  • Events
  • Change Tracking
  • Serialization
  • Compiler directives
• Performance
• Unity integration
• Roslyn analyzer
• AI Agent Integration
• Roadmap
• Community projects & references
• License

• [email protected]
• Telegram

If you like Static ECS and it helps your project, you can support its development:

The library has a dependency on StaticPack 1.2.6 for binary serialization, StaticPack must also be installed

• As source code

  From the release page or as an archive from the branch. In the master branch there is a stable tested version

• Installation for Unity

  Via git module in Unity PackageManager:

  https://github.com/Felid-Force-Studios/StaticEcs.git
  https://github.com/Felid-Force-Studios/StaticPack.git
  

  Or adding to the manifest Packages/manifest.json:

  "com.felid-force-studios.static-ecs": "https://github.com/Felid-Force-Studios/StaticEcs.git"
  "com.felid-force-studios.static-pack": "https://github.com/Felid-Force-Studios/StaticPack.git"

• NuGet

  dotnet add package FFS.StaticEcs
  

  For debug build with assertions:

  dotnet add package FFS.StaticEcs.Debug
  

  Packages: FFS.StaticEcs · FFS.StaticEcs.Debug

StaticEcs — a new ECS architecture based on an inverted hierarchical bitmap model. Unlike traditional ECS frameworks that rely on archetypes or sparse sets, this design introduces an inverted index structure where each component type owns entity bitmaps instead of entities storing component masks. A hierarchical aggregation of these bitmaps provides logarithmic-space indexing of entity blocks, enabling O(1) block filtering and efficient parallel iteration through bitwise operations. This approach completely removes archetype migration and sparse-set indirection, offering direct SoA-style memory access across millions of entities with minimal cache misses. The model achieves up to 64× fewer memory lookups per block and scales linearly with the number of active component sets, making it ideal for large-scale simulations, open worlds with streaming, networked games with state synchronization, reactive AI with thousands of agents, and projects with frequent component composition changes (buffs, effects, statuses).

In archetype-based ECS (Unity DOTS, Flecs, Bevy, Arch), every component addition or removal triggers entity migration — copying all data to a new archetype, and the number of component combinations leads to archetype explosion. In sparse-set ECS (EnTT, DefaultEcs), component access requires indirect addressing through sparse tables with at least two cache misses per lookup. StaticEcs eliminates both problems: each entity occupies a fixed slot in segmented arrays and never moves in memory — Add/Remove is an O(1) bit flip in the presence mask with no data copying. Memory-stable entity addresses enable cheap entity relations through versioned identifiers (EntityGID), including links with streaming where some related entities reside in unloaded zones — ideal for complex simulations in open worlds. The number of component types has no impact on storage structure, since each type owns its own mask independently of the others. Two-dimensional EntityType × Cluster partitioning further ensures cache locality: entities of the same type within a cluster occupy adjacent memory segments, while clusters allow loading and unloading entire spatial zones without touching the rest of the data.

Memory is organized hierarchically: chunks (4,096 entities) → segments (256) → blocks (64). A world query starts by ANDing heuristic masks at the chunk level — a single bitwise operation covers up to 4,096 entities, skipping empty blocks entirely — then refines at the 64-entity block level. Batch operations (BatchAdd, BatchRemove, BatchSetTag) process up to 64 entities with a single bitwise operation.

• The core idea of this implementation is static: all world and component data resides in static generic classes (World<TWorld>), enabling avoidance of costly virtual calls and allocations, with a convenient API and plenty of syntactic sugar. The JIT compiler eliminates dead code for unused component hooks
• This framework is focused on maximum ease of use, speed and comfort of code writing without loss of performance
• Multi-world creation, strict typing, ~zero-cost abstractions
• Binary serialization system with world, cluster, and per-entity snapshots, schema versioning and compression support
• Entity relations system with automatic bidirectional hooks for hierarchies, groups, and links
• Reactive change tracking for network synchronization, UI, and triggers
• Multi-components — variable-length per-entity data (inventory, buffs) without heap allocations
• Multithreaded processing with parallel queries and block-level safety guarantees
• Low memory usage, SoA layout (Structure of Arrays) — components of the same type in contiguous arrays
• Built on Bitmap architecture, no archetypes, no sparse-sets
• The framework was created for the needs of a private project and put out in open-source.

💡 For compile-time checks install FFS.StaticEcs.Analyzers — a separate NuGet / UPM package with a Roslyn analyzer and code-fix suite.

using FFS.Libraries.StaticEcs;

// Define the world type
public struct WT : IWorldType { }

// Define type-alias for convenient access
public abstract class W : World<WT> { }

// Define the systems type
public struct GameSystems : ISystemsType { }

// Define type-alias for systems
public abstract class GameSys : W.Systems<GameSystems> { }

// Define components
public struct Position : IComponent { public Vector3 Value; }
public struct Direction : IComponent { public Vector3 Value; }
public struct Velocity : IComponent { public float Value; }

// Define a system
public struct VelocitySystem : ISystem {
    public void Update() {
        // Iteration via foreach
        foreach (var entity in W.Query<All<Position, Velocity, Direction>>().Entities()) {
            ref var pos = ref entity.Ref<Position>();
            ref readonly var dir = ref entity.Read<Direction>();
            ref readonly var vel = ref entity.Read<Velocity>();
            pos.Value += dir.Value * vel.Value;
        }

        // Or via delegate (faster, zero-allocation)
        W.Query().For(
            static (ref Position pos, in Velocity vel, in Direction dir) => {
                pos.Value += dir.Value * vel.Value;
            }
        );
    }
}

public class Program {
    public static void Main() {
        // Create the world
        W.Create();

        // Auto-register all components, tags, events, links and entity types from the
        // assembly that declares the IWorldType struct `WT` (resolved as typeof(WT).Assembly).
        // Safe on all runtimes including Unity IL2CPP, Unity WebGL and NativeAOT — no stack walking.
        // For multi-assembly projects use: W.Types().RegisterAll(typeof(WT).Assembly, typeof(Other).Assembly);
        W.Types().RegisterAll();

        // Initialize the world
        W.Initialize();

        // Create and configure systems
        GameSys.Create();
        GameSys.Add(new VelocitySystem(), order: 0);
        GameSys.Initialize();

        // Create an entity with components
        var entity = W.NewEntity<Default>().Set(
            new Position { Value = Vector3.Zero },
            new Direction { Value = Vector3.UnitX },
            new Velocity { Value = 1f }
        );

        // Update all systems — called every frame
        GameSys.Update();
        // Advance change tracking (changes become visible next frame)
        W.Tick();

        // Destroy systems
        GameSys.Destroy();
        // Destroy the world and clean up all data
        W.Destroy();
    }
}

If you use AI coding assistants (Claude Code, Cursor, Copilot, etc.) with StaticEcs:

• llms.txt: Point your agent at https://felid-force-studios.github.io/StaticEcs/llms.txt for a concise AI-readable reference
• Full context: https://felid-force-studios.github.io/StaticEcs/llms-full.txt for comprehensive documentation
• Claude Code: Copy the consumer CLAUDE.md snippet into your project's CLAUDE.md
• Common pitfalls: See the pitfalls guide

StaticEcs is feature-complete for its core scope. Active development focuses on two things:

• Extended Unity Burst support — most of the public API will be made available from Burst-compiled code paths.
• Maintenance & stability — bug fixes, performance refinements, small quality-of-life improvements.

No large new features are planned at this time. If you hit a bug, have a question, or want to suggest an improvement — please open an issue or send a pull request. Contributions are very welcome.

StaticTopDownShooter by @d4nilevi4 — 2D top-down shooter, Unity 6, StaticEcs. Enemies use Utility AI to take cover and return fire.

StaticEngine by @d4nilevi4 — experimental C#/.NET 10 game engine inspired by Bevy. Built on StaticEcs + Raylib-cs.

MIT license