ClonesGame.com Forums

[Simon]

Hi folks,

(1:08:33 AM) geoo: I think Simon was gonna start a QL discussion topic sometime, he hasn't done so yet though
(1:09:04 AM) rt: lazy penner

Here is the thread. :-) The latest featue change for quantum loop was to not erase assigned skills even when a group is replayed. This change raised several questions about whether it was good or bad, and what else to change for best usability.

The decision must depend on what QL should be about. As I see it, there are only two possibilities:

• Different groups may do anything and depend on each other in any way.
• Groups may only depend on earlier played groups, not on those played afterwards.

For the first way, it's most efficient to play all groups at once, but also single groups at a time, and to alternate between these options as the player sees fit. This makes it as easy as possible to try and carry out a thought-up solution.

Note the game allows cyclic dependancies already: Play group A, then B which depends on A, then A again and repeat its earlier actions, while adding stuff that depends on B, and so on. But then again...

rt: playing all at once makes it easy to create a solution in which groups depend cyclically on each other, which was not the intention of QL. each group only needs to be played once in isolation. part of the QL challenge is that groups cannot react to other groups, you have to plan ahead
Simon: But it's possible to do it already.
rt: it's not encouraged

If the groups shouldn't depend on later played groups, then the current mode allows too much. For the second way from the two-item list above, features must be taken out from the current game:

rt: perhaps that intention should be made clearer, you can suggest ways to accomplish this
Simon: I know one :)
rt: awesome!
Simon: But I fear you're going to implement it.
rt: hahaha, i surely will
Simon: You must make it impossible to replay a group without erasing all the groups, and in addition store the locations of each morph assignment. If the later groups alter the position of the morphs given to the earlier group, reject the solution. Then savestates must remember the total information and not just jump around the time of a single group.
rt: do you think there should be a message during play when a previous morph is in the wrong location, such as "The <color> group's actions have altered the <other color> group's morphs! Solution rejected." and end the level right there?
Simon: Yeah. Warn the player early.
rt: then just replaying a group doesn't need to discard other group data, only when a morph location is off does it need to reject the current playthrough
Simon: Hmm, I should ponder that for loopholes, it sounds safe at least.
rt: yeah, ponder and propose in a thread.

It doesn't have to be as radical as this, as you don't have to erase all the skill assignments. If you replay a group, it's enough to erase all skills from that one and any later group; you don't have to erase those of even earlier groups.

The point of this thread is to decide on the greater idea/purpose of the Quantum Loop mode, and afterwards do usability on how to implement that idea properly.

Present opinions: It should be obvious that rt's all for non-cyclic dependancy, and he's likely the person who put most thoughts and work into both levels and the engine. All levels in the singleplayer mode are solvable without cyclic dependancies.

My view is that prohibited cyclic dependancies are a bit unnatural: until now, levels are always failed by losing clones due to physical separation from exits/other goals. There can be cyclic dependancies in any other game mode as well. Just dividing the skillset between clones is a great, simple, elegant idea already. Even though this idea may be implemented in a future game mode, I'd rather make the present gamemodes most enjoyable before adding similar additional ones. Errors in a non-cyclic dependancy implementation may lead to larger portions of the work to be redone.

-- Simon

[Simon]

Take courage, noble gentlemen, and post, post, post!

Don't be as lazy as these two.

-- Simon

[geoo]

The decision must depend on what QL should be about. As I see it, there are only two possibilities:

• Different groups may do anything and depend on each other in any way.
• Groups may only depend on earlier played groups, not on those played afterwards.

For the first way, it's most efficient to play all groups at once, but also single groups at a time, and to alternate between these options as the player sees fit. This makes it as easy as possible to try and carry out a thought-up solution.

I agree that this game mode should either make cyclic dependencies easy to do, or impossible altogether, and not something inbetween. Currently, cyclic dependencies are possible, but not always easy to execute.

If the mode shall allow for cyclic dependencies, it is, possibility-wise, equivalent to simply controlling all groups at once. In that case, the QL implementation would be vastly inferior to simply having all groups playable at once, gameplay-wise, with all the restarting and replaying required. Should that new Super Synergy gameplay mode be implemented, it'd also be redundant. I'd also allow for easier backrouting the existing QL levels, as they are designed without cyclic dependencies in mind.

Therefore, I think it'd be consistent to force QL to be played how it was apparently initially meant to be, without cyclic dependencies.
I think Simon's suggestion is already a good step how that could be implemented, though I think it can still be refined a bit. Another challenge would be to make the game mode still easy to understand, despite its conceptual difference from the normal playing modes.

