next »

[a-k-]

I love how there is deep programming magic going on everywhere in this project... there's interesting stuff running on a server, there's interesting stuff running on the client side, and the player is somehow taking part in this by solving crazy puzzles by programming.
It's like performance art. :O

Thank you, that's a beautiful way to look at this project! I've noticed the parallels in the dealing with graphs (and DAGs and trees), but somehow the absurdity of all this has never occurred to me! Now I wish I could add languages as fast as players solve the puzzles...

[a-k-]

Whenever is integrated now. Here's how individual commands are translated:



As you can see, everything is driven through stdin/stdout. In order to keep lines short, a print statement can host up to 5 commands.
Unlike the other languages, which are unlocked by level progression, this one is unlocked after completing the minigame.

Minigame enhancements

• The minigame is now accessible from Level Select. A cloud of unlocked keywords is displayed when the minigame "level" is selected (see below).
• Hovering a block in the code highlights the corresponding commands in the solution, and vice versa.
• Keywords are animated when a puzzle is completed successfully.
• Server histogram for the maximal # of languages that players ever completed
• Achievement for completing a full minigame without too many errors

(for players that unlocked everything, this should accommodate 200+ keywords)

The main thing that's still missing is a win screen - I don't have any good idea for that yet.

[a-k-]

Adding some unnecessary flavors to the Intro:


(the left dialect is still the default; the right and bottom ones are new.)

For consistency with the other dialects (as well as floating-point precision issues), I've made only little use of PostgreSQL geometric datatypes - I may change that in the future (at least, for points).

Well, now I have one more place to cram languages into...

[JobLeonard]

My goodness, not just SQL but SQL dialects

[a-k-]

My goodness, not just SQL but SQL dialects

And dataframes! (pandas)

[JobLeonard]

So how much of this is developing the game and how much of this is you flexing? 

Don't get me wrong, I approve of both

[a-k-]

So how much of this is developing the game and how much of this is you flexing?  

Don't get me wrong, I approve of both

Heh, I guess it's neither? It's not something that the game needed (it's a bonus for observant players, but didn't really originate as such). And that something is in the game doesn't necessarily imply that I have deep knowledge of it (a.k.a the Internet era...)

Now if you're asking about game development, there's some stuff from ~3 months ago:

• A new level in which you build a fractal with an O(3ⁿ) algorithm (a variation on Sierpinski triangle)
• A new level in which the distribution of the outputs is tested (and needs to be nearly uniform)
• Fixed a player-reported bug in which they managed to reach commands that were displayed as "not executed" by repeatedly stepping back and forward
  
  
  (the actual case is spoilery, so here's just a trivial example of comments that the game displays)
  
  
• "Program map" widget that facilitates navigation in large boards (with scroll/zoom support and program counter animation)
• Deprecated Ctrl for multiple selection (due to conflicts with Ctrl for copying) - a message is displayed when players do that
  
• Faster solutions re-verification upon savefile upgrade/downgrade (no longer commiting the savefile for every solution separately --> fewer fsync/IndexedDB updates)
• Workaround for Firefox bug in handling small/short FLAC files (appending silence fixed it for files but not data URIs; appending noise fixed both)

[a-k-]

2 variants of R (data.table and dplyr), followed by Julia:

[a-k-]

Versions for Windows and Linux (32/64 bit) are now available on the game's website.

Content is identical to the HTML5 version, except that the PC versions are

• Faster and more lightweight
• No need to manually save and load the savefile
• Support up to 3 profiles
• VM-friendly (no shaders)

Savefiles can be moved freely between the HTML5 version and the PC ones.

[bayersglassey]

:D I occasionally poke at this game, and never get very far, but always have a couple of "WAIT - REALLY??" moments.

I see you have implemented out-of-memory errors...
(And the DO...LOOP block even has an automatically-generated comment warning you about it!)

[a-k-]

:D I occasionally poke at this game, and never get very far, but always have a couple of "WAIT - REALLY??" moments.

I see you have implemented out-of-memory errors...
(And the DO...LOOP block even has an automatically-generated comment warning you about it!)

<spoiler> There's actually a level specifically for this, and you've just happened to solve it! :-)
It's the level that teaches loops, and building infinite structures just seemed to be the best way to do that (no conditions, more open-ended, and of course there's the coolness factor...) </spoiler>

By the way, the limit on the # of nodes was originally driven by the layout algorithm, which in the general case runs every frame. It calculates O(n) square roots on the CPU (distances between pairs of nodes), and at some point the FPS just dropped too much.

[bayersglassey]

Ooh, good spoiler. :D

Also, I forgot to mention I really enjoyed how the first time it wrote DO ... LOOP in the right-hand panel, little "DO" and "LOOP" boxes popped out and fell down off the screen... kind of like 2 pieces of confetti.
And I don't seem to be able to see them again, so there must be a global variable somewhere like PLAYER_SAW_THE_DO_LOOP_CONFETTI. I really like how chock full of such tiny fun things this project is.

[bayersglassey]

Also wait a minute... how does the layout algorithm only need the calculate O(n) distances between pairs of nodes??
Maybe I'm misunderstanding what you mean by layout algorithm...
To do the physics calculations, surely you need to find O(n^2) distances so you know, for each pair of nodes, whether they're colliding?..
(I assume "n" is number of nodes here...)

