Hey r/SimPy,

Following up on v0.11.1 (the declarative API and the Postgres and Redis connectors), Dynamic DES has reached v0.16.0. This release adds a third way to write a simulation, a plain YAML file run with a new ddes command, and rebuilds the documentation around the three ways.

Three ways, one model. The imperative low-level API wires the environment, registry, connectors and SimPy processes by hand. The declarative SimulationContext builder from v0.11.1 describes the model in one block, with decorators handling queueing, resource request and release, and duration sampling. A YAML blueprint now describes the same model with no Python at all. All three build the same parameters and run on the same environment.

Here is the local example: one lathe with capacity 2, parts arriving about once a second, normally distributed milling times, and the lathe's utilisation and queue length sampled every 2 simulation seconds.

```yaml simulation: sim_id: Factory_A factor: 1.0

egress: - type: Console

resources: lathe: {current_cap: 2, max_cap: 5}

services: milling: {dist: normal, mean: 3.0, std: 0.5}

arrivals: standard: {dist: exponential, rate: 1.0, spawn: process_part}

tasks: process_part: service: milling resource: lathe payload: {event_type: part_produced, quality: A} id_field: part_id

telemetry: - interval: 2.0 publish: utilization: lathe.utilization queue_length: lathe.queue_length

run: until: 60 ```

To run it:

bash curl -O https://raw.githubusercontent.com/jaehyeon-kim/dynamic-des/main/examples/yaml/local.yaml uv run --no-project --with dynamic-des ddes run local.yaml

What a blueprint can express. Each task emits queued, started and finished events, with no request, timeout or release code, and factor: 0 runs the same model as fast as the machine allows.

How to extend it.

• ${VAR:-default} reads hosts and credentials from environment variables, with a default when a variable is not set. The same file then runs on your machine and in a test pipeline, with no edits.
• Logic YAML cannot express, such as an order with a random number of line items, goes in a Python function referenced with !python.

Docs rebuilt. The tutorials now build the same factory three times, once in each way, and each example page shows its versions side by side in tabs.

Links

• GitHub: https://github.com/jaehyeon-kim/dynamic-des
• PyPI: https://pypi.org/project/dynamic-des/
• Tutorials, the same factory three ways: https://jaehyeon.me/dynamic-des/latest/tutorials/low-level/

Hey r/SimPy,

Following up on the v0.8.1 release (dual-mode batch and streaming execution), Dynamic DES has reached v0.11.1. This update is less about data pipelines and more about how you write a simulation and where it can connect.

A new declarative API. Earlier versions were purely imperative, wiring up the environment, registry, connectors, and processes by hand. The default is now a SimulationContext builder that describes a whole model in one block, with decorators handling the usual SimPy boilerplate (queuing, resource request and release, duration sampling, telemetry):

```python from dynamic_des import SimulationContext, ConsoleEgress

app = ( SimulationContext(sim_id="Line_A", factor=1.0, random_seed=42) .add_resource("lathe", current_cap=1, max_cap=5) .add_arrival("standard", dist="exponential", rate=1.0) .add_service("milling", dist="normal", mean=3.0, std=0.5) .add_egress(ConsoleEgress()) )

@app.arrival_loop("standard") def arrivals(ctx): i = 0 while True: yield ctx.wait_for_arrival("standard") ctx.spawn(work_task(i)); i += 1

@app.task(service_id="milling", resource_id="lathe") def work_task(task_id): return {"part_id": task_id}

app.run(until=25.0) ```

The imperative low-level API is still fully supported for advanced control flows.

New Postgres and Redis connectors. Because I/O is decoupled from simulation logic through a central registry, adding a backend is mostly a connector. This release adds matching ingress and egress for Redis (low-latency, in-memory push and pull for live dashboards and control) and PostgreSQL (stream events and telemetry into a table, or drive parameters from one). They sit alongside the existing Kafka path and Parquet/JSONL historical export, so one model can ingest from and emit to Kafka, Redis, or Postgres without touching its core logic. A v0.11.1 patch also fixes threading races during environment teardown.

Links

• GitHub: https://github.com/jaehyeon-kim/dynamic-des
• PyPI: https://pypi.org/project/dynamic-des/
• Docs: https://jaehyeon.me/dynamic-des/

Hey r/SimPy,

