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

[Stefan Majewsky]

Am Dienstag 20 Oktober 2009 19:04:20 schrieb Matthew Woehlke:
> Okay, I am too lazy to use blog comments ;-).

I sympathize with you, esp. for such long texts. ;-)

> Please don't take the following long lists of gripes the wrong way. My
> overall impression was quite favorable.

As long as the gripes are constructive (which yours definitely are), I'm fine. 
(Even if grapes would be more desirable... Hmm... grapes.)

> 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.

Hm, I never had the idea to _not_ make it behave in the way it does now, 
although I might add an "easy mode" in which a faint impression of the final 
image appears at the bottom of the puzzle table, with pieces snapping to their 
position in this preview.

> - 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.

The default background is the default because it was the only one when I added 
background textures. Also, it is the only one created by a KDE artist: Eugene, 
who drew it at a time when Palapeli did not support background textures yet, 
so he had no chance of testing it. My friends and I usually call this texture 
the "80s wallpaper", and I consider it an integral part of the Palapeli 
experience. ;-)

Apart from these explanations, my hands are tied when it comes to creating 
softer backgrounds, 'cause I'm not a graphics designer.

> - 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.

Good idea. The X-Y selection is there because it's more straight-forward.

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

Has been selled for performance. I'm not sure whether QGraphicsView does 
smooth shading for QGraphicsPixmapItems at all.

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

Palapeli's puzzle files contain pre-rendered raster images. That's a design 
decision: I want puzzle files to be easy, portable and self-contained.

> - 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.

It says "image author" on purpose. Putting the image into a Palapeli slicer is 
not really an action that deserves attribution (at least when compared to 
creating the image).

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

Yes, bug. This problem will disappear when I rewrite the zooming and arranging 
stuff.

> - 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).

Hm, this shouldn't happen, but I have an idea why the algorithm could fail. 
Could you please test whether the jigsaw slicer generates better results with 
the attached patch applied? (You will have to rebuild the puzzles. Puzzles 
that have already been built won't change anymore.)

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

You mean the thin lines between them? I cannot reduce them more, and have 
started to think of them as a feature: It allows you to distinguish assembled 
pieces just as you can in real life, because normal piece edges are rounded.

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

Are you trying to delete one of the default puzzles? If no, how did you create 
the puzzle? And do you have write access to the puzzle file?

> 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.

Already on the list: "baskets". Whenever you want to separate a bunch of 
pieces from the rest, you create a basket and throw the pieces into it. Then 
you can either continue with the rest, or look into the basket and put the 
pieces in there together. (As you see, "baskets" is a bad name. It's highly 
non-obvious to play a jigsaw puzzle in a basket.)

> - 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.

Grid: Of course not. More reality in slicing: I'm focussing on other things 
currently. The current slicing is good enough for the start, though more 
reality is desirable.

> - 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.

Palapeli has infrastructure for "puzzle feeds", which provide a similar (yet 
better integrated) functionality. Unfortunately, there will not be enough time 
left for an interface to these. This gives me time to think about how to 
generate puzzles from images on the fly.

> Lastly, I'm not particularly interested in building playground/games.
> Any objection to the following patch?
> 
> Index: CMakeLists.txt
> [...]

I'm afraid that some build-system guy would complain about this kind of stuff, 
because it's not how it is supposed to be done, so for now I kindly ask you to 
keep this in your working copy. Alternatively, you can use a setup similar to 
mine, which is described on my blog (http://majewsky.wordpress.com, then the 
link at the very top right).

Greetings
Stefan

-- 
Die Zukunft wird nicht gemeistert von denen, die an der Vergangenheit kleben.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jigsawslicer-better-scale-behavior-on-nonsquare-pieces.diff
Type: text/x-patch
Size: 3469 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-games-devel/attachments/20091021/7293b8a6/attachment.diff 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-games-devel/attachments/20091021/7293b8a6/attachment.sig