Question

This has a game development project under itself, but it’s really about coding and mapping data to other pieces of data. This is why I decided to post it here.

The format that I’m using for external inventory item data storage:

[ID:IT_FO_TROUT]
[Name:Trout]
[Description:A raw trout.]
[Value:10]

[3DModel:null]
[InventoryIcon:trout]

[Tag:Consumable]
[Tag:Food]
[Tag:Stackable]

[OnConsume:RestoreHealth(15)]
[OnConsume:RestoreFatigue(15)]

The question is concentrated upon the last 2 OnConsume properties. Basically, the two properties mean that when the item gets consumed, the consumer’s health goes up by 15 points, and his fatigue does so as well. This, in the background, invokes 2 different methods:

void RestoreHealth(Character Subject, int Amount);
void RestoreFatigue(Character Subject, int Amount);

How would you go about mapping the methods to their in-file string counterparts? This is what I thought of:

1. Every time an item gets consumed, a list of strings (the events) gets passed to an Item event manager. The manager parses each string and calls the appropriate methods. Very easy to set up, and since this is not an operation that happens too often, the impact on performance might not be considerable (strings will also be tiny (max 10-15 characters) in size, and parsed in O(n) time).

2. Each inventory item (class) parses the string events once and only once, on initialization. Each string event gets mapped to its appropriate method via a dictionary. This is the most efficient method in terms of performance that I can think of, but it makes it extremely difficult to do other things:
   All of the values in the dictionary would have to be delegates of the same kind. This means I cannot keep

   a) RestoreHealth(int)

   b) SummonMonster(Position, Count)

   in the same dictionary, and would have to set a new data structure for each kind of callable method. This is a tremendous amount of work to do.

Some ways that came to mind, to improve both methods:

1. I could use some sort of temporary cache inside the Item event
   manager, so that an item’s OnConsume events don’t get parsed
   twice? I might hit the same issues as the ones I hit during 2)
   though, as the cache would have to be a map<InventoryItem,List<delegate>>.

2. The hashtable data structure inside the .NET libraries allows
   for any kind of object to be a key and/or value at any given time
   (unlike the dictionary). I could use this and map string A to
   delegate X, while also having mapped string B to delegate Y
   inside the same structure. Any reasons why I should not do this? Can
   you foresee any trouble that would be brought by this method?

I was also thinking about something in the ways of reflection, but I’m not exactly experienced when it comes to it. And I’m pretty sure parsing the string every time is faster.

EDIT

My final solution, with Alexey Raga’s answer in mind. Using interfaces for each kind of event.

public interface IConsumeEvent    
{    
    void ApplyConsumeEffects(BaseCharacter Consumer);   
}

Sample implementer (particular event):

public class RestoreHealthEvent : IConsumeEvent
{    
    private int Amount = Amount;

    public RestoreHealthEvent(int Amount)
    {
        this.Amount = Amount;
    }

    public void ApplyConsumeEffects(BaseCharacter Consumer)   
    {
        Consumer.Stats.AlterStat(CharacterStats.CharStat.Health, Amount);    
    }    
}

Inside the parser (the only place where we care about the event’s particularities – because we’re parsing the data files themselves):

RestoreHealthEvent ResHealthEv = new RestoreHealthEvent (Value);
NewItem.ConsumeEvents.Add (ResHealthEv );

When a character consumes an item:

foreach (IConsumeEvent ConsumeEvent in Item.ConsumeEvents)
{
    //We're inside a parent method that's inside a parent BaseCharacter class; we're consuming an item right now.
    ConsumeEvent.ApplyConsumeEffects(this);
}

Answer 1

Why not “map” them to “command” classes once-and-only-once instead?

For example,

[OnConsume:RestoreHealth(15)]
[OnConsume:RestoreFatigue(15)]

could be mapped to RestoreHealth and RestoreFatigue command classes that can be defined as:

public sealed class RestoreHealth : ICommand {
    public int Value { get; set; }
    //whatever else you need
}

public sealed class SummonMonster : ICommand {
    public int Count {get; set; }
    public Position Position { get; set; }
}

Consider commands as just wrappers for your parameters at this point 😉 So instead of passing multiple parameters you always wrap them and pass only one.
It also gives a bit of semantics too.

Now you can map your inventory items to commands that need to be “sent” when each item is consumed.

You can implement a simple “bus” interface like:

public interface IBus {
    void Send(ICommand command);
    void Subscribe(object subscriber);
}

and now you just get an instance of IBus and call its Send method when appropriate.

By doing this you separate your “definition” (what needs to be done) and your logic (how to perform an action) concerns.

For the receiving and reacting part you implement the Subscribe method to interrogate the subscriber instance (again, once and only once) figuring out all its method which can “handle” commands.
You can come up with some IHandle<T> where T: ICommand interface in your handlers, or just find them by convention (any Handle method that accepts only one argument of ICommand and returns void), or whatever works for you.

It is basically the same part of “delegate/action” lists that you were talking about except that now it is per command:

map<CommandType, List<action>>

Because all the actions now accept only one parameter (which is ICommand) you can easily keep them all in the same list.

When some command is received, your IBus implementation just gets the list of actions for the given command type and simply calls these actions passing the given command as a parameter.

Hope it helps.

Advanced: you can do one step further: have a ConsumeItem command:

public sealed void ConsumeItem: ICommand {
    public InventoryItem Item { get; set; }
}

You already have a class that is responsible for holding a map between InventoryItem and Commands, so this class can become a process manager:

1. It subscribes to ConsumeItem command (through the bus)
2. In its Handle method it gets the list of commands for the given inventory item
3. It sends these commands to the bus.

Well, now we have separated clearly these three concerns:

1. While consuming an inventory item we just “know” about IBus and send a ConsumeItem command and we don’t care what happens next.
2. The “ConsumeInventoryManager” (whatever you call it) also knows about IBus', subscribes forConsumeItem` command and “knows” what needs to be done when each item is consumed (list of commands). It just sends these commands and doesn’t care who and how handle them.
3. The business logic (characters, monsters, etc) just handle the commands that make sense to them (RestoreHealth, Die, etc) and don’t care where (and why) they came from.

Good luck 🙂