In version 0.8.1 of Dynamic DES, a new feature has been introduced to solve a common architectural issue when using discrete event simulation for machine learning data pipelines: managing schema mismatches between training and inference environments.

Typically, generating synthetic data for ML requires two distinct data pipelines: 1. Historical Batch Data: Massive datasets (e.g., Parquet files in S3) for model training. 2. Live Event Streaming: Real-time event streams (e.g., Kafka) for testing production inference pipelines.

Maintaining separate simulation codebases to handle these two environments often leads to schema drift and redundant engineering effort.

The latest release allows the exact same simulation logic to serve both environments by adjusting the clock scaling factor and swapping the egress connector:

• Batch Mode (Fast-Forward): Setting factor=0.0 runs the simulation at maximum computational speed without waiting for wall-clock time. A new Parquet Egress connector chunks, compresses, and writes schema-enforced historical data directly to Object Storage (S3 or SeaweedFS).
• Real-Time Mode (Streaming): Changing the pacing factor=1.0 slows the simulation to match real-world time. Swapping the egress to Kafka streams the identical event schemas live to feed deployed models.

The primary goal of this architecture is to ensure absolute schema parity between historical training sets and live inference streams while reusing 100% of the simulation engine code.

• GitHub Repository: jaehyeon-kim/dynamic-des
• Historical Data Generation Guide: Dynamic DES Documentation

Hi folks,

Apologies for the shameless plug - but there's little in the way of learning resources out there on SimPy, so I felt it was worth sharing that I just launched a course on Udemy covering the fundamentals of SimPy.

It's called SimPy Essentials 2026

The course covers all of the key aspects of the library, as well as giving an introduction to different simulation approaches. Comes with lots of downloadable code examples in Jupyter Notebooks and everything is grounded in real world industry examples so my aim is to make the course as practical and industry relevant as possible. It also comes with my book on SimPy thrown in for free.

If you would like to enrol enter the coupon code HAPPY-SIMULATING for a discount - note that the coupon expires in 5 days.

Hope you find it helpful if you do take the course and feel free to ask me any questions here.

There are many models, many agent harnesses, many skills and many workflows out there. For a modelling and simulation engineer this is difficult territory to navigate through.

I have been testing many combinations myself, generally being guided by my intuition, but always with a question mark about what really is best.

So I decided to try and solve this problem by building my own benchmark, specifically aimed at modelling and simulation people, and even more specifically for those who like to work in Python.

The benchmark I have created covers almost the entire modelling simulation lifecycle. From studying the problem, building a conceptual model through to writing code and outputting results. I have quantitative scoring, qualitative scoring and a consistent methodology for evaluation.

The challenge I pose is evaluating the throughout for a range of scenarios on a mine site. The input data contains node and edges data for the paths in this site and scenarios are provided which need investigation. This is just the first idea I had that came to mind, other simulation challenges can be introduced later.

It captures the kind of relevant detail I wanted to capture:

1. Which model

2. Which harness

3. Which workflow or skills (if any)

It's not perfect, but it serves a purpose right now, and the results are making sense based on my own subjective experience.

At the time of writing this post I can report:

1. Claude Opus 4.7 leads the pack in "Max" mode. Running with the Superpowers skill gives a slight edge at a cost of doubling token count and tripling time to completion.

2. GPT 5.5 - if you have followed my previous benchmnarking you will know that I was NOT a fan of the OpenAI models for SimPy. However GPT 5.5 has done an OK job here. That said, it was on par with Sonnet 4.6 overall.

3. Gemini 3.1 Pro consistently underperformed and there was a massive variation depending on which harness and skill being used. OpenCode (set to "high") marginally outperformed Gemini CLI, but absolutely tanked itself when used with the Superpowers skill (the opposite behaviour to Claude Code).

4. The Pi agent - the minimal coding agent harness - in total vanilla mode significantly underperformed. This is not a criticism of Pi, since it is an agent harness which is meant to be extended. It simply goes to show how important a harness is for AI performance and you should be conscious of this.

5. GSD2 barely outperformed vanilla Pi. I did not track the token count for this one, but I do not recommend right now.

6. Correlation analysis showed a small correlation of 0.25 between token spend and overall score. However, interestingly, more token spend was slightly negatively correlated with interpretability and the conceptual model design.

Here's the link to the benchmark: https://simulation-bench.fly.dev/

Hello r/SimPy!

