What is an appropriate data structure and database schema to store logic rules?

Question

Preface: I don\'t have experience with rules engines, building rules, modeling rules, implementing data structures for rules, or whatnot. Therefore, I don\'t know what I\'m doin

Answer 1

It seems like your problem breaks down to testing whether a particular condition has been satisfied.

You will have compound conditions. So given a table of items:

ID_Item    Description
----------------------
1          A         
2          B         
3          C         
4          F         

and given a table of possible actions:

ID_Action  VerbID  ItemID    ConditionID
----------------------------------------
1          BUY     4         1

We construct a table of conditions:

ID_Condition  VerbA  ObjectA_ID  Boolean  VerbB            ObjectB_ID
---------------------------------------------------------------------
1             OWNS   1           OR       MEETS_CONDITION  2
2             OWNS   2           AND      OWNS             3

So OWNS means the id is a key to the Items table, and MEETS_CONDITION means that the id is a key to the Conditions table.

This isn't meant to restrict you. You can add other tables with quests or whatever, and add extra verbs to tell you where to look. Or, just put quests into your Items table when you complete them, and then interpret a completed quest as owning a particular badge. Then you can handle both items and quests with the same code.

Answer 2

This is a very complex problem that I'm not qualified to answer, but I've seen lots of references to. The fundamental problem is that for games, quests and items and "stats" for various objects can have non-relational dependencies. This thread may help you a lot.

You might want to pick up a couple books on the topic, and look into using LUA as a rules processor.

Answer 3

Personally I would do this in code, not in SQL. Each item should be its own class implementing an interface (i.e. IItem). IItem would have a method called OkToPurchase that would determine if it is OK to purchase that item. To do that, it would use one or more of a collection of rules (i.e. HasPreviouslyPurchased(x), CurrentlyOwns(x), etc.) that you can build.

The nice thing is that it is easy to extend this approach with new rules without breaking all the existing logic.

Here's some pseudocode:

bool OkToPurchase()
{
   if( HasPreviouslyPurchased('x') && !CurrentlyOwns('y') )
       return true;
   else
       return false;
}

bool HasPreviouslyPurchased( item )
{
    return purchases.contains( item )
}

bool CurrentlyOwns( item )
{
    return user.Items.contains( item )
}