next »

[JobLeonard]

Yeah, since examples were more about the default behavior of an unlabeled break statement (if I understood you correctly) I wondered if these languages supported labeled breaks or if there only was this madness.

Thanks for clarifying though!

[a-k-]

Zig, Rust and Nim have been added to the captcha spin-off game, which now features 15 languages (only four fewer than the main game!)

Progression:
- Level 1 - Python, C++, Go
- Level 2 - Zig, Rust, Nim
- Levels 3-5 - the other languages


(Rust: using a labeled break as a substitute for "goto")


The more involved among the three was Nim, whose loops can't be labeled (unlike loops in Zig and Rust).

Go func crosswalks() {     [0] L1:     for {         [1]         for {             [2]             if <3> {                 break;             }             [7]             if <8> {                 continue L1;             }             [9]         }         if <4> {             break;         }         [6]     }     [5] }

===>

Nim proc crosswalks() =   [0]   block block1:     while true:       block block2:         [1]         while true:           [2]           if <3>:             break           [7]           if <8>:             break block2           [9]         if <4>:           break block1         [6]   [5]

(Nim: introducing "block2" to serve for multi-level continue, then "block1" for what becomes a multi-level break)

Yeah, since examples were more about the default behavior of an unlabeled break statement (if I understood you correctly) I wondered if these languages supported labeled breaks or if there only was this madness.

Thanks for clarifying though!

I've since learned that Nim 2.0 (release candidate) is following Rust and deprecating unlabeled break inside blocks. A little less confusing!

[JobLeonard]

Probably a good call, demanding that the programmer is explicit about intent seems appropriate with breaks

[a-k-]

I guess it was bound to happen... JavaScript is now included in captcha game.

Algorithm:

• Start with the Go translation.
• Replace each (forward) "goto" with either an anonymous function + "return" or a labeled statement + "break".
  An anonymous function is preferred, and is emitted if there's no "return" and no "break" or "continue" that reference loops/statements in an outer scope.
• Represent "for { ... if <cond> { break; } }" with a do-while loop (unless "continue" is used).

An example that demonstrates all cases:



Also shown above are the hints for this particular puzzle. I haven't talked about it here, but hints were added some four months ago as part of making the game easier and more accessible (along with other, trivial changes). They're "context-sensitive" and work better for ordinary languages than esoteric ones that are often harder to explain.

There's a critical technical limitation that I haven't resolved: hints are currently generated in the Go server based exclusively on the code, so I resort to heuristics such as

has_labeled_loop := exists(": while") || exists(": do")
has_labeled_block := count(": ") > count(": while") + count(": do")
if exists("break ") {
   if has_labeled_loop && has_labeled_block {
      hint("break <label>", "exit loop or exit block")
   } else if has_labeled_loop {
      hint("break <label>", "exit loop")
   } else if has_labeled_block {
      hint("break <label>", "exit block")
   }
}

A more refined (and robust) approach would be to generate info about the emitted constructs during the code generation, which can later be used by the server for hints. However, the code is generated sometimes in the C++ process (e.g. in the case of Go), sometimes in the Python process (e.g. SNUSP) and sometimes involves both (e.g. JS), so I'm not really keen on doing that yet...

[a-k-]

A provisional Level Complete screen for the captcha game:

[a-k-]

The captcha game has finally got a leaderboard.
- A player name can be entered in Level Complete.
- The name need not be unique.
- The leaderboard displays the max # of languages completed per name.

The Back button is now disabled (in supporting browsers) to discourage players from fruitlessly attempting to cheat.

Additionally, as counter-intuitive as it may seem, I've added the J language (from the main game) specifically in order to make the game easier.

In general, the more "unusual" languages the game includes, the easier individual puzzles become. This is better explained with an example:


(a randomly-generated Nim puzzle)

In this case, there's actually no need to read the code to get the correct answer:
- Diagram 2: D and E precede B
- Diagram 3: C precedes B
- Diagram 4: D and E precede C

In ordinary languages (think Python/JS/etc.), only Diagram 1 makes sense.

So where do the other diagrams come from?
- Diagrams 2 and 4 are indicative of languages where I use "functions" for control flow (Prolog and Thue; also OCaml though not in this case.)
- Diagram 3 screams J ("whilst. B do. C end.") In fact, I don't know any other real-world language that can produce such a diagram. (If I knew, I would add it instead of J...)

[a-k-]

Bug fix (Linux version) - no server communication on some Linux distributions

The Linux version uses libcurl (the library that underpins curl) for HTTPS. Apparently, as part of libcurl's build process, it looks for trusted CA certificates in various locations in the filesystem and hardcodes the path to the CA bundle and/or certificates directory into the library. When the game run on a distribution that used different paths than the one used for the build, no certificate could be found and SSL certificate verification failed.

That was fixed by implementing the logic in libcurl's autoconfigure script to run at runtime. For future-proofing, I also added my own heuristics, support for related curl environment variables that libcurl didn't read, and a command-line option equivalent to --insecure.

While I was at it, I also added support for HTTP2 and removed the 32 bit version.


Histograms shown earlier on Internet reconnection

When server communication fails, the game uses exponential backoff for retries, with some upper bound on wait time. Consequently, when Internet connection was restored, it could take a while until level histograms were displayed again.

Now in the HTML5 and Windows versions (Linux has no equivalent APIs), the exponential backoff is reset whenever the offline status changes to online, so server communication can be restored immediately if needed. This also handles cases where the APIs aren't reliable, e.g. report online status before Internet actually becomes available - communication will fail but retries will be attempted earlier.


Intro - 11th variant


(DuckDB)


More tooltips


(player histograms)


(dragging a scrollbar)

[a-k-]

Some updates to the spin-off game:

- Gradual code deformation upon successive captcha failures:



The code is made out of 5 <pre> elements overlaid on each other with offset (3 for the text + 2 for the indentation). An image would be resilient to CSS tweaking but that's not really a concern here.

To preserve legibility (under normal play), the level of deformation is normalized so that languages with more condensed code (e.g. OCaml) or where every character counts (e.g. Thue) will degrade more slowly.

This also has the side effect of defeating Edge's "Web select" feature.

- Easier progression - more tolerance for failure the first time a new language is introduced

- Restored Back button functionality to allow players to learn from mistakes by reviewing past puzzles

A banner is displayed when the player navigates to a previous puzzle. I initially tried to implement it without JS, using CSS such as .target:visited ~ #banner { display: block }, but discovered that browsers severly limited what could be done with :visited and that seemed infeasible.

[a-k-]

A new language for captchas: Factor.


(do-while and unconditional loops in Factor)

As you can see above, I couldn't decide whether to use more idiomatic constructs (esp. "do while") or more popular ones ("loop"). To make the puzzles more varied, each program is assigned a random preference according to which it gets translated, and the level ends up with a few more keywords.


Here's the current mix of languages across the two (and a half) games:

[a-k-]

Factor code now uses while for loops with test in the middle (just like Rebol and J, and in the main game, also Forth):

[a-k-]

The game has over 30K player solutions now! And many new entrants to the leaderboards (+80% than before).

Shown to the right are the hint levels.


Smooth scrolling



I came up with my own algorithm here. For the initial scrolling, I chose the quadratic ease-in-out function because of its linear derivative. Then, on repeated scrolling, instead of starting the animation at t₀=0, it's started at a t₀ in the range (0, 0.5] such that the velocity is preserved. Granted, it's not very smooth, but at least it's continuous... (and simple.)

In the process, I discovered the Dark Secret of Smooth Scrolling: you really want to have one animation for both horizontal and vertical scrollbars. That is, if you're not into trippily-curved navigation. My Scrollbar class will never be the same...


Hamburger menu



An innovative variation on the beloved UI button: instead of demanding that the user aim the mouse pointer at the icon, they right-click anywhere in the editor. Then, instead of general navigation links, they're presented with a list of actions they can apply to the element they clicked! I call it position-dependent Hamburger menu, for lack of a better name.

Most editing operations now have three ways to be performed:
1. Drag-and-drop / button click
2. Keyboard shortcut
3. Using the new menu (keyboard/mouse)

Some popular ones even have a fourth option (double click).


Friends enhancements

1. Simpler interface for becoming Friends - one player invites the other and the latter accepts.

Under the hood, the server doesn't really have any concept of invitations, though. As before, it just maintains a set of pairs of players, and A and B are regarded as Friends if both (A, B) and (B, A). When a player "declines" an "invitation", they're only hiding it locally in the UI.

2. Achievements of Friends are displayed.


Miscellaneous

More tables are zoomable.

Subtle enhancements to keyboard/mouse controls, generalizing existing editing operations:
- Some actions that acted on one command now support multiple selection.
- Some actions that were permitted only in specific contexts (e.g. during drag-and-drop) now support additional ones.
- Some actions that were possible only using the mouse can now be performed also using the keyboard, and vice versa.

[a-k-]

New features in the debugger:

• Set Next Command (called "Set Next Statement" and "Jump to Cursor" in IDEs) provides the ability to immediately jump to a specific command while debugging.
  
  It can be handy e.g. when the game's nondeterminism forces the program into a path different than the one the player wants to debug. Of course, manually altering the execution flow disqualifies a program from being regarded as a solution.
  
  
• Run to Command ("Run to Cursor") and its time-travel counterpart run the program and pause at a specific command.
  
  That could previously be done with breakpoints, but some players may be more accustomed to a more direct flow.

Future work:

• Shift+click for skipping breakpoints (a.k.a "Force Run to Cursor")? That may be overkill.
• Include in context menu? If the program runs in the background, menu items may become enabled or disabled while the player interacts with the menu. It can be confusing.
• Better icon for Set Next Command, and a keyboard shortcut

[a-k-]

I was trying to assign unique and intuitive hotkeys (mnemonics) for the items in the context menu, and after a few failed attempts began to wonder whether that was even possible.

>>> items = ['undo', 'redo', 'delete', 'exchange', ... ... ... ]
>>> len(items)
22
>>> len(set(''.join(items)) - {' '})
23

There are 22 menu items, which combined together, make use of 23 letters (all except J,Q,Z). It looked too tight to be feasible, but I checked anyway:

>>> def options(item):
...     return set(item) - {' '}
...
>>> options('delete')
{'l', 'e', 'd', 't'}



>>> import networkx as nx
>>> g = nx.Graph()
>>> g.add_edges_from((item, option) for item in items for option in options(item))
>>> matching = nx.bipartite.maximum_matching(g, items)
>>> len(matching) / 2
22.0

A complete matching!
That's how it looked:

>>> for item in items:
...     option = matching[item]
...     print(item.replace(option, f'({option})', 1))
...
und(o)
(r)edo
(d)elete
ex(c)hange
... ...

With a few tweaks, I run the matching algorithm for 10K iterations, each time shuffling the order of edges so as to get a (potentially) different assignment, and printed all options available for every menu item:

(u)(n)(d)(o)
(r)(e)(d)(o)
(d)(e)(l)e(t)e
(e)(x)(c)(h)(a)(n)(g)e
(c)(o)(p)(y)
(m)(o)(v)(e)
(d)(e)(l)e(t)e (o)(r) (s)(h)r(i)(n)(k)
... ...

It seemed that I could choose any hotkey for start. So I did: assigned X for exchange and K for breakpoint, since these are the shortcuts used in the editor. Run it again, and got:

... ...
cop(y)
mo(v)e
delete or s(h)rink
... ...

Many items with only one option, and that's after assigning hotkeys for only 2 out of the 22 menu items!
Oh well, graphs are hard...


---
Update: the final result, with many nonstandard hotkeys:

[a-k-]

The translations to the next language are ready. Just need to put them in proper shape...

Go	==>	???
func MyFunc() {     [0]     for {         [1]         if <2> {             break         }     }     [3]     for {         [4]         if <5> {             break         }         [6]     }     [7] }		custom_command  my block   stmts     [0]     stmts       repeat_stmts_until         stmts           [1]         <2>     [3]     catch  break       stmts         forever           stmts             [4]             if  <5>               stmts                 throw  break             [6]     [7]

[a-k-]

Snap! is now integrated in the captcha game. Somehow, the number of languages in the two games has reached a total of 30...