(Note: I'll henceforth refer to the replay of the current group being automatically replayed until you take over by assigning a morph as 'action-replay'.)

It doesn't have to be as radical as this, as you don't have to erase all the skill assignments. If you replay a group, it's enough to erase all skills from that one and any later group; you don't have to erase those of even earlier groups.

To minimize the amount of replaying involved, action replay could be applied to the group that you're replaying. (Of course, always under the premise that the replaying of one group immediately stops with a warning as soon as it desynches, i.e. the actual position of the assignment differs from the one that got stored with the replay.)
In fact, it could even be extended beyond that group: Say you have played group A, then group B, then re-do group A, and then re-do group B. During the second try of group A, the group B will be replayed as inactive (i.e. without any morhps being assigned), however at the second attempt of playing group B, the action-replay of group B from the first attempt could kick in. This would reduce a lot of work if you just did some fix at the end of group A, with group B not being affected up until that point.
More generally, if you switch back to an earlier group, the replays of the later groups don't get replayed, but they are remembered and if you replay one of the later groups, the action replay is available.
The player will have to establish a linear order. As at no point replays from later groups are replayed while playing an earlier group, and all desynchronisations are detected, that way it will not be possible to have groups depend on each other cyclically, as in the end a linear playing order is maintained, while at the same time minimizing the amount of manual replaying required.

Now, this mechanic would have to be made evident to the player. For that, I guess it would be suitable to display the number in the order the groups have been played up to now next to each group, while the flag indicates that a replay is available (but will only be replayed if the group is the same or comes before the group that is played next). As for buttons, an 'Remove ordering number from group' and a 'Erase replay from group' should be available. Remove entire ordering is not sufficient, as if you, say, have played group A and B, and now want to play group C as direct follow-up to A, you'll have to remove the number from B, but not from A. If you remove an ordering number, all high ordering numbers will be removed as well, so e.g. removing ordering number 1 is equivalent to removing the entire ordering.

[rt]

First off, thanks for taking the time to write out your thoughts and concerns on this topic. You guys have provided a lot of great ideas and continue to do so.

As i see it, there are 3 "features" to consider:
1) Action-reply (the ability to load up an "active group" solution and take over at some point)
2) Decoherence detection (Simon's idea to track morph position of previous groups and abort if the current solution interferes with the old ones)
3) Non-cyclic detection (If you play a group, then play others groups, then come back to the first group then the solutions for all groups you played since the last time you played the first group must be cleared)

#2 is definitely needed regardless of the other two. It will help to prevent confusion as to why the morphs you previously gave may not be working anymore. No group should interfere with a previous group. There is a message displayed for the player which provides instant feedback.

#1 was added for 1.28, somewhat, but now seems like a step in the wrong direction. Allowing action-replay makes it easier to produce a cyclic solution as a side effect of making it easier to correct one part of a solution. This was intended to reduce the time required to tweak a solution, but it's already caused some confusion.

#3 seems like the most sure way to prevent cyclic solutions, but may be confusing to the player as other group solutions will disappear when a certain group is played. There would have to be something added to the GUI to indicate dependence.


I propose that #2 be implemented only. With #1 removed it would become impractical to create cyclic solutions, methinks. Technically it would still be possible if you could use morph queuing to ensure the position of all morphs won't change (to bypass #2), but most of the time morph queuing is not possible which will result in decoherence thus voiding the solution. This being the case then #3 would be overkill.

Summary: Same as v1.27 but with decoherence detection.

Please consider this scenario and let me know of any consequences, theoretical situations, and alternatives. If you have actual working cyclic solutions to some levels then ponder if these changes will prevent your solution and force a linear one.

[CCX]

No cyclic dependencies will definitely kill my current WR solution for "Share the Land", and I suspect "Ruins" may also benefit from cyclic dependencies for molding efficiently time-wise. Other than that, I think actually all the other QL levels (though granted, most of the QL levels are in Wattson and I haven't touched any of those) I haven't used cyclic dependencies, but that's a moot point because with a change this big, you pretty much have to reset all scores for all QL levels anyway. I also suspect with these changes, it would not be possible to carry savestates from previous versions over, thus forcing an actual replaying of all QL levels.

I'm not entirely sure how all this new work would be significantly better than simply what rt already said at the beginning, that cyclic-dependency solutions are not required and discouraged, and if you want to do one regardless, then tough, you'll have to grind it out with more restarts as the way it is currently. Is the effort spent in hard-banning cyclic dependencies in a small subset of levels really worth it over the same time spent on other areas like improving multiplayer etc?

[rt]

with a change this big, you pretty much have to reset all scores for all QL levels anyway.

This is an issue. It would be best to identify which levels have cyclic solutions and only clear those ones, but that is not really practical. Perhaps clearing only the top 5 scores for each QL level would suffice? This way the level stats won't be empty and the top score should be reachable.

Is the effort spent in hard-banning cyclic dependencies in a small subset of levels really worth it

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). That is one reason why i propose to revert back to v1.27 rules but with the added detection for morph location changes which provide feedback about "wrong" actions. That is a fairly simple change and is already done. It's the #3 from my previous post that i want to avoid unless it becomes necessary.

[CCX]

I'd like to get a sense of how the proposals work out with the test quantum loop level I posted in another forum (for reasons mentioned there, I'm not posting/publishing the level here; you don't need the details anyway for this discussion).

From a logical point of view, the intended level solution has cyclical dependencies. Your first move is to make doppel with first green clone out, to block off to the right so the other group (blue) can proceed further with various moves to the left. Later the green clone will rely on the changes made by the blue clone to get to where he needs to go. Finally, after the green clone is done blazing the path to the exit, the blue clone will drill down into the clob tunnel created by the green clone so they can exit.

Thus blue depends on green, then green depends on blue, and finally blue depends on green again.

However, I think under the current discussion, including the discussion of what exactly constitutes a "cyclic depdency", I believe the intended solution is still valid, I'm not sure. You first play the green group to make the doppel move. Then you play the blue group. Because the blue group doesn't depend on anything other than the initial green doppel to get to the various positions where it carries out blue's morphs, you can pretty much play all the remaining moves for the blue group in one go, as long as you don't do the final drill too early (otherwise the clob tunnel isn't finished yet, and you drill through the platform and fall into the abyss; I can also add a cancel-morph to the blue group to remove the timing of this completely, without changing the fact that the blue still depends on the green's clob tunnel to reach the exit). You now replay the green group filling in all moves, taking care to repeat the initial doppel move at the exact same position as before, so it doesn't decohere blue's moves.

Based on my understanding of the various proposals offered here, I think the only system where this solution is not allowed is the one where replaying the green group also erases the blue group's moves, which I don't think is currently on the table.

Anyway, use that as a starting point for further discussion and exploration.

[geoo]

However, I think under the current discussion, including the discussion of what exactly constitutes a "cyclic depdency", I believe the intended solution is still valid, I'm not sure. You first play the green group to make the doppel move. [...]

From what I understand, this is not supposed to be possible in QL, because the level should be solvable playing each group exactly once. And the change that is about to be introduced would require you (the second time playing green) to place the green blocker at the pixel-precisely same position as the first time when you played the green group, as otherwise the blue clones would turn around some pixels earlier/later, affecting the position of the morphs you'll assign to them later, and thereby failing the position check.

My gripe with this particular implementation is that you can still make use of cyclic dependencies (like the above mentioned blocker scenario) if you are patient enough to try to make the pixel precise placements. I reckon the effort required to pull off some solution of this calibre (especially if required more than once) will prevent players from depending on it in normal playthroughs, but I suspect that there might be solutions relying on this for getting top rankings, thus requiring any player to challenge that high-score to do this as well.
But perhaps I'm overrating the rankings, the few times I actually try to attack the top scores I content myself with solutions that match the top score in everything but time taken (unless it is obvious that the top time requires a fundamentally different approach), because I'm satisfied once I have conceptualized a solution, and I don't want to spend too many tries on execution and optimizing time. In the same fashion I guess I'd be ok if someone got a better QL score by taking 1000 tries to get the pixel precision done, which I'd just not want to afford.
(For the record, I don't think any of my QL scores use cyclic dependencies, as I tried to play the levels the way they were intended to be played once I knew about that.)

The proposed solution in my earlier post would solve this (essentially solving #3 on rt's list), and might even require less manual replaying due to the proposed action replay feature, but yeah, its complexity might overwhelm new players, and I recall not grasping the original QL comcept at the beginning that easily (though I still blame the level description Free Fall had back in these days for that ). Removing the action replay or limiting it to the current group would reduce that complexity a bit, but would reduce a lot of flexibility for the player as well.

[CCX]

From what I understand, this is not supposed to be possible in QL, because the level should be solvable playing each group exactly once. And the change that is about to be introduced would require you (the second time playing green) to place the green blocker at the pixel-precisely same position as the first time when you played the green group, as otherwise the blue clones would turn around some pixels earlier/later, affecting the position of the morphs you'll assign to them later, and thereby failing the position check.

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?

Also, consider the case that we eliminate the first green doppel move, replacing that with a wall. The resulting solution still has a cyclic dependency in some sense, since the green clone requires the changes made by blue clones before it can carry out its moves, but then the final blue move (drill down into green's clob tunnel, created as green's last move) only works if it is done after green has sufficiently completed its moves. Is the fact that there is no decoherence in this case enough for the solution to be acceptable? Or do we still consider it decoherence when a later group's moves alter the behavior of a previous group's move, without actually changing the position where the morph assignments of the previous group's moves took place?

Sorry if this confuses matters more than it clears things up. Hopefully at least it's somewhat entertaining to think through these sort of situations that may come up when people start creating new QL levels.

[CCX]

My gripe with this particular implementation is that you can still make use of cyclic dependencies (like the above mentioned blocker scenario) if you are patient enough to try to make the pixel precise placements. I reckon the effort required to pull off some solution of this calibre (especially if required more than once) will prevent players from depending on it in normal playthroughs, but I suspect that there might be solutions relying on this for getting top rankings, thus requiring any player to challenge that high-score to do this as well.
But perhaps I'm overrating the rankings, the few times I actually try to attack the top scores I content myself with solutions that match the top score in everything but time taken (unless it is obvious that the top time requires a fundamentally different approach), because I'm satisfied once I have conceptualized a solution, and I don't want to spend too many tries on execution and optimizing time.

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.