3x3x3 simulator in 745 bytes of javascript

According to that, that single line is unnecessary, but when you remove it (which is ok since it's unnecessary), you don't have any line anymore, and that old saying still claims there's an unnecessary line of code. So obviously that old saying is wrong.

It's a half-joke. Almost all perl programs have a few unnecessary lines of code.

I did:
#!/usr/bin/perl -w

One line and a bug.
 
Last edited:
Let me make this a proper challenge by defining the requirements:
- Must look like Tom's original or "equivalent" (you can for example make it graphical, or use 10..15 instead of A..F)
- Must have reasonably laid out up/down/left/right keys working like Tom's original (or use the mouse or whatever in a convenient way).
- Must have one-key/click random state scrambling.
This is certainly a stronger requirement than the original one. No sliding puzzle sim posted so far has even been close to random state scrambling.

I made one with a 9999-move one-key scrambler and the old visuals, but it's 271 characters now (plus <pre> tag): http://jsfiddle.net/pq6VK/4/

No. That's not the same. [...]
- Scrambling in our cube sim still is proper! Holding a key for like five seconds or randomly hitting keys for five seconds is both reasonably convenient and provides reasonably good scrambles. Not the case for the 15-puzzle, where you need a lot more random moves for a good quality scramble.
Of course it's the same. They're both puzzles that don't scramble themselves. Real 15 puzzles don't scramble themselves either, you know. How can you call it a proper real puzzle if it doesn't even have random-state scrambling?!

Anyway, in the new cube sims, holding a key doesn't do anything useful anymore (you have to mash keys). While I agree a 15-puzzle takes longer to scramble than a 3x3x3, you can still scramble the puzzle completely by mashing random keys. It just might take longer. And I don't personally have any problem with that.


http://jsfiddle.net/Yx8Wz/5/

I made it graphical with css sprites. Not shorter but more interesting than the work I'm supposed to be doing right now.
It just replaces the text with an image. It might make it easier for someone to actually solve.
Looks pretty nice. I did a 3:58.95 solve on it.
 
Last edited:
This is certainly a stronger requirement than the original one.

I didn't call it a challenge for nothing :D

No sliding puzzle sim posted so far has even been close to random state scrambling.

Really? That's rather surprising, given how easy it is. Basically just spam a random permutation and fix parity (or spam again until parity is ok, it's a 50/50 chance after all). Also, the one Ben has been using lately (this one) appears to be doing exactly that (see it's "scrambleStd" function).

Of course it's the same.

No it's not. For 15-puzzle there's an obvious view and for the cube there isn't, and for the cube we have reasonable scrambling while your 15-puzzle did not. But I'm just repeating myself, so I doubt it helps.

Oh, another major difference is that nobody really wanted to use that cube simulator, as it was terribly user-unfriendly from the start. The 15-puzzle on the contrary was very user-friendly.

Real 15 puzzles don't scramble themselves either, you know.

Of course I know, and the resulting poor-quality hand-scrambles are precisely the reason I never took this puzzle and its records seriously. The "real" one, that is. I do highly respect the recent simulator records (those by Ben, I mean, I actually don't know of others). The computer *does* allow us to scramble it properly, and trivially so, so we should do that.

While I agree a 15-puzzle takes longer to scramble than a 3x3x3, you can still scramble the puzzle completely by mashing random keys. It just might take longer.

"Might" take longer? It most certainly does. Much longer. And it's simply not reasonable at all, given that random state scrambling is trivial (it is fairly easy for 3x3 as well, btw, as we're not producing a short scramble alg to be applied to a real cube (which is indeed hard) but only produce a scramble *state*).

I made one with a 9999-move one-key scrambler and the old visuals, but it's 271 characters now (plus <pre> tag): http://jsfiddle.net/pq6VK/4/

Doesn't work for me. The result screen is empty and stays empty when I press keys (tested in Chrome and IE).
 
Last edited:
Simulator for the Rubik's Cube.

I think Carson deserves better than that. I actually agree with what I think he means. This cube simulator doesn't simulate the cube. It doesn't simulate an L turn, for example, which is a fundamental move on the real cube. We simulate that turn. But that's not the same. Essentially it's not a simulator for the Rubik's Cube. If it for example allowed <r,u,f> turning, we also wouldn't call it a Rubik's Cube simulator but an <r,u,f> solving simulator.
 
Last edited:
Really? That's rather surprising, given how easy it is. Basically just spam a random permutation and fix parity (or spam again until parity is ok, it's a 50/50 chance after all)
Not surprising at all, given that we are trying for as few characters as possible. Because of those pesky \ns I can't really think of any short way to actually generate a random state. You're free to try yourself, and I'd like to see your result.

