next »

[a-k-]

Not ready for integration yet, but this is going to be the 16th language:

Code: v                             < > "AAAAAAAAAA" 91+k, &   #v_v v                           < > "BBBBBBB" 7k,              v v                            < > "CCCCCC" 6k, &              | v                             < > "DDDDDDD" 7k,              ^ v                         < > "EEE" ,,, @		Code: >              v v "AAAAAAAAAA" << > 91+k, &   #v_v v "BBBBBBB"    < > 7k,         v v "CCCCCC"    <  < > 6k, &         | v "DDDDDDD"     < > 7k,            ^ v "EEE"      < > ,,, @		Code: v                < > AAAAAAAAAA #v_v v               < > BBBBBBB      v v              <  < > CCCCCC         | v                < > DDDDDDD         ^ v             < > EEE @
Option 1: - Befunge-93 + "k" from Befunge-98 - Execution using I/O - Commands written right to left		Option 2: Same as Option 1, except: - Commands written left to right - Better packed horizontally		Option 3: Same as Option 2, except: - Befunge-98 - Direct execution ("fingerprint")

(loops, conditions and commands execution - 3 options for modeling)


Update: added image + two more options

[a-k-]

Befunge is now integrated in the game:



The last post has been updated with the options I considered until settling on full adoption of Befunge-98 features.

Additionally, following LiquidAsh's great suggestions in the Playtesting board, I've added support for varying the inputs to a level based on the program that runs on them, and a corresponding chicken and egg level to let players enjoy the resulting mess...

[a-k-]

Compare with friends

Probably the simplest and least user-friendly implementation of Friends:


(to connect, Foo and Bar had to exchange "friend IDs" outside the game)

Minigame hints


(clicking Hint after failure cements correct keywords and removes incorrect ones)

[a-k-]

Been doing mostly little enhancements/fixes to the UI, some following player feedback and others that were long overdue. My favorite one is that shortcuts in the Controls screen are grayed if still locked:


(a snippet of what new players may see)

I've also added more keyboard shortcuts for advanced editing. Some functionality can still be done only using the mouse, and it remains to be seen how to reconcile it with the existing shortcuts, the limitations of the HTML5 version, and perhaps also support mixed keyboard/mouse inputs (as I already do for actions that are initiated by the mouse):

• Copying/moving commands (including rotating/flipping, though those already have keyboard shortcuts when dragging with the mouse)
• Pasting from clipboard
• Selecting a non-rectangular area
• Scrolling without changing selection

[a-k-]

For the json-philes among us, jq has been added to the Intro:



I preferred clarity over brevity so deliberately avoided foreach and INDEX/JOIN (basically, anything with multiple arguments), but now that I'm looking at the full script, I can't tell which incantation is simpler than the other.

Code:

jq -s 'foreach .[] as $circle (-1; . + 1; $circle + {node: .})' circles.json
jq -s '[., [range(length)]] | transpose | map(.[0] + {node: .[1]}) | .[]' circles.json

(equivalent ways to assign sequential 'node' numbers to circles)

[a-k-]

This may feel like a cross between Befunge and Piet:

Code:

           >>  (command 4k)
            ^k  (command 4k+1)
(start)  >>>>l
            vj  (command 4k+2)
            >>  (command 4k+3)

(every 4 commands take 5 rows)

Most of the translation and UI is already implemented. Still need to decide whether to display the execution flow through the program. It's much simpler than Piet (no concept of "color blocks" that result in diagonal execution paths), so that may not be necessary for understanding the translation, but the language is just as cool so I feel like it deserves everything I've provided for Piet...

[a-k-]

This time I didn't bother generating the tiles in an order that resembled execution order, so some tiles choose to fly far and the animation feels a bit chaotic. Maybe I'll just divide the tiles to groups geographically and animate each one separately.

