Turing Tumble Community

Speed runs on Turing Tumble

#1

My Turing Tumble arrived today and while I was going through the first challenges, I noticed that some setups seemed to run faster than others. After solving challenge 8 I decided to see if I could speed up the solution.

My first attempt resulted in a definitely faster version, but it was also more prone to glitches. But with a few tweaks I did away with the glitches and reduced the run time from 1:13 (the solution in the book) to 1:01.
By using a hack I was even able to reduce the time even further to 56 seconds, without any glitches turning up.

So does anyone want to join me in seeing how fast this machine can run?

4 Likes
#2

I haven’t timed any machines yet, but I get the impression that there’s quite a lot of variance in how fast the balls go through the parts. We should probably figure out how much of a problem that is if we want to turn this into a competitive metric.

1 Like
#3

What a fun idea! Maybe the metric shouldn’t be actual time, but rather a count of the number of times a ball hits a part?

#4

I was going to suggest this, but isn’t this going to be almost the same for every solution of a puzzle, since each ball needs to hit one part on each level? The only things affecting this metric are a) how many balls run through the machine (which is often predefined by the puzzle goal), b) how many balls hit the part in the bottom centre slot, c) if an interceptor is used, how far up the interceptor is placed.

With actual time, one big factor is how far away from the levers a ball hits the bottom (and which direction its going).

1 Like
#5

The Idea was mostly given form as I noticed that the balls run at a different speed through different setups. So my solutions all hit the same number of parts, but the alignment on some were more favorable for a speedy runthrough.

1 Like
#6

Here are my video’s for reference:

1 Like
#7

That’s awesome, and The4thJawa, it’s so good to see you finally got your game!

Ok, here’s an idea. What if the time was given relative to some standard run? For instance, you’d report your time for the puzzle 5 solution (the one that just uses a crossover and makes a red, blue, red, blue… pattern) as your standard time. Then you’d also report the time for your setup. The ratio of the two would be the speed you could compare with other people.

#8

I’m glad to finally get my hands on it and start playing with it. :grin:

I’ve been comparing the speedruns I did to the textbook examples. But either could work I guess.

We could possibly classify the various runs:

  • Textbook: Same as the solution in the book
  • Glitched: Valid solution to the problem but causes glitches to happen
  • Hacked: Contains an invalid set-up (such as dropping ball from a height)
  • Add-ons: Contains extra components

But for now I’m focusing on solving all the puzzles in the little spare time I’ve got. So more speedruns will have to wait for a bit.

1 Like
#9

It seems like one of the biggest factors for speed (with the early puzzles at least) is how many times the ball has to change direction. A board with four ramps going one way and then four going the other way to drop on the bottom ramp is significantly faster than one that moves more directly downward, but does so by switching direction on each drop. On puzzle 10 the solution with a minimum of direction changes ran at approximately 7.5 seconds per pair of balls of the same color, while one with switchbacks ran at just over 10 seconds per pair of balls, for a total time of around 60 seconds for the first and almost 90 seconds for the second.

#10

@JackInNC: That’s indeed an important factor. But there are also some others that do pop-up:

  • Going too fast may cause balls to bounce off, making the program glitched
  • Going too fast to a switch-over may cause a little bounce on the switch-over making you lose time rather than win it by going fast
  • (Unfortunately) I noticed that some component were slower to turn than others of the same type
  • There are probably other thing that pop-up especially if you attempt Hacked or Add-on setups

So while making the balls go in a straight line is an important factor, it’s not the only one.

#11

Another factor in speed is that ramps have a built-in braking effect - if the balls pick up too much speed, they get slowed significantly - which limits how long a run of ramps in the same direction will offer an improvement.

#12

If you want to make a race of this, why not just rank solutions like this:

1st Priority: Least amount of parts.
2: Least total time.
3: Least amount of balls.
4: Least amount of balls hitting a computational part (Anything but the bottom and interceptors).

#13

I don’t know what category this would fall into, but you can increase the speed exponentially by using ramps that aren’t weighted. You can cut off a lot of time.