Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

waypoints and portals #1356

Merged
merged 3 commits into from
Jul 12, 2023
Merged

waypoints and portals #1356

merged 3 commits into from
Jul 12, 2023

Conversation

kostmo
Copy link
Member

@kostmo kostmo commented Jul 2, 2023

Portals are a prerequisite to subworlds (#144).

However, portals as a first-class feature have utility that is independent of subworlds. The Hackman scenario (#1135), for example, currently has to provide redundant implementations of portal logic for the base robot and for system robots. Furthermore, the locations specified in these bespoke portal implementations are hard-coded in the .sw file, so are brittle with changes to the map.

Demos

scripts/play.sh --scenario data/scenarios/Testing/1356-portals/automatic-waypoint-patrol.yaml

image

scripts/play.sh --scenario scenarios/Testing/1356-portals/portals-flip-and-rotate.yaml --autoplay

image

Portal and waypoint semantics

Waypoints

Waypoints are introduced as an intermediate abstraction to better accommodate substructures.

A waypoint command, independent of portal mechanics, is also introduced to allow system robots to query named locations.

  • Waypoints may be defined either in a standalone list (as a sibling field to the map), or within the map via the palette.
    • An object notation is now supported as an alternative to, and backwards compatible with, the list notation for palette values.
    • Using the palette to define waypoints is typically more convenient, as it allows specification of both a waypoint and an entity which can be used to depict the waypoint location.
  • Waypoints can be defined at the root level or within "substructures".
  • In contrast with "destructive" entity overlay from overlapping substructures, waypoints are aggregated from all substructures, even when overlapping.
  • Multiple waypoints under different names can exist at the same location. I.e. waypoints can have plural multiplicity.
    • Uniqueness of locations for a given waypoint name is not enforced unless the unique flag is set to true for one of the instances of that waypoint name.

Portals

  • Portals are defined as (entrance, exit) pairs of waypoints.
    • The entrance is a bare waypoint name, but the exit is a waypoint name paired with an optional subworld name. Omitting the subworld name implies a portal that exits to the same subworld as its entrance.
  • Portals can have multiple entrances but only a single exit.
  • A waypoint with multiplicity > 1 will result in multiple portals (all to the same exit) when specified as an entrance.

Obstructions

  • Portal entrances can be blocked, which will prevent movement into the portal. Portal exits are not checked for obstructions when traversing the portal.

Other musings

  • Should some robots not be able to go through portals? e.g. based on capability (c.f. The Terminator which needs an organic skin covering)
  • We could keep track of how many times a robot has passed through a portal in its internal state. Is there a use for such a statistic?
    • Come to think of it, there are other figures that may also be interesting to track, such as total distance moved.

@kostmo kostmo mentioned this pull request Jul 2, 2023
@kostmo kostmo force-pushed the feature/portals branch 6 times, most recently from a56f824 to 213cd25 Compare July 3, 2023 05:53
@kostmo kostmo marked this pull request as ready for review July 3, 2023 05:54
@kostmo kostmo requested a review from byorgey July 3, 2023 05:54
@byorgey
Copy link
Member

byorgey commented Jul 3, 2023

Looks fun! I'm travelling but hope to be able to look at this within the next few days sometime.

Copy link
Member

@byorgey byorgey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks cool! Just a few questions/comments.

test/integration/Main.hs Show resolved Hide resolved
src/Swarm/Game/Step.hs Show resolved Hide resolved
correctedWaypoints =
binTuples $
map
(\x -> (wpName $ wpConfig $ value x, fmap (offsetWaypoint upperLeft) x))
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using the upperLeft here as a vector to apply an offset

@kostmo kostmo added the merge me Trigger the merge process of the Pull request. label Jul 12, 2023
@kostmo kostmo merged commit cfb1e92 into main Jul 12, 2023
7 checks passed
@kostmo kostmo deleted the feature/portals branch July 12, 2023 01:58
@kostmo
Copy link
Member Author

kostmo commented Jul 12, 2023

Oops, mergebot got stuck so I clicked the merge button. Should have manually rebased first to pre-empt the breakage.

mergify bot pushed a commit that referenced this pull request Jul 12, 2023
mergify bot pushed a commit that referenced this pull request Jul 22, 2023
Closes #144.

This builds upon portals support (#1356)

# Demo

    scripts/play.sh --scenario data/scenarios/Testing/144-subworlds/subworld-mapped-robots.yaml --autoplay --speed 2

[![asciicast](https://asciinema.org/a/vC13dW8M1S8t2b1J4XkW80U1q.svg)](https://asciinema.org/a/vC13dW8M1S8t2b1J4XkW80U1q)

# Future work
* Augment portal definitions with an optional "relative orientation" attribute, that can turn the player around when passing through the portal (#1379)
* Specify whether portal performs instant transportation or whether `move down` is required (#1368)
mergify bot pushed a commit that referenced this pull request Nov 22, 2023
Previously, the logic to wrap horizontally was hand-coded, both for the player (using a dedicated monitor robot) and for ghosts (who, as system robots, implemented the teleportation themselves).

Now that we can use built-in portal functionality (#1356), no custom logic is needed to handle the teleportation.  A (much-simplified) monitor robot still observes the base robot to award the hidden "World wrap" goal.

## Demo

    scripts/play.sh -i data/scenarios/Challenges/hackman.yaml --autoplay --speed 6
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merge me Trigger the merge process of the Pull request.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants