Delineating between or combining term creation and term membership

I’m writing the logic for a role-playing game. What are the advantages and disadvantages of delineating between term creation and membership like so:

obj(sword1).            % there is a new object called "sword1"
isa(sword,sword1). % "sword1" shares any attributes of a generic "sword" class

and combining these steps by just using the second statement? Is the first statement even necessary? I suppose the first statement assigns membership to a generic “object” that may also have some shared properties. I could create a rule like:

obj(X) :- isa(X,sword).

But I would need a rule like this for every kind of object, so I’m back where I started, right?

Maybe it helps if you think about everything in terms of properties (even the property of existing)?

% property(sub, super)
property(sword, object).
property(sword1, sword).
property(sword1, exists).
property(object, inanimate).
property(inanimate, nonhuman).
property(sword, weapon).

property1(Sub, Super):- property(Sub, Super).
property1(Sub, Super):- property(Sub, Intermediate), property1(Intermediate, Super).

You could also look into the semantic graph extensions libraries – which allows you to define these things as well using a standard language and inference system.

@JCR , yes the property approach you described is helpful. It reminds me of the “component” part of ECS.. By attaching or tagging a property to an object, you signal to your larger game system that the object gains or loses some functionality or behavior without using hierarchical class inheritance. @grossdan , are you referring to the semantic web (RDF) graph extensions?

Yes.

Once you externalize objects and properties and seek to inherit them, then that’s a kind of system that does that for you.

It depends how much more you want from a system like this, if you own light-weight implementation sufficies or you want something more comprehensive.

Dan

@grossdan and @JCR . It does make sense to look at RDF, but I’m not able to use SWI-Prolog extensions like the semantic library. I’m using a simple C# implementation of Prolog. Still, I like the triple approach and might implement rules for basic graphs. Right now, I’m writing something like:

tag(isa,kindof,relation).
tag(kindof,kindof,relation).
tag(furniture,kindof,object).
tag(bed,kindof,furniture).
tag(bed1,isa,bed).

Going back to the ECS analogy I mentioned previously, is there any benefit to an “entity” that is just a unique ID: e1, e2, etc so I can write tag(e184,alias,deer1). Or, are tags/properties really enough? Later I can write tag(e184,alias,meat1). I can see some advantages to this approach because a unique object can have multiple aliases and be referenced by whatever alias makes sense in a given context. But, how could I then write tag(meat1,status,spoiled)` and have the tag associated with e184?

Agree! Probably this depends on your specific implementation; e.g. you might want to have a string associated with an object tag(e184, alias, "The golden magic sword")

You could do

tag(e184,alias,meat1).
tag(meat1,status,spoiled).
tag(Id, status, Status):- tag(Id, alias, Object), tag(Object, status, Status).

But then you might want to have a variable that keeps track of time (status presumably changes depending on time).

Thanks @JCR & @j4n_bur53 . The component approach makes a lot of sense. In my application characters also need to be able to identify objects that they see and use, so isa/2 might be important in that regard. Otherwise the characters might exclaim “Hey, this thing is sharp, made of metal, and hurts people. What should we call it?”

1 Like

Knife? Arrowhead? Razor? Sword? A metal sharpie that this guy over there uses to hurt people?

1 Like