TIL about https://fontpixel.com thanks to the attribution information on the latest #lispgamejam entry by @Alexjgriffith

With only ~1 week to make this game there are certain things that were left undone like more graceful handling of disconnects that allow players to rejoin the game, etc. but making anything multiplayer is a challenge and I'm proud of what we were able to accomplish in a short period of time.

The last game we made for the lisp game jam was also multiplayer but it was a traditional client-server model due to infrastructure limitations. But now, thanks to @tsyesika and NLnet, we can make p2p games using our new end-to-end encrypted relay! The web server is simply the means to deliver the static game binary and assets to your computer and does nothing else. All game state is stored in the browser and anyone can host a game.

The game I worked on for the #lispgamejam is called Polydraw. It's a peer-to-peer multiplayer party game reminiscent of something you'd find in a Jackbox party pack.

Players take turns drawing based on a prompt and the other players try to guess what it is. The catch is that the artist only has 60 seconds and can only draw a series of triangles.

Thanks to @cwebber for the concept and animations, @vv for the tunes, and @mlemweb for the prompts.

https://davexunit.itch.io/polydraw

A little bit of post-jam analysis https://itch.io/jam/autumn-lisp-game-jam-2026/topic/7357433/language-stats

Congratulations to everyone that submitted to the #lispgamejam! We received 23 entries this time. Check 'em out!

https://itch.io/jam/autumn-lisp-game-jam-2026/entries

I started comparing balanced diets to guile's intsets as the results are as expected. if the set stored in a diet is actually dense (a lot of adjacent ints) and thus the tree is shallower than the intset's prefix tree then it's faster to query the diet. otherwise the intset's 32-way branching wins.

it's also much faster to add contiguous ranges of numbers to a diet because it was built for this and you don't have to insert one number at a time.

okay I seem to have a successful fusion of diets and red-black trees. let's call them "balanced diets".

Hoot 0.10.0 is out! We've fixed some bugs, improved record types in the interpreter, and made a bit of progress towards R6RS compatibility, among other things.

Full release notes on the @spritely blog:

https://spritely.institute/news/hoot-0-10-0-released.html

#spritely #scheme

something I realized last night: since diets are a sort of meta-tree that can delete nodes during insert (when the new interval overlaps or is adjacent to two existing intervals) and add nodes during deletion (when the interval to be deleted is a subset of an existing interval), that means that both operations need to incorporate the red-black tree insertion and deletion algorithms.

yesterday at the gym I saw a guy wearing a shirt that said "we HRT you" and I thought well the intended reading of that must be "we heart you" not "we hurt you" and of course "HRT" stands for "hormone replacement therapy" but then he turned around and the back of the shirt said "hudson river trading"

RE: https://mastodon.gamedev.place/@djlink/117505969964946590

This is why I have been pessimistic about LLM "reverse engineering". The big LLM companies will just do the equivalent of YouTube/Twitch taking down your video/stream when they detect copyrighted music or whatever.

Big companies can slurp up the commons, but you won't be able to return the favor.

The great thing about functional pearl papers is that they are short enough to be printed out so you can highlight and write notes on the pages and have it by your side while implementing.

I read Chris Okasaki's "Red-Black Trees in a Functional Setting" (1993) paper over the weekend and it's brilliant. Pretty much all the resources on red-black trees out there describe very imperative algorithms but this paper describes a functional insert algorithm that is much simpler than anything else I've seen.

https://www.cs.tufts.edu/~nr/cs257/archive/chris-okasaki/redblack99.pdf

Unfortunately, Okasaki conveniently leaves out deletion! Red-black tree deletion is mind bending! Thankfully I'm not the first person to notice this. Kimball Germane and Matthew Might published a functional pearl of their own in 2014: "Deletion: The curse of the red-black tree"

https://matt.might.net/papers/germane2014deletion.pdf

I'm reading about all of this in an effort to add the balancing properties of red-black trees to the discrete interval encoding trees (diets) in Martin Erwig's "Diets for fat sets" (1993):

https://web.engr.oregonstate.edu/~erwig/papers/Diet_JFP98.pdf

My microbenchmark is showing about a 10% improvement in set membership queries over the unbalanced version with a randomly generated large set. Maybe it's not worth all the effort but I don't really like implementing trees that *could* degenerate to O(n) query time.

I don't have a reddit account anymore but some weird spammer/bot is saying they made Terminal Phase by @cwebber on r/lisp

https://www.reddit.com/r/lisp/comments/1xcdfvi/i_made_a_space_shooter_that_runs_in_your_terminal/

"no PHP" has been a firm demand for all of my jobs since college.

Today is one of those days where several different projects have converged at @spritely. In 2024, @cwebber made a federated relay system for OCapN. In 2025, I made a prototype of a local-first chat program that does CRDT data sync over OCapN. Over the past few months, @tsyesika has added end-to-end encryption to the relay system. And just now, at last, @tsyesika and I had an end-to-end encrypted chat using two relays that federate over Tor and it all just worked!!! its-happening.gif

Some other reliable protocols built on UDP (or IP) are 1) RUDP, made by Bell Labs for Plan9, which has a draft RFC from 1999 and 2) SCTP, notably used by WebRTC. I think I can rule out SCTP as a good fit because it has multistreaming (like QUIC) and multihoming which are both unnecessary for OCapN. RUDP seems much simpler but anything that was ever deployed seems to use something that forks from the draft spec, but perhaps it's a good starting point.

I have been thinking about how QUIC, the new hotness in low-level transport protocols, might apply to OCapN. My initial findings suggest it would be a poor fit but I'm still doing research.

QUIC's killer feature, stream multiplexing, doesn't do anything for OCapN because 1) OCapN mandates only one connection may be open between any two peers at a time for reasons of reference equality (in the sense of eq? in Scheme) so there can't be multiple streams at this abstraction layer 2) OCapN mandates FIFO order of message delivery and 3) unlike HTTP, OCapN is async and doesn't use a request/response cycle so once a message is delivered the pipe isn't blocked waiting for a result. The remaining advantages of QUIC are relatively minor things like faster connection due to not having to wait for a TCP handshake before doing a TLS/Noise/whatever handshake and just not being ossified like TCP.

A reliable transport built on UDP would still be very useful for OCapN because you need UDP for NAT hole punching, but idk if there's anything that can be taken off the shelf and used as-is.

today's book is A Deepness in the Sky by Vernor Vinge and golly gee it's the first edition hardcover edition