[a-k-]

Ooh, good spoiler. :D

Also, I forgot to mention I really enjoyed how the first time it wrote DO ... LOOP in the right-hand panel, little "DO" and "LOOP" boxes popped out and fell down off the screen... kind of like 2 pieces of confetti.
And I don't seem to be able to see them again, so there must be a global variable somewhere like PLAYER_SAW_THE_DO_LOOP_CONFETTI. I really like how chock full of such tiny fun things this project is.

Thanks! Yeah, keywords, once unlocked, are stored in the savefile and don't animate again. There used to be a setting for that in the UI ("words: new/all"), but I removed it just 3 weeks ago...

The animation is nice in the beginning of the game, but when players launch the game to solve a particular level they got stuck in, all those words popping out again every minute or two (whenever the language switches automatically) can be quite distracting. Players complained about it and that's why I added the setting in the first place (with "animate new" as default), but now, a year later, I've come to view the "all" option as risky.

The unlocking of keywords (and languages) serve as a parallel progression track - you can view them in the Records screen, they appear on the leaderboard, and you can also play with them in the mini-game ("fill in the blanks"). Having too many animations may encourage players to minimize the code pane, hindering progression (keywords are unlocked only when visible). So I feel that's for the best. Anyway, across all languages there are more than 200 keywords - that's more than enough confetti for one player...

Also wait a minute... how does the layout algorithm only need the calculate O(n) distances between pairs of nodes??
Maybe I'm misunderstanding what you mean by layout algorithm...
To do the physics calculations, surely you need to find O(n^2) distances so you know, for each pair of nodes, whether they're colliding?..
(I assume "n" is number of nodes here...)

You understand perfectly! I forgot to mention that the nodes are placed in a grid of the order of sqrt(n)*sqrt(n) cells, and only pairs in nearby cells are considered. Assuming a uniform distribution, the amount of work per cell is constant. It's part of a classic algorithm (p. 1135 "speeding up").

[bayersglassey]

It's part of a classic algorithm (p. 1135 "speeding up").

That's a good read...

We need not faithfully imitate a celestial, chemical, or atomic system - we desire only that the results be pleasing.

What I like to hear in a paper.

[a-k-]

A new histogram:



This one is unusual in that a player can be represented by multiple bars - either "–" (not shown above) or one or more terms (N, N² etc.)

[a-k-]

Some UI updates done over the last weeks:

• A screen listing keyboard shortcuts ("Controls"), accessible from Options:
  
  
  (roughly divided to navigation, editing and debugging; taken from the PC version, where |Esc| and |F6|...|F10| are used instead of |Tab| and |6|...|0|)
  
  
• Code pane marking lines with keywords that can be unlocked by scrolling them into view:
  
  
  ("then" is invisible)
  
  
• Keyboard support for Options screen
  
• Ctrl+A shortcut - toggles between selecting current solution and all solutions
  
• Open Directory button in Profiles screen (PC versions only)
  

[a-k-]

I was just trying to understand when "paragraphs" fall through and when they act as subroutines:

PROGRAM-ID. TEST. PROCEDURE DIVISION. A.    DISPLAY "A". B.    DISPLAY "B". C.    DISPLAY "C"    PERFORM A.		PROGRAM-ID. TEST. PROCEDURE DIVISION. A.    DISPLAY "A"    PERFORM B. B.    DISPLAY "B". C.    DISPLAY "C"    PERFORM A.		PROGRAM-ID. TEST. PROCEDURE DIVISION. A.    DISPLAY "A"    GO TO B. B.    DISPLAY "B". C.    DISPLAY "C"    PERFORM A.
Output: A B C A		Output: A B B C A B		Output: A B C A B C A B C ... (infinitely)

Removes COBOL from the list of languages.

[bayersglassey]

I was just trying to understand when "paragraphs" fall through and when they act as subroutines:

I had to read over that table a few times before I understood what there was to not understand. O_o

Found this page: https://queenofcobol.com/perform-vs-go-to/
...which describes the issue you're showing in your table, and it sounds like the "fix" is something like... "PERFORM A THROUGH B".
What a horrific language feature. I don't even understand how that would work if you were trying to compile it. Like... what does the assembly code at the end of a paragraph look like?.. does it... compare itself against the paragraph we're currently intending to return from?..

Removes COBOL from the list of languages.

Sounds about right! D:


If you were willing to try adding Cobol support, then may I recommend you have a look at ABAP. >

[a-k-]

Found this page: https://queenofcobol.com/perform-vs-go-to/
...which describes the issue you're showing in your table, and it sounds like the "fix" is something like... "PERFORM A THROUGH B".

While I was running those experiments, I speculated that there was a call stack for PERFORM and that it got cleared on GO TO, but later I found in Wikipedia a description of the actual execution model and it was different than I'd thought. For example, my model wouldn't explain the second example in the link you posted.

I don't even understand how that would work if you were trying to compile it. Like... what does the assembly code at the end of a paragraph look like?.. does it... compare itself against the paragraph we're currently intending to return from?..

I guess it can be a textbook example of threaded code, like Forth that has an even more flexible control flow. At least, for problem paragraphs (also depending on how they're used).

If you were willing to try adding Cobol support, then may I recommend you have a look at ABAP. >

ABAP does look similar, at least visually - I hope it had saner control flow constructs!