3x3x3 simulator in 745 bytes of javascript

would using document.documentElement instead of access the pre tag work? if so that's a saving of four

and after looking at this, I imagine the 15 puzzle could be made tiiiny.
 
Can I go into the realm of "ugly hacks" and undocumented behavior?

Replaced doc.getbyId(a) with document.body.lastChild
Also removes the id property from the pre tag (is that counted?)

Replace for loop with "for (j in s)".
Seems to work on both Firefox and Chrome.
(I think this would easily break though? Like by adding to String.proto? No idea...)

-13 chars in script
-7 in html

http://jsfiddle.net/SH5UX/16/
(I edited 13, the last one linked... no idea what I missed)

EDIT: I guess you're gonna go with a one-liner and get rid of the pre tag completely...? If so try document.body instead of docElem, also seems to work
 
Last edited:
278 characters: http://jsfiddle.net/SH5UX/18/
- Got rid of g entirely inside our function by redefining h to be the .split("") version of the old h
- Moved definition of s
- Got rid of the html entirely in favor of document.body.innerHTML, because why the hell not
- Replaced \n with a space

EDIT: hey, if anything goes, why not just replace "document.body.innerHTML=h.join("")" with "alert(h)"? and while we're at it, remove the spaces from h too... that would bring it down to 251 or so.
 
Last edited:
I just noticed, if you resize the window, you can get the 3 lines to wrap, and its similar to the original layout (minus the monospace font, so it can get a bit misaligned).

Just in case anyone wants to attempt a solve.
 
15 puzzle in 194 characters. http://jsfiddle.net/pq6VK/3/
Or 169 with alert(h) if you prefer ;)

Good job, but... nah, not ok.

For the 15-puzzle I'd say there is a natural and straight-forward minimum-requirements standard and we should follow it:
- Proper 4x4 view (like Tom's original).
- Properly laid out up/down/left/right keys (doesn't have to be the arrow keys, could be i/n/a/f, for example).
- Proper scrambling function (single key press), because proper hand-scrambling is hard. I suggest random state or at least 9999 random moves (maybe more, we should actually analyze this (this could be an interesting side project)).
 
Last edited:
Good job, but... nah, not ok.

For the 15-puzzle I'd say there is a natural and straight-forward minimum-requirements standard and we should follow it:
- Proper 4x4 view (like Tom's original).
- Properly laid out up/down/left/right keys (doesn't have to be the arrow keys, could be i/n/a/f, for example).
- Proper scrambling function (single key press), because proper hand-scrambling is hard. I suggest random state or at least 9999 random moves (maybe more, we should actually analyze this (this could be an interesting side project)).

Then you could also say for a 3x3x3 sim:
- Proper net view
- Proper movements for all 6 sides
- Proper scrambling function

My opinion, the lack of the second and the third option is maybe accaptable, but I don't like these "show all sides in one row" sims. For me, only the first sim is accaptable.
 
...I find it really hard to define a reasonable minimum standard.
Indeed, and that's why I think my 15 puzzle is acceptable :p FWIW it does actually have properly laid out up/down/left/right keys (use the arrow keys) although of course any other key can do turns too. The "proper 4x4 view" and "proper scrambling function" are the same kind of concessions we already made on the 3x3x3 sim without much complaint. I could add the 4x4 view back easily enough (i.e. without wasting a huge number of characters) but the proper scrambling function would be difficult due to the way I use q.

Oh, and as people have already mentioned, the scrambling function in the original 15puzzle sim was already not very good. Adding an extra character (99 moves -> 999 moves) would help, but ultimately unless we have a very specific idea of what makes an acceptable scrambler (e.g. must be random state with randomly placed hole) it's only natural to keep saving bytes by making the scrambler worse or even absent.
 
Last edited:
Indeed, and that's why I think my 15 puzzle is acceptable :p

No, no, no... that sentence only referred to the cube.

The "proper 4x4 view" and "proper scrambling function" are the same kind of concessions we already made on the 3x3x3 sim without much complaint.

No. That's not the same.

- The cube view issue was doomed to begin with, as there simply is no "obvious/natural" way to do it (except maybe graphical projection of the 3D cube onto the screen).
- 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.

unless we have a very specific idea of what makes an acceptable scrambler (e.g. must be random state with randomly placed hole) it's only natural to keep saving bytes by making the scrambler worse or even absent.

I did provide a very specific idea of what makes an acceptable scrambler (random state or 9999 random moves, and single key press (though I'd also accept any other convenient method resulting in good quality scrambles in about five seconds)). I disagree that bad or missing scrambling is acceptable (though if either, then I prefer missing).
 
Last edited:
There's an old saying among perl programmers. "Every program has one unnecessary line of code, and a bug."
According to that, you could reduce this program to a single line of code, with a bug.
 
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.
- Optional: Timer, starting with the first move after scrambling, updating at least every 0.1 seconds during the attempt, stopping with a certain key/click, showing at least "seconds.centiseconds" (the time formatted like that, not that string) and "DNF" if stopped when puzzle not solved.
- Optional: Show a sub-10 solve (by anyone)
 
There's an old saying among perl programmers. "Every program has one unnecessary line of code, and a bug."
According to that, you could reduce this program to a single line of code, with a bug.

1 line of code with a bug ok. heres my 3x3sim in c++

main(){}

bug: doesnt actually simulate a 3x3
 
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.
- Optional: Timer, starting with the first move after scrambling, updating at least every 0.1 seconds during the attempt, stopping with a certain key/click, showing at least "seconds.centiseconds" (the time formatted like that, not that string) and "DNF" if stopped when puzzle not solved.
- Optional: Show a sub-10 solve (by anyone)

I don't know JS, sorry. :-) That was encouragement for the people who are making it shorter.

1 line of code with a bug ok. heres my 3x3sim in c++

main(){}

bug: doesnt actually simulate a 3x3

Nice! Here's mine in Perl:

#!/usr/bin/perl -w
 
There's an old saying among perl programmers. "Every program has one unnecessary line of code, and a bug."
According to that, you could reduce this program to a single line of code, with a bug.

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. So obviously that old saying is wrong.
 
Last edited:
Back
Top