Jump to content

Recommended Posts

Posted

Wow, this is a truly remarkable construction both in terms of mechanics and in terms of aesthetics, amazing achievement! And I say that not just as a lego enthusiast, but also as a software engineer. This is a really nice way of illustrating how early mechanical computers worked.

After watching/reading the explanations, I understand most of the principles, but I'd still have some questions about the details of its workings. The principle of the OR gate is clear (either of two vertical pushes), the explanation of the AND gate took me some time to understand, if I'm correct it requires a combination of tilting and vertical pushing, and the tilt comes from the memory (is that always so?). That's the details, but the overall logic is not yet clear. If I understand correctly, the overall logic determines for each state (6 of them) and each user input (8 of them), the resulting counter move along with updating the state right? The memory encodes the state we are in, each row corresponding to one state (though what the individual bits encode is not totally clear). And then, the overall logic is along the lines of "if we are in state S0 AND the user makes this OR that move, then we move to state S1, which also implies the right counter-move", right?

As for this becoming an Ideas lego set, I'm quite confident you'd get enough votes, however, there might be some obstacles of it ending up becoming an official set; mainly due to the complexity of construction and operation; this may not be for casual builders. So if Lego considers this, they might look for the simplification of the user experience, and I guess the less they have to think about it the more chances you have, so may be worth thinking ahead :)

The constructions seems pretty complicated, though the build process does not necessarily need to be complicated (even though somewhat repetitive), it would be good to understand how easy it is to make building mistakes that result in movement jamming or other erroneous operation for example. But more importantly, I'm afraid that also operating it, especially the steps of resetting, could turn out to be somewhat complicated for an average person. For example, even though now I get the reset process, I'm pretty sure I would not remember it in two weeks time :)

First thing I wonder about is game play. I understand now that the memory needs to be transitioned with a separate gesture. What happens if I accidentally skip that, and play another move? Is that blocked, or will that result in some suboptimal / random moves? Also, it's not clear to me why this separate gesture is actually required, if movement of the memory is powered by the scissor mechanism? Can the keystroke not also trigger memory movement, since it has its own power source?

Next thing is resetting. If I look at it from a user perspective, a more ideal procedure for resetting would be

  • Reset the whole display with one lever (instead of a CW and a CCW rotation per field). I'm thinking that all field resetters could be linked and moved in sync, and a rubber band could pull back the lever (instead of needing to turn back all squares)
  • Rewind the memory with one movement, instead of three movements. A single controller move could in principle operate all three stages of lifting the gates, shifting the memory, lowering the gates

These would significantly simplify the resetting procedure, and seem mechanically doable, though I understand that it might require some significant adjustments.

These are just some ideas by the perfectionist inside me, but it is already an outstanding work as it is!

Posted

This is an absolutely extraordinary achievement! I specialise in trying to do impossible-sounding things purely mechanically. In fact I did ponder a few times whether such a thing could be done, but I dismissed it as out of the question!

Posted

@Nalyd997, @Morgoth924, @Kai NRG, @Davidz90, @MKJoshA Thank you 😊 

4 hours ago, aeh5040 said:

This is an absolutely extraordinary achievement! I specialise in trying to do impossible-sounding things purely mechanically. In fact I did ponder a few times whether such a thing could be done, but I dismissed it as out of the question!

Thanks 😊 And we seem have two hobbies in common then 😉. I was also close to dismissing it when I googled the possible number of game states for Tic-tac-toe (Google came up with an insanely high number). Ofcourse most of those states are ludicrous and moves that no one would ever make.

8 hours ago, gyenesvi said:

...

After watching/reading the explanations, I understand most of the principles, but I'd still have some questions about the details of its workings. The principle of the OR gate is clear (either of two vertical pushes), the explanation of the AND gate took me some time to understand, if I'm correct it requires a combination of tilting and vertical pushing, and the tilt comes from the memory (is that always so?). That's the details, but the overall logic is not yet clear. If I understand correctly, the overall logic determines for each state (6 of them) and each user input (8 of them), the resulting counter move along with updating the state right? The memory encodes the state we are in, each row corresponding to one state (though what the individual bits encode is not totally clear). And then, the overall logic is along the lines of "if we are in state S0 AND the user makes this OR that move, then we move to state S1, which also implies the right counter-move", right?

...

Correct, when the memory is read by the bars which push the and gates into vertical alignment in case the memory is 'high'/true. 

I think I may need to clarify the two 8-input OR gates: These large horizontal H shapes are the central connections between the input AND gates and the output AND gates. Basically all these AND gates "patch in" to one of the OR gates that connect all keys and fields. Crucially the arms that can block the memory also patch in to these OR gates.

Thus the memory bits define which keys trigger which large or gate and what countermove will occur and also where the memory needs to go next.

8 hours ago, gyenesvi said:

...

The constructions seems pretty complicated, though the build process does not necessarily need to be complicated (even though somewhat repetitive), it would be good to understand how easy it is to make building mistakes that result in movement jamming or other erroneous operation for example. 

...

