Code – Prose Poetry Code

What’s in the pipeline – June 2025

As usual, I have a ton of different things I’m working on in my spare time, but I’m prioritizing some of them. I really do think these few are "big" enough to deserve being called out now, so here goes.

Altidisk

Altidisk is my latest and now greatest conlang project. In about a year and a half, it’s grown to a lexicon of almost 6000 words and a corpus of nearly 15,000, which makes it far bigger than Suvile, Virisai, or any other language I’ve created. And this is the first one I’ve seriously constructed for other people to speak, which is one reason why I’m able to be so productive with it. I have incentive.

I also have the relative ease of Altidisk being derived from Proto-Germanic in a lot of ways, and thus more of a cousin to English than something completely a priori. That means a great amount of overlap in grammar and vocabulary, although there are some "false friends" in there, owing to linguistic evolution over the past couple of millennia. (As an example, quick in Altidisk is pronounced the same as in English, but doesn’t mean "fast" so much as "alive". This is, in fact, the original connotation of the English word, too.)

At the moment, I’m about 75% of the way through a personal translation of The Little Prince, thanks to seeing someone on the old mailing list doing that. It’s the biggest translation project I’ve ever done by a wide margin, clocking in at nearly 12,000 words already. I probably won’t release it publicly, but I may post snippets and use extracts for the grammar sketch that I want to get out by the end of this year.

Pixeme

I’ve talked about Pixeme before, and it’s something I’ve been kicking around for years now. The basic idea is similar to Tatoeba, in that it’s a crowdsourced translation site. But Pixeme is different because it’s image-based. Instead of a simple word or phrase or sentence, you’ll see translations of a sentence with an image associated.

The more I think about the concept, the more I’d like to develop it. One important aspect is the "topic" of the image, and that’s something I’m not quite sure how to convey. For example, if you see a picture with a woman walking a dog through a park on a sunny afternoon, which part of that are you highlighting? Yes, "all of them" is an acceptable answer, but it complicates the structure, and it can lead to ambiguity.

But the basic principle is one I’ve tested on myself. Granted, I don’t learn in the same way as most people, but I’m also old enough that I can’t properly learn a new language, so I’d say that evens out.

What I still haven’t decided—and this is the reason Pixeme has never really gotten going—is which tech stack I want to use. I’m tired of Python and FastAPI. I deal with them at work all the time, and I want to try something different. Unfortunately, most of the other good options are equally flawed, whether it’s from being shackled to a horrible server-side language (Nest.js, Phoenix) or developed by people who promote the genocide of my race (Django Ninja).

Board With It

Out in the real world, I don’t do much, but that’s something I’d like to change. Over the past couple of years, I’ve considered an idea that…well, it’s out there. I’m calling it "Board With It", because I like puns, and it’s a fairly simple concept. Basically, it’s a nonprofit that helps children and teens (and possibly young adults later on) to learn critical thinking and social skills through playing board games.

Okay, not just board games. Since I initially thought of it, I’ve expanded the scope of Board With It to include RPGs and card games. Tabletop, in general, though definitely not a TCG or CCG like Magic: the Gathering. I want to teach kids how to socialize, not get addicted.

It’s not a bad idea. It just takes a lot to make it work. Time, mostly, which is something I’m perpetually short on. Space, preferably a public or semi-private space. (I’ve even considered looking for a church around here that would offer a classroom or something!) Oh, and volunteers: the beta test I’ve envisioned is a four-week trial run consisting of eight sessions, each about 1-2 hours long. The first few sessions would introduce the kids (ages 8-12) to tabletop gaming in general, as something more than just playing Monopoly or Risk with your family. Then would come the emphasis on gaming as a social hobby that also trains your brain. Simple.

Microcosm

Last, and most recent, is Microcosm. This is kind of an umbrella project, and isn’t yet well-defined. My hope for it is that it becomes a community project for retro computing, low-level programming, microcontroller-focused maker work, and things like that. Basically anything running on the really, really low end. Think 6502s, or tiny MCUs that cost a buck apiece. There would be tutorials, dev tools, links to articles, and so on.

Really, because this one is so vast and nebulous, there’s not much I can say about it yet. On the other hand, it feels like the one that’s the most fun, and fun is something I desperately need these days. So keep watching microcosm.works for that…once I put something up, that is.

Fork in the road

The past week or so has been an eventful one in the game development world. Unity is still backpedaling on their disastrous attempt at charging devs per-sale. The CCP-infested Unreal Engine has lowered its royalty fee. Ubisoft is teaching us all how best to set half a billion dollars on fire.

And then there’s Godot.

I’ve written about Godot Engine in the past. It first came out about 10 years ago, and it took the opensource world by storm. Here was a pro-level—okay, semi-pro back then—game engine that was free to use, without worrying that Unity would demand payment when you only ever opened the editor twice. (This actually happened to my brother.) Over the past decade, it grew, evolved, becoming the premier engine for budding developers on a budget.

All that changed a few days ago. "Get woke, go broke," the saying goes, and Godot’s management has chosen to go for broke. A far-left "community manager" proudly boasted on Twitter that this engine was perfectly fine being on an admittedly overzealous list of woke games. Fine. Sure. Find me a AAA studio that isn’t utterly broken to the mind virus, and I’ll gladly buy their games. Well, except I can’t actually buy their games; they won’t sell them to me. (California got one right this time, amazingly enough.)

Most people probably ignored the initial message, seeing it as just another fluorescent-haired professional victim parroting the latest narrative. And that’s probably how it was originally intended. But then came the doubling down. People who questioned the intent of the message started getting banned. Developers were kicked out. Backers were kicked out. The project head first claimed to be apolitical, then whined about being bullied off Twitter altogether, retreating to the safe space of leftist Mastodon. At every turn, those who objected to, disputed, or simply asked about Godot’s underlying political agenda were purged.

The great thing about open source is that this doesn’t mean the end. Because anyone can take the source, compile it, and release the resulting binaries, an open project can’t be shut down by progressive whim; this is most likely why so many are switching to "open core" models or demanding copyright assignments.

