Blog Title

Spells from a file

2026-03-09T00:00:00Z

I was initially a little shocked that as of 2026, C++'s standard library doesn't provide a means to watch files for changes. But after thinking about it for a few seconds, it seems to require a third party library in a lot of other languages/environments too. Okay, so I guess that's something I needed to learn.

I plan to support all the important operating systems—Arch, Debian, Ubuntu, er, Linux Mint perhaps, and maybe some others—so I started learning the inotify API. It's actually very simple and I feel silly for not having used it before. Moreover the man pages are informative, even including some example code. OK, so there's no excuse left.

I need to think about some of the game-specific details, but Gealdor now has the means to watch filesystem changes. This will complement the socket server, but is also going to be much more useful in development (I suspect).

I get it, it's a bit dull, but sometimes progress is.

SDL_net is really nice

2026-02-23T00:00:00Z

When tinkering on a long-term project, I accumulate a lot of "demo" programs: small, simple applications that test out one thing in isolation—with the intention of merging into the main project if it feels successful.

I made one such demo using SDL_net recently. It's a very simple socket server that listens for connections and responds with a message. To be honest, I'm not used to networking when working with C/C++, and so was pleasantly surprised when it worked with ease.

It took maybe an hour and a half to get working. And it only took this long because I mistakenly followed an out-dated tutorial first, instead of going straight to the SDL_net documentation like a sensible person. Once I'd done The Right Thing, it was a breeze.

I used various tools and languages like netcat, curl, Racket and Python to check a few examples and convince myself it was working—and that I had numerous options for interaction in the future. I think this could work well.

Uses for Gealdor

Why is this useful for Gealdor? Well, players need to compose their spells and submit them to a ~~compiler~~ spell synthesis incantation, which checks each spell's validity and—for user convenience—should output plenty of useful notices about invalid syntax or misnamed spells, etc.

Spell writers are allowed to use computers too, though (things have moved on in the magic world). So the game will want a text editing interface.

Some people might resent the (relatively limited) text editing interface I'm capable of making. So there's some sense in at least allowing them to compose spells in a program of their choice. Allowing spells to be communicated like this also technically allows me to write the UI part in a different language, without having to bother with bindings.

For example, I could use (Dr Racket, a very extensible editor used in the Racket world, which—as you might expect—supports custom languages with relative ease). I could even use HTML and JS (probably not, though; I do enough of this already). Or I could use anything else. Another, more compelling reason to communicate input like this in general is supporting assistive technology: if the communication protocol is public, anybody can write their own interface where required.

Publishing a protocol sounds complicated, but the game already has a language for communicating spells. Building a protocol on top of this should be fairly easy.

The game language

2026-02-15T00:00:00Z

Gealdor, the magic game I'm working on, involves a simple language for manipulating characters within a plane. The grammar is quite simple: there are several types of statements which do things, and statements can also be grouped together in a spell. (The bores out there might call spells 0-ary functions, but I find "spell" much more captivating.)

Movement

With this language, you can move (or not) a character:

stay
stay twice
step east thrice
step south five times

Casting

In English, the word cast most commonly means to throw or sling something. But from that (I assume, anyway) came a number of metaphorical meanings: you can cast your eyes on (i.e. look at) something; cast metal (i.e. shape it while molten); etc. It apparently even meant to vomit at one point. More relevantly, I hope, you can also cast a spell, meaning to perform or undertake it. This ambiguity makes cast a nice keyword for a magical language, in my opinion.

Some or all characters will be able to cast things:

cast stone
cast fireball west
cast spell do_something_exciting

A stone is just an obstacle, in this game. The latter two should be self-explanatory.

Summoning

The word summon is a bit more straightforward: you call for things to appear, sometimes by magic.

The more magical characters in Gealdor can also summon things:

summon ghoul
summon demon heading north
summon familiar casting spell do_something_exciting

I haven't worked out all the details of what ghouls and demons will do. Possibly they will need to be summoned from somewhere. It depends on what allows for the best puzzles.

A familiar (the noun) tends to mean a kind of spirit or creature that accompanies or watches over someone (normally magical). In this game, a familiar has a slightly different, but more concrete definition: it is a magical clone of the current character, who casts a spell upon its creation. Since a spell can invoke further spells, this will allow for ~~recursion~~ joyful mess. Players will have to use such recursive magic to solve the tougher problems in Gealdor.

Spells

Spells are magic, but they often come written down. Therefore anybody can observe a spell, which is just a list of commands.

observe spell do_something_exciting
  summon ghoul
  step north
  cast fireball west
  cast spell do_something_else
obverse

I'm not sure about the observe keyword, and even less sure about obverse. I'm trying to be clever and I think it's failing. These could well change in future.

Natural language

I like that this syntax feels less rigidly computational and more like natural language than most programming languages. Probably it doesn't go far enough, and I would quite like to make it flow even more like a spoken language.

A naive tilemap renderer

2026-02-07T00:00:00Z

One of the biggest mistakes I've made so far is writing code. Lots of people have told me over the years that I should Just Use This Engine, for some definition of This. I've tried using some engines, and some of them were even very good (LÖVE and Godot spring to mind). But I don't often find that entertaining. And this project is not about me making a game for the players to enjoy. It's about me having fun tinkering. If the end result is playable, great. If it's fun, that would be remarkable.

The renderer

My tilemap renderer sucks. I forget the details, but I do recall that it does some smart things, and a lot of daft things.

For the sake of entertainment, here's one silly thing it did while I was working on it.

The woes of off-by-one errors. Uses Kenney's Tiny Dungeon sprites.

This particular issue is fixed now, but hopefully now you understand the level of quality we're dealing with.

This is okay, probably

The appearance of the game will definitely change in future:

the art is an asset pack from kenney.nl, which I dropped in for the sake of just getting something—anything—running;
I haven't yet decided between 2D or 2.5D, pixel art or not, etc.

Right now, fully functional gameplay is the priority, so I can experiment more with the puzzles. Appearance is important, but the game will only be fun if the puzzles and gameplay are solid.

Mistakes

I wrote the renderer using OpenGL. Two mistakes I made:

writing a renderer at all;
doing it naively, without accounting for pixel art being, well, pixelly.

I didn't need to write a renderer. I could have used an engine, a library, or just done the obvious thing, given that I'm using SDL3, of using SDL_Renderer, SDL_Texture et al. Probably the output would have looked better with the latter. But I felt that this custom renderer would give me more flexibility later on (questionable), and also, I just wanted to.

Embracing bugs

The worst remaining problem with this naive implementation is that it represents pixel locations using floats. This introduces inaccuracies in the location of rendered sprites, and so we get tears in the image (the thin lines appearing between tiles).

Tearing (and a few un-rotated tiles). Uses Kenney's Tiny Dungeon sprites.

I haven't fixed the tearing yet. Possibly the easiest fix would be to just render pixels to a texture and then perform scaling. Again, this could have been done easily with e.g. SDL_Renderer et al., but also again, I like making my life hard and gameplay is more important. So, let me apologise now for all the terrible screenshots you poor readers will be subjected to in future.

A grave error

2026-02-03T00:00:00Z

I've been informed that I'm using The Wrong Software to create my website. I'd like to take this opportunity to formally apologise to the internet and announce my retirement from blogging.

Gealdor, a game I'm making

2026-02-02T00:00:00Z

I'm making a ~~programming~~ magic game called Gealdor. The word is from Old English, cognate with the Germanic word galdr, and roughly means a spell or incantation.

Gealdor is/will be a 2D (or possibly 2.5D) puzzle game that involves writing spells to solve puzzles. The spells use a language grammar I've already determined. I need more puzzles, but I think the language is reasonably expressive and allows for some fun.

I'll waffle about this project a lot, so it has its own Gealdor tag.

Boring programming details

I'm writing the game in C++, using SDL3 for basics like window and input handling, and CMake manages the build and packaging.

The game has a Domain-Specific Language (DSL) implemented in C++ using PEGTL (I can't recommend PEGTL enough; it seems very solid and has lovely documentation). Developing the DSL is going remarkably smoothly, so far; perhaps actual gameplay will follow soon.

I wrote a janky renderer in OpenGL, too. This will probably change drastically if the game is ever published, but puzzles are the priority right now. I can get reasonably far with counters, paper and pen, but the puzzles can be quite complex, limiting what can be achieved before the gameplay works properly. Also, ultimately only the gameplay can make it fun—anything else is a (relative) waste of time.

Originally the game was a dual-language project with Racket as well, but I've since removed that part of the codebase. Maintaining a C API for language bindings was a pain, and also Racket has a couple of peculiarities that slowed the project down. I say this with love, though: I relish coding with Racket, and will keep trying to use it in my projects (it may even reappear in this one at a later date). I strongly recommend it if you want to learn a Lisp.

Welcome to a totally useful and not at all time-wasting blog by chronic procrastinator toasty

2026-01-31T00:00:00Z

Hello, I'm starting a blog. Hooray!

I've wanted to do so for a while, but every time I try I get distracted with pointless things like styling or the "tech".

I've also been very hesitant to put anything online, ever since the internet became an enclosed commons, weaponised against its inhabitants and drowning in the slop it was used to train.

But here we are. A simple Eleventy template is working well with some minor tweaks. If we can just keep readers to a minimum, maybe it won't get detected by the text extruders' crawlers either. Truly, the best of both worlds.

Why now, then?

What's the point? Well, ~~there is none~~ I'm working on a couple of projects and writing about them might help with motivation. Writing helps me form ideas and channel my regrets. There might even be some useful feedback. Or it might just stop me actually doing the thing. Let's find out I guess.