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)
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?
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.
@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:
Going back to the ECS analogy I mentioned previously, is there any benefit to an “entity” that is just a unique ID:
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(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?”
Knife? Arrowhead? Razor? Sword? A metal sharpie that this guy over there uses to hurt people?