Doesn't work for me. The result screen is empty and stays empty when I press keys (tested in Chrome and IE).
It looks like Chrome wasn't accepting function(e)d(e.keyCode%5) - it wanted some {}s. Here's a fixed version with 272 characters: http://jsfiddle.net/pq6VK/5/

PS: can I at least get a "nice job" for completely optimizing the 15 puzzle myself?
 
Not surprising at all, given that we are trying for as few characters as possible. Because of those pesky \ns I can't really think of any short way to actually generate a random state. You're free to try yourself, and I'd like to see your result.


It looks like Chrome wasn't accepting function(e)d(e.keyCode%5) - it wanted some {}s. Here's a fixed version with 272 characters: http://jsfiddle.net/pq6VK/5/

PS: can I at least get a "nice job" for completely optimizing the 15 puzzle myself?

nice job
 
Not surprising at all, given that we are trying for as few characters as possible.

Yes surprising. Judging by what you're saying now, I guess your "No sliding puzzle sim posted so far" meant "posted in this thread". That was not at all clear, as I think there just had been Thom's and yours and both were 15-puzzles while "sliding puzzle" is more general. So I thought you meant in general (which should've been clear by me pointing to one outside?). And there it is surprising (or rather, wrong).

PS: can I at least get a "nice job" for completely optimizing the 15 puzzle myself?

Sure. I already did tell you [post=905415]"Good job"[/post] precisely because I do think you deserve praise, but if "nice" is preferable: Nice job.
 
Last edited:
Yes surprising. Judging by what you're saying now, I guess your "No sliding puzzle sim posted so far" meant "posted in this thread". That was not at all clear, as I think there just had been Thom's and yours and both were 15-puzzles while "sliding puzzle" is more general. So I thought you meant in general (which should've been clear by me pointing to one outside?). And there it is surprising (or rather, wrong).
Nah, I was specifically talking about code-golfed ones (that is, ones in this thread). The ones people use for speedsolving are, unsurprisingly, random-state.
 
I think Carson deserves better than that. I actually agree with what I think he means. This cube simulator doesn't simulate the cube. It doesn't simulate an L turn, for example, which is a fundamental move on the real cube. We simulate that turn. But that's not the same. Essentially it's not a simulator for the Rubik's Cube. If it for example allowed <r,u,f> turning, we also wouldn't call it a Rubik's Cube simulator but an <r,u,f> solving simulator.

I agree that /we/ are simulating the turn, but disagree that it is not a simulator.

For me, it's good enough that it reaches every position and can be fully scrambled and solved (also that is has some kind of visual output).
 
Last edited:
I agree that /we/ are simulating the turn, but disagree that it is not a simulator.

For me, it's good enough that it reaches every position and can be fully scrambled and solved (also that is has some kind of visual output).

User experience anyone? I can solve a rubik's cube. While that doesn't make me special among this community, I have been solving them for almost a decade now. While I'm not the fastest, I like to think that I have accumulated a fair amount of knowledge on the subject. Here is my issue with calling this a simulator: I can't solve it. With the knowledge of a decade of solving, I am unable to solve this "simulated cube". To do so, I would have to learn how to solve a cube with the same restrictions placed upon it as in this "sim". While this may be good enough for you... I can't justify calling it a sim under those circumstances. To me, it is just a programming experiment... a damn good one, but that is all it is.
 
I'm not arguing that any keyboard sim can replicate the exact experience, but this one requires additional knowledge to solve. Since certain moves are not possible (yes, I understand the same resulting states are possible, but the moves themselves are not) the method changes. If the algorithms used to solve a rubik's cube cannot be used to solve this, how can it be considered a sim?

It certainly is MUCH more difficult for me to solve any keyboard sim. I find that I have to stop to think about the the individual movements contained within an algorithm. While I haven't tried this in quite some time, my best time is probably several minutes. So, yes, I am very bad at it... but I am still able to solve it using the same techniques and knowledge.
 
Back
Top