Цитата:
Сообщение от Tails
В принципе, это норм, только класс я бы назвал CharacterProperty и значения использовал не строковые, а целочисленные. (Int, Uint). Строки - жирные и тормознутые.
|
Согласен. Решил делать строки, чтобы в отладке удобно было. Пишешь trace("чего-нибудь " + PropID) и сразу понятно, о чём идёт речь. Возможно, потом поменяю для оптимизации.
Цитата:
Вот это фигня какая-то, я бы сделал по другому, описал 2 таблички - "Условия" и "Действия". Допустим, в игре есть используемые предметы, тогда, сущность "Предмет" будет выглядеть так:
 Код: class Item {
var id:Uint; // ID Предмета
var useCondition:Uint; // ID Условия, которое должно выполняться для использования предмета
var useAction:Uint; // ID Выполняемого действия.
}
class Condition {
var id:Uint;
var minStrength:Number;
}
|
Я с тобой тут поспорю. Во-первых, условия могут отличаться как количественно, так и качественно. В твоём варианте получается, что любое количественное изменение (сила не 5, а 10) - это появление нового экземпляра, а любое качественное (т.е. не только сила, а сила 5 и ловкость 8 вместе) - новый класс или наследник. Или ты предлагаешь воссоздавать в Condition все свойства проверяемого объекта и устанавливать значения для тех, которые должны быть проверены? Там ещё экипированные предметы, статус-эффекты и хрен знает что ещё.
Во-вторых, при таком подходе имеем туеву хучу плохо читаемых объектов. Как потом разбираться, что из себя представляет Condition id8 или id28? Imho, запись вроде {IDs.PLAYER, IDs.PROP_STRENGTH, 15} читается лучше.
В-третьих, я не совсем понял, откуда метод, выполняющий проверку условия id8 "знает", что свойство minStrength в экземпляре Condition связано именно со свойством _strength персонажа, а не с каким-нибудь другим?
СлаваRa, а я подумал, это троллинг такой с твоей стороны
