Bryan, thanks for publishing, this is great work. I'm curious if this this build could fit and swap a 13.3 E-ink screen with display board. Some open source hardware synergy with https://github.com/Modos-Labs/Glider/tree/main

I was really impressed with the online presentation of EmacsConf 2024. Everything captured and published in org-mode: Transcripts, Comments, QA, Video links. Was really nice to peruse.

Deeply nested inline anonymous function callbacks are the anti pattern. Decoupled explicit named functions passed as callbacks are a significantly better developer experience and provide clearer stack traces. I never understood why this conversation didn't take the lexicon and instead the imo inferior `async` pattern got pushed hard.

Extracting callbacks into separate functions is just more indirection.

And they don't solve the core issue of async control flow that async/await solves, so it's not an alternative to async/await much less a superior one.

A classic example is when you want to conditionally do something asynchronously like B() in this case.

    function process(id, callback) {
      A(id, (result) => {
        if (result === 3) {
          B(() => {
            C(result, callback);
          });
        } else {
          C(result, callback);
        }
      });
    }

Versus:

    async function process(id) {
      const result = await A(id);
      if (result === 3) {
        await B();
      }
      return C(result);
    }

Add a couple more layers of this and the async/await function stays simple and flat, and the callback version grows significantly more complex and nested.

Without the async keyword, it was far superior to anons. Also, named functions showed up on stack traces making it easy to know what is getting called

No serious person is going to claim that any form of callbacks is superior to async/wait

Don't forget having to use try... catch for exception handling. This is why promises are the one true way!

High performance real-time games it is questionable. Any genre that is more static turn based can be a great boon.

Check it out, it is handling hundreds of entities at >>60 FPS. And I still did not do much performance optimization (there are still many lazy seqs around and unoptimized code).

Also most of the sprite rendering is the main problem, which an atlas texture could also improve even more. (Right now all creature animations are separate texture files).

And you can always step down a level to java if the need arises!

the issue with JVM/java was always that when that GC triggers you are just absolutely hosed.

C# tends to be a bit more forgiving about when it triggers GC and how. The generational garbage collector in C# will tend to be more reliable or at least I never ran into super huge issues with the places I've used C# for game dev.

The JVM GC has this unfortunate effect of having very bad pauses occasionally. And appears to do so regardless of the type of GC you are using.

There are some techniques you can use to get around this -> re-using entities. Using C# structs. Not doing allocations/deallocations inside the main game loop if you can.

For small enough games it is irrelevant but as soon as you start to get a larger game with lots of memory allocations/deallocations it really crushes performance.

Minecraft is written in Java, it doesn't look like the choice of platform kept it from becoming a success.

It was however completely rewritten in C++ when they needed to port it to more constrained platforms, every mobile and console version uses the C++ codebase while PC has both versions in parallel. If you ever intend to release your game on multiple platforms then Minecraft isn't an example to follow unless you're up for starting over from scratch at some point.

A side effect from specific platforms not allowing Java, and Microsoft buying Mojang.

Notch surely isn't sorry for having coded it in Java.

It worked out for Notch, sure, but most indie devs don't get the luxury of only considering console ports after they're already set for life from initially only releasing on PC. Planning for cross-platform from the start is table stakes, especially now the Switch has become just as if not more of a popular platform for indie games than PC is.

Most indie devs already strike gold if they manage one platform at all.

Too much is wasted on what language, or engine to use, instead of what actually make as a game.

And even when everything is done right, it is a drop in the ocean of daily released titles.

If anything using Java made it extremely moddable and is IMO part of the reason why it became a success.

Bad performance did delay one of the big new-biome-type releases in the Java version.

Unity's new incremental gc saved our bacon.

60 FPS of 3D objects in a 3D world?

very cool I like the UI. Wish it had the catalog from keygenjukebox do net though.

Noted.

> Where did the motivation come from?

I host a bay area indie gamedev coworking group. The coworking group's regular recurring meetup interval kept me in a peer pressure and positive feedback loop. I also felt the need in the market had not been addressed until this new wave of engines started appearing.

> I’m impressed that you can remember the obstacles you overcame several years ago.

I kept a daily journal in org-mode and separate dev log file. Can search through this and my commit history for lots of info.

Makes sense, thanks for the feedback

The dependent work to setup a signaling server and ICE/STUN/TURN NAT punch through is a big barrier to using WebRTC.

Thanks for reading and sharing your work!

I host an indie gamedev coworking group in the bay area and on discord that you might find interesting. Will DM you.

> How did this one go? I ended up literally doing a `ln` for shared frontend/backend files.

Very easy with module imports. Same scene graph and entity component system shared between client and server.

Greetings Vekz! Great to read your article!

(Conrad from the coworking group)

Thank you. Great idea.

Too Real.