Verbundene Agents in Rhai lesen

Reading Connected Agents in Rhai

In Metapad, agents coordinate through the graph itself — they read each other's state through their links. There's no message-passing, no event system; just direct reads. This keeps every interaction visible in the model, and it makes simulations easy to debug because everything important is on the diagram.

get_connected — the basic traversal

let teammates = get_connected(agent, "belongs_to");

get_connected returns an array of agents reachable from the current agent via a given relationship type. It walks the link in either direction, so the same call works whether your agent is the source or the target of the relationship. Once you have an array, you can do anything Rhai's array methods support:

teammates.len()                                   // count
teammates.filter(|a| a.get_prop("role") == "Eng") // subset

sum_prop and count_prop — common aggregations

For the two most common patterns — summing a numeric property across the array, or counting agents with a particular value — Metapad provides shortcuts:

sum_prop(get_connected(agent, "has_member"), "salary")
count_prop(get_connected(agent, "has_member"), "state", "Active")

These are exactly what you'd want for KPI rollups, headcount, total cost, total revenue — anywhere a parent agent needs to summarize its children.

Reading the past

Some processes have natural time lags — a factory ships today, the warehouse receives tomorrow. The 3-argument form of get_connected lets a formula see what its neighbors looked like one or more timesteps ago:

// What the connected factories shipped one tick ago
sum_prop(get_connected(agent, "supplied_by", -1), "shipped")

This is the famous Beergame pattern: warehouse demand at time T pulls from factory shipments at T−1, modeling delivery time as a structural feature of the model rather than something you have to remember to encode.

A worked example: limits to growth

Imagine a population whose growth is limited by a finite carrying capacity. The intro model has this exact setup. The growth factor is adjusted by a connected Resource Adequacy node:

// Growth rate adjusted by connected resource adequacy
let resources = get_connected(agent, "limit_growth");
let resource_factor = if resources.len() > 0 {
    resources[0].get_prop("value")
} else {
    1.0
};
agent.get_prop("growth_factor") * resource_factor

The same formula works whether there's one resource node or several — and resource depletion automatically slows growth without anyone wiring up an explicit "resource depleted" event.

Tips

• Keep the graph honest. If two agents need to coordinate, draw the link. Hidden coordination through naming conventions or external state is much harder to reason about.
• Prefer aggregations to loops. sum_prop and count_prop cover most cases and are clearer than a manual for loop.
• Read history sparingly. The -1/-2 offsets are powerful, but each offset adds a small amount of bookkeeping behind the scenes. Use them for genuine delays, not to paper over circular dependencies.

Next steps

• Writing Property Formulas — where these reads typically live
• Writing Act Methods — when the read drives a multi-property update
• Diagnosing Simulation Errors and Warnings — when reads return surprising values
• Rhai Function Reference — full signatures for every helper