Well, this is exactly why I said that if recipes/scripts are to be allowed, they should be counted for the same number of moves as their manual folding equivalent. Let's take your hypothetical script for example– I would expect the script to require at least the following:
Set recent best
Repeat 10 times: rebuild for 1 iteration
Load recent best
==> That's 12 moves already. If we add in the needed shake and wiggle, the protocol becomes the following:
Set recent best
Repeat 10 times: rebuild for 1 iteration, then shake and wiggle
Restore recent best
==> That's 32 moves. If this were a duel puzzle with a 20-move limit, the script cannot even be completed; instead, one would have to stop at model #6 before spending the last and 20th move on "restore very best." And we haven't even added anything advanced that would be difficult (or cumbersome) to replicate manually.
.
The bottom line is that I don't see the usage of recipes/scripts in such puzzles as a problem because those who use automated methods will hit the move limit very quickly. And I can say this from my personal experience from my last 3 years of playing foldit: automated methods that are very complicated (e.g. overnight scripts) are generally much less cost-effective from a "score gained per moves made" ratio standpoint relative to manual folding. Since this is the case, I would expect players who rely on scripts to actually be at a disadvantage in puzzles with a move limit.
I would love to work on non-script puzzle :)
I probably end in inverted top 10 but … :P
Surely it would be easier to implement as a "No scripts" type of puzzle.
Having to calculate the value of script moves etc, would be too time consuming for it to be set up I would imagine
X number of moves..no scripts. One chance only. Once you have done your moves, thats it, over and out.
A puzzle would need to be up for so many days( 3, 5 etc) to allow for times zones, people working etc.
There's no need to calculate the number of script moves. Just use a mechanics similar to that of duel puzzles, so that the number of moves would be incremented by one when any of the following occurs:
- Dragging any piece
- Shake
- Wiggle all / backbone / side chains
- Undo
- Restore recent/very best
- Rebuild (one iteration)
- Freezing or unfreezing
Looks like I forgot the following:
- Applying the alignment would also count as one move for each accepted iteration.
- If loading solution is allowed, that should also count as one move.
(The bottom line is that anything that generates a point on the undo graph would count as one move. That would require very little to no redesign.)
If players recognize that scripts are using an enormous number of moves for a disproportionately small number of points, compared with manual play they will naturally gravitate to manual play in a puzzle which only allows a finite number of moves.
if this were implemented (and we've talked about it in our meetings for a while, but it never makes it to the top of our priority queue) it would most likely allow scripts, but as many people have mentioned: using scripts would quickly use up most of your moves so they would most likely not be used.
It seems to me that the number cannot be either too high or too low:
-
If the limit is too high, it wouldn't affect things much other than discouraging overnight rebuild scripts.
-
If the limit is too low, not much exploration could be done even manually. Plus, this could encourage "Hail Mary pass"-type moves (i.e. tactics that have a low probability of succeeding but a high payoff if it succeeds) in the attempt of maximizing the score-gain-to-moves-made ratio and generate a lot of models that are mostly incorrect.
==> So, it seems to me that the optimal move limit would be somewhere in the 100 to 10000 range…
yes, it would require some testing to find out the optimal range.
There are three other aspects to speed folding that are in keeping with learning how proteins fold by using the collective intelligence of the players and not just about the 'game.'
First, teamwork should and would be an important consideration of speed folding. Because the game becomes a reasonably shorter version of itself, the team is able to discuss best results and improve upon them. It then is not about the play so much as it is the replay. I can see teams trying the puzzle over and over, to keep within the time (move) limit and get better and better results. In the process, perhaps there will be insights as to what is making a difference to the outcome and what is not. I'm reminded of the scene from the movie Apollo 13 where a fellow astronaut on the ground is trying to figure out how to make a CO2 scrubber from the remaining parts and duct tape, fire the retro rockets, and use the little fuel that they have left in the proper sequence to get them down safely. He tries the sequence of moves over and over and over until he figured out how to do it with the remaining fuel. According to the movie version of events, he saved the day.
The second aspect to why we should try speed folding is the possibility that there is going to be new scripts written just for this type of game. And, like protein folding in nature, where folding is done over and over until an advantage is achieved and the new variation is kept instead of discarded, scripts can be rewritten after the game has been played, again and again, eliminated superfluous moves. This revisiting and streamlining will also help to teach us what works and what does not.
The third possibility is that players, themselves, figure out simplified play. For example, let's say that at the end of a run, it is seen that a certain helix is now at a new location. In the first run, the helix got there through trial and error and 100,000 wiggles and shakes, banding and pulls, of a Compressor script. Knowing the advantageous end position, folders may be able to band and pull the helix into its correct position in just a few moves. It is this revisiting that is to be encouraged in speed folding. To do that, I would emphasize the shorter game variation.
