ClonesGame.com Forums

[Simon]

permits you to create solutions in which two groups may depend on each other [...] it allows for the possibility.

Cyclic dependance was already possible in the old version. You just had to go through the group twice and do the later things twice.

Do you think it was better with the old method where it auto-erased a groups playback when you play the same group?

In case these two implementations are the only thing to consider, the old one was more useful for me.

The fundamental problem arises from supposedly changed intent, though. Do you wish to make it as easy as possible to create a solution? Then you should also offer to play all groups at once, and fully support action replays (it's what CC explained in more detail).

-- Simon

[CCX]

Then you should also offer to play all groups at once

As awesome as that capability would be from the player's POV, I'm guessing that something which breaks the whole concept behind quantum loop probably won't be happening anytime soon.

--------------

It turned out I dabbled a little in the editor last night with quantum loop levels, and in the process I actually have something to add to this thread related to that:

#12: The "sync group" option in the group settings dialog becomes quite a hinderance in setting morphs for quantum loop levels. Right now I think that option is always on every time you go into the editor (this includes exiting from playtesting the level I think), until you explicitly deselect that option, and then make a morph change without switching to a different group (otherwise as soon as you switch group the option comes back on again). It's easy to forget to do it and then you mess up the morph counts in your quantum loop level.

I think the "sync group" option is really only for multiplayer levels, and it would probably make sense to build in some smarts so that instead of defaulting to the option always turned on whenever you go into the editor, it should be on only if you go into the editor and the level being edited is a multiplayer level. It could also be turned on whenever you change the level from singleplayer to multiplayer (and probably good idea to turn off when going the other way, though much less likely).

#13: as a Test Mode option during playtesting, it might be good to allow control of all groups for quantum loop levels when Test Mode is enabled, to reduce some of the hassle involved in playtesting QL levels. It is acceptable in this case that the moves made to the nonactive groups are not recorded anywhere and are forgotten when level is restarted.

On a related note, TestMode-only moves (ie. adding a clone, dragging existing clones) probably shouldn't be recorded for quantum loop levels. Although this can also be partially solved also by proper action replay support (ie. ability to cancel future morphs from previous playing of the group).

#14: it might be good for the editor to automatically set a newly added beaming pad (exit) to "Exclusive" when the level is a QL level, as that is usually the intention for exits in QL levels.

[Simon]

Agree with your ideas for the level editor, they sound very reasonable.

Then you should also offer to play all groups at once

I'm guessing that something which breaks the whole concept behind quantum loop probably won't be happening anytime soon.

What exactly is the concept of Quantum Loop?

-- Simon

[rt]

1.29 includes a bugfix for QL checkpoints that can eat extra morphs, and also the behaviour is changed so that when you assign a morph to a clone (or select it) then all future morphs from previous playthroughs for that group will be discarded.

Thus, you can incrementally add on to a single group's solution OR implicitly clear all previous solutions by taking control of a clone at any time. The explicit clear on the pre-game menu remains, and with a right-click option to clear all groups instead of only the selected one.

Controlling multiple groups at the same time is against the spirit of QL, the core idea being to weave a solution with yourself from the past, one layer at a time, each in harmony with the previous to produce an elegant compound solution. If you could control all groups at once then the puzzles would either cease to be challenging or would become nearly impossible requiring the player to be in multiple places at the same time.
However, the multiple group concept would fit perfectly with the Super Synergy mode we are planning. In that mode you play a puzzle designed for multiple groups to be played by multiple players over the network, but the local player can control all groups if there are no other players. It's multiplayer co-op on a singleplayer puzzle. Similar modes but with a different intent.

[Simon]

1.29 includes a bugfix for QL checkpoints that can eat extra morphs, and also the behaviour is changed so that when you assign a morph to a clone (or select it) then all future morphs from previous playthroughs for that group will be discarded.

Cool, this is a great addition.

I will also make a larger thread about the implementation of the Quantum Loop idea soon. This thread should be up in the next few days. The matter is a bit too complex to cram it all into this thread.

#15. It's not possible to directional-queue builder on a builder working in the other direction. This was possible in the previous versions and would really come in handy again.

-- Simon

[rt]

#15. It's not possible to directional-queue builder on a builder working in the other direction. This was possible in the previous versions and would really come in handy again.

I'd never even thought about doing that, but it's a great way to build zig-zag stairs. Fixed in 1.29.

[rt]

I think the "sync group" option is really only for multiplayer levels...it should be on only if you go into the editor and the level being edited is a multiplayer level

This is now the default behavior in 1.29, thanks.

[rt]

The solution you're proposing (i.e. only scrolling when you're actively moving the clone) would solve this issue, as having the screen move when you're moving the clone around is useful.

In 1.29 the camera will only follow the light clone if it's moving.

[geoo]

I'd never even thought about doing that, but it's a great way to build zig-zag stairs. Fixed in 1.29.

In 1.29 the camera will only follow the light clone if it's moving.

Thanks for these, I've been using directional pre-assign for zig-zag stairs excessively, and its absence has been causing me a bit of trouble as well. Also I hope the light clones will cause less annoyance for me now.

I got weird issue in Gofo's hidden level 'Tundra': I can't collect the two moving QDots at the top, the clones will just move over them without collecting. I've been trying to build into them, and using the slingshot cycle to get them, but in vain.
My best failing score on the scoreboard however says I managed to collect all of them at some point a while ago, so I'm wondering what the conditions are for collecting these two QDots, or if it is an issue with the latest version.

[rt]

I got weird issue in Gofo's hidden level 'Tundra': I can't collect the two moving QDots at the top, the clones will just move over them without collecting

Yep, this is a bug. Those QDots have the pickup group set to Blue, but the player group is Grey. This will be fixed in 1.29 so you can grab those qdots.