Skip to main content

Push-Pull Block Puzzles are Hard

  • Conference paper
  • First Online:
Algorithms and Complexity (CIAC 2017)

Part of the book series: Lecture Notes in Computer Science ((LNTCS,volume 10236))

Included in the following conference series:

Abstract

This paper proves that push-pull block puzzles in 3D are PSPACE-complete to solve, and push-pull block puzzles in 2D with thin walls are NP-hard to solve, settling an open question [19]. Push-pull block puzzles are a type of recreational motion planning problem, similar to Sokoban, that involve moving a ‘robot’ on a square grid with \(1 \times 1\) obstacles. The obstacles cannot be traversed by the robot, but some can be pushed and pulled by the robot into adjacent squares. Thin walls prevent movement between two adjacent squares. This work follows in a long line of algorithms and complexity work on similar problems [3,4,5,6,7,8,9, 14, 16, 18]. The 2D push-pull block puzzle shows up in the video games Pukoban as well as The Legend of Zelda: A Link to the Past, giving another proof of hardness for the latter [2]. This variant of block-pushing puzzles is of particular interest because of its connections to reversibility, since any action (e.g., push or pull) can be inverted by another valid action (e.g., pull or push).

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

Chapter
USD 29.95
Price excludes VAT (USA)
  • Available as PDF
  • Read on any device
  • Instant download
  • Own it forever
eBook
USD 39.99
Price excludes VAT (USA)
  • Available as EPUB and PDF
  • Read on any device
  • Instant download
  • Own it forever
Softcover Book
USD 54.99
Price excludes VAT (USA)
  • Compact, lightweight edition
  • Dispatched in 3 to 5 business days
  • Free shipping worldwide - see info

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

