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

Add puzzle 012 #19

Merged
merged 7 commits into from
Feb 24, 2024
Merged

Add puzzle 012 #19

merged 7 commits into from
Feb 24, 2024

Conversation

kflorence
Copy link
Owner

This puzzle further strengthens the rules introduced in previous portal puzzles. It is also the most difficult portal puzzle to this point.

This PR also includes a number of other bug fixes and improvements:

  • Beam step-specific state (which is ultimately stored in the terminal opening state configuration, which is the basis for beam state configuration) has been refactored so that it is attached to specific steps and will be automatically added and removed when the steps are added and removed. This state is currently only used by portals, but could be used by other things in the future.
  • Items can now specify 'immutable' in the state configuration, which should basically act the same as setting each individual modifier key to false (e.g. movable, toggleable, rotatable, etc.). Beam and wall items will have immutable set by default.
  • Item IDs are now retained in cache, making them stable IDs. Previously, item IDs were re-generated when the page was refreshed, which meant that if an item had been moved its ID could change. The generation and storage of item IDs on the loading of a puzzle is not stored as a delta, so it won't show up as a move and won't be undo-able.
  • Swap now requires tiles to contain movable items, instead of any items.
  • Masks are now re-evaluated when dequeued, with the potential to cancel the mask. This is because state can change in between when the mask is queued and when it gets processed. For example, if multiple portals are reached at the same time, the resolution of one of the portals may cause a subsequent portal mask to no longer be valid.
  • The tile indicator has been refactored to apply an "is not immutable" filter. The primary purpose of the indicator is to show the user they can interact with something in that tile, and immutable modifiers are not interactable, so it just creates noise. The lock and immutable modifiers mostly apply when moving something anyways.
  • Fixed getting color elements for a newly selected tile, if it contained merge beams it was throwing an error using because it was using step.color instead of step.colors (which is an array).
  • Updated the portal collision logic in beam.onCollision was not handling every case.
  • Fixed state index not being updated correctly if keepDelta was false on state update.
  • Fixed state actions like undo and redo not being properly prevented even if they were disabled visually. The reset action is also now being disabled in cases where it should be.
  • Fixed the puzzle mask queue not being emptied when the puzzle was reloaded, which caused some strange undo/redo behaviors.

When there are multiple options for an exit portal, the user must
decide, and the decision gets stored in beam state. That state was only
being cleared when the beam was turned off, but it should be cleared
whenever the step that decision is related to changes (for example, if
the entry portal is rotated).

This also cleans up the storage of these decisions in beam state, moving
them into a portal specific key that the portal item will maintain.
After adding the ability to 'merge beams' using a single exit portal,
I've noticed it introduces some unintended complexity such as allowing a
single beam to merge into itself over and over. Perahaps instead of
adding more complexity to check the beam to make sure it isn't self,
this functionality should instead be split into a separate item which
allows for the merging/splitting of beams, and portals should retain
their much simpler 'only one beam can exist in a given direction at a
time' rule.
Items can now specify 'immutable' in the state configuration, which
should basically act the same as setting each individual modifier key to
false (e.g. movable, toggleable, rotatable, etc). Beam and wall items
will have immutable set by default.

Item IDs are now retained in cache, making them stable IDs. Previously,
item IDs were re-generated when the page was refreshed, which meant that
if an item had been moved its ID could change. The generation and
storage of item IDs on the loading of a puzzle is not stored as a delta,
so it won't show up as a move and won't be undo-able.

Portal logic has been reverted back to just checking if a direction is
already occupied. This means beams cannot be merged through an exit
portal. That functionality will be added later as a separate item.
Additionally, portal directions cache is now cleared if a portal is
moved, since the beams connected to that portal will need to re-evaluate
their histories.

Swap now requires tiles to contain movable items, instead of any items.
This allows the mask to be re-evaluated when it gets dequeued, with the
potential to cancel the mask. This is because state can change in
between when the mask is queued and when it gets processed. For example,
if multiple portals are reached at the same time, the resolution of one
of the portals may cause a subsequent portal mask to no longer be valid.
Still needs test coverage, but I have confirmed that it is solvable as
is. An additional change in this commit is the addition of an "is not
immutable" filter for modifiers when displaying the indicator badge on
tiles. I think the primary purpose of the indicator is to show the user
they can interact with something in that tile, and immutable modifiers
are not interactable, so it just creates noise. The lock and immutable
modifiers mostly apply when moving something anyways.
This also fixes a few bugs:
- when getting color elements for a newly selected tile, if it contained
  merge beams it was throwing an error using step.color instead of
  step.colors.
- the portal collision logic in beam.onCollision was not handling every
  case.
- state index wasn't being updated correctly if keepDelta was false on
  update.
- state actions like undo and redo weren't properly prevented even if
  they were disabled visually. The reset action was also never disabled
  in cases where it should be.
- the puzzle mask queue was not being emptied when the puzzle was
  reloaded, which caused some strange undo/redo behaviors.
@kflorence kflorence merged commit d50916f into main Feb 24, 2024
1 check passed
@kflorence kflorence deleted the 012 branch February 24, 2024 01:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant