Mechanisms Sharing new (and old) mechanisms

@cpw - I explored the sideways delay a bit more, and couldn't use the effect to help R cross forbidden terrain.... But what i did notice is that the climb only needs a gap/hole one brick big...

Spoiler

For the sideways delay, the trick is to have the draggable activated and moving slowly past the steps as R is on them, to make him pause. By "activated", I mean the circles on the draggable are lit up in white.

 

Yep -- exactly what I also tried with the sideways slider. I like your addition of the hole squeeze though

 

Here is the mechanism I used in Interceptor v2:

Spoiler

Go on the rotating arm, jump high enough with the slider, then rotate the arm when B is at the desired hight. It is quite stable for high jumps.

 

Now the Jumpy mechanism offers something more than just jumping. Finally it justifies the mechanism's large footprint compared to the Tiny Jump button.

 

You can also notice that B is slowly going down when he is freezed in the air. It can be used to land on the win block even if you jumped too high.

 

@meko - this thread is a treasure trove of ideas, well done for starting it!

But it's getting large and unwieldy now - maybe it's time to split it up into several "Mechanisms" threads, a separate one for each mechanism? Otherwise some very valuable ideas could end up being buried by others.

Just a suggestion.

 

@Frenzies - yes.

 

Anyway. Meantime here's a study on some one-way paths..

Spoiler

These paths combine horizontally placed stairs and the claustrophobic effect to achieve:

• one-way traffic;
  
• and traffic that is switchable to two-way.

Another feature of this mechanism is that it is non-destructive, it is not a single-use mechanism.

Notice that the switch simply adds or removes a 1 block extension horizontally to the claustrophobic 2-cell ceiling. Any method that achieves the same end can be used - the only limit is your imagination!


Also, this study arose from an examination of @Block builder's recent excellent challenge, Sixty-four. In particular, his intended solution.

 

@trids I was thinking of this as well while trying to come up with new ideas for The Twins III......Still not sure if that is suitable for my series though, I'm having a hard time trying to do something that is only achievable with two R bots together in sync (which has been the main theme of the series).

 

@cpw - yes, this one-way path is definitely a B-bot mechanism.

So for your syncing requirement, would it help or hinder if you left B out of the picture this time? There being 2 R bots still qualifies for the "Twins" theme. Maybe you could use their interaction with each other to determine a path to the win?

 

@trids I'll consider your suggestion. It's just that I want it to involve B to offer more variety As for the one-way path (in case you might have missed it), I posted a similar one earlier on the last page that combines claustrophobia with R's stone pillar allergy to create one that works for both B and R. I still haven't actually come up with a good way to use it though

 

@cpw - thanks! I must have missed it somehow. I'll take a look and let you know if i have any ideas

 

There is an aphorism in certain trades which are secretive: If you want to hide something, publish it. Most people only skim material.

At what point does the burden is on a person to actually do more than wait to be spoon-fed?

As it is, I truly think it's easier to read through, and then reread occasionally, a complete conversation to stumble upon all kinds of new ideas. One never knows when a piece of information might suddenly rub against another to spark inspiration, like rubbing two sticks together to create the spark which lights a fire.

Speaking of which...

...I used a variation of that one-way path in this level, and in a later one as well. Thanks for that!

----

A mechanism which is very common in certain puzzles is the use of a previous action to lock off a future action. Here's an example.

Spoiler

The few levels where I've used the idea haven't gotten much feedback, which makes me think it's not a well-known concept and frustrating to the player.

The other idea I haven't seen explicitly expressed is that all levels of one section of a draggable object are transparent between the actual draggable blocks and the user. (Attached sections which are motivated by another draggable do block screen the draggable.) I had originally wanted to use huge movable blocks in the level elephant golf, with the draggable buried at the core, but I was frustrated to discover that the draggable was still grabbable by the player, instead of merely rendering the piece movable in the mekorama environment.

Here's a quick demo of the idea.

Spoiler

The block on the left has just one draggable, visible from the back. The other has a core of draggabbles, other than one slider block. The stone wall blocks dragging the draggable blocks, but not the metal blocks surrounding the draggables.

I know hidden draggables are frowned upon, but i just thought this was interesting.

 

I ran into the following while trying to get the appearance of a waterfall to look more natural.

Spoiler

And here's what's happening.

Spoiler

If a path is only blocked halfway, it is calculated as valid. In this case, the sliders are blocked due to an upright slider rail atop one of the sliders running into a horizontal slider rail under the upper lip of the top platform. B moves right at the zappers, but can't make it across the path, falling into the square below.

What's nice is that it works consistently, instead of requiring the player to build a callus on the tip of the finger from frantic tapping as required for some tricks.

 

One more little thing I noticed recently...

A robot's eye will generally not look behind the bot. Ahead, up, to the sides, and a combination thereof, yes, but not directly behind.

Eyes not mounted on a bot will generally treat southwest as the "front," in terms of eye movement.

Spoiler

I was recently building a level with a few creatures, and was trying to determine if eye movement could be constrained.

I do like that @Martin Magni built that behavior in, so that bots give a visual cue regarding their "frontness." The rules this little universe is built on shows a great deal of care, more than might be assumed upon first viewing....

 

Here's one of my experiments with the Teleportation button I recently published in my second R tricks demo (as well as my Quantum Tunnelling). I didn't utilize this setup since I'm still trying to figure out if there's any way to stabilize it.

To see it in action, simply hold the draggable while R is approaching the inset upwards staircase:

Spoiler

I noticed that R apparently has a higher chance to get through the entire obstacle with a metal head (pun intended ), and the effect seems to become less inconsistent as the head grows bigger. Zapper bots / eye bots seem to have a hard time getting through layers of grass blocks. With the head being sufficiently large, R would be teleported inside, vibrates violently, and tends to escape through a "weak point" of the structure, i.e. somewhere with a gap or a hole. Stone blocks also seem to hinder his escape. Sometimes (with certain setups) R would also emerge suddenly on top of the obstacle, or from the side walls.

I'm hoping that there'll be some kind of pattern that could be followed when designing the shape of the obstacle, as well as deciding on the block types to be used......

 

I've put this application of sticky sliders into a few levels at this point.

Spoiler

The easiest method for creating a quiet movable of this sort is to have two sliders set perpendicularly to each other as part of the assembly. In the above, the two such sliders are under the stair and stone cylinder blocks.

What's interesting is that the movable assembly not only slows down or locks the R bots standing/walking on it, but also prevents an R bot from stepping onto it from separate elements, while an attempt to move the draggable block is being made. That can be seen easily in the following example.

Spoiler

One can extend this further using a locked movable alongside an R bot, with the stickiness being present when the R bot's arm/shoulder wind up intersecting with the draggable.

Spoiler

This is demonstrated in the earlier example from @trids, suggesting that a wall of locked draggable blocks where R's shoulder intersected/penetrated said wall, in place of the moving slider/draggable combo used in @trids's example, would eliminate timing issues.