Normally we downweight posts that just have a Part 1 and then stop, but this one actually delivers the goods:

https://thingspool.net/morsels/page-11.html (part 2)

https://thingspool.net/morsels/page-12.html (part 3)

https://thingspool.net/morsels/page-13.html (part 4)

https://thingspool.net/morsels/page-14.html (part 5)

(and keeps going!)

There's an interesting (to me at least) overlap between gamestate as a set of facts and relations(Prolog), and the point of ECS("This is a database"[1]).

I personally experiment in Datascript as a gamestate db, but it's still quite an early attempt to conclude if it's a success. It's great seeing how ideas in this tutorial map 1-to-1 to that idea.

1. https://www.gamedevs.org/uploads/data-driven-game-object-sys...

In the same vein, I had a lot of fun reading a game programming book with logic programming, but instead of Prolog it used CLIPS:

Adventures in Rule-Based Programming: A CLIPS Tutorial https://a.co/d/7wVOcZp

I'd never considered how the commonplace actor-world/entity-trait model is a neat fit for Prolog's whole relational deal. Though predictable and efficient run-time is also critical, and Prolog typically brute-forces its way through matching terms to satisfy the query. I haven't finished reading the series though - maybe they address it?

This is such a breath of fresh air on tackling the state machine issue in games with heavy logic (city simulation, for instance). I never thought about using Prolog for this.

Bravo!

I'll leave this here since it is useful: https://github.com/emacstheviking/gnuprolog-libsdl2

The centered monospace text is quite hard to read on mobile, but reader mode seems to work well. Back to reading it now...