Next steps:
- Implement a simulator
- Display execution paths according to simulation
- Decide where to unlock the thing (that's the tricky part!)

[a-k-]

Translation to Manufactoria has been released.


(orthogonal lightning bolts)

You may have noticed some redundant branches in the last gif - those have been eliminated by using variable-length encoding (prefix-free). I've also fixed the order of commands so that inverting the condition of a while loop won't shuffle things around unnecessarily (this change improved Piet as well).

Visually, the tiles are modeled after the 2022 version of the game, but only instructions that existed in the Flash version too are used. As for keywords, there's no official definition that I'm aware of, so I've just taken the names that are used in the savefile and factored out common substrings to arrive at something that's more minimal.

[a-k-]

I've just found a funny bug in the HTML5 version.

There's a screen in the game ("Records") that displays the code of all the best solutions of the player, and there's an option to zoom out with Ctrl+wheel. Naturally, when you zoom out there's more text to render, so in the PC version, for my savefile (lots of solutions), frame time increases from 0.8ms (no zoom) to 1.1ms (max zoom out) - nothing to worry about.

The HTML5 version is slower, and frame handling+rendering time without zoom is 2-4ms. But when I zoom out, it jumps to ~350ms for some zoom levels, and stays at 2-4ms for others - consistently, as if there were some cursed zoom levels.

Code: (state preserved across frames)

float m_zoomFactor;    // 1 = no zoom, <1 = zoom out

// rendering optimization
float m_lastFontSize;
int m_lastFontSizeInPixels;

Code: (rendering a frame)

    const float fontSize = 75 * m_zoomFactor;    // 75 virtual pixels = 2.5% window height
    const int fontSizeInPixels = toPixels(fontSize);

    if (fontSize != m_lastFontSize || fontSizeInPixels != m_lastFontSizeInPixels) {
        m_lastFontSize = fontSize;
        m_lastFontSizeInPixels = fontSizeInPixels;

        // calculate text metrics... (slow due to proportional font)
    }

    // render visible text... (fast)

Can you spot the issue in this perfectly-legal code?


<spoiler>
The culprit is fontSize != m_lastFontSize.
While optimizing, Emscripten turns this into 75 * m_zoomFactor != m_lastFontSize, where the left-hand side is double precision (JavaScript) and the RHS is single precision (read from Float32Array). For some values of m_zoomFactor, this condition will always evaluate to true.

Emscripten has a build option PRECISE_F32 that avoid such cases by sprinkling Math.fround() everywhere, but that has performance impact so it's disabled by default. Fortunately, I don't use the above practice a lot, so I can simply fix all relevant cases by adding volatile.
</spoiler>

[bayersglassey]

Befunge is now integrated in the game

This reads like the last journal entry of a Lovecraft protagonist, or of the dwarves of Moria.
I felt a little chill up my spine...

[bayersglassey]

That is a really cool animation... what is happening there??

[a-k-]

That is a really cool animation... what is happening there??

Huh, that's simpler than you imagine.

The contents of the grid is regarded as a sequence of tiles, according to the somewhat-arbitrary order which I happen to generate them in (i.e. ignoring tile coordinates). This way, we have two "strings" S and T for the old and new code.

To calculate the S-->T animation, I run a diff algorithm that computes the minimal edit script - a series of insertions, deletions and copy operations (common substrings) that transform S into T. Tiles that are deleted are faded out, tiles that are inserted are faded in, and the common tiles just move from source to target coordinates if those differ.

foobar --> bazbar
123456     123456
edit script (for example): foobazbar
- fade out: foo
- fade in:  zba
- move:     ba from 45 to 12

A surprising effect is that when you undo a change you don't always get the same animation played backwards:


(repeatedly undoing/redoing a change: animation at the top is reversed, but the bottom part uses a different animation for undo)

That's because there can be several edit scripts that are minimal, and in general, diff(T, S) doesn't necessarily return the "inverse" transformation of diff(S, T) (by inverse I mean, exchanging insertions<-->deletions).

(Of course, you don't notice this when you diff code - normal code doesn't consist of so many repeating lines...)

I have a feeling that I can fix this inconsistency by reversing the strings before computing the diff, along the lines of
    consistent_diff(S, T) = (S <= T) ? diff(S, T) : reversed(inverse(diff(reversed(T), reversed(S))))
    consistent_diff(S, T) = (S <= T) ? diff(S, T) : reversed(diff(reversed(S), reversed(T)))
but I haven't attempted that - it all depends on how the diff algorithm breaks ties.

Update: alternatively, I can use
    consistent_diff(S, T) = (S <= T) ? diff(S, T) : inverse(diff(T, S))
which should work for all diff implementations.

Anyway, I guess I'll use neither since I've already got used to these strange undo/redo animations (they remind me of perpetuum mobile, go figure...)

This reads like the last journal entry of a Lovecraft protagonist, or of the dwarves of Moria.
I felt a little chill up my spine...

(probably?)

[a-k-]

Two new levels

No spoilers... (it's kind of a new mechanic)

Performance

I've focused mainly on the screen that players interact with the most - the editor. Specifically, on what happens when players edit their solution.
This is from the latest Windows version, about 10 seconds of frantically making ~100 edits to a gigantic solution in a complex level:



As you can see, dynamic memory management is the top spender of CPU cycles (multiply by x1.5 to add deallocations). That's expected as these algorithms don't crunch numbers*, and that was the case also before I started optimizing, yet I found it funny to discover that malloc/free were almost the only proxy for performance - it was very hard to find my algorithms anywhere else as if that were all they were doing.

I can still reduce the total by x2 or so, but for now I guess that will do (also for HTML5 on battery power).

Random Intro

Players now get a random variant of the Intro. It can still be changed in the settings, but that's no longer an easter egg. And there's an eighth variant:


(SQLAlchemy)

---
* except diff(), with 1.2% CPU time besides its malloc/free impact

[a-k-]

As if I didn't abuse Prolog enough as a language in the game, now it's also available in the Intro. I knew it wouldn't be a very good fit, but I just couldn't resist its Query By Example-style JOINs:

Code: (idiomatic Prolog)

link(N1, N2) :- arrow(X1, Y1, X2, Y2), coord(X1, Y1, N1), coord(X2, Y2, N2).

(joining arrow(X1, Y1, X2, Y2) with coord(X, Y, N) twice to produce link(N1, N2))

Unfortunately, Prolog REPLs support little more than queries, so I had to do some adaptations that resulted in a script that can't really serve as a good example for the language.

For start, in SWI-Prolog, defining predicates such as the above in the REPL requires you to type (in bold/italics):

?- [user].
|: link(N1, N2) :- arrow(X1, Y1, X2, Y2), coord(X1, Y1, N1), coord(X2, Y2, N2).
|: <<pressed Ctrl+D/Ctrl+Z>> ^D% user://3 compiled 0.00 sec, 1 clauses
true.

That was a little noisy and I also didn't want to show key presses, so instead I opted to define predicates dynamically, i.e.

?- assertz((link(N1, N2) :- arrow(X1, Y1, X2, Y2), coord(X1, Y1, N1), coord(X2, Y2, N2))).
true.

Then there's how results for queries were displayed:

?- link(N1, N2).
N1 = 1,
N2 = 3 <<pressed R>> ;
N1 = 1,
N2 = 4 <<pressed R>> ;
  ...
N1 = 4,
N2 = 6.

The Intro required one line per result, so manual printing seemed appropriate:

?- forall(link(N1, N2), writeln((N1, N2))).
1,3
1,4
...
4,6
true.

Here I felt that backtracking would be more true to exploratory work than forall, so that became

?- link(N1, N2), writeln((N1, N2)), fail.
1,3
1,4
...
4,6
false.

I did ultimately use that approach at times, but in general preferred to have each result defined as a distinct fact, like in a database:

?- arrow(X1, Y1, X2, Y2), coord(X1, Y1, N1), coord(X2, Y2, N2), assertz(link(N1, N2)), fail.
false.

That had the benefit of making explicit printing redundant:

?- listing(link).
:- dynamic link/2.

link(1, 3).
link(1, 4).
   ...
link(4, 6).

true.

And there were more hacks, of course. You get the idea...

[a-k-]

Feasible: yes
Fun: ?

[a-k-]

(not to be confused with bomain-driven design)

[JobLeonard]

"unsuspecting programmers" lol, you make it sound like you're plotting something evil

[a-k-]

"unsuspecting programmers" lol, you make it sound like you're plotting something evil

I am! That's just the first step...

[a-k-]

This deserves a more elaborate post, but since Cloudflare has just announced their new Ca.ptcha, I urge you to try my competing solution ("cf.gC.apt.cha", available here on the Playtesting board) before a multibillion company killer-acquires it.

Passing the ca.ptc.ha requires only 4 (correct) clicks, but you can continue playing to unlock 3 bonus languages*, including this exclusive one that didn't fit the parent game:




A few UI enhancements that have been made:
- Option to eliminate candidates (useful especially when playing on the phone)
- Diagrams increasingly getting deformed on repeated failures and after unlocking all content ("endless mode")
- Indentation made clearer by overlaying two <pre> elements with some vertical offset to create connected lines


(indentation lines are shown here in yellow for emphasis. | is used instead of &boxv; because if the latter is not present in the monospace font, the browser's fallback of using a variable-width font misplaces the lines.)

---
* yeah I couldn't help myself...

[a-k-]

Continuing with the captcha game, two languages have been added, one of them new (REBOL):


Here's how the two games relate to each other:


Finally, I can add languages that don't support goto...