2.1 Multiuser

Track one copy of game state for each user that /arrives.

Nothing that one user does should impact the game experience of other users.

2.2 Creative Domain

Make a new domain, with multiple locations and items.

• Distribute at least one depth-0 and one depth-1 item for others to host.

• Have at least one location each to host depth-0, depth-1, and depth-2 items.

• The domain should be of non-trivial complexity. This is a fuzzy measure, but here are some rough guidelines:

  • There should be at least 4 non-empty locations
  • There should be at least 2 no-depth items
  • There should be some kind of theme tying the domain together and making it believable. This doesn’t need to be realistic (fantasy and science fiction elements are fine, for example) but it shouldn’t be nonsenical chaos.

• A user can’t lose: the domain should remain solvable no matter what the user does.

  This does not mean you cannot cause items to disappear: it is fine, for example, to /transfer and item to some nonexistent location like "gone". However, if you do that then there must be some way to access the full domain without the item.

  Secret areas do not need to follow these rules.

• A user can solve the domain using only in-game information.

  You should not make a puzzle depend on knowing how UIUC campus is laid out or the specific gravity of linseed oil or the professor’s hairstyle.

  Secret areas do not need to follow these rules.

2.3 Completion and Score

When a user completes your domain, send the hub a /score message with value 1:

{ "domain": ... # your domain ID
, "secret": ... # your domain's secret
, "user": ...   # the user's ID as given in /arrive
, "score": 1.0  # the user's score in this domain
}

You are welcome to also give scores between 0 and 1 if you wish.

2.4 Submit your code

The code you upload must match the code you run during the project checkoff.

3.1 Two-layer navigation

Each student VM will manage one domain. Each domain has multiple locations.

Travel within a domain is done with the go command and its six directions: down, east, north, south, up, west. Optionally, a domain may allow shortcut travel commands like go house The web front-end will automatically expand w or west to go west before sending it to the domain VM.

Travel between domains is done with the journey command and its four directions: east, north, south, west; or the number of any domain server (e.g. 567 to journey to the domain served by fa24-cs340-567.cs.illinois.edu); or the self-reported name of a domain, if that name is unique among all domains. These commands are managed by the central server and are not even sent to the domain server, though the hub will send the domain /arrive and /depart requests to let the domain know that the user journeyed.

It is recommended that each domain have one or more locations from which the request to go north gets the response $journey north, and so on for the other four cardinal directions. This is recommended, but not required.

3.2 Hosting other domain’s items

Each domain must provide at least one item of depth 0 and one item of depth 1 to the hub during /newhub to be hosted by other domains.

Each domain must have at least one of each of the following

• A location to store depth 0 items it hosts for other domains.

  These items must be accessible by visiting the domain alone; they cannot be hidden behind any items hosted by other domains.

• A location to store depth 1 items it hosts for other domains.

  These items must not be accessible by visiting the domain alone; a user must first acquire one of the domain’s depth 0 items hosted by another domain before they can obtain any depth 1 items that are hosted by this domain.

• A location to store depth 2 items it hosts for other domains.

  These items must not be accessible by visiting the domain alone; a user must first acquire one of the domain’s depth 1 items hosted by another domain before they can obtain any depth 2 items that are hosted by this domain.

The hub will put copies of each hosted item in more than one domain to protect against one getting lost in a misconfigured or impossibly-hard domain. The hub will remove all other copies from its internal tracking once one of the host domains /transfers the item to the user’s "inventory". Because of this, the following sequence is possible:

1. A user /arrives with a given item in their list of prizes.
2. The user journeys to another domain and gets that item there (this is invisible to your domain).
3. The user /arrives again; the item is no longer in their list of prizes.

If you are tracking your own inventory, you should check for this condition to avoid giving them the same hosted item twice.

3.3 Duplicate item names

Item names are in general not unique.

It is quite possible that a user may get an item named "key" in domain 1, and another item named "key" in domain 2, and then travel to domain 3 and try to use key on lock without first getting domain 3’s "key".

Your domain should use the following conventions:

1. Always allow users to specify items by id.

   Example: take 42 should take the item with id = 42.

2. Allow users to specify items by unambiguous names.

   Example: take key should take item 42 if item 42 is the only item in the location with name key.

3. Decide whether to have actions require item IDs or item names.

   Example: use axe on door probably makes sense to work with any item named axe.

   Example: use key on door probably makes sense to work only with one specific item named key.

4. If the user does something that would have worked with a different item with the same name, give a response that makes that clear.

   Example: You don't have a key that fits this lock.

5. If you need a specific item ID, make that item’s description sufficiently complex to likely be unique.

3.4 Multi-player

Each user will get their own copy of the entire game world. In other words, when I play the game, no part of my play experience should depend on what other players are doing.

The hub will track the following information about users:

1. Their inventory.
2. Items they have once held but since dropped, and where they dropped them.
3. The set of domains they’ve visited.
4. A completion score per domain provided by domains they’ve visited in the form of a number between 0 and 1.

This will be used to display a map and scoreboard.

3.5 Praise and Report

When a user finds something about a domain that they think is nifty, they can use the praise ... command to leave a comment for the designer of the domain. These comments have no impact on grades, but will be given to the domain developer after the course completes.

When a user finds something about a domain that they think is broken, they can use the report ... command to leave a comment for the course staff to look into. The report will be accompanied by the log of actions the user has taken. These reports may result in course staff removing points from the project based on failure to implement it correctly.

To help us review the reports, we will group them by their first word. The following opening words are predefined for specific purposes:

• report mp10 if the domain seems to be substantively identical to MP10’s domain.
• report tiny if the domain seems to have very little content.
• report abuse if the domain sends strings that are abusive, triggering, or inappropriate.
• report broken if the domain is violating the basic behavioral norms of the adventure, such as not showing dropped items or not responding to take or look.