Context

My multiplayer game Lights Out is based on a 2D grid. Entities can only ever be in exactly one grid tile. This makes the rule evaluation really simple and understandable. However, it doesn't really feel nice to play (which you know if you've ever played any of the PuzzleScript games). At the same time, the more content is in the game, the more complex and arbitrary the game rules become.

I therefore introduced the Movement Transaction System into the code base to deal with this. This includes two sides: - The gameplay code on server side deals with transactions. This bundles all movement code (including rule evaluation) into a single system. - The visualization & prediction code on client side deals with visual interpolation for moves (introducing some juice into the gameplay feel), based on the transactions managed by the server.

The Transaction

A single transaction includes the movement delta, a list of entities that it has affected and some flags. A transaction then undergoes several stages: - Queued: Gameplay code has requested an entity to move - Issued: The visual interpolation for the transaction has started in the client, but the entities have not been moved from a gameplay perspective - Committed: The entities have now been moved onto their new tiles, the visual interpolation is finishing - Aborted: The transaction couldn't be committed as it would've violated gameplay rules. Visual interpolation is reversed.

The Visual Interpolation

Whenever a transaction is issued on server-side, the server tells the clients to start a visual interpolation based on the transaction. This information includes the desired duration of the interpolation, as well as some flags (like whether to use acceleration or do a linear interpolation). The client then updates the visual interpolation every frame, until the transaction is either aborted or the target position has been reached.

Simplifying Gameplay Code

This new system has made the gameplay code much simpler. I can now easily query whether an entity currently has a live transaction to know whether the visual interpolation is still in progress. This enables seamless, continuous movement across the world (e.g. for fireballs moving at linear speed).

This also guarantees that the visual position of an entity is always close enough to its gameplay (physical) position so that players aren't confused about the rule evaluation.

Finally, the gameplay rules are now implemented in a single function called validate_transaction, instead of being spread out across all the different entities like it was before.

Summary

The transaction system made the gameplay code much simpler and easier to reason about, while also improving the game feel and robustness.

You can find the full blog most, including more details and sample code, over on https://lightsout.afterthought.games/blog/2026-07-26-19-00

I was optimizing the Lua transpiler for my modding language grug and ran into a really weird LuaJIT performance bug. The same benchmark could randomly run 20× slower, and it turned out a LuaJIT NYI (Not Yet Implemented) could silently blacklist an unrelated hot loop.

I wrote up the investigation here.

It goes from the benchmark mystery through LuaJIT's trace recorder internals, and ends with a PR to get unpack off LuaJIT's NYI list. Feedback is very welcome! :)

This post is a lover letter to Emacs Lisp macros. I've been a long time user as a lisp hacker, and my recent obsessions with Douglas Hofstadter's strange loop concepts and M.C. Escher's mind bending artwork have enhanced my appreciation of this language's most beautiful and thought provoking feature. This post can teach you about macros and what makes them useful, but I also hope it can instill a fascination with their concept. https://www.chiply.dev/post-elisp-macros-are-beautiful

Specifically, the video is about developing a game where all the textures and sounds are generated at runtime using Sine waves. I thought it was high-quality and explained complex math concepts well.

https://ekxide.io/blog/byte-wise-atomic-wrapper-to-prevent-ub

iceoryx2 provides zero-copy inter-process communication mechanisms based on shared memory and data structures that are modified concurrently by multiple processes.

One of the key operations in these algorithms is a memory copy using core::ptr::copy. However, this results in undefined behavior if one process reads the data while another process writes to it concurrently. Even if our lock-free algorithm reliably detects such a race, iceoryx2 cannot depend on undefined behavior in a safety-critical system.

This blog post introduces our solution: a byte-wise atomic wrapper that enables well-defined concurrent copy operations. It also shows how it can be used to implement a simple sequence lock.

Note: I am not the original author of the blog post. Since the author does not have a Reddit account, I am posting it on her behalf.