References

  1. Abdelkader, A., Acharya, A., Dasler, P.: 2048 without new tiles is still hard. In: LIPIcs-Leibniz International Proceedings in Informatics, vol. 49. Schloss Dagstuhl-Leibniz-Zentrum fuer Informatik (2016)

    Google Scholar 

  2. Aloupis, G., Demaine, E.D., Guo, A., Viglietta, G.: Classic nintendo games are (NP-)hard. In: Proceedings of the 7th International Conference on Fun with Algorithms (FUN 2014), Lipari Island, Italy, 1–3 July 2014

    Google Scholar 

  3. Culberson, J.C.: Sokoban is PSPACE-complete. In: Proceedings International Conference on Fun with Algorithms (FUN 1998), pp. 65–76. Carleton Scientific, Waterloo, Ontario, Canada, June 1998

    Google Scholar 

  4. Demaine, E.D., Demaine, M.L., O’Rourke, J.: PushPush and Push-1 are NP-hard in 2D. In: Proceedings of the 12th Annual Canadian Conference on Computational Geometry (CCCG 2000), pp. 211–219. Fredericton, New Brunswick, Canada, 16–18 August 2000

    Google Scholar 

  5. Demaine, E.D., Hearn, R.A., Hoffmann, M.: Push-2-F is PSPACE-complete. In: Proceedings of the 14th Canadian Conference on Computational Geometry (CCCG 2002), pp. 31–35. Lethbridge, Alberta, Canada, 12–14 August 2002

    Google Scholar 

  6. Demaine, E.D., Hoffmann, M.: Pushing blocks is NP-complete for noncrossing solution paths. In: Proceedings of the 13th Canadian Conference on Computational Geometry (CCCG 2001), pp. 65–68. Waterloo, Ontario, Canada, 13–15 August 2001

    Google Scholar 

  7. Demaine, E.D., Hoffmann, M., Holzer, M.: PushPush-\(k\) is PSPACE-complete. In: Proceedings of the 3rd International Conference on Fun with Algorithms (FUN 2004), pp. 159–170. Isola d’Elba, Italy, 26–28 May 2004

    Google Scholar 

  8. Dhagat, A., O’Rourke, J.: Motion planning amidst movable square blocks. In: Proceedings of the 4th Canadian Conference on Computational Geometry (CCCG 1992) (1992)

    Google Scholar 

  9. Dor, D., Zwick, U.: SOKOBAN and other motion planning problems. Comput. Geom. 13(4), 215–228 (1999)

    Article  MathSciNet  MATH  Google Scholar 

  10. Flake, G.W., Baum, E.B.: Rush hour is PSPACE-complete, or why you should generously tip parking lot attendants. Theoret. Comput. Sci. 270(1–2), 895–911 (2002)

    Article  MathSciNet  MATH  Google Scholar 

  11. Garey, M.R., Johnson, D.S.: Computers and Intractability: A Guide to the Theory of NP-Completeness. W. H. Freeman & Company, New York (1979)

    MATH  Google Scholar 

  12. Guala, L., Leucci, S., Natale, E.: Bejeweled, candy crush and other match-three games are (NP-) hard. In: IEEE Conference on Computational Intelligence and Games (CIG), pp. 1–8. IEEE (2014)

    Google Scholar 

  13. Hearn, R.A., Demaine, E.D.: PSPACE-completeness of sliding-block puzzles and other problems through the nondeterministic constraint logic model of computation. Theoret. Comput. Sci. 343(1), 72–96 (2005)

    Article  MathSciNet  MATH  Google Scholar 

  14. Hoffman, M.: Push-* is NP-hard. In: Proceedings of the 12th Canadian Conference on Computational Geometry (CCCG 2000), Lethbridge, Alberta, Canada (2000)

    Google Scholar 

  15. Ratner, D., Warmuth, M.K.: Finding a shortest solution for the n \(\times \) n extension of the 15-PUZZLE is intractable. In: Proceedings of AAAI, pp. 168–172 (1986)

    Google Scholar 

  16. Ritt, M.: Motion planning with pull moves. arXiv:1008.2952 (2010)

  17. Savitch, W.J.: Relationships between nondeterministic and deterministic tape complexities. J. Comput. Syst. Sci. 4(2), 177–192 (1970)

    Article  MathSciNet  MATH  Google Scholar 

  18. Wilfong, G.: Motion planning in the presence of movable obstacles. Ann. Math. Artif. Intell. 3(1), 131–150 (1991)

    Article  MathSciNet  MATH  Google Scholar 

  19. Zubaran, T., Ritt, M.: Agent motion planning with pull and push moves. In: Anais do VIII Encontro Nacional de InteligÃłncia Artificial (ENIA), Natal, July 2011

    Google Scholar 

Download references

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to Jayson Lynch .

Editor information

Editors and Affiliations

Appendices

A Additional Details on 2D Push-Pull Block Puzzles Proof

This section provides some additional figures and description to help explain the proof of Theorem 1.

Here we walk through the allowable transitions in the Set-Verify gadget and also address the potential Broken state in the Push-Pull construction which is not in the abstract gadget. In the Unset state, the \(S_i \rightarrow S_o\) transition is the only possibility, changing the state to Set. In the Set state, the \(S_o \rightarrow S_i\) transition is possible, changing the state back to Unset, as well as the \(V_i \rightarrow V_o\) transition, which changes the state to Verified. Finally, from the Verified state, the only transitions possible are \(V_o \rightarrow V_i\), changing the state back to Set, and \(V_i \rightarrow V_o\), leaving the state as Verified. In the Broken state, the only possible transition is \(S_o \rightarrow S_i\), changing the state to Unset. Any time we would enter the Broken state, we could instead enter the Set state, which allows strictly more transitions, and therefore will be strictly more helpful in reaching the goal. The Broken state is not helpful towards reaching the goal, so we will disregard its existence.

