Walker skill cancels, then always turns?

[ccexplore]

I'm not happy with either design (keep-0.6-walker or the proposed walker-always-turns) for the idempotence violation. Clicking 1 time should have almost the same effect as clicking several times. I find that far more important than the proposed simplification.

Well, I suppose you can explicitly change the single walker skill into separate "walk left now" and "walk right now" skills.  It would provide idempotence without completely removing the ability to turn (or mere cancel in other cases).  But somehow I suspect no one will find that proposal appealing.   And cancel-only is boring, so perhaps in this case, better gameplay trumps principles?

[geoo]

I think Simon asked for my opinion, so I'm writing a few comments below.

Initially I thought the proposed walker change would have huge backroute potential, but it doesn't seems like that after some consideration and the discussion above. Still, it's not something that can be automatically checked.

I only see a minor increase in conceptual simplicity with the change, I think the amount of time it takes to learn the skill is not going to differ much.

As for functionality, it's hard for me to judge which is more desirable. I can see a slight advantage of the new behaviour with builders and platformers (behaviour is consistent even during and after shrugging), before it was possible to turn a builder/platformer after shrugging, but it was very precise. My hunch is that if you cancel a builder/platformer, often you don't want it to walk off the (possibly deadly) ledge in puzzle mode. In multiplayer mode I believe I do use the current behaviour however to speed up the Lix once the bridge is long enough, though jumpers work there just as well. Applied to blockers I see the above argument that especially near a ledge, you'll want the blocker to turn when releasing. For all other skills it doesn't seem to make much of a difference, except for the consistency when they are about to transform back into walker: E.g. when a basher or miner is about to finish, currently you have to wait for it to transform into walker to turn it around, while with the proposed behaviour you could just assign the walker whenever.

So overall, I'm almost indifferent to the change. It seems like it has a slight functionality advantage, but comes at the cost of checking levels.

[Simon]

I will keep the 0.6 walker.

Reason: The proposal doesn't simplify enough to warrant level breakage, untested backroutes, and difference to NL.

The proposal may be slightly better design -- had the proposal been in Lix since the beginning, I would prefer it over 0.6 physics and argue with game design -- but I'm not 100 % happy with either design. A good simplification would make the walker skill do only one thing all the time, it wouldn't do two things sometimes. I thought about this for a month, but haven't seen better solutions.

To cover levels for Lix 0.7, please use 0.7.7. Don't use 0.7.8, this has the proposed walker physics that I've rejected. Lix 0.7.9 will again have the 0.6 walker physics and will be good to cover.

-- Simon