It will take me to read this book, but I love it! I'll be following along in https://github.com/mthom/scryer-prolog (written in Rust) so one should be able to take these techniques into Rust game programming.

It's one of the more interesting games I have ever played.

https://store.steampowered.com/app/881100/Noita/

https://www.youtube.com/watch?v=prXuyMCgbTc

Also, probably, MUDs.

What graphical games are trying do to at something 'revolutionary' text games did that before 40 years ago with interactive fiction (more in the 90's with the reinassance of astounding amatur games such as Curses/Jigsaw/Anchorhead/Devours/Spider and Werb than the former Infocom games); roguelikes like Nethack/Slashem and CDDA:Bright Nights and online MUDs far beyond the usual fantasy settings, such as cyberpunk or scifi settings with weird materials and interactions.

The best game creators such as Warren Spector surely played with libre games/indie/geeky games too to bring new ideas to the gameplay.

I think referencing Nethack in the original Deus Ex wasn't just a happy easter egg, but a homage to the emergent gameplay probably inspired by it.

The best about Deus Ex weren't neither the graphics or lore, but what you could do in-game, breaking the linear settings on FPS' and making them accesible unlike System Shock 1 and 2, where they tried and failed because the game difficulty didn't scaled well and the gameplay wasn't as polished. Ditto with Arx Fatalix (now Libertatis) and Ultima Underworld.

The resolution algorithm(s) implemented by a general purpose logic programming or relational language are not the only ones possible, and being more general may not be efficient for the type of problem you want the game engine to solve efficiently. Conversely extending a logic programming language to natively include these features may invalidate simplifying assumptions or require a change in evaluation order that makes the language impossible to implement as simply or efficiently.

A concrete example (of extending logic programming with game specific features):

I wanted to both use logic programming relations and also linear constraints, so that you could say something like "A <= (B-10.0) .OR. B <= (A-10.0)" which you could picture as constraining the position of the centers of two width=10.0 game objects so that their boundaries do not overlap, but you don't care which is in front of the other. (Statements like this would be used to build up a scene or more complex game object qualitatively, without pinning down exact coordinates rather letting the linear constraint solver pick them.)

Since running the linear constraint solver to resolve something like "f(A) <= g(B)" actually (potentially) updates all of the interrelated variables (A or B might also have constraints against C,D,E,F), running it as soon as you pick the LHS or RHS of the logic expression "prop(X) .OR. prop(Y)" could potentially invalidate propositions elsewhere previously committed to. So what you probably want to do is, rather than interpreting the "<=" on linear variables as a test with a boolean result, interpret it as a command to add "f(A) <= g(B)" to the global store of linear constraints, and then at some later time run the solver on the complete matrix of linear variables.

That leads to design questions like how does the language know when it's done adding constraints and time to solve, what if we really do need a logic clause to depend on testing a value not constraining it, etc. But all of that's just a distraction from the real issue, which is that for the case of BOTH the linear constraint solving and the logic programming, in the context of a game engine we really need to have more control over both when lengthy computation is run and how long it runs.

That is, even if we design a good way for the extension features to run from the POV of the logic language, from the POV of the outer system we still have the problem of sometimes the search time to resolve part of a logic program blows up and it's difficult for the programmer to always predict when/where that will happen. In this sense it's not even required that hand-rolled imperative code be faster, it can be slower - as long as it's predictable.

And in reality you wouldn't even necessarily be hand-rolling it; what I'm talking about is whether the rules engine is a solver that is externally driven (and pre-emptible) by imperative game code, or the whole game runs within the "solver" (i.e. relational language). As tempting as it is to imagine what could be done if literally "the whole" game were relational, the fact is using that technology for a whole game implies a magic relation solver that doesn't actually exist.

But with Inform6, the OOP applied to game design and literal ingame objects' relation (as the ZMachine) states it's when the difficulty plummets down to the point to be trivial.

http://logicmazes.com/alice.html

  alice.html:353 Uncaught TypeError: Cannot read properties of undefined (reading 'play')
      at playSound (alice.html:353:30)
      at finalize2 (alice.html:347:1)
      at <anonymous>:1:1

https://www.clipsrules.net/

At first guess, I would imagine this could look like writing down known constraints on the solution as a kind of "type declaration".

https://www.scryer.pl/lists

Markus Triska has probably the best resources on modern Prolog.

Just search for "Power of Prolog" on YouTube or the internets.

I think you get access to their engine if you buy one of their games through steam and you can mess with Osiris (not sure if that's still true for BG3, but it was the case for Divinity: Original Sin).

[1] https://docs.larian.game/Osiris_Overview

For good habits and a good introduction: https://www.metalevel.at/prolog

I like "Prolog Programming for Artificial Intelligence" as a great print book with interesting projects that is fairly modern but be warned that much of the code is not idiomatic, so please refer to the first resource if you are looking to write too quality stuff.

https://a.co/d/5NGr6KS

http://minikanren.org/ - MiniKanren, a different language in the same vein, small and embedded into lots of host languages.

https://microsoft.github.io/z3guide/docs/logic/intro/ - Z3, again a different language but hits many of the same areas and use cases along with plenty of others. Also usable as a library (probably how most people access it, often through Python).

That being said, it seems to get quite convoluted when trying to introduce dynamism (i.e. time) to the system. I was about to wonder if a hybrid of functional and logic programming could address this, and then I remembered Verse [0] exists ;-)

[0]: https://github.com/UnrealVerseGuru/VerseProgrammingLanguage

That said, there's plenty of research in the DB world on precompiled and JITted query execution plans. All of that would apply to a Prolog or Datalog engine as well.

Also, a personal interest of mine I keep wanting to come back to is how much one can make use of GPU and TPU hardware to accelerate the joins that go on in these systems. There are people working in this space already: https://arxiv.org/html/2311.02206v3 but I believe their emphasis is on large scale data sets (e.g. big data graphs) whereas I'm curious to see if there's a way that an approach using HW acceleration could make low latency "OLTP" type applications possible for applications like robotics/vehicle autonomy/games, using complex rule sets.

I watch my son play Dwarf Fortress and I'm like... it needs a Prolog.

[0] https://en.wikipedia.org/wiki/Mercury_(programming_language)

[1] https://en.wikipedia.org/wiki/Visual_Prolog

[2] https://en.wikipedia.org/wiki/MiniKanren