For the Set-Verify gadget in the Unset state, the \(S_i\) entrance is the only one which allows the robot to move any blocks. From the \(S_i\) entrance it can traverse to \(S_o\), and it can also pull block 2 down behind them. Doing so will allow a traversal from \(V_i\) to \(V_o\). To traverse back from \(S_o\) to \(S_i\), the robot must first traverse back from \(V_o\) to \(V_i\). Then, when the robot travels back from \(S_o\) to \(S_i\), it must push block 2 back, ensuring the \(V_i\) to \(V_o\) traversal is impossible. Further, access to any sequence of entrances will not allow the robot to alter the system to allow traversals between the \(V_i\) and \(S_i\) entrances.

Fig. 5.
figure 5

Clause gadget, \(C_k\), with variables \(x_a=1\), \(x_b=0\), \(x_c=0\).

Fig. 6.
figure 6

A variable gadget representing \(X_k\) occurring in six clauses, three of those times negated. The value of the variable has been set to true.

Crossover Gadgets. In this section we build up the needed two use crossover gadget from a series of weaker types of crossover gadgets. One may wonder why we need crossover gadgets when Planar 3SAT is NP-complete. This only guarantees that connecting the vertices to their clauses by edges results in a planar graph, it does not ensure that we can navigate our robot between all of these gadgets in a planar manner or that our gadgets themselves are planar. The most obvious issue can be seen in the clause gadget (Fig. 5) where one of the Set Verify gadgets must lie between the other two hallways, but must also be accessible by its associated variable gadget.

Directed Destructive Crossover. This gadget, depicted in Fig. 7a, allows either a traversal from a to \(a'\) or b to \(b'\). Once a traversal has occurred, that path may be traversed in reverse, but the other is impassable unless the original traversal is undone.

First, observe that transitions are initially only possible via the a and b entrances, since the transitions possible through a Set-Verify in the Set state can be entered through \(V_i\) and \(S_o\), not \(S_i\). Assume without loss of generality that the gadget is entered at a. This changes the state of the left Set-Verify to Verified. At this point, only the right \(S_o\) and left \(V_o\) transitions are passable. Taking the \(V_o\) transition either reverts all changes to the original state, or leaves the left crossover in the Verified state, which allows strictly less future transition than the original state. Therefore, we will disregard that option. Taking the \(S_o\) transition changes the right Set-Verify to Unset, and completes the crossover. At this point, the only possible transition is to undo the transition just made, from \(a'\) back to a, restoring the original state. The gadget could be entered via a, but the robot would only be able to leave via a, possibly changing the state to Set. Both options result in the robot exiting out its original entrance, and allow the same or less future transitions, so we may disregard those options. Thus, the only transition possibilities are as stated above.

Fig. 7.
figure 7

Two types of crossover gadgets

In-order Directed Crossover. This gadget, depicted in Fig. 7b allows a traversal from a to \(a'\), followed by a traversal from b to \(b'\). These traversals may also be reversed.

Initially, no entrance is passable except for a, since \(V_o\) is passable only in the Verified state, and \(S_o\) is passable only in the Set state. Once the left \(V_o \rightarrow V_i\) transition is made, the robot has 2 options. It can either change the left Set-Verify gadget’s state to Set, or leave it as Verified. In either case, the \(S_i\) entrance on that toggle is impassable, since a \(S_i\) entrance may only be traversed in the Unset state. The only transition possible on the right crossover is \(S_i \rightarrow S_o\), changing the state from Unset to Set. This completes the first crossing.

Now, there are at most 2 transitions possible: from \(a'\) back to a, undoing the whole process, or entering at b. Note that entering at b is only possible if the left Set-Verify is in the Set state, so let us assume that state change occurred. In that case, the left \(S_o \rightarrow S_i\) transition may be performed, changing the left Set-Verify’s state to Unset. At that point, the only possible transitions are back to b, or through the right Set-Verify’s \(V_i \rightarrow V_o\) transition, completing the second crossover.

Fig. 8.
figure 8

The two use directed crossover is constructed from a directed destructive crossover and two in-order directed crossovers.

If the left Set-Verify was left in the Verify state, strictly less future transitions are possible compared to the case where it was changed into the set state, so we may disregard that possibility.

Two Use Directed Crossover. The Two Use Directed Crossover, depicted in Fig. 8, is the gadget needed for our proof. It allows a traversal from a to \(a'\) followed by a traversal from b to \(b'\), or from b to \(b'\) and then a to \(a'\). These transitions may also be reversed.

It is constructed out of an In-order Directed Crossover gadget and a Destructive Directed Crossover, as shown in Fig. 8. The a to \(a'\) traversal is initially passable, and goes through both gadgets, blocking the destructive crossover but leaving the in-order crossover open for the b to \(b'\) traversal. If the a to \(a'\) traversal does not occur, the b to \(b'\) traversal is possible via the destructive crossover.

Because of the behavior of the constituent crossovers which make up this gadget, no transition from a to b a to \(b'\), etc. is possible. The crossover permits reversal of each of the transitions described, but the crossings can only be reversed in queue order (last in, first out).

Two Use Crossover. Four Directed Crossovers can be combined, as shown below, to create a crossover that can be traversed in any direction [4]. This is not necessary for our proof but is shown for general interest. Unfortunately, the inability to go through this gadget multiple times in the same direction without first going back through means it likely isn’t sufficient for PSPACE-completeness.

B 3D Push-Pull is NP-hard

In this section we prove that 3D Push-k Pull-l with fixed blocks is NP-hard, for all positive k and l. All of the hard work was done in Sect. 2. Here we will simply show how we can use the additional dimension to tweak the previous gadgets to build them without thin walls. We reduce from 3SAT, constructing our variables from chains of 3D Set-Verify gadgets, and our clauses from the verify side of the corresponding 3D Set-Verify gadget.

Theorem 4

3D Push-k Pull-l with fixed blocks is NP-hard, for all positive k and l.

Proof

We follow the proof of Theorem 1 using a modified Set-Verify gadget, shown in Fig. 9. It can be easily checked that this has the same properties as the Set-Verify given in Sect. 2. The cyclic ordering of the entrances in the 3D Set-Verify is different from that of the 2D Set-Verify, however this is not important as we no longer need to construct crossovers. Also, this construction does not use thin-walls. While this was critical in the prior construction due to the need for closely packed turns, the additional dimension allows enough freedom to keep separate hallways from being adjacent to each other. With a functional Set-Verify gadget, the remaining constructions of variables and clauses proceeded as in Sect. 2. No crossover gadgets are needed since we are working in 3D. Finally, we note that all blocks are in hallways of length at most 3, thus the gadgets still function as described for any positive push and pull values.

Fig. 9.
figure 9

A Set-Verify gadget in 3D where the entrances and exits extend upward, notated by the diagonal arrows. This gadget is in the unset state.

C Additional Details on PSPACE-Completeness Proof

This section provides some additional figures and description to help explain the proof of Theorem 2.

Fig. 10.
figure 10

3D diagrams of 4-toggles. Red spheres are blocks and blue surfaces are impassable. (Color figure online)

Fig. 11.
figure 11

Diagram of a lock. The 3a to 4a traversal is only possible in state A and returns the toggle to state A.

Fig. 12.
figure 12

An existential gadget.

Binary Counter. Universal quantifiers must iterate through all possible combinations of values that they can take. In this section we construct a gadget that runs though all the states of its subcomponents as the robot progresses through the gadget. This construction will serve as the base for our universal quantifiers.

Fig. 13.
figure 13

The central portion of a three bit binary counter made from 2-toggles.

A binary counter has a fixed number of internal bits. Whenever the binary counter is traversed in the forwards direction, the binary number formed by the internal bits increases by one and the robot leaves via one of the exits. If the binary counter is traversed in the reverse direction, the internal value is reduced by one. If the binary counter is partially traversed, but then the robot leaves via its initial entrance, the internal value does not change.

The binary counter is implemented as a series of 2-toggles, as shown in Fig. 13. To see that this produces the desired effect, identify a toggle in state A as a 0 bit, and a toggle in state B as a 1 bit. Let the entrance toggle’s bit be the least significant bit, and the final toggle be the most significant. When the robot enters the binary counter in the forwards direction, it will flip the state of every toggle it passes through. When it enters a toggle that is initially in state B, and thus whose bit is 1, it will flip the state/bit and proceed to the next toggle, via the \(2B - 2A\) pathway. When it encounters a toggle that is initially in state A / bit 0, it will flip the state/bit and exit via the \(1A - 1B\) pathway. Thus, the overall effect on the bits of the binary counter is to change a sequence of bits ending at the least significant bit from \(01\ldots 11\) to \(10\ldots 00\), where the entrance is at the right. This has the effect of increasing the value of the binary counter by one. We will not examine the reverse transitions or rigorously complete the binary counter here, as we do not use it directly in the final construction.

Analysis of the Quantifier Chain. A quantifier chain is implemented much like a binary counter, with some additions. Every universal variable will be represented by a 2-toggle and many locks, where individual locks will serve as a literal. The 2-toggles are hooked up in the same manner as the 2-toggles in a binary counter gadget. This forces the 2-toggle and many locks gadgets to be set to the corresponding values in the simulated binary counter.

Traversing the quantifier chain in the reverse direction is only possible if the robot enters via the lowest order universal toggle whose setting is 1. The traversal will go back one setting in the sequence of possible settings of the universal variables, and allow the robot to set all existential variables corresponding to altered universal variables arbitrarily. No other existential variables can be changed.

There is also a special exit, the overflow exit, which can only be reached after all of the universal variable settings have been traversed. This is the goal location for the robot.

The next addition is the existential variables, which consist of existential gadgets placed just after the 2A exits of each universal variable, and just before the 1A and 2B entrances of the next universal variable, as shown in Fig. 4.

One portion of the apparatus which has not been analyzed thus far is the potential for the robot to re-enter the chain of existentials via a different exit pathway than the one just exited. This would be problematic if the robot re-entered via a universal gadget it had not just exited, both because the robot should not be able to take any action other than reversing its prior progress, decrementing the binary counter/universal quantifiers. Problems would also arise if the robot got access to any existential quantifiers it did not just traverse.

After a traversal, the universal quantifiers have the settings \(\ldots ??10\ldots 00\), where the lowest significance 1 is on the pathway just exited. To prevent the robot from re-entering via any pathway other than the one just exited, we add a series of locks to each exit that are only passable if all lower-significance universal toggles are in state 0, as shown in Fig. 4. This does not impede the exit that the robot uses initially, since all lower-significance universal toggles are indeed 0. These locks do prevent re-entry into any higher-significance universal toggles, since the lock corresponding to the lowest-significance 1 will be closed. The robot cannot re-enter via any toggle that is in state 0, due to the arrangement of the toggle pathways. Thus, the unique re-enterable pathway is the lowest-significance toggle in state 1, as desired.

Rights and permissions

Reprints and permissions

Copyright information

© 2017 Springer International Publishing AG

About this paper

Cite this paper

Demaine, E.D., Grosof, I., Lynch, J. (2017). Push-Pull Block Puzzles are Hard. In: Fotakis, D., Pagourtzis, A., Paschos, V. (eds) Algorithms and Complexity. CIAC 2017. Lecture Notes in Computer Science(), vol 10236. Springer, Cham. https://doi.org/10.1007/978-3-319-57586-5_16

Download citation

  • DOI: https://doi.org/10.1007/978-3-319-57586-5_16

  • Published:

  • Publisher Name: Springer, Cham

  • Print ISBN: 978-3-319-57585-8

  • Online ISBN: 978-3-319-57586-5

  • eBook Packages: Computer ScienceComputer Science (R0)

Publish with us

Policies and ethics