I've done a lot of little languages for game projects, at first poorly and unsuccessfully, but increasingly getting wins. I made a postfix stack language as a

I've done a lot of little languages for game projects, at first poorly and unsuccessfully, but increasingly getting wins. I made a postfix stack language as a scripting system to describe bullet patterns; I didn't use it to the degree I thought I would and it was hard to debug: Lessons Learned. I made an s-expression parser and small interpreter(not particularly Scheme-like, though) for an in-game console. It added a lot of friction to make the API accessible from this parser: Lessons Learned. I made a data language intended to allow for the composition of documents with varying node types. Subsequently I realized I had reinvented XML and started using that instead. I made a small VM, "Ivy", intended to provide a logical abstraction for concurrency(e.g. game actor state machines), with subthreads spawned and maintained by running a special opcode(they get pushed onto a stack, and then terminated when the opcode at the base of the stack returns false). I then target the VM as the output of various data languages. The approach didn't really provide wins in practical situations as it turned out to be more expressive to have the VM spawn more instances of itself through an API call, but it has continued to be maintained and revised and the newest generation, renamed "Hedera", is mostly designed but not operational: It's shifted to a single-thread design and a new focus on clean, hot-swappable addressing of global data resources(think URIs) which I'm using throughout the game code now. I made an XML-syntax GUI system to supplement an IMGUI. The document acts to represent the kinds of things that are normally stored in a retained-mode layout(positioning, nesting, relative scale, etc.), and it offers finer control with explicit stack push and pop and conditionals for quick disabling of elements. I'm still using this one. I made a story engine scripted with an XML syntax. This one uses the Ivy VM described above, first compiling the data to a behavior tree system, and then to the VM opcodes. It supports concrete functions for gameplay(setting counters, rendering text, presenting choices, substituting names and personal pronouns) as well as their structuring in terms of which ones get called when, pushing story passages onto a stack, transferring outcomes to hardcoded algorithms, and support for recalling save games if the story content changes. There is a lot of customization that precluded working with Ink, Choicescript, Twine, etc. - taken in whole, the stack is probably overengineered and could have been built faster/cleaner with different approaches, but it works.