When I built the prototype it turned out that it was very testable during every step of the build. The advantage of that is that a building mistake can be fixed in time. Basically unit testing before integration 😉. The main risk for erroneous operation die to a building mistake is an error in the memory. This is why the memory can be reasonably easily removed.

9 hours ago, gyenesvi said:

...

But more importantly, I'm afraid that also operating it, especially the steps of resetting, could turn out to be somewhat complicated for an average person. For example, even though now I get the reset process, I'm pretty sure I would not remember it in two weeks time :)

First thing I wonder about is game play. I understand now that the memory needs to be transitioned with a separate gesture. What happens if I accidentally skip that, and play another move? Is that blocked, or will that result in some suboptimal / random moves? Also, it's not clear to me why this separate gesture is actually required, if movement of the memory is powered by the scissor mechanism? Can the keystroke not also trigger memory movement, since it has its own power source?

Next thing is resetting. If I look at it from a user perspective, a more ideal procedure for resetting would be

  • Reset the whole display with one lever (instead of a CW and a CCW rotation per field). I'm thinking that all field resetters could be linked and moved in sync, and a rubber band could pull back the lever (instead of needing to turn back all squares)
  • Rewind the memory with one movement, instead of three movements. A single controller move could in principle operate all three stages of lifting the gates, shifting the memory, lowering the gates

These would significantly simplify the resetting procedure, and seem mechanically doable, though I understand that it might require some significant adjustments.

These are just some ideas by the perfectionist inside me, but it is already an outstanding work as it is!

There are indeed a lot more possibilities, but I ran into the LEGO Ideas part limit. That is also why there is no win-lose indication. The signal is available, but the parts are not.

If you press two valid keys without turning the dial, then currently there's no guard in place. A guard could be integrated and triggered by an additional OR in the middle in both the two large OR gates. Then be reset by a dial turn. That would require additional parts.

A major obstacle to automatically moving the memory on a key stroke press, is that the memory readers must be lifted and this requires a user action. Turning the dial lifts the memory readers. This needs the power of the dial rotation and is supported by two springs (shock breakers) to push the memory readers up for memory reading, but also force them down to correctly read the bits. 

Central reset of the display was the original idea, but my solution didn't fit. The idea was a slider mechanism, gears had too much play and reset needs precision on all 6 axles. It's a bit finicky. The seperate controls never fail to reset each line.

The different rotating directions for display reset is a last minute fix to an error I made. That is easy to fix and I can't image LEGO wouldn't do it if this became a set.

A rubber band on the lever is definitely a good idea 👍 even as it is now.

And to the last comment: Thanks 😊 and thanks for sharing the suggestions and taking the time to write it all down. 

Posted
38 minutes ago, Joostv said:

There are indeed a lot more possibilities, but I ran into the LEGO Ideas part limit. That is also why there is no win-lose indication. The signal is available, but the parts are not.

I will say it again, and it may upset people: There are alternatives to LEGO. Some of these use superior pieces (regarding stability = clutch power) of highest quality. Prints only. And they also ask for user input.

What I find most important for this beautiful mechanism: Never go "cheap" or run into parts limits. That may be OK for the IDEAS program. But it is not for a true beautiful mechanics program. Some alternatives using superior pieces go nuts on tiling floors, shaping walls, adding a plethora of decoration elements, never forgetting about the functions. At a fraction of the price, TLG would be asking for. Including all TLG self-imposed limitations.  

But - should it be LEGO, then yes, this build needs what I would call serious downgrading. Which would be ... "bad" (Dr. Egon Spengler)

All the best
Thorsten  

Posted

This is absolutely stunning, so much planning and implementation, just an incredibly cool mechanism. All that and the design and looks are simply amazing, would look good in any setting. Hats off to you sir.

What's even better is the inspiration to build a similar mechanism, for that I thank you.

Posted (edited)

Again, I think this is a monumental achievement! You have already inspired me to revisit another long-dormant crazy idea...

Now the part I don't really want to say: Sadly, based on the past record, I fear the chances of it passing Lego Ideas are basically nil. Which is not to say that you should not try, of course!

But in any case (but especially given this reality) I hope you will consider developing an enhanced version that addresses some of the compromises you had to make based on the part limit. This idea deserves to be unconstrained by arbitrary limits!

Edited by aeh5040
Posted
14 hours ago, aeh5040 said:

Again, I think this is a monumental achievement! You have already inspired me to revisit another long-dormant crazy idea...

Now the part I don't really want to say: Sadly, based on the past record, I fear the chances of it passing Lego Ideas are basically nil. Which is not to say that you should not try, of course!

But in any case (but especially given this reality) I hope you will consider developing an enhanced version that addresses some of the compromises you had to make based on the part limit. This idea deserves to be unconstrained by arbitrary limits!

Thanks! 

To be honest, if it fails on Lego Ideas I'll likely create a smaller 'inspired' design with a different function (not playing Tic-tac-toe) and share instructions of that. This design has some really hard to source parts, which is something I would change when sharing instructions. Different route, different (self imposed) limitations 😉

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...