Logic programming in general and miniKanren specifically

[chooseusername]

I looked into this a long time ago.  For me, the primary attraction was being able to have code operate on other code, as if it was all data.  Which it would be.  My interest was having the world defined in terms of an ontology.  How bodies were composed, what invertebrates are, what a sword is made out of, suitability of materials for being forged into things like swords, and so on.

And there's an engine out there, which provides basically this form of information and the tools to reason on them: OpenCyc.  This has Python bindings, but all communication with the engine is through sockets.  And the memory usage is high.

Unfortunately, after all the time I spent looking into it, I came to realise that there were gaps in the ontology it provides.  And the ability to extend the free version was also limited.  You can read further on this here, in my old blog post.  It is entirely possible to extract the facts and rules out of OpenCyc, and to plug them into another rules engine, but I doubt it is worth it.

[tuturto]

Unfortunately, after all the time I spent looking into it, I came to realise that there were gaps in the ontology it provides.  And the ability to extend the free version was also limited.  You can read further on this here, in my old blog post.  It is entirely possible to extract the facts and rules out of OpenCyc, and to plug them into another rules engine, but I doubt it is worth it.

Whoa, that's like completely different scale what I had in my mind. I read your blog posting and had a read around the Cycorp site. The concept is really fascinating, but also really heavy weight. Most likely it doesn't make any sense to extract facts or rules from it and use them somewhere else. But it would be hilarious if the game actually understood what emptying a container means and how human bodies are constructed. One could come up with all kinds of creative uses for ruleset like that.

The thing I'm finding troublesome with miniKanren is that it is really small (hence mini, I suppose) and anything more complicated than basic relations you have to code by yourself. On the other hand this means that you aren't constrained by existing data structures. I probably will try to work my way through the book first and then think of throwing some code together for the game, if it still sounds like a good idea.

[mushroom patch]

I didn't realize premade, reasonably complete rule sets like this were available. I've often thought about using data mining techniques to try to cobble together something like this (but much narrower). Have you thought about using analogies to thicken up your rules? E.g. if you have objects or concepts in your game that aren't adequately addressed by what's in OpenCyc, maybe you can achieve satisfactory results by identifying those objects or concepts with some other set of objects and concepts that relate to each other in similar ways and "reason by analogy." (An idea I had a while back in this vein was to create randomized alchemy systems by data mining (culinary) recipes and applying randomized substitution rules to the ingredients and procedures described in them.) The point is, whatever's in this OpenCyc thing already, you can probably squeeze more out of it with some creative substitutions than by the most literal minded approach.

Anyway, I'm impressed by the ambition. Also, I like the blog.

[chooseusername]

No, the analogy approach isn't of interest to me.

Think about the procedurally driven gameplay you have already seen in roguelikes.  Where you can try and mount any object, or can bash something, and so forth.  Some gameplay is only discovered if you experiment and discover the potential of what available actions work on what and the advantages of such actions.  But really, this is a manually constructed set of rules.  And the problem with manual construction where most of this is defined by hand-written code, is that the human mind has to remember to hand apply the rules in all similar situations by putting in a code clause to make it so.

With a rules engine and an ontology, everything can be generalised and implied, rather than specific and explicit.  Procedurally driven gameplay becomes deeper and inherent based on the underlying rules, rather than haphazard, somewhat shallow and prone to absent-minded application manually.  Like for instance, Incursion is, as all other roguelikes are.

And that's only the most obvious benefit.  It's always seemed to me that you should be able to have a generic fantasy-oriented historical ontology worked on in an open source manner, and all historically-based games should be able to benefit.

[mushroom patch]

Yeah. If you had a way of building rule sets in such a way that it wasn't like you're coding something, you could probably find a lot of volunteers to work on something like that. Like, if people didn't have to deal with a text editor, revision control system, syntax involving a lot of parentheses, etc. Something like a web or telnet interface with some basic visualization stuff. In other words, the way to do it would be to develop tools to crowdsource it. If you wanted to get pretty fancy, you could probably also data mine wikipedia and similar sources, but that would be a more difficult undertaking.

These Bay 12 forum people might be interested in contributing to a project like what you're describing.

[mushroom patch]

To elaborate a bit, it should come as no surprise that the kinds of concerns about matters of general interest (e.g. human and/or animal anatomy) that arise in roguelikes and similar games (e.g. the mechanics of dissecting a corpse) are sufficiently far from what cycorp calls "commonsense reasoning" that general purpose knowledge bases are unlikely to get you much milage. Something domain specific is clearly in order.

On the other hand, the level of knowledge about anatomy needed to exceed what's doable in most roguelikes is available in the lyrics of "Dem Bones," so I kind of agree that an ontology like you're talking about would be nice to have.