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.

Sign up for GitHub

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

Jump to bottom

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 •
edited
Loading

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
Merged
@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
@kostmo kostmo force-pushed the feature/portals branch from 213cd25 to 046e85c Compare July 3, 2023 06:13
@kostmo kostmo force-pushed the feature/portals branch from 046e85c to c9a89db Compare July 3, 2023 06:15
@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.

byorgey
byorgey approved these changes Jul 12, 2023
View reviewed changes
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
data/scenarios/Testing/1356-portals/automatic-waypoint-patrol.yaml Show resolved Hide resolved
src/Swarm/Game/Scenario/Topography/Navigation/Portal.hs Show resolved Hide resolved
@kostmo kostmo mentioned this pull request Jul 12, 2023
Open
kostmo
kostmo commented Jul 12, 2023
View reviewed changes
src/Swarm/Game/Scenario/Topography/Navigation/Portal.hs
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
@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.

This was referenced Jul 12, 2023
Merged
Open
mergify bot pushed a commit that referenced this pull request Jul 12, 2023
@kostmo
merge fixup (#1367)
8548e4f 
See #1356 (comment)
mergify bot pushed a commit that referenced this pull request Jul 22, 2023
@kostmo
subworlds (#1353)
f9c2263 
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)
@kostmo kostmo mentioned this pull request Nov 22, 2023
Merged
mergify bot pushed a commit that referenced this pull request Nov 22, 2023
@kostmo
use built-in portal functionality for Hackman scenario (#1651)
40f26df 
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
@kostmo kostmo mentioned this pull request Jan 4, 2025
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@byorgey byorgey byorgey approved these changes

Assignees
No one assigned
Labels
merge me Trigger the merge process of the Pull request.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@kostmo @byorgey