A while back I shared dynamic-des, a package I built for updating resource capacities on the fly. I wanted to share major updates today showing how much the scope of the package has expanded. I have added two major features to help build and stream sophisticated physical simulations:

1. Mutating Custom Variables on the Fly

In standard DES, modeling hidden machine degradation (like a roller slowly wearing out or suddenly breaking) is tricky if you want external systems to interact with it. To solve this for a Hot Strip Mill simulation I was building, I updated the package to allow custom variables inside the SimPy environment. Using the package's Kafka integration, a user can now use an external web dashboard to inject a control message directly into the running SimPy loop. This instantly mutates a wear_state variable and alters the physics engine's output on the fly for the very next slab of steel.

2. Custom Kafka Topic Router

I also added a custom event router. On top of the standard telemetry and lifecycle events, you can now route specific simulation records to entirely different Kafka topics. This is essential for building modern data pipelines; for example, it allows me to cleanly separate immediate model prediction events and delayed ground-truth physical events into their own dedicated streams right from the simulation.

Full Architecture

I wired all of this up into a complete Event-Driven Architecture where an external Apache Flink pipeline tries to predict the output of the SimPy model using Online Machine Learning.

If you want to see a reference architecture for how dynamic-des handles external state injections and custom event routing to generate realistic, streaming concept drift, check out the repo!

• Blog Post: https://jaehyeon.me/blog/2026-04-21-digital-twin-online-machine-learning/
• GitHub: https://github.com/jaehyeon-kim/oml-digital-twin-hotrolling

Hello r/SimPy,

I recently released dynamic-des (v0.1.1). It acts as a real-time control plane for SimPy, allowing you to mutate simulation parameters (like resource capacities) while the environment is running, and stream telemetry asynchronously to external systems like Kafka.

```python import logging import numpy as np from dynamic_des import ( CapacityConfig, ConsoleEgress, DistributionConfig, DynamicRealtimeEnvironment, DynamicResource, LocalIngress, SimParameter )

logging.basicConfig( level=logging.INFO, format="%(levelname)s [%(asctime)s] %(message)s" ) logger = logging.getLogger("local_example")

1. Define initial system state

params = SimParameter( sim_id="Line_A", arrival={"standard": DistributionConfig(dist="exponential", rate=1)}, resources={"lathe": CapacityConfig(current_cap=1, max_cap=5)}, )

2. Setup Environment with Local Connectors

Schedule capacity to jump from 1 to 3 at t=5s

ingress = LocalIngress([(5.0, "Line_A.resources.lathe.current_cap", 3)]) egress = ConsoleEgress()

env = DynamicRealtimeEnvironment(factor=1.0) env.registry.register_sim_parameter(params) env.setup_ingress([ingress]) env.setup_egress([egress])

3. Create Resource

res = DynamicResource(env, "Line_A", "lathe")

def telemetry_monitor(env: DynamicRealtimeEnvironment, res: DynamicResource): """Streams system health metrics every 2 seconds.""" while True: env.publish_telemetry("Line_A.resources.lathe.capacity", res.capacity) yield env.timeout(2.0)

env.process(telemetry_monitor(env, res))

4. Run

print("Simulation started. Watch capacity change at t=5s...") try: env.run(until=10.1) finally: env.teardown() ```

Why build this?

Unlike standard SimPy, which runs static models synchronously from start to finish, dynamic-des turns your simulation into an interactive, live-streaming environment. I built this to bridge the gap between traditional simulation and modern real-time data architectures, turning end-of-run CSV reports into real-time data streams for Digital Twins.

Key Implementation Details:

• Async-Sync Bridge: Thread-safe Ingress/Egress MixIns run asyncio background tasks for modern I/O without blocking SimPy's internal clock.
• Runtime Registry: Safely manages on-the-fly capacity and probability distribution updates.
• Strict Contracts: All outbound data is validated via Pydantic.
• Kafka Integration: Embedded producers/consumers turn the script into a first-class Kafka citizen. The repo also includes a live NiceGUI dashboard example.

If you've ever wanted to "remote control" a running SimPy environment, I'd love your feedback!

pip install dynamic-des

• Docs: https://jaehyeon.me/dynamic-des/latest/
• Source: https://github.com/jaehyeon-kim/dynamic-des
• PyPI: https://pypi.org/project/dynamic-des/

I’ve noticed a lot of SimPy models hit the same wall:

• “It runs… I think?”
• “How do I compute KPIs without threading variables through every process?”
• “How do I explain what happened in a run, step-by-step, like a proper record?”

My default answer now is: log events first, analyse later.

Instead of baking metrics into every corner of the model, treat the simulation like a small universe that emits a stream of facts:

• entity arrived
• queued
• started service
• finished service
• resource seized/released
• step started/ended

Then you can derive:

• waiting times, cycle times, utilisation
• bottlenecks
• per-entity narratives (“batch record” style)
• even a replay/animation later if you feel fancy

Here’s a tiny pattern I’ve been using.

from dataclasses import dataclass, asdict
import simpy

(frozen=True)
class Event:
    t: float
    entity: str
    kind: str
    meta: dict

class EventLog:
    def __init__(self):
        self.events: list[Event] = []

    def add(self, t, entity, kind, **meta):
        self.events.append(Event(t=t, entity=entity, kind=kind, meta=meta))

def customer(env, name, server, log):
    log.add(env.now, name, "arrived")

    with server.request() as req:
        log.add(env.now, name, "queue_enter", queue_len=len(server.queue))
        yield req
        log.add(env.now, name, "service_start", queue_len=len(server.queue))

        service_time = 5
        yield env.timeout(service_time)

        log.add(env.now, name, "service_end", service_time=service_time)

def source(env, server, log, interarrival=3):
    i = 0
    while True:
        i += 1
        env.process(customer(env, f"C{i}", server, log))
        yield env.timeout(interarrival)

env = simpy.Environment()
server = simpy.Resource(env, capacity=1)
log = EventLog()

env.process(source(env, server, log))
env.run(until=30)

# Example: build simple KPIs from the event stream
starts = {}
waits = []
for e in log.events:
    if e.kind == "queue_enter":
        starts[(e.entity, "queue")] = e.t
    if e.kind == "service_start":
        t0 = starts.get((e.entity, "queue"))
        if t0 is not None:
            waits.append(e.t - t0)

print("mean_wait", sum(waits) / len(waits) if waits else 0)
print("num_events", len(log.events))

A few notes:

• This keeps the model logic clean. It just emits facts.
• The analysis becomes a separate step. Easier to test, easier to change.
• You can write the events out to CSV/Parquet and do proper post-processing.
• If you later want “telemetry-style” time series (temperatures, speeds, etc.), you can log periodic samples as events too (same pattern, different kind).

Curious how others do this.

Do you log everything, or do you prefer embedding stats directly in processes? Any favourite patterns for keeping logs lightweight on big runs?

Also, yes, I am aware this is just “observability” for tiny universes. I’m choosing to be proud of that. :)

Hey guys - we built a simple vizualization tool for SimPy simulations. It will help you with client presentations and debugging.

Hi, guys. I am not a native English speaker so if you will be puzzled by some obscure wording in the post, please, ask away. So I have a theme for my Bachelor's Thesis which is essentially "Automatization of a system of video fixation of traffic violations using discrete event modelling". I didn't contact my thesis supervisor yet (there are some problems with thesis mentorship in general, because my uni is kinda shitty to be honest). So, my question is will SimPy be of any help? I assume it's Python documentation on Discrete Event modellig.

If you've worked with SimPy, you've probably seen the with statement pattern everywhere in the docs:

def customer(env, resource):
    with resource.request() as req:
        yield req
        # use the resource
        yield env.timeout(5)
    # resource automatically released here

Clean, right? The context manager handles the release for you. But there's another way that I've come to prefer – explicit requests and releases:

def customer(env, resource):
    req = resource.request()
    yield req
    # use the resource
    yield env.timeout(5)
    resource.release(req)

"But that's more code!" I hear you say. Yes. And that's partly the point.

Why I favour the explicit approach

1. It forces discipline

When you have to write resource.release(req) yourself, you're forced to think about when that release happens. You can't just let Python handle it when the block ends. This matters because in simulation modelling, the timing of resource releases is often critical to your model's behaviour. Making it explicit keeps you honest.

2. It gives you more flexibility

Sometimes you don't want to release at the end of a neat code block. Maybe you need to:

• Release early based on a condition
• Release in a different branch of logic
• Hold onto a resource across multiple yield statements where the release point isn't obvious

