Bug 211864 - make pieces rotateable to increase the difficulty
Summary: make pieces rotateable to increase the difficulty
Status: CONFIRMED
Alias: None
Product: palapeli
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE Unspecified
: NOR wishlist
Target Milestone: ---
Assignee: Stefan Majewsky
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-26 00:12 UTC by Stefan Majewsky
Modified: 2014-09-05 19:40 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Majewsky 2009-10-26 00:12:27 UTC
Version:            (using KDE 4.3.2)
Installed from:    openSUSE RPMs

[This feature request has been imported manually from a todolist in SVN.]

It should optionally be possible to make pieces rotateable, to increase the difficulty of the puzzle and to make it feel more realistic.
Comment 1 uetsah 2010-05-20 13:53:59 UTC
If this wish is still being considered, I'd like to contribute my 2 cents regarding how this could possibly be integrates with Palapeli:

A) Single-clicking (but not dragging) a piece that's already selected rotates it 90 degrees clockwise. (Since the puzzle pieces are rectangular-based, this should suffice - right?)

B) The currently selected piece gets rotation markers drawn around it, which can be dragged to freely rotate it around it's center. (For 100% realism. See Inkscape, which has implemented rotation of items in this way.)

Just in case you're still trying to think of the best way to do this...
Comment 2 Stefan Majewsky 2010-05-20 15:30:25 UTC
(In reply to comment #1)
> Just in case you're still trying to think of the best way to do this...

Yes, this is not decided yet, and as of now, Inkscape-like rotation markers seem to be the best way of implementing a rotation interface on non-multitouch devices.

> A) Single-clicking (but not dragging) a piece that's already selected rotates
> it 90 degrees clockwise. (Since the puzzle pieces are rectangular-based, this
> should suffice - right?)

No. There are already slicers that create non-rectangular pieces (http://code.google.com/p/palapeli-goldberg-slicer), and one of Palapeli's most fundamental design decisions is that it does not make any assumption about the inner structure of the puzzles. Palapeli's internal picture of puzzles boils down to:

1) a bunch of piece images, and their location within the complete image
2) a list of neighborship relations (i.e. A is adjacent to B), which is used for snapping
Comment 3 Johannes Loehnert 2010-07-04 22:06:43 UTC
another $0.02:
- interface: +1 for rotation markers (I envisioned a transparent circle around the piece with a knob at the 12 o'clock position); as well as rotation left and right on leftclick / rightclick (configurable of course). whatever it is, it should be discoverable without reading the manual.

- fixed steps: could a property be added to SlicerJob to set a proposed rotation step (e.g. 60° for hexagonal pieces, 90° for rect pieces, 0° for irregular puzzle)? The proposal could also be used when shuffling the puzzle. I realize this means extending the puzzle file and savegame formats; however that must be done anyway to remember the rotation angles.
Comment 4 Matthew Woehlke 2014-08-01 13:12:00 UTC
> fixed steps: could a property be added to SlicerJob to set a proposed rotation
> step (e.g. 60° for hexagonal pieces, 90° for rect pieces, 0° for irregular
> puzzle)?

I think you mean <small number> for irregular pieces; 0° would not work :-). (Maybe 15°?)

Obviously, snapping would only work if the difference in piece rotation is smaller than some threshold. (The implementation of determining if the relative position is correct, which I guess is how things currently work, may already suffice once modified to account for rotation, as would be necessary.)
Comment 5 Matthew Woehlke 2014-09-05 18:45:12 UTC
Also, it is probably possible to guess the rotation angle for an existing puzzle by analysis of the angles made by connecting adjacent pieces. As far as saves, it should be necessary only to support a 'without rotation' mode (in fact, might want to do that anyway) such that old saves can still be used.
Comment 6 Ian Wadham 2014-09-05 19:40:24 UTC
If I had time, which I don't, I would implement rotation by making it a part of shuffling, i.e. pick a random number for each piece in the range 0 to 359.

I already modified the save-file format considerably for Palapeli v2, in which pieces can be in holders as well as the puzzle table, but I believe the code will accept old save-formats.  The co-ordinates of pieces, relative to the puzzle table or the holder they are in, are held simply as lines reading <piece_number>=<pair_of_numbers>.

That could become <piece_number>=<trio_of_numbers>, with the third number being the rotation.  It would default to zero for backwards compatibility.