ClonesGame.com Forums

[geoo]

If you're okay with not optimizing time, the freeze-time feature can greatly assist you with pixel-precise placements, for a penalty of 1 second per use.

Right when freeze time was introduced, I mapped it to the key that was previously occupied by pause before the existence of freeze time. That still doesn't make me want to go for pixel precise movements.

What about some alternatives to the opening green move that eliminates the timing/position precision? For example, instead of doppel, maybe the green clone molds once over a small gap (and can't lay more than one mold brick due to low ceiling), and the clones are naturally turned around by a wall to the right of the gap? How much of a goal is it to prevent a solution/level like that from working, when it may be fairly easy to repeat the first move of the green group without decohering the blue group?

From what I understand, this kind of cyclic dependency will still work under the system proposed by rt, and be easy to execute. Same with pre-assigning while in air, and I found an original level where use can be made of this to get a 100% solution: Relative Zero, replay attached. (Why can't I attach .clones files?) You first set the white blocker, then play green, white again with the blocker being easy to set correctly, and then red. It uses cyclic dependency, but it wouldn't be detected by the system rt proposed. I couldn't spot a 100% solution without cyclic dependency right now, but apparently it's possible as to ccexplore's score.

I think custom levels are the lesser concern here, because if, like in your case, you want to rely on cyclic dependencies, you'll be able to use the Super Synergy mode for that once it has been introduced. If you want to make regular QL levels without relying on cyclic dependencies, you'd have to take care too make all cyclic routes insanely difficult to execute due to pixel precision required to get through coherence detection.

The effort is not so much to ban cyclic solutions as it is to help clarify the intended method of QL (one group each playthrough with no interference). [...]

From a theoretical standpoint, in that case it'd be best to allow the player only to choose groups that haven't been played yet (or the one that has just been played, to overwrite the current replay), or clear all replays. That makes it pretty simple, but also sounds inflexible and like a lot of replaying required: problem here is that if you have at least three groups, and want to swap the order between two groups that are not the first one played. The system would require you to replay the first group as well then. So yeah, it doesn't sound like a good idea, though it depends on how frequent the latter scenario is.

[rt]

After reading over the thoughts here, and playing some of the existing QL levels i've started thinking that #3 from my previous post is the most "QL flavoured" solution, despite it's challenges. #2 is still a good thing, but it would become a warning instead of an error to allow for some creative bending with solutions without breaking the linear play order. I'm not certain about #1, it has benefits, but adds complexity? In any case, it should be possible to add that feature independent of these, if desired.

Summary: Same as 1.27 with morph-location warnings and forced 1-play-per-group, which was always intended.

Changes to GUI:
- Pre-game voice bubble should say something like "Add <color> Group To Solution" for the tooltip instead of "Play as this group"
- End-of-match menu should only be regular EOM menu if all groups have been played (indicate pass/fail), otherwise it's a special QL menu with a "Add Next Group To Solution" button, a more helpful message to the player.
- Group color icons on pre-game menu to indicate which other groups will be cleared when selected group is cleared, for reference (other groups played since the last time selected group was played). Possibly displayed as little colored clone heads under the main 3-clone image.

Thoughts?

[CCX]

Same with pre-assigning while in air, and I found an original level where use can be made of this to get a 100% solution: Relative Zero, replay attached. (Why can't I attach .clones files?) You first set the white blocker, then play green, white again with the blocker being easy to set correctly, and then red. It uses cyclic dependency, but it wouldn't be detected by the system rt proposed. I couldn't spot a 100% solution without cyclic dependency right now, but apparently it's possible as to ccexplore's score.

Your solution can be adapted pretty easily to completely remove the cyclic dependency:

Instead of using white to doppel to turn the green clones around, simply have the first green clone doppel on the short platform with the QDot, preferably as soon as possible. With the green molder happening much sooner, you can afford to wait until the green clob finishes before assigning the white doppel, so that there's absolutely no way for the white doppel to influence green clones in even benign ways. (Though it's actually possible to release the red group without relying on that doppel at all.)

sidenote: although my current WR solution is pretty similar to the modified solution described above, the end part is done a bit differently which is why it is so fast and uses slightly fewer morphs. Be warned that the end part is unlikely something you can figure out ahead of time; I only came to it after observing something perfectly legitimate but unanticipated during one of my attempts.

[edit: you can actually argue that my WR solution in its current form has a benign cyclic dependency, because I didn't wait before having white do its thing at the end, and what it does will change the walking path of the remaining green clones even though it doesn't change the end result in this case. Even that benign C.D. is likely removable by artificially delaying some of the moves for the ending part. In terms of decoherence as I understood it from this thread, there is none in my WR solution.]

[CCX]

After reading over the thoughts here, and playing some of the existing QL levels i've started thinking that #3 from my previous post is the most "QL flavoured" solution, despite it's challenges. #2 is still a good thing, but it would become a warning instead of an error to allow for some creative bending with solutions without breaking the linear play order.

So what does replaying a group mean in your current proposal? Taking geoo's solution to "Relative Zero" as the example, let's say you played white, then play green, and now you replay white to add new morphs (without needing to clear the existing ones). Under v1.27 rules, white is automatically cleared when replayed, but with #3, does it also mean that green will be cleared as well, or is it only cleared if the user explicitly clears white rather than merely replaying it?

[I think I need the above point clarified to understand the intended benefit of downgrading #2 (decoherence detection) to just a warning that doesn't invalidate the solution.]

[rt]

let's say you played white, then play green, and now you replay white to add new morphs

Under the current proposal the active group will be cleared when played (as it was in 1.27) and in addition all groups played since the last time you played the active group will be cleared. So in this case since green was played after the last time white was played then green will be cleared along with white when white is replayed.
The idea is that the final solution will always have each group played only once. Let me know if more clarification is needed.

[CCX]

Ok, so it seems that downgrading #2 (decoherence detection) to a warning would still leave open the loophole of getting at least some decoherent solutions to work, just a lot harder as to be (hopefully) impractical. The main benefit that I can see (just one so far) is if we want to allow solutions where decoherence occur "by accident" rather than by design--such as a case where a later group's move (say a mold bridge, but across walkable terrain rather than a gap) changes the walking path of an earlier group, but not so much that it changes that earlier group's subsequent moves into something completely different and not possible without the path change. (So the earlier group can still get to the place for its next morph, with or without walking across the mold bridge. Except of course walking across and falling off the mold bridge likely threw off the timing from the way you originally played the earlier group.) You can think of it as a case where the interference of the later group on the earlier group is really an unwanted effect.

The problem is that it seems that accidental decoherence will be more a nuisance than a benefit, since except for the extreme case of intentionally executing a decoherent solution, accidental decoherence is more likely to throw off the intended results of the earlier group's moves than not. And it's no easier to correct such a problem than intentionally trying to force a truly decoherent solution to work, since replaying the earlier group clears the later group's moves, so you have to rely on blindly adjusting the timing of the affected moves when replaying the earlier group, and hope that it fits with how you replay the later group (since most likely you won't repeat their moves exactly the same way as before).

So if you are already doing all the extra work of detecting decoherence, it doesn't seem likely to me that downgrading it from error to warning would "allow for some creative bending with solutions without breaking the linear play order" as you stated. Instead it just seems to leave open the ability to "cheat" your way out of the linear play order (if you try hard enough). For solutions where accidental decoherence happen, you are left with no easy way to correct the timing to make the solution work out.

[geoo]

I don't quite see the benefits of removing the coherence check either.
If you 'accidentally' cause a 'small' desynchronisation, e.g. CCX's scenario with the useless builder, you're most likely screwed anyway, as you've wasted that builder, and QL puzzles tend to be morph conservation puzzles. I don't see it happen that often that you desynch little enough that the solution stays meaningful, unless you specifically intend for the desynch.
Omitting the decoherence check, allows for scenarios like this:
Say group A had a builder and a driller, and group B has a basher. The level is set up that both groups start at the same place, and you have to execute building over a gap, bashing through a wall and drilling sequentially in that order. Shouldn't be doable with the QL concept, however if you have group A build, wait a bit and anticipate the approximate position of one clone if the basher tunnel had been made, and then drill, you'd get a perfectly valid solution if you just do the bashing next. I haven't looked in real levels for solutions like this, but this scenario is feasible, because for drilling you frequenly have a wider range of positions that do the job, and thus anticipating the position of the clone wouldn't have to be exact.
Doing the decoherence check however will definitely nail that there's no solution that uses cyclic dependencies in some (perhaps disguised, like above) way, that's why I'd prefer it like this.

- Group color icons on pre-game menu to indicate which other groups will be cleared when selected group is cleared, for reference (other groups played since the last time selected group was played). Possibly displayed as little colored clone heads under the main 3-clone image.

In addition to that, to make the pattern stand out even more, you could arrange the group icons in the speech bubble in the order they have been played, with the groups that haven't been played added to the end.

As you said, action replay is something that can be added on top at some point, but here's a suggestion to allow the option to use it in a very simple manner: You'd have a checkbox on the pre-level screen that indicates whether the player wants to use action replay or not, and by default it is off. So if the player simply ignores the checkbox, everything will work just fine, but it's still possible to use the feature.

[rt]

I don't quite see the benefits of removing the coherence check either.
If you 'accidentally' cause a 'small' desynchronisation, e.g. CCX's scenario with the useless builder, you're most likely screwed anyway

Hmm, is there no way to allow for unimportant accidental desync's without also allowing for intended disguised cyclic dependencies? Failing a solution because of an accidental desync which doesn't affect the full solution seems a bit harsh.
Perhaps the morph-location check could allow the morph to be within a radius of the original instead of exact (with a warning) but if the morph is too far away then it's an error and does not save the current group's playback?

action replay is something that can be added on top at some point, but here's a suggestion to allow the option to use it in a very simple manner: You'd have a checkbox on the pre-level screen

That's interesting, easy to put in place and would make that feature more clear too.

[CCX]

Hmm, is there no way to allow for unimportant accidental desync's without also allowing for intended disguised cyclic dependencies? Failing a solution because of an accidental desync which doesn't affect the full solution seems a bit harsh.
Perhaps the morph-location check could allow the morph to be within a radius of the original instead of exact (with a warning) but if the morph is too far away then it's an error and does not save the current group's playback?

It could work, it's not foolproof but I think it will catch the majority of willful violations.

However, I think the point both geoo and I were making is that, in the current way playbacks are implemented, accidental desync's are likely to ruin the solution anyway even if the desync is forgiven as a warning. Going back to what geoo called the "useless molder" scenario, if the desync'd group that was delayed by the walking and falling off of the mold bridge was going to clob a wall, that delay has a good chance of causing the clob to abort prematurely because the affected clone is no longer near enough to the wall when clobbing starts. So it seems that the benefit of forgiving accidental desync might not be sufficient to worth the downside of creating possible confusion about the "no desync/cyclic dependency" intention. I guess it's not easy to judge without some actual playing experience to see how common the various scenarios play out.

There are potentially other ways to try to make the effects of accidental desync's less harmful (eg. try to have the game smartly alter the timing of moves played back, so that the clob assignment in above scenario happens at the same position as original playback, despite the unintentional delay introduced), but these other ways will take more work to implement, test, and debug.

===============

And also, to correct a minor misconception:

e.g. CCX's scenario with the useless builder, you're most likely screwed anyway, as you've wasted that builder, and QL puzzles tend to be morph conservation puzzles.

The mold-bridge-over-land is only useless due to my lack of description. It may be of no use to the group performing the mold, and is even interfering with the previous group unintentionally, but a later group may depend on the mold bridge to, say, fall down safely from above without splatting.

[rt]

However, I think the point both geoo and I were making is that, in the current way playbacks are implemented, accidental desync's are likely to ruin the solution anyway even if the desync is forgiven as a warning.

Ok, i've added in both #3 (1-play-per-group) and #2 (morph location check) and am playing through all QL levels. So far the only one that had to be tweaked was "Spacey" for Wattson. If no other level requires changes then i think we'll run with this "full on" QL implementation for 1.29. Thanks for all the input!

Edit: All QL levels are still solvable with the intended solution and new rules. The Narrows was hard though