Scanty docuentation 2025 12 01 I completely failed to produce anything of significance during the fall 2025 ten-day Lisp game challenge. Mind you, I expected something like this, but I had not expected my entire apartment to be turned upside down by a condp-committee mandated cockroch exterminator. Undeterred, I continue working on the project long after the challenge time is over. I still want to learn what there is to learn frlm this project. The Racket Scheme macro system isn't easy to get into for anything but the most trivial situations. I have got something running, but it isn't right yet. I have a smll piece of test game converted incorrectly from the Ink documentation. And the set of macros work to do *something*, but I haven't got the tail-recursion and continuation-passing right yet. This directory contains the state of the code I as it stands on Devember 1. Except for the example from the Ink code, it is available underthe GPL3+, but it is not yet ready for serious use. The implementation is still flaky, and I expect it will chage significantly once it gets used for anything serious. Tis ismainl an experiment to figure out whay may work. If you think you might find this code useful, please make your own copy, or you may find it changing under your feet while you use it. My longer-term plans for this code is to integrate it with my other game-development components, however mismaatched they may seem today. The Ink notation provides notations for widely branching decision trees, In paricuar, it hs things it cals 'knots;\', which are collections of alterantives, Usuallyit is the player who decides between these alternatives once gameplay eaches a knot, The users of Inkle seem to have been able to easiy put together games, so I decided to bend my favorite programming language in that direction. I programmed a Lispified version of few of Ink's control structures into Racket. I'm interested in seeing how they behave when superimposed on fuly-fledged prograing language. I leave loops to be implemented in Lisp. A knot consists of several alternatives. In my implementation, each alternitive has a key and an action. The key is a string; the action a thunk. The choice clause contains a list of alteratives. The kays are provided to the player, who gets to choose one, whic is then acted on. Ink considers it useful to allow each key to be chosen ony once; my 'choi*' imposes this restriction. (note: the * is deroved from the asterisk used in Ink to denote such a restricted choice). There is also a 'choi+' that can be chosen many times. There are still implemenation issues with the use of nested choices. Knots have names. Alternatives can uss (go name) to transsfer comtrl toa named knot. I wonder if this is really the right set of control flow features, I'll have to try it out to see,