[Kde-games-devel] The State of KNetwalk

Parker Coates parker.coates at gmail.com
Tue Dec 15 02:31:18 CET 2009


On Mon, Dec 14, 2009 at 19:40, Matthew Woehlke wrote:
> Parker Coates wrote:
>> I guess I don't really understand why having some puzzles with big
>> holes in them and others that are barely "shuffled" is a good thing.
>> It just seems to result in one sometimes getting lucky and getting an
>> especially easy game, which I don't really think captures the spirit
>> of KNetwalk either.
>
> "Big holes"? Do you mean you've seen more than one hole? I can't say I
> have, but I don't see a reason not to forbid layouts with more than a
> certain (very small) percentage of holes. Say, 2-4 on Hard. But I don't
> see a problem with having one tile empty.

I've definitely seen cases with at least a 8 adjacent empty tiles,
which can be a serious advantage. Even a single empty tile can be a
pretty major head start when playing a very hard game as it
immediately gives you four "edges" to work from. Of course, I've never
seen anything as drastic as the situation shown in that bug report
where the majority of the board is vacant.

Basically, I don't see vacant tiles as adding anything to the game.
The majority of layouts don't contain any, so it seems a bit weird
when they do show up. If each difficulty level had a set number of
empty cells, then at least it would be an intentional feature.
Currently, it just feels like an anomaly.

> I also officially do not object to ensuring that a certain % of tiles
> are not in the correct position. I don't really agree with trying to
> equalize the type of wrong rotation, though.

To be entirely honest, I doubt anyone would notice if the number of
left-clicks and right-clicks was suddenly always equal, but you're
probably right that it would be overkill. My main concern here was
making sure that we don't waste a 180 degree "shuffle" on a straight
piece. I also thought that if every Hard level required the exact same
number of moves to win, it would make calculating the move penalty
much simpler. Honestly I haven't really examined how KNetwalk handles
these things currently, so some of what I'm planning might already be
in there.

> (On a related note, my Android port of netwalk counts a "click" as any
> number of consecutive rotations of a piece. Probably a good thing since
> it is much easier to play by touch, and that really only provides one
> direction of rotation.)

As I footnoted in my original mail, I created a similar patch for
KNetwalk over a year ago, but sadly it was neither accepted, nor
rejected. I recently found it while cleaning up my inbox, which is
what prompted me to write this mail in the first place.

Parker


More information about the kde-games-devel mailing list