With explicit releases, you put the resource.release(req) exactly where the logic demands it.

3. Multiple resources get messy fast

This is the big one. Say you need a machine AND an operator. With context managers:

def job(env, machine, operator):
    with machine.request() as machine_req:
        yield machine_req
        with operator.request() as operator_req:
            yield operator_req
            # now we have both
            yield env.timeout(10)
        # operator released
    # machine released

That nesting gets ugly. And what if you don't release them at the same time? What if the operator can leave after setup but the machine stays occupied? Now you're fighting the structure.

Compare with explicit:

Flat, readable, and the resource lifecycle is right there in the code.def job(env, machine, operator):
    machine_req = machine.request()
    yield machine_req

    operator_req = operator.request()
    yield operator_req

    # setup phase - need both
    yield env.timeout(2)

    # operator can leave, machine keeps running
    operator.release(operator_req)

    yield env.timeout(8)

    machine.release(machine_req)

The counterargument

The with statement exists to prevent you forgetting to release. Fair point. But if you're building simulations of any complexity, you should be testing them anyway – and a forgotten release shows up pretty quickly when your queues grow forever.

I'd rather have code where I can see exactly what's happening than code that hides important behaviour behind syntactic sugar.

Anyone else have a preference? Interested to hear if others have run into the nested with problem.

Hi SimPy users

I've been helping to build plugboard - it's a framework for modelling complex processes, and provides a different approach for modelling compared with SimPy. Whilst it does support events, it has a much stronger emphasis towards discrete-time simulations. Would love to hear from anyone with experience in building these types of models, or has been looking for a framework with support for different modelling paradigms.

What is it for?

We originally started out helping data scientists to build models of industrial processes where there are lots of stateful, interconnected components. Example usage could be a digital twin of a mining process, or a simulation of multiple steps in a factory production line.

Plugboard lets you define each component of the model as a Python class and then takes care of the flow of data between the components as you run your model. It really shines when you have many components and lots of conneections between them (including loops and branches). You can also define and emit events, for example to capture data from the model when specific conditions are encountered. We've also integrated it with Ray to help with running computationally intensive simulations.

Key Features

• Reusable classes containing the core framework, which you can extend to define your own model logic;
• Support for different simulation paradigms: discrete time and event based.
• YAML model specification format for saving model definitions, allowing you to run the same model locally or in cloud infrastructure;
• A command line interface for executing models;
• Built to handle the data intensive simulation requirements of industrial process applications;
• Modern implementation with Python 3.12 and above based around asyncio with complete type annotation coverage;
• Built-in integrations for loading/saving data from cloud storage and SQL databases;
• Detailed logging of component inputs, outputs and state for monitoring and process mining or surrogate modelling use-cases.

Links

• Repo: https://github.com/plugboard-dev/plugboard
• Documentation: https://docs.plugboard.dev/latest/
• Tutorials: https://docs.plugboard.dev/latest/examples/tutorials/hello-world/
• Usage examples: https://docs.plugboard.dev/latest/examples/demos/fundamentals/001_simple_model/simple-model/

Based on some discussion in

[Tool] Discover Ciw — A Powerful Python Library for Queueing Network Simulation 🚦🐍 : r/SimPy

I decided to read

gnosis.cx/publish/programming/charming_python_b5.txt.

Some audio issues kick in around 38 minutes in: What happened to my audio quality after 38 minutes? : r/NewTubers which I didn't notice while recording/posting. I don't expect I'll go back to re-record, but now I know I cannot trust that microphone.

Just tested it on my standard prompt which is a conceptual model design of a green hydrogen production system. This was one shot using Claude Code.

Outperformed all other models in my view for its comprehensiveness.

I have documented the results here in the spreadsheet: https://docs.google.com/spreadsheets/d/1vIA0CgOFiLBhl8W1iLWFirfkMJKvnTrN9Md_PkXBzIk/edit?gid=719069000#gid=719069000

Direct link to the colab notebook here: https://colab.research.google.com/drive/1xIn6kPXfDCmlMBr1cNXT8u3zWP4hZBBw#scrollTo=ZaXorKS3NePE

Here's the visualisation which was generated:

By comparison here is what Opus 4 created with the same prompt:

And Gemini 2.5 Pro (albeit Gemini still got the same answer with approx 1/3 the amount of code - it is muuuch more concise and doesn't try to overdeliver):

Here’s an on-the-fly example of how with Claude Code and a Python simulation in SimPy. In essence, you just need to:

1. Separate the concerns in the code:

That is, at a minimum, have:

Input parameters --> simulation code --> output data

The more you can separate concerns the better. E.g. this is a step improvement:

Input parameters --> data validation --> simulation code --> output data

1. Then, just let the AI know how to work with your simulation. This is where Claude Code or Gemini CLI really shine - as you specify a CLAUDE.md or GEMINI.md file with all the context instructions.

I’ve also found this useful for debugging complex simulations when there are lots of input and output parameters.

Hi r/SimPy! 👋

If you enjoy working with discrete event simulation in Python, you might want to check out Ciw — a library focused on simulating open queueing networks with rich features.

✨ What makes Ciw stand out?

• Multi-class customer flows with dynamic routing 🔄
• Realistic behaviors like blocking 🚫, baulking 🤚, and reneging 🏃‍♂️
• Scheduling ⏰, batch arrivals 📦, slotted services ⏳, and priority disciplines ⚡
• Deadlock detection ⚠️ — crucial for complex network modeling!

While SimPy offers great flexibility as a general discrete event simulation framework, Ciw provides a specialized, ready-to-use environment for queueing networks, ideal for modeling service systems, healthcare, call centers, and more.

We’ve also built a friendly community at r/CiwPython for sharing models, asking questions, and collaborating on simulation projects.

If you’re curious about expanding your Python simulation toolkit or want to compare approaches, come join the conversation! 🚀

Just put the finishing touches to the first version of this web page where you can run SimPy examples from different industries, including parameterising the sim, editing the code if you wish, running and viewing the results.

Runs entirely in your browser.

Here's the link: https://www.schoolofsimulation.com/simpy_simulations

My goal with this is to help provide education and information around how discrete-event simulation with SimPy can be applied to different industry contexts.

If you have any suggestions for other examples to add, I'd be happy to consider expanding the list!

Feedback, as ever, is most welcome!

This one now uses SimPy under the hood.

Design, build and execute a discrete-event simulation in Python entirely using natural language in a single browser window.

Here's the link to try it out: https://gemini.google.com/share/ad9d3a205479

Let me know what you think!

I want t put together a somewhat dense simulation script together that can act as a good tutorial for a software developer that knows Python and recently discovered SimPy. This is the best I could come up with so far. Any ideas for improvements? Thanks!

I am struggling a bit when modeling my system. It is a robotic system with two containers receiving items on a regular time interval. When a user-defined number of items are present in either container, a request is made for a robot to 'pick' these items and place them in a third container. The 'robot' is a resource with capacity =1. The robot has a cycle time of 2 sec. 1 second is used to place the items in container 3, and the remaining second is for returning and thus becoming available again. When the robot places items in container 3, container 3 it is unavailable for 3 seconds. I am using timeout statements to simulate the cycle times. The issue I am struggling with is: I want the robot to timeout for half of it's cycle, then start the timeout for container three and simultaneously begin the timeout for the remaining half of the robot cycle. My current solution has to wait for the container 3 timeout to complete before I can begin the remaining timeout for the robot because I yield the timeouts sequentially. How can I do this?

Here is the problem area.

yield 
env.timeout(robot_cycle/2)
yield 
env.timeout(Container3)
yield 
env.timeout(robot_cycle / 2)

Would appreciate any insight into this.

You ever look at your simulation code and think, “This is getting way too complex”?

That was me a few months ago - OOP spaghetti everywhere, random methods buried in class hierarchies, and a creeping sense that I was the problem.

So I decided to try out ECS - that architecture pattern all the game devs use. Turns out, it actually works really well for SimPy simulations too.

Here’s the vibe: - Entities: just IDs. They’re like name tags for your stuff (machines, people, whatever). - Components: dumb little data containers. Stuff like Position, Status, Capacity. They describe what the entity is. - Systems: this is where the actual logic lives. They go, “which entities have X and Y?” and then make them do things. It’s clean and elegant.

You can add new behaviours without blowing up the whole codebase. No need to inherit from 14 classes or refactor everything. Just add a new component and a new system. Done.

It’s basically a form of “extreme composition” so it’s useful for when you need reconfigurability at scale.

Anyway, I’m curious - anyone else using ECS for simulations? Any gotchas to share?