End result, though, is Redot Engine. Yes, the name’s derivative, but that’s to be expected. The whole thing is derivative, but in the positive sense that only free code under a permissive license allows. Redot hasn’t even released a build yet, and they’re already overwhelmed with support, so much so that Godot’s screeching gallery has started openly attacking it. They use the usual communist methods, so familiar from Antifa, BLM, and anything to do with Trump: projection, accusations of white supremacist beliefs, attempts to clog the system with garbage, and vague allusions of unseemly images stored on the "bad guys’" computers.

All this, because someone said, "No, I don’t want my game engine to have a political agenda."

Nor should it. Tools should be apolitical, because a tool, in and of itself, is amoral. It does not think or act on its own. It simply exists. The uses of a tool are in no way indicative of any inherent moral qualities of that tool. Nuclear bombs were once considered a viable means of digging canals, after all. And even if we accept the idea that a tool can espouse an ideology, why would we want one that’s communist? Why would we want to support the single most deadly ideology in all of human history? The one responsible for the Holodomor and the One Child Policy, the one that gave the world Stalin and Mao and Castro and Chavez?

Redot, as I see it, can be a chance to show that some people are still fighting against the encroachment of anti-human ideology in software. That gives me hope, because I’ve often felt I was fighting that battle alone, as I watched project after project adopt censorious codes of conduct or otherwise wall themselves off from rational discourse.

It’s not perfect yet, so my other hope is that the Redot team understands two things. One, something founded purely on a negative basis—that is, solely to be against another—cannot endure. This was the downfall of Voat and Threads, among many others

Second, if Redot wants to be inclusive in the true, non-bowdlerized meaning of the word, then it must be open. As yet, it is not. All discussion and development is currently hosted only in walled gardens: Discord, Github, Twitter, Youtube. There isn’t any way for a privacy-conscious developer/author to contribute, and I won’t compromise my own morals by supporting the very platforms which have spread the woke mind virus to software development in the first place.

So that’s where we stand right now. Godot has self-immolated, and I have no problem saying they deserve it. Redot is carrying the torch, but they need to prove that their words are not just wind. If they do, then we will have not only a great game engine for free, but a beacon of light in an otherwise dark time.

Twine thoughts

As I mentioned a few months back, I’m writing interactive fiction now. I’ve been planning one called The Anitra Incident, which I envision as a kind of prequel to my Orphans of the Stars novel series. (The second, which I’m actually in the process of writing, is…something else that I’ll never attach my real name to.)

In the previous post, I looked at what I consider the top four tools for creating interactive fiction: Inform 7, Twine, Ren’Py, and Ink. I think I made it clear then why I felt Twine was the best choice for what I’m writing. Now that I’ve been working with it for a while, I have some thoughts to share. These are more of a ramble than even my usual posts here, so bear with me.

Ditch the editor

Twine’s biggest draw is that it has its own editor, with a nifty little drag-and-drop visual tool to organize your stories. It looks good, and it helps to get people interested in creating, rather than whining about how they don’t want to have to learn anything.

But it sucks.

Yes, the editor works just fine for small-scale constructions. Twine divides its stories into passages, which are just that: bits of text that can be anywhere from a few words to an entire chapter, with all the necessary logic for interactivity sprinkled in. A big story with a lot of branching points, arcs, and the like is going to have hundreds, if not thousands, of passages. (Case in point: my unnamed side project has 232 total passages already, and that’s not much more than a set of locations and a handful of conversation scenes.) Trying to keep all that straight will quickly become impossible.

On top of that, the editor’s structure makes it difficult to write code. There isn’t much room for "metadata" on a passage; for the most part, that’s limited to a series of tags, which you have to edit using the "chip" style of tagging that web devs love for some inexplicable reason. But that means you have to put all the code in that little box, even if you’re using a tool that expects tags. In my case, that’s TinyQBN, a library for implementing what the creators of Sunless Sea call "storylets".

I could rant about the editor for another few posts, but I just don’t bother using it, so I won’t bother discussing it further. Yes, setting up a custom workflow is a bit more difficult. Yes, it’s worth it in the end. After doing the work, I can now write my story in Vim and my code in, er, Code. And it all comes out the same, except that I also have better handling of external JS libraries, static analysis tools that can run automatically, and so much more that I’m used to from my life as a developer.

People are stupid

Which brings me to my next point. The average Twine user is not a professional developer or a professional author. Worse yet, neither are the Twine power users. As far as I can tell, I’m just about the only one using Twine who does both. Believe me, it shows.

Most Twine tutorials are written for someone who has never so much as looked at code, and who barely even knows what fiction is, let alone how to write it. I don’t know why Twine’s community targets journalists as its intended audience, but that’s how it is.

For someone who knows both fields, it’s just frustrating. I’ve already read the intro material. I know what a macro is. But no one out there is creating any resources for the intermediate or advanced users. How should I structure a story in terms of source files? What are some common design patterns in interactive fiction, and how do I apply them in Twine? When should I break a scene across multiple passages, and what’s the best way to handle that?

I get that much of writing fiction is an art. I’m well aware that there’s no one-size-fits-all method for creating a novel. But to assume that everyone is forever going to be stuck at the beginner stage is doing the rest of us a disservice. I’m aware that zoomers, degenerates, and progressives (the main components of the intfiction.org "community") don’t know how to learn; people who look to Tumblr for knowledge and wisdom have shown pretty definitively that they have neither. Surely somebody out there cares about the rest of us, though.

If not, maybe I should work on that myself.

Wokeness taints everything

Allegedly, the interactive fiction community is thriving, and Twine is a big part of that. In reality, there’s not much of a community. Much like any other hobby (people don’t generally make a living off adventure stories, unless they work for Failbetter), the anti-human rot of progressivism infects every large gathering that would have the chance to become a community. Those of us who prefer free expression to censorship are, as usual, labeled extremists for the radical view that words are just words. Strange for a hobby built around words, but that’s the whole point of the woke ideology: to tear apart any gathering of like-minded individuals by setting them against one another.

So there’s an interactive fiction forum, but it’s so heavily censored that you get banned just for saying something that someone might think is "bad" in some ill-defined way. There’s a group on Reddit, but that’s…well, Reddit. It’s the Mos Eisley of the internet. Your other major option is Discord, which might be even worse!

Interactive fiction started in the days before the web. It became popular because of technologies like Usenet, where you were expected to be civil, yes, but you weren’t coddled. To have its gathering places be nothing more than wastelands of diversity, mere online versions of Portland and Detroit, is just sad.

(This isn’t specific to Twine, mind you. The Inform community goes even farther. They not only stand against freedom of speech, but also anonymity.)

Tech is tech

Beneath it all, Twine is nothing more than a very weird SPA framework. Sure, you have to compile the source, but the end result is an HTML page and a bunch of assets. It’s like Svelte in a way, except that (as far as I’m aware) the Twine authors don’t openly support child trafficking and religious persecution. As a developer, I think looking at it as a web framework has helped me better understand how to use it as an authoring tool.

This is where my earlier point about getting rid of the Twine IDE as soon as possible comes back into play. Once you abandon that crutch, you realize just how much freedom you have, with all that entails. For my current story, I’ve added the Pure CSS library to help with some layout issues. On my initial draft of The Anitra Incident, I’d used Moment.js for timekeeping; now, somebody finally made a decent native date system macro that does most of what you’d need in a story.

The output is HTML, meaning that you get to use CSS for styling, Javascript for scripting, and all that good stuff. People have managed to integrate Phaser, a 2D sprite-based game engine, into Twine stories, and I’ve been looking at how they did that. I wouldn’t be surprised if somebody even tried combining Twine with React and a full-stack framework. (Come to think of it, that’s not a bad idea. Okay, maybe not React, but Vue and Nuxt…)

One true format

Twine comes prepackaged with a number of "story formats", which are combinations of style templates and authoring DSLs. I briefly went over them in the previous post on this topic. In short, Chapbook is new, and mostly unused. Snowman is not much more than raw Javascript with a parser.

The other two are the most popular: Harlowe and Sugarcube. Harlowe is the default format in the Twine IDE, so it’s the one most newcomers learn first, but I think that’s a horrible decision. If you want to do anything even remotely complex, you’ll quickly run into the limitations of Harlowe. Far worse, however, is the fact that those limitations are by design. The authors, much like Apple, go out of their way to break any attempt at getting outside their sandbox.

In other words, there’s really no reason not to go straight to Sugarcube and stay there. It works. It’s not difficult to pick up. Most of the libraries out there are for it. (A few are format-agnostic, I’ll admit.) And you won’t be supporting the intentional hobbling of technology.

Conclusion

To sum up, then, what I’ve learned about Twine from using it is that it’s a great tool for what it does. It has some extraneous bits, and these are unfortunately the same bits that newcomers are pushed towards. If you’re willing to take the time to set up your own dev environment, use Sugarcube and a compiler like Tweego, and live with the fact that you’ll get no help from the community beyond "here’s how to make text red" and "here’s how to let your players make up their own words to use as pronouns", you won’t have any problems.

Writing a novel is a lot of work. Writing a program is a lot of work. Trying to do both, which is all interactive fiction really is, can be a monumental undertaking. But it’s fun, too. That’s what I’ve discovered in the past few months.

Dumbing down tech

I recognize that I’m smarter than most people. I’ve known that as long as I can remember. When I was six years old, I took a standardized IQ test. You know, the kind whose results are actually usable. I apparently scored a minimum of 175; it wasn’t until a few years later, when I was studying statistics, that I understood both what that meant in relation to society at large and why it had to be a minimum. (IQ is a relative measurement, not an absolute one. Once you get to a certain point, small sample sizes make a precise evaluation impossible.)

There is, of course, a big difference between intelligence and wisdom, though I like to think I also have a good stock of the latter. In some fields, however, the intelligence factor is the defining one, and tech is one of those fields. Why? Because intelligence isn’t just being able to recite facts and formulas. It’s about reasoning. Logic, deduction, critical thinking, and all those other analytical skills that have been absent from most children’s curricula for decades. While some people literally do have brains that are better wired for that sort of thinking—I know, because I’m one of them—anyone can learn. Logic is a teachable skill. Deductive reasoning isn’t intuition.

Modern society, in a most unfortunate turn of events, has deemed analytical thinking to be a hindrance rather than an aid. While public schooling has always been about indoctrination first, and education a very distant second, recent years have only made the problem both more visible and more pronounced. I’ll get back to this point in a moment, but it bears some consideration: as a 40-year-old man, I grew up in a society that was indifferent to high intelligence, but I now find myself living in one that is actively hostile to it.

I’ve always enjoyed reading tech books. Even in the age of Medium tutorials, online docs, and video walkthroughs, I still find it easiest to learn a new technology from a book-length discussion of it. And these books used to be wonderful. Knuth’s The Art of Computer Programming has parts that are now approaching 60 years old, yet it’s still relevant today. The O’Reilly programming language books were often better than a language’s official documentation.

It’s been awhile since I really needed to read a book for a new technology. I’ve spent the past few years working with a single stack that doesn’t have a lot of "book presence" anyway, and the solo projects I’ve started have tended to use things I already knew. Now that I’m unemployed and back to the eternal job hunt, though, I wanted to look for something new, and I was tired of looking at online resources that are, by and large, poorly written, poorly edited, and almost completely useless beyond the beginner level. So I turned to books, hoping for something better.

I didn’t find it.

One book I tried was Real World OCaml. For a few years, I’ve been telling myself that I should learn a functional language. I hate functional programming in general, because I find it useless for real-world problems—the lone exception is Pandoc, which I use to create my novels, because text transformation is one of the few actual uses for FP. But it’s become all the rage, so I looked at what I felt to be the least objectionable of the lot.

The language itself isn’t bad. It has some questionable decisions, but it’s far more palatable than Haskell or Clojure. That comes from embracing imperative programming as valid, meaning that an OCaml program can actually accomplish things without getting lost in mathematical jargon or a sea of parentheses.

But the book…well, it wasn’t bad. It just didn’t live up to its title. There wasn’t much of the real world in it, just the same examples I’d get from a quick Brave search. The whirlwind tour of the language was probably the best part, because it was informative. Tech books work best when they inform.

Okay, maybe that’s a one-off. Maybe I ran into a bad example. So I tried again. I’m working on Pixeme again, the occasional side project I’ve rewritten half a dozen times now, and I decided that this iteration would use the stack I originally intended before I got, er, distracted. As it turns out, the authors of the intriguing Htmx library have also written a book about it, called Hypermedia Systems.

This was where I started getting worried. The book is less about helping you learn their library and more about advancing their agenda. Yes, that agenda has its good parts, and I agree with the core of it, that a full-stack app can offer a better experience for both developers and users than a bloated, Javascript-heavy SPA. The rest of it is mostly unhelpful.

As someone who has been ridiculed for pronouncing "GIF" correctly (like the peanut butter, as the format’s author said) and fighting to keep "hacker" from referring to blackhats, I have to laugh when the authors try to claim that a RESTful API isn’t really REST, and use an appeal to authority to state that the term can only apply to a server returning HTML or some reasonable facsimile.

Advocacy aside, the book was unhelpful in other ways. I can accept that you feel your technology is mostly for the front end, so you don’t want to bog down your book with the perils and pitfalls of a back-end server. But when you’re diving into a method of development that requires a symbiotic relationship between the two, using the academic "beyond the scope" cop-out to wall off any discussion of how to actually structure a back end to benefit from your library is doing your readers—your users—a great disservice. If the scope of your book doesn’t include patterns for taking advantage of a "hypermedia" API, then what does it include? A few new HTML attributes and your whining that people are ignoring a rant from three decades ago?

Alright, I thought after this, I’ll give it one more shot. Never let it be said that I’m not stubborn. The back end of this newest version of Pixeme is going to use Django. Mostly, that’s because I’m tired of having to build out or link together all the different parts of a server-side framework that FastAPI doesn’t include. Things like logins, upload handling, etc. I still want to use Python, because that’s become the language I’m most productive in, but I want something with batteries included.

The official documentation for Django is an excellent reference, but it’s just that: a reference. There’s a tutorial, but this ends very quickly, and offers almost no insight on, say, best practices. That, for me, is the key strength of a tech book: it has the space and the "weight" to explain the whys as well as the hows. So I went looking for a recent book on the topic, and I ended up with Ultimate Django for Web App Development Using Python. A bit of a mouthful, but it’s so new that it even uses the "on X, formerly Twitter" phrasing that mainstream media has adopted to refer to Twitter. (Seriously, nobody in the real world calls it X, just like nobody refers to the Google corporate entity as Alphabet.)

In this case, the book is somewhat informative, and it functions a lot like an expanded version of the official Django tutorial. If you’re new to the framework, then it’s probably not a bad guide to getting started. From something with "ultimate" in the title, I just expected…more. Outside of the tutorial bits, there’s not much there. The book has a brief overview of setting up a Docker container, but Docker deserves to be wiped off the face of the earth, so that’s not much help. And the last chapter introduced Django Ninja, a sort of FastAPI clone that would be incredible if not for the fact that its developers support child trafficking and religious persecution.

Beyond that, the text of the book is littered with typos and grammatical errors. Most of these cases have the telltale look of an ESL author or editor, a fact which is depressingly common in tech references of all kinds nowadays. Some parts are almost unreadable, and I made sure to look over any code samples I wanted to use very carefully. It’s like dealing with ChatGPT, except here I know there was a real human involved at some point, someone who looked at the text and said, "Yeah, this is right." That’s even worse.

Three strikes, and I’m out. Maybe I’m just unlucky, or maybe these three books are representative of modern tech literature. If it’s the latter, that only reinforces my earlier point: today’s society rewards mediocrity and punishes intelligence, even in fields where intelligence is paramount.

Especially in programming, where there is no room for alternate interpretations, the culture of "good enough" is not only depressing but actively harmful. We laugh wryly at the AAA video game with a 200 GB install size and a 50 GB patch on release day, but past experiences show that it doesn’t have to be that way. We can have smart developers. As with any evolutionary endeavor, we have to select for them. Intelligence needs to be rewarded at all stages of life. Otherwise, we’ll be stuck where we are now: with ESL-level books that recapitulate tutorials, screeds disguised as reference texts, and a thousand dead or paywalled links that have nothing of value.

As a case in point, I was looking just yesterday for information about code generation from abstract syntax trees. This is a fundamental part of compiler design, something every programming language has to deal with at some point. Finding a good, helpful resource should be easy, right?

Searching the web netted me a few link farms and a half-finished tutorial using Lisp. Looking for books wasn’t much better, because the only decent reference is still the Dragon Book, published in 1986! Yes, the state of the art has certainly advanced in the past 38 years, but…good luck finding out how.

That’s what needs to change. It isn’t only access to information. It isn’t only that this information isn’t being written down. It’s a confluence of factors. All of it happening all at once is making us dumber as a people. Worst of all is that we accept it. Whether you consider it the "price of democracy" or simply decide that there’s nothing you can do about it, accepting this rot has only let it fester.

Interactive fiction revisited

I’ve always been one to do things just to say I did them. It’s why I became an author, why I ran for office last year, and why I still, despite having failed on multiple occasions, try to create electronic music. (Now I really want to get back into LMMS…)

I’ve also felt that teaching programming is an important goal. Not because I believe everyone should, or even can, become a developer, but because the critical thinking, reasoning, and logical skills necessary to write code are in short supply throughout society these days. If young people learned a little about programming, my thinking goes, that would better prepare them to look at every other part of the world in the same way.

These two desires of mine combine in a few very narrow ways. I’ve tried writing pedagogical programming languages, for example, and I’ve urged those I feel most receptive to try out Scratch, Grasshopper, and other teaching tools.

For the most part, that hasn’t worked. But lately I’ve been getting back into the idea of creating interactive fiction. For those who don’t know, this is a nebulous catch-all term for visual novels, old-school text adventures, and a few other types of games. (For those who disagree with me calling them "games", you’re wrong, because they’re games by any reasonable definition.)

Interactive fiction isn’t so much a genre as it is a medium, but all types have something in common: they use programming to turn simple prose into something a player can interact with. Some work by presenting the user a list of choices. Some, like the older text adventures, are played by typing commands. This isn’t so much a dichotomy as it is a spectrum; "choice-based" games can incorporate a parser. Thanks to the power of programming—every Turing-complete language is equally capable—there are no absolutes.

But there are differences. As I prepare to write, and in some cases rewrite, my first piece of interactive fiction, The Anitra Incident, I’ve studied the tools available, searching for the ones that fit me best, and the ones that work for the needs of the story. In that process, I’ve come to see four of them as standing above the rest, each for a different reason.

Inform 7

Inform 7 is the king of "parser-based" interactive fiction. It continues the tradition of old-fashioned text adventures like Zork, occasionally updating them to work better with modern computing. Programming is done through a natural-like language intended to vaguely resemble English prose. Games are compiled to an antiquated virtual machine and run through an interpreter that can be anything from a web browser to a native app to an executable on an old Amiga floppy disk.

Until last year, I wouldn’t even look at Inform 7 for development, for one very specific reason: it was closed-source. I don’t use closed-source tools for any other part of my development (Python, Vim, Clang, Git, open-source VS Code forks, and every other tool I use, they’re all freely available), so I was happy to finally have the chance to explore Inform when it was released under the Artistic License in 2022.

The good:

Being mature is a good thing in programming, and resisting the temptation to add faddish things just to keep up with trends is a noble goal. Inform has, as far as possible, perfected the parser style of interaction.
Inform serves as a de facto introduction to text adventures, so it has a large community, with lots of extensions and examples to draw from.
Tools like Vorple allow the intentionally limited language to access the rich multimedia features of modern web browsers, which opens up a whole new world of interaction.

The bad:

The Inform 7 programming language is just different enough from English that you can’t really write it as prose, and it’s peculiar enough in its function that you can’t take it as just another programming language.
While the primary documentation is vast, it’s also horrible. The developers’ guide, called Writing With Inform, is baroque to the extreme, and it’s written in a stuffy British style that gives me the impression of a Brontë character sneering at the rabble who would dare to write code.
The community seems to embody that same style, turning their noses up at the perceived limitations of non-parser adventure games.

Overall, Inform 7 isn’t bad. It excels in a very narrow niche: anything that resembles Zork, Colossal Cave Adventure, and old text adventures of that sort. If you want to write something that isn’t based around puzzles, rooms, and the guess-the-verb game of using a text parser, though, you’re going to fight the system every step of the way. And you’ll be doing it without much help.

Twine

Twine is, in many ways, the opposite of Inform 7. It’s been around a long time, but it embraces the open community that comes from having open source. Instead of being based around a parser, it uses the concept of passages, linking between them mostly through player interaction. (That makes it "choice-based", in the parlance of the interactive fiction community. Problem is, "choice-based" is used mostly as a slur, from what I’ve seen.)

For programming, Twine allows a variety of "story formats", which all work around a core set of capabilities. In the default installation, you have four options:

Chapbook, which I’ve never used
Harlowe, hobbled by design to the point of uselessness
Snowman, a too-thin veneer over Javascript
Sugarcube, an HTML-looking middle ground

I chose Sugarcube because of the way it comes closest to the sweet spot of being powerful and extensible while also providing a decent standard library.

There’s an editor for Twine, but you can also use the Tweego compiler and just write your games in a text editor or IDE, which is what I do. Output is an HTML file plus some ancillary Javascript and CSS, reminiscent of a single page app of the kind you’d make with React or Vue.

The good:

Twine is easy to get started with. The editor is friendly, and the output looks nice even by default.
Sugarcube is actually decent, as long as you treat it like any other templating language. Think of it like Jinja, for example. The built-in macros, for the most part, cover what you’re going to need, but making your own isn’t that hard.
The Twine community is almost as big as Inform’s, and there are a lot of tutorials for getting started.

The bad:

You’ll quickly outgrow the editor, but setting up a Tweego dev environment isn’t trivial.
Although the community is big, the differing story formats mean it’s also fractured. So you’ll often find someone asking exactly the question you were going to ask…but they’re using Harlowe, so the answers they get won’t help you.
As with Inform, the documentation assumes you’re a programming newbie, and there’s little out there for those of us who know how to write code (and prose, for that matter!) but want to know how to write this kind of code.

My overall opinion of Twine is positive. I think it’s the best gateway to interactive fiction for two reasons. One, it’s more accessible than Inform, in both development of the game and playing it. Two, Twine offers more room to grow, at least if you’re using Sugarcube or Snowman.

Ren’Py

Ren’Py describes itself as a "visual novel engine". Visual novels are probably the most popular type of interactive fiction nowadays, especially in the anime fandom. In fact, some big indie games in recent years, like Doki Doki Literature Club, are nothing more than visual novels. Of all the ways, to create this type of game, Ren’Py tends to get the most press, so I’ve taken multiple looks at it over the years.

Programming a Ren’Py novel is done using a Python-based DSL that directly exposes the tropes of the medium. So, for example, you can define characters, and then the game will show them when showing their dialogue. The final result will be a native executable that runs on the platform of your choice, and there’s a web export currently listed as beta.

The good:

Ren’Py is simple to get started with. The tutorial is actually a complete visual novel, and it has more content than some I’ve seen.
The engine is geared toward multimedia. You don’t have to worry about "What if the player’s using an old version of mobile Safari?" as with Twine, or Inform’s "What if they want to play on a C64?" You just use your art and assets like you would any "real" game.
Python is, in my opinion, one of the easiest programming languages out there, so extensibility is not that difficult.

The bad:

The documentation is horribly lacking. Outside of the basic tutorial, there’s almost nothing official to go on, apart from API docs.
Ren’Py is very much a visual novel engine, and it shows. If you want to write anything else, you’re going to struggle.
The English-speaking community isn’t as big as that of Twine and Inform; many, if not most, developers are Japanese, meaning that language barriers are always going to be in the way.

I can’t really recommend Ren’Py for general use, but if you want to make a visual novel, it’s unparalleled. Well, I assume it is. As bad as the documentation is, it’s sometimes hard to tell.

Ink

Ink is the fourth and final option I’ve considered. Calling itself a "narrative scripting language", Ink’s niche is in the Choose Your Own Adventure and "branching narrative" space. In that sense, it can be seen as a very simplified Twine. But it’s also designed to be embedded. Unlike the others on this list, where you’re expected to make a game in them by extended their capabilities, Ink expects you to extend it by putting it in the game you’re making.

That’s a big difference, and it’s why Ink is so hard to classify. On one hand, it can be seen as little more than a dialogue library for games. On the other, it has enough power to create interactive fiction by itself. The Ink compiler offers a web export option, and that qualifies as a game in its own right. The JSON export option, however, is probably the one most games that aren’t intended to be interactive fiction will use.

The good:

Ink’s syntax is very clean and sparse, so the "I know I can’t code" people have little to worry about.
The embedding option is the killer feature for non-solo work, because Ink is by far the easiest to integrate with any other game development engine/library/whatever.
Also unlike the other options on my list, Ink has corporate backing while still being open source. That means there’s always going to be some quality control, if only because the game studios using it will expect it…and pay for it.

The bad:

Ink is only really good for branching narration and dialogue. That severely limits its niche when using it alone.
The engine integrations are pushed really hard, but Unity is the officially-blessed one. If you’ve followed Unity news lately, you know that’s a disaster waiting to happen.
Outside of Ink’s developers, there’s not much of a community.

Of the four options on this list, Ink is the best if you’re working directly with anything else. Want to make a Godot game with some CYOA-style interaction? This is the top choice. But anything more complex isn’t going to be done with Ink alone, and learning an entire game engine, with all that entails, is probably too much for a single dev working on a passion project.

Conclusion

Those are my thoughts on four of the most popular interactive fiction development systems. I have other thoughts on the medium as a whole, but I’ll save them for later.

Crux Eternal

I’ve finally done it. I’ve made a game.

Okay, okay. It’s just a demo for now, but it’s complete in that regard. It’s called Crux Eternal (the name is an inside joke, I’ll admit) and it’s a simple puzzle game based on the “Kakuro” or “Cross Sums” puzzles I’ve worked since I was a kid. They’re a bit like Sudoku mixed with a crossword, and they can be surprisingly difficult.

This demo version includes 15 puzzle configurations, all in the smallest size that made sense to me. There’s a timer, and the game does track your best times for each configuration. Puzzles are randomly generated to fit the pattern, so there’s some replayability, as well.

I’d certainly love to flesh out Crux Eternal into a full-fledged game. This was the first time I’d brought a Godot project (or any gamedev project, for that matter) from inception to completion, and I’d like to keep it going. I also have a few other game ideas rattling around in my head, though, so maybe I’ll work on them instead.

Anyway, you can play Crux Eternal online in your browser, or you can download local versions for Linux and Windows. The source is available over on my Gitlab, and it’s MIT-licensed.

A month with Nim

A few weeks back, I posted about my adventures in writing a kernel using the Nim programming language. Well, I’m still working at it, and I thought it would be fun to give a progress report. Fair warning: this is going to be one of the most technical posts I’ve written in a long time. If you’re not familiar with a lot of programming and OS terminology, you’re going to have a hard time following along.

The language

Let’s start by looking at my language of choice. Nim is an odd duck in the world of programming languages. In purpose, it sits in that mid tier between low-level languages such as C and “application” languages like Python. This middle space used to be the sole domain of C++, but recent years have seen a growing crop of contenders: Rust, Go, D, Vala, Swift, Zig, and so on.

Nim is definitely one of those. Syntactically, it shares a lot in common with Python, most notably its indentation-based structure. But it’s much closer to the metal. Since it compiles to (a very cryptic subset of) C rather than some kind of VM bytecode, you get a lot of optimizations for free, thanks to the GCC and Clang teams. Thus, you’ve got this great mix of high-level sugar and low-level power, which is really what I was looking for all along. And the Nim community, unlike Rust, does it without sacrificing basic scientific facts such as sexual dimorphism!

Still, being a good programming language—even a lower-level one—doesn’t make something good for writing an operating system. That’s the downside of D, for example; there, the language itself is solid, but its standard library relies on garbage collection, making it a no-go.

I bring up that specific example for a very good reason: Nim’s standard library just works. It’s almost all “pure” code, where the devs eat their own dogfood. The system module is hard-coded to use what amounts to a set of compiler intrinsics, but everything else is built off them. In an OS kernel, where you can’t expect to have a bulky runtime available, this is a dream come true. I only had to implement a dozen simple C functions (strlen, memcpy, etc.), hook in an allocator (liballoc is a good default for “hobby” OSes), and that was it. I don’t even have all the hardware initialized yet, but I already have access to dynamic arrays, hash tables, string formatting, and all those other goodies.

Of course, nothing’s ever perfect. Nim gets very verbose when you’re working so close to bare metal. The developers’ insistence on defaulting literal values to signed integers is a pain, because anyone who has ever worked at the assembly level knows that you have to use unsigned numbers for things like bitfields. Also, converting between integers and pointers (another thing absolutely necessary in OS programming, and absolutely antithetical to the “safe code” movement) is overly verbose. Yeah, I could use a template or macro or something, but…ugh.

The system

I’m going to continue with this project until I get bored or run out of ideas. Since building the bare-bones kernel in the previous post, I’ve expanded its scope. Now, I’m planning out a microkernel OS centered around a message passing interface. The catch is that it’s intended to be a single-user system; there will be “profiles” for multiple users to store their own programs, files, and so on, but only one user will be running it at a time. Other users’ data will be hidden away, though I do envision a kind of shared space.

Another design concept I’ve been toying with is doing away with processes. They’ll just be threads that don’t have a parent instead. So running a program will start a “main” thread, and that thread can then create children or siblings. Child threads inherit some state, and the parent has some direct control of their lifecycle. Siblings, on the other hand, are independent. This also affects IPC: parents and their children can use shared memory far more easily, and the design will reflect this.

The microkernel structure means that very little will run in kernel-space. The physical and virtual memory allocators are already in place, though I may redesign them as time goes on. Some hardware abstraction exists; I’ll need lots more before I can even consider a 0.1 release. I’m currently working out how I want to write the scheduler and mapping out system calls. Almost everything else will live in user-space. There’s no reason not to.

I’m calling this project Concerto. As with most of my works, that’s a name with multiple meanings. A concerto is, of course, a kind of musical composition where many instruments support a single lead—this is, to my eyes, essentially the musical equivalent of a microkernel. It also connotes many working together (i.e., in concert) to create something grand. And I can’t deny a bit of a political jab: concertos are a distinctly Western form of music that came from the era of Enlightenment. As our enemies insist on dragging us into a new Dark Age and the destruction of our heritage, every reminder of what we have built is welcome.

So that’s what I’ve been doing in the free time that is no longer as copious as it used to be. I’ll let you know how it turns out.

A barebones kernel in Nim

I’ve been fascinated by operating systems for a very long time. For someone who genuinely loves low-level programming, they’re the lowest you can get in our modern age, barring a few microcontroller applications. So I’ve spent the occasional weeks over the past 20 or so years looking into the field, wondering if there’s a way to make my mark on it. At the same time, I’ve been looking at ways to write those low-level programs.

Combining those two threads of research has led me to create Nim Limine Barebones.

What is it?

It’s pretty simple. This is a port of the Limine Bare Bones tutorial kernel to the Nim programming language. It doesn’t do much; it’s literally the “Hello World” of OS development. But it can be used as the start of something much greater.

Why Nim?

I’ve looked at a lot of different languages that purport to be suitable for low-level “systems” programming. I settled on Nim because I wanted to learn something new, but also because every other option has a flaw.

C is the gold standard for OS work, but it’s really a horrible language. Especially when you don’t have the luxury of an operating system to protect you from, say, filling every byte of memory with garbage.
C++ is one of my favorite languages anyway, but using it on bare metal is harder than you might think. A freestanding implementation has to throw out most of the standard library (i.e., the bits that make C++ worth using), so you’re mostly left with C plus classes.
Rust might be a decent language, but its syntax is as ugly as the politics of its developers. I’d never use it for an unpaid project.
Go, from all I’ve read, requires a hefty runtime to get started, and Google has no inclination to change that. It’s also a language I find annoying for some irrational reason.
D is pretty much the opposite of Rust in both politics and syntax. It would be a great choice if not for a bit of runtime you just can’t get rid of. Oh, and the fact that nobody can seem to agree on what, exactly, the language should be.
Zig looks okay, and I found it extremely interesting when I delved into it a few months back. Alas, it’s just too immature for production use, and the latest revisions of the compiler have completely removed some necessary options for bare-metal development.

Nim isn’t perfect by any means, but what I’ve seen so far makes it look like a good “better C” that doesn’t require too many hoops to get the runtime out of the way. For application development, it wouldn’t beat out C++ for me—things like multiple inheritance are just too useful—but at the OS level? Sure beats trying to write my own std::vector. (Seriously. Where are the minimal STL implementations to go along with mlibc?)

Why Limine?

Most OS tutorials are centered on Multiboot. After all, it is kind of a standard. Here, though, I went with Limine. It’s a little more obscure, and much newer; the project is only a few months old here at the start of 2023, as it is intended to replace the older Stivale bootloader.

Limine has a lot of advantages, in my opinion. It’s entirely 64-bit. It sets up a call stack for you, which mostly cuts out the need for assembly in the boot phase. Framebuffers are sensible, there’s an integrated terminal that can work until your own is ready, and it’s just nice in general.

That said, it does have its annoyances. It requires a “higher half” kernel, and that makes paging a necessity sooner than it should be. But the page tables Limine gives you are intentionally sparse. And for this project in particular, dealing with an array of function pointers is just awful. Surely there’s a better way.

Conclusion

All told, I’m happy with what I wrote. It’s a good start, and it fills a niche that nobody else was really looking at. Yes, there’s another barebones Nim kernel out there, and I took inspiration from it. I like to think I’ve provided a better starting point for myself and anyone who would like to follow in my footsteps.

Wrapping up

(I have a ton of gifts to wrap, so this is what I’m going to do instead.)

We’re almost to the end of another year, and this one has been a ride. Lots of ups and downs, in both the literal and figurative senses, which seems appropriate. After all, I went into 2022 thinking it was the last full year I’d live, so why not go out with a bang?

Twelve months later…I’m not sure of anything anymore. In some ways, the few good things that have happened in my life have made it worse. Stasis is death, and I was dying. Now I’m living, but it’s hard to start that when you’ve waited until you’re almost 40. Part of me wants to get things done. Another part wants me to turn my back on all of it. I want to give of myself, yet I also want time for myself. It’s a battle most people deal with years, if not decades, before where I am now, but age doesn’t always bring wisdom.

Still, I set goals for myself, and I think it’s a good time to look at how I’ve fared with them. Then, I’m going to set a few more for 2023.

The Great Works

I put forth my four Great Works at the beginning of the year, and I would say that I accomplished most of them.

First, Alana, the site I’m building for my “real” job, is coming along. It’s hit a few roadblocks here and there, and my dev team (such as it is) is perpetually understaffed for the tasks we’ve been given. Despite that, it’s a real site, and it has real users. If there’s any one problem I can see, it’s that the roadmap has far too many items on it, and there’s very little rhyme or reason to them. The perils of having a boss with ADHD.

Second, I spent a lot of time early in the year working on Technetism. In the past few months, I’ve backed off a little bit. That’s because I feel that the philosophy is sketched out now, and it just needs some literature and a few adherents. We’ll get to it, but I can truly say that I have created a school of thought that reflects my view of the world. The rest is just filling in the gaps.

Third, I ran for office. Okay, I didn’t have much of a campaign, and my opponent even claimed I had dropped out of the race the week before the election, but my name was on the ballot. People talked to me, talked about me. My name was on the tickers at the bottom of all three local networks. Best of all, my mere presence forced my opponent to campaign, something she hasn’t had to do in a decade. I came away with 28% of the vote just by offering a choice. If I can do it, there’s hope for everyone.

Last of all, I have to admit that I mostly gave up on Iconic. It has notes and a rough outline of where I want to go, but I just couldn’t put in the effort. I still believe that visual communication is a noble goal, that METI should be pursued, and that there is someone out there waiting for our call. If I have time in 2023, I may even pick up the project again. For now, this has to stand as the one true failure of the Great Works, but it was always the long shot.

Next up

Of the few goals I have in mind for next year, only a couple are really relevant to PPC.

Foremost among these is The Prison of Ignorance. I need to go back and edit the book, adding what I’ve learned about technetism through its development. I’ll also have to slap on a preface, an afterword, and all that. Other than those trivial minutiae, my first nonfiction philosophical tract isn’t too far away from completion. So let’s get it done.

Getting into philosophy and politics has also rekindled my interest in history and the things that make our Western civilization the greatest that has ever existed. To that end, I plan to read at least 12 of the so-called Great Books. This is a list of over 300 of the most influential works humanity has ever produced, and I regret to say that I’ve only truly read a small fraction of those. I plan to fix that.

I haven’t done much writing at all this year, so I also want to rectify that situation in 2023. I’d like to get On the Stellar Sea finished in draft form, as well as Pitch Shift. (That will be the first book I’ve ever written where I’ve actually visited the setting! Can you believe that?) Releasing Homeward From Afar is on my to-do list, as well as putting as many of my books as possible on a store besides Amazon.

On the development front, I’ve recently had an itch that I can only scratch by going back to Pixeme. This was a project I started a few years ago, and even built out quite a bit, but never released. The gist is that it’s a site to help people learn languages by using pictures. I’ve refined the concept, my job has given me more experience working on bigger apps, and now I want to see if I can build something.

And that’s pretty much it. Sure, those aren’t the life-changing goals I’d attempted this year, but my life has changed enough as it is. For the time being, I’d like some stability. Evolution, not revolution. Above all, that’s what I ask of 2023.

Not for everyone

I’ve written a few times about what I call the “democratization” of development. Specifically, I’ve explored how giving ordinary people access to development tools (game engines, programming libraries, and so on) that used to be restricted only to large corporations benefits all of us.

Because it does. The indie gaming scene is the only place real innovation in games still takes place. Open-source software runs the world, even if you never see it. These wouldn’t be possible if we lived in the bad old days of the 90s and early 2000s, when a decent compiler and IDE cost as much as a new computer, when even the “family-friendly” console manufacturer’s answer to “how do I start making games?” told you to go to college.

We’re better than that now. And even though some of the biggest causes (Github, Minecraft, Firefox) have fallen to —rather, joined—the dark forces of wokeness, the legacy they built while they were still on the side of good remains. For all intents and purposes, programming is open to everyone.

The next question one might as is a natural follow-on to that statement. Programming is open to all, but should it be? Or is there something to be said for gatekeeping? After all, we’ve seen what democratization and inclusivity have done to RPGs. We’ve seen the massive drop in average literary quality that came with the opening of the Kindle Store.

Of course, I could never agree with that. If not for the world of open source, I wouldn’t be where I am today. If I’d had to save up to buy every single development tool I ever used, well, I wouldn’t have used very many of them. Billions of people around the world can understand where I’m coming from. Many of them live in worse poverty than I ever have, but they all have the same opportunity to learn this craft; one of my coworkers lives in Nigeria, and what person who grew up in the 80s and 90s would ever expect that?

From the financial standpoint, then, democratization is undeniably a good thing. From the social perspective, it’s the same. Yes, we have trouble. Straight white men are being pushed out of tech circles everywhere you look. Those who stay are muffled into impotence by “code of conduct” censorship regimes. But programming doesn’t require a community. It creates them. And those of us who truly create through code have the power to determine who we want inhabiting our communities.

Despite the numerous problems allowing the whole world into development has caused, then, I still wouldn’t want to go back. We’d just be giving up too much.

Another question I would expect one to ask is who should learn to code. It’s a valid question, as the very phrase “learn to code” has become kind of a buzzword—merely saying it became a bannable offense on Twitter, so you know it has some positive effect. Philosophically, it cuts to the heart of democracy in a way few people understand. After all, if everyone has an opportunity, does everyone also have the responsibility?

One reason this question came to mind was because of a disagreement I had with my boss a couple of weeks ago. He insists that development is little more than physical labor, on par with, say, a factory or assembly line job. As a developer myself, I feel what I do is more of a craft, a skilled trade that is mostly mental. I don’t just write code; I solve problems. This difference of opinion is, in a sense, a different way of looking at the fundamental question, because an unskilled job is something anyone can learn how to do.

I do believe that everybody should learn about programming. Computers are such a fundamental part of modern life that we are doing ourselves a disservice if we don’t understand at least how they do what they do. For the same reason, I think everyone needs a basic understanding of how a lot of other things work: internal combustion engines, power plants (of all kinds), radios, electronic circuits, indoor plumbing, and so on. Rather than teaching our children about make-believe genders, wouldn’t this be a better use of compulsory education?

That said, while we all need some knowledge, I recognize that not everyone has the ability to use that knowledge as a professional developer would. This is the crux of my disagreement. My boss thinks “developer” is a title, something you can train for and take on, the same as a sales manager.

I, on the other hand, see from personal experience that not everyone has that mindset. I’ve tried to teach programming to a few people, and it doesn’t stick. They’ve all said the same thing when I asked why: “My brain just doesn’t work that way.” And that’s really what it is. Some people are just wired differently. We have a different way of looking at the world.

You can’t chalk it up to intelligence. My brother is very smart, but he completely zones out the minute one of his favorite Youtube personalities starts talking code. Yet I’ve seen people who would struggle to reach the average in an IQ test write some masterful programs.

You can’t say it’s a mental disorder. I have only two of those: anxiety and depression. Neither are universal among programmers, though we collectively cover a huge swath of disorderly mentality. Many of the top developers truly are on the autism spectrum. One of the best who ever lived, Terry Davis, was a paranoid schizophrenic. But there are plenty who are, by all accounts, perfectly normal. I consider myself an average programmer, and I’d say I’m also near the mean in terms of mental health.

You can’t claim it’s because of demographics. Yes, I’m an American man, and most of the programmers you might know by name are the same. That’s only fair, as the US effectively invented the field, and it became male-dominated early on. (Not always, however. The inventor of COBOL was a woman, as was the first programmer who ever lived.) Yet there are great developers all over the world, and they come in all shapes and sizes. Russia’s hackers are famous…or infamous. Japan has given us some of the most talented and most devoted devs you’ll ever meet. And many great tools are being made in the Republic of China, even as the hardware they’re running on comes from the Communist usurpers on the mainland.

No, there’s something in the way certain people think that makes them good or bad at programming. And that’s fine. There’s nothing wrong with having our differences. I know I’m hopeless at, say, drawing. I’m too squeamish to ever be a doctor or a hunter. I recognize this, and I recognize that some people might just have a problem ever learning how to code. I still believe they should understand the fundamentals, if only because that would give them a better view of the world they live in. But I can respect their wishes to never go beyond that introduction.

In the end, it’s good that development has become democratized. Whether or not everyone uses the gifts we have been given, it’s better for all of us that they are there. When programming was reserved for the elite, only those who had that status could participate. But the programmer’s mindset is not limited to the rich, the college-educated, or the Westerner. It can show up anywhere, in anyone. Much like a fantasy gift of magical talent or the Force in Star Wars, our power does not come from our upbringing. It’s a part of who we are, so it’s good that we all have the chance to discover, train, and harness it.