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>