1 Why depth?

To make our adventure game feel like a single game instead of a bunch of individual games, some items needed to solve domain X will be found by users in domain Y instead of X.

But we do not want to have the following situation:

Domain 1 gives domain 2 a key to hide; domain 2 hides it in an area accessible only with domain 2’s gem
Domain 2 gives domain 1 a gem to hide; domain 1 hides it in an area accessible only with domain 1’s key

To prevent this, we introduce a notion of depth.

2 Three item types

My domain defines some items that users find in my domain. MP10 had a paper like this. Let’s call these items local. Local items do not have a depth. I send a list of local items to the hub; it gives them identifiers but does nothing else with them. I place these items somewhere in my domain for users to find.

My domain defines some items that users find in other domains. MP10 had a key like this. Let’s call these items remote. Remote items do have a depth. I send a list of local items to the hub; it gives them identifiers and sends them to other domains for me. I do not place these items in my domain.

My domain hosts some items that were defined by other domains. MP10 got different such items on different runs: sometimes an i-card, sometimes an axe, and so on. Let’s call these items guests. Guest items do have a depth. I don’t send these to the hub: it sends them to me as part of /arrive. I place these items somewhere in my domain for users to find.

3 Placement and depth

I can place my local items within my domain wherever I wish.

I cannot place my remote items in my domain at all.

I can place the guest item’s I’m hosting in places based on their depth:

Depth=0 guest items can be found by users who have none of my remote items.
Depth=1 guest items can be found by users who have one of my depth=0 remote items.
Depth=2 guest items can be found by users who have one of my depth=1 remote items.

Suppose my domain sends the following list of items during /newhub, with all information except names and depth removed for brevity:

[ {"name":"A", "depth":0}
, {"name":"B", "depth":1}
, {"name":"C", "depth":2}
, {"name":"D"}
, {"name":"E"}
]

In response, the hub gives my domain the following list: [12, 13, 14, 15, 16]

During a user’s first /arrive the hub sends my domain the following items, with all information except names, depth, and ID removed for brevity:

{ "carried":
    [ {"name":"P", "id": 78}
    , {"name":"Q", "id": 89}
    ]
, "owned": []
, "dropped": []
, "prize":
    [ {"name":"W", "id": 33, "depth":0}
    , {"name":"X", "id": 44, "depth":1}
    , {"name":"Y", "id": 55, "depth":1}
    , {"name":"Z", "id": 66, "depth":2}
    ]
}

The following table summarizes what items my domain needs to be able to give the user:

Give	If user has	(optionally, if also has)
15 (local)		12, 13, 14, 16
16 (local)		12, 13, 14, 15
33 (remote 0)		15, 16
44 (remote 1)	12	15, 16
55 (remote 1)	12	15, 16
66 (remote 2)	13	12, 15, 16

Expanding on one row: item 66 (Z) is a remote depth=2 item. That means it should become available when the user has my remote depth=1 item (13 B). If I want I can also require that they have some or all of my items of lesser (12 A) or no (15 D and 16 E) depth.

4 Duplicates

The hub will place my domain’s remote items in other domains of its choice, possibly even with the same item in several other domains. That could mean that a user finds the same item twice. Don’t worry about that; it’s the hub’s job to sort that out. If your domain handles your local items and the guest items you’re hosting appropriately, and if it does not give users any of its own remote items, then everything will work out.