How "smart objects" are implemented and actually work?

Question

I'm drafting my game and implementing small stuff in it, but hit a roadblock. You see, for my game I would like for different items to behave the same or to share behavior, for instance, some items can be picked up and dropped to the floor, some items can get damaged and be repair while some only can get damage (the player cannot repair the item), some items can be use for a variety of different purposes (fire arms as weapons, frying pan as cooking tool and as a weapon), some items can get wet while others can get wet, catch fire and spread it further (or not; this is a reference to systemic games) and so on.

In my mind, the behavior must exist in the object and be abstracted from the player/AI/Other items nevertheless I'm lacking experience on how to go about this and I think that beside implementing a behavior there must exist also code that knows how to interact with such behavior, but this approach feels odd IMHO. In any case, I was asking around and The Sims was thrown in a reply, searching on the web found Living with The Sims’ AI: 21 Tricks to Adopt for Your Game, the trick 5 reads:

Each object has a public interface that broadcasts its functionality to actors in the game. This is called advertising data in The Sims, and contains a list of possible actions and what motives they satisfy.

If reading this correctly, it means that "smart objects" have a standard interface that actors can access to, right? My guess is that this interface covers everything behavior/systemic-wise that could happen in the game and the "actors" have code implemented that allow them to make use of this advertised interface, right?

Answer 1

Well, concerning "The Sims" article you are reffering to that actually could mean a lot of different things. But the core idea as I get it is that each object can expose a list of "functions" that can be applied to it. For example

item : ["destroy", "pick up", "eat", "cook"]

and then the actor decides it can be processed with:

item.pickUp(actor)

or

actor.pickUp(item)

or something else, depending on details of implementation.

So imaging the actor clicks on the item and basically sees this list of possible interactions. Each action is binded to specific code for processing and accepts the actor as argument.

The "broadcast" mentioned in the article means, as far I understand, that item are proactively inform actors about their features so they can move to them and interact if necessary.

Answer 2

With strong typed languages, you can create this functionality broadcast in public interfaces by the way of interfaces. Say:

interface IDamageSource
{
    DamagePoints Damage { get; }
    void Consume( DamagePoints points );
}

interface IDamageTarget
{
   void TakeDamage( DamageSource source );
}

interface IFixTarget
{
    FixMaterial[] FixCost();
    void FixApply( FixMaterial[] materials );
}

class Tool implements IDamageSource, IDamageTarget, IFixTarget {}
class Rock implements IDamageSource, IDamageTarget {}

class DamageEffect
{
    public InterfaceUpdates DoDamage( IDamageSource source , IDamageTarget target )
    {
        // Common logic, return any visual effects to later GUI render
    }
}

So in this example, a Rock can cause damage and can be damaged but not restored, and a Tool can cause damage, be damaged and be fixed with some cost. Any specifics is handled in each object implementation of interface, and the common logic is handled in DamageEffect.

When the user points to a object in screen, then you can "ask" to object:

// Can damage?

user.AttackAction.Enabled = user.SelectedObject is IDamageTarget;

// Can fix?

var fixable = user.SelectedObject as IFixTarget;
if ( fixable == null )
    user.FixAction.Status = UserFixActionEnum.NotFixable;
else
    if ( this.HasEnoughMaterials( fixable.FixCost() ) )
        user.FixAction.Status = UserFixActionEnum.Fixable;
    else
        user.FixAction.Status = UserFixActionEnum.MissingMaterials;

This could be realized by all "in game" objects having a common standard interface, but this is the way of one big class with tons of unrelated functionality, and that is a bad design that leads to very bad code later on.