[Kde-games-devel] The State of KNetwalk

[Matthew Woehlke]

Parker Coates wrote:
> 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.

Yes, that's ridiculous. One is IMO usually okay (though still an 
advantage), two maybe... three is really pushing it though.

I played a bit more, recently, and did see a game with maybe four empty 
spaces.

To clarify my objection, I'm not sure I am in favor of *eliminating* 
holes, but limiting the count to something sane (maybe two) sounds like 
a very good idea.

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

That makes sense. Actually, I guess I would be okay if the number of 
mis-rotated pieces was roughly constant. (Maybe it should be, even, 
though that's still not all of what affects the difficulty. I wouldn't 
make it *exactly* constant, but within a reasonable range would be okay 
I think. I also don't think I would make it number of 90° rotations 
needed, but rather pieces that need to be rotated.)

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

I thought about this a bit more. One problem with counting all rotations 
of a piece as 1 is it penalizes you for moving a piece in a way that is 
either right, or one rotation closer to right (such as when you know an 
elbow must connect to a certain edge), which can help with solving a board.

So instead, maybe when you rotate a piece, start a short timer, and 
don't count the rotation until the timer expires. (Clicking another 
piece would expire it early; clicking again would restart it.) When it 
expires, count for the number of rotations relative to the position when 
the timer was started, or two in case of no change (so you can't cheat 
and change your mind). This was a triple click because you rotate the 
wrong way as intended will only count as 1, but you aren't penalized for 
two rotations (when the piece was 180° from correct) with other moves in 
between.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"It's not easy for [Microsoft] to accept [competing fairly]"
   -- Dave Heiner (a Microsoft VP, paraphrased)