[Kde-games-devel] How do you play jigsaw puzzles

[Matthew Woehlke]

Okay, I am too lazy to use blog comments ;-).

Please don't take the following long lists of gripes the wrong way. My 
overall impression was quite favorable. In particular, I am very pleased 
that you avoid the typical mistake that pieces snap to their final 
positions, rather than each other. Real life doesn't work this way, but 
many computer jigsaw games have absolute places that define a piece's 
"final position", and will lock pieces into place if you can position 
them correctly.

I also like the use of a background texture for the table, and most of 
the textures are fairly good (see comment below).

We obviously don't have the technology to capture the exact same tactile 
sensation as doing a physical jigsaw, but you've succeeded in making a 
virtual version that feels comfortably similar (unlike, as above, many 
computer jigsaw games I've tried).

The most important changes I would like to see (these will be covered in 
more detail below) are:

- Pieces can rotate, and don't all start at the correct rotation

- Ability to quickly sort pieces into multiple "piles"/"boxes"

- Better puzzle creation (number of pieces, not per direction)

- Better default background, "softer" backgrounds in general


What I don't like:
==================

- Pieces don't rotate :-). Having all the pieces correctly rotated 
reduces the challenge somewhat.

- The default background ;-). I could use something that's a similar 
color, but the geometric texture doesn't say "table" to me. The others 
are all very nice, though all could use a bit less contrast. I think in 
general the table should have very, very low contrast (though it's good 
that it does *have* texture!). In fact, you might want to consider 
plugging a multi-octave perlin noise generator on top of the ability to 
choose any color for the table.

- Creating puzzles by number of pieces in X,Y direction. Please just 
give us approximate number of pieces, and let the slicer decide based on 
that, and the input image's aspect ratio. I accidentally made a 10x10 
puzzle out of a 16:5 image... and I think some slicers (see below) won't 
be well defined by such dimensions.

- No smooth shading when zooming in... pixels become quite obvious.

- Puzzle pieces are raster; vector would be prettier. (Something to 
maybe improve some time in the future...)

- Puzzle author is mandatory. Am I the author because I picked an image, 
slicer, and number of pieces? That doesn't seem right. And if I get an 
image off the internet, there is a very good chance I don't know who 
produced that image.

Bugs?
=====

- Changing the table size doesn't seem to work with a puzzle in progress.

- Severely deformed pieces can have overlapping cutouts, leading to XOR 
effects. Try making a puzzle with a bad aspect ratio (e.g. 3x as many 
pieces horizontally as vertically on a square image) and you should be 
able to reproduce this. However, other than violating some laws of 
physics, this didn't seem to break anything. This can probably be 
avoided by creating puzzles by total number of pieces instead (as 
suggested above).

- There is still a small bit of artifacting on pieces that are put 
together. (It's not bad, though.)

- Delete puzzle doesn't appear to be hooked up.

Future ideas:
=============

- One technique I've often seen for doing puzzles is to separate the 
table from one or more boxes of pieces. This helps to categorize; you 
can toss all pieces that are, for example, a similar color into one box. 
  I think it would be helpful to have a feature that would configure one 
or more "boxes", or even just piece groups, and a way to quickly move 
pieces (e.g. just by clicking on them) to a group. Anything sent to that 
group should then be clustered in close proximity, but not overlapping.

- Better random slicer. First off, I hope slicers don't have to lay 
pieces out in a grid (I think no?). What would really make palapeli rock 
is ability to cut pieces like real puzzles where pieces can be three or 
five sided, slightly offset, etc. Studying real jigsaws would be a 
source of many good ideas.

- Tessellating slicers :-D. Salamanders and snowflakes, to start with, 
but there are plenty of Escher shapes that can be used as well as 
regular tessellations (Escher makes for better material though because 
the pieces aren't just simple polygons).

- Get new images from kde-look.org. Seriously, a large percentage of 
wallpapers would make decent puzzles as well, and kde-look is a ready 
source of such.


Lastly, I'm not particularly interested in building playground/games. 
Any objection to the following patch?

Index: CMakeLists.txt
===================================================================
--- CMakeLists.txt      (revision 1038078)
+++ CMakeLists.txt      (working copy)
@@ -1,5 +1,14 @@
  project(palapeli)

+find_package(Qt4 REQUIRED)
+find_package(KDE4 REQUIRED)
+find_package(LibKDEGames REQUIRED)
+
+include_directories(${KDE4_INCLUDES})
+include_directories(${KDEGAMES_INCLUDE_DIRS})
+
+include(KDE4Defaults)
+
  add_subdirectory(libpala)
  add_subdirectory(cmake)
  add_subdirectory(slicers)
===================================================================

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
So, an astrophysicist, a quantum physicist, and an astrologer walk into 
a bar...