Что такое соответствующая структура данных и схема базы данных для хранения логических правил?
Используйте Вар ()
class Foo(object):
def __init__(self):
self.a = 1
self.b = 2
vars(Foo()) #==> {'a': 1, 'b': 2}
vars(Foo()).keys() #==> ['a', 'b']
3 ответа
Похоже, ваша проблема сводится к проверке выполнения определенного условия.
У вас будут сложные условия. Итак, дана таблица элементов:
ID_Item Description ---------------------- 1 A 2 B 3 C 4 F
и дана таблица возможных действий:
ID_Action VerbID ItemID ConditionID ---------------------------------------- 1 BUY 4 1
Мы создаем таблицу условий:
ID_Condition VerbA ObjectA_ID Boolean VerbB ObjectB_ID --------------------------------------------------------------------- 1 OWNS 1 OR MEETS_CONDITION 2 2 OWNS 2 AND OWNS 3
Итак, OWNS означает, что идентификатор является ключом к таблице элементов, а MEETS_CONDITION означает, что идентификатор является ключом к таблице условий.
Это не означает, что вы ограничиваете вас. Вы можете добавить другие таблицы с квестами или чем-то еще, а также добавить дополнительные глаголы, чтобы указывать, где искать. Или просто поместите квесты в таблицу предметов после их завершения, а затем интерпретируйте завершенный квест как получение определенного значка. Тогда вы сможете обрабатывать как предметы, так и квесты с одним и тем же кодом.
Это очень сложная проблема, на которую я не могу ответить, но я видел много ссылок. Основная проблема в том, что для игр квесты, предметы и «статистика» для различных объектов могут иметь нереляционные зависимости. Эта ветка может вам очень помочь .
Вы можете взять пару книг по этой теме и изучить возможность использования LUA в качестве обработчика правил.
Лично я сделал бы это в коде, а не в SQL. Каждый элемент должен быть собственным классом, реализующим интерфейс (например, IItem). У IItem будет метод OkToPurchase, который определит, можно ли покупать этот предмет. Для этого он будет использовать одно или несколько из набора правил (например, HasPreviouslyPurchased (x), CurrentOwns (x) и т. Д.), Которые вы можете создать.
Приятно то, что этот подход легко расширить с помощью новых правил, не нарушая всей существующей логики.
Вот какой-то псевдокод:
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 )
}