MapCoordinator

Remarks

Slice one built PlacementDirector as a pure function of counts — how many of the requester's party, guild and friends are on each candidate — and left open who computes them. This is the answer: the map keeps the affinity attributes of the players on it, so scoring never touches a database and the property tests stay possible.

⚠ A roster of attributes, not of people. What is kept per player is their party, their guild, their language and which shard they are on — four fields, supplied by the gate at placement time. Keeping anything more would make this a cache of the account database, with the invalidation problem that implies.

⚠ Friends are not counted yet, and the term is therefore always zero. A friend list is a social-graph query the gate owns and doc 27 puts on the service plane; the weight and the plumbing are here so that supplying it later is a parameter rather than a redesign.

Fields and properties (4)

• public ShardKey Key

  What this map is.

• public IReadOnlyCollection<ShardReport> Shards

  Every shard, in any state.

• public int Population

  How many players the map believes it is holding.

• public PlacementDecision? LastDecision

  The last placement's full argument, for vixen live explain.

Methods (6)

• public MapCoordinator(ShardKey key, PlacementWeights? weights = null, FleetPolicy? policy = null)

  Stands one up.

• public PlaceResult Place(PlaceRequest request, DateTimeOffset now)

  Puts a player somewhere, or says a shard is on its way.

• public void ShardChanged(ShardReport report)

  Records what a shard now is.

• public void PlayerLeft(PlayerKey player, ShardId shard)

  Forgets a player who has left a shard.

• public FleetAction Tick(DateTimeOffset now)

  One turn of the spawn and merge heuristics.

• public double ArrivalRate(DateTimeOffset now)

  Arrivals per second, as the projection sees them.

Used by (2)

• MapCoordinatorTestsVixen.Live.Orchestrator.Tests
• MapGrainVixen.Live.Orchestrator