Вопрос по проектированию - Страница 8

Wolsh · 16.10.2017, 10:35

квадратные скобки — массив; а в нем лежат Обжекты.

Appleman · 16.10.2017, 13:56

Цитата:

Сообщение от Wolsh

квадратные скобки — массив; а в нем лежат Обжекты.

Большое спасибо, теперь понятно. Да и дальше в коде действительно видно, что Обжекты.

Цитата:

Сообщение от caseyryan

Код AS3:

{
   dialog1: [{skillLevel: 1, textID: "walkInThePark"}, {skillLevel: 2, textID: "killDragon"}, { skillLevel: 100500, textID: "changeTheWorld" }]
}

Эту систему можно дальше рекурсивно усложнять, в зависимости от потребностей. Но для первой игры, я бы не советовал этого делать. Возникнет большая путаница, и есть вероятность, что система вообще не будет работать

caseyryan, спасибо, весь код вдумчиво просмотрел. Но если честно, то такое я бы и сам наваял. Я изначально писал, что условия могут, во-первых, касаться разнообразных вещей (различные свойства персонажа, наличие/отсутствие некоторого предмета и т.п.), а во-вторых, сравниваются не обязательно по типу "равно", но также "больше" или "меньше". В этом вопрос.

Есть возможность каким-то образом так формулировать условия в этих самых обжектах, чтобы они сразу были указателями на нужные свойства и типы сравнения? Например, у нас есть строковые идентификаторы свойств персонажей, которые совпадают с именами переменных класса Character. Таким образом, если нам нужно "вытащить" значение свойства intelligence, которое хранится в нашем списке условий в переменной prop1:String = "intelligence", то мы просто обратимся character[prop1 as String] (если я ничего не путаю в синтаксисе по неопытности). Я думаю, понятно, что имеется в виду.

caseyryan · 16.10.2017, 16:36

Код AS3:

character[prop1 as String]

Так лучше не делать. Это сработает, только если prop1 действительно строка.
Лучше делать так:

Код AS3:

character[String(prop1)]

или так:

Код AS3:

character[prop1.toString()]

Appleman · 19.10.2017, 17:27

Друзья!

Я с разработкой своей игрушки продолжаю неспешное движение вбок (по тому анекдоту про аспиранта, которому двигать науку вперёд мозгов не хватает, а назад - научный руководитель не позволяет

). Возникло ещё несколько вопросов.

Помимо собственных игровых свойств, у персонажа есть свойства, получаемые от других объектов. Самый простой пример из RPG-жанра - всякие модификаторы от экипировки. Например, надетый на голову шлем "Толоконный лоб" даёт +1 к интеллекту, понятно. Раздумываю, как организовать это дело в программе. Явно напрашивается отдельный класс для шмоток Item, и наш шлем будет храниться в какой-нибудь переменной данного типа или его наследника (например ItemHat). Вопросы:

Во-первых, насколько хорошей практикой считается создание "раскидистых" деревьев наследования для случаев, подобных описанному? Ведь игровых предметов может быть десяток-другой разнообразных типов, некоторые могут также ветвиться ещё дальше... Преимущества - в том, что во-первых, можно чётко разграничивать, какие типы куда применимы, а во-вторых, при создании интерфейса пользователя в распоряжении будет уже готовая структура. Верно ли я рассуждаю? В чём недостатки такого подхода?

Во-вторых, чтобы "надеть" шлем на персонажа, его объект должен содержать соответствующий "слот". В моём понимании, это свойство hatUsed:ItemHat класса Character. Соответственно, оно может быть либо пустым, если ничего не надето, либо туда будет помещаться один из экземпляров класса ItemHat. Вопрос, правильно ли я рассуждаю и правильно ли я представляю, что подобные вещи прорабатываются сразу в пакете data (а не model).

В-третьих, создав классы для предметов, где-то в программе необходимо создать и сами предметы, т.е. экземпляры классов. Где и каким образом обычно это делается? Я пока прямо в Main нафигачил несколько для теста, но это не комильфо. Плюс встаёт вопрос идентификации этих экземпляров. Если мы говорим не о "генерёнке", а об "именных" предметах или NPC, то для них сразу резервируется некая переменная нужного типа, в которую записывается экземпляр, верно?

В-четвёртых, возник ещё любопытный вопрос. Допустим, у персонажа может быть свойство, принимающее одно из заранее определённых значений (отвлечённо - это знак зодиака, чтобы было понятно, о чём идёт речь). Присвоенное персонажу значение учитывается игровой механикой в определённых ситуациях. Здесь можно было бы по аналогии создать класс Zodiac с 12 экземплярами по числу знаков и присваивать персонажу один из них. Но в описанной ситуации кроме собственно имени экземпляра для корректной работы больше ничего не требуется, и городить целый класс кажется излишним. С другой стороны, коллега wolsh предостерегал от замены Strong-типизации на String-типизацию. Где истина?

Спасибо!

caseyryan · 20.10.2017, 10:54

Цитата:

В моём понимании, это свойство hatUsed:ItemHat класса Character.

Это не гибкий подход. Что если ты захочешь добавить какой-то новый предмет, например ItemCap, вместо ItemHat? Тоже одевается на голову, но класс уже другой и в эту переменную не записать. При таком подходе придется каждый раз добавлять и новые свойства персонажу. Я бы сделал массив, в котором хранил экземпляры добавленных предметов. Сами придметы должны все расширять какой-то базовый класс, например Item, и добавляться персонажу они тоже должны как Item. В самом классе можно сделать несколько констант, которые отвечают за те свойства, которые модифицирует предмет, например так

Код AS3:

// в классе Item
public static const TYPE_HEALTH:String = "health";
public static const TYPE_ARMOR:String = "armor";
 
public var type:String = null; // назначается в наследниках
public var value:Number = 0; 
 
// в конструкторе наследника
public function HatItem() {
     type = Item.TYPE_ARMOR; // шапка увеличивает защищенность
     value = .15 // на 15% от текущей защищенности персонажа
}
 
// в классе персонажа
private var _items:Array = [];
private var _health:Number = 100; // базовая величина здоровья, без 
private var _healthIncrease:Number = 0; // величина прироста, которую могут давать преметы
private var _armor:Number = 50;
private var _armorIncrease:Number = 0; 
 
public function addItem(newItem:Item):void {
     if (item) {
         for each (var item:Item in _items) {
             if (item.type == item.type) {
                  trace("предмет такого типа уже надет, сначала нужно снять его"); // если не нужно, чтобы игрок использовал предметы одного типа несколько раз
                  return;
             }
         }
         _items.push(newItem);
         calculateValues(); // пересчитываем показатели игрока после добавления нового предмета
 
     }
}
public function removeItem(item:Item):void {
    if (item) {
        var index:int = _items.indexOf(item);
        if (index > -1) {
            _items.removeAt(index);
        }
        calculateValues();
    }
}
 
private function calculateValues():void {
      _healthIncrease = 0;
      _armorIncrease = 0; // обнуляем все показатели, чтобы записать новые без багов
      for each (var item:Item in _items) {
          switch (item.type) {
              case Item.TYPE_HEALTH:
                    _healthIncrease = item.value;
                    break;
              case Item.TYPE_ARMOR:
                    _armorIncrease = item.value;
                    break;
          } 
      }
}
 
// используем где надо с учетом прибавок
public function get health():Number {
     return _health + (_health * _healthIncrease);
}
public function get armor():Number {
     return _armor + (_armor* _armorIncrease);
}

как-то так

Цитата:

В-третьих, создав классы для предметов, где-то в программе необходимо создать и сами предметы

Ну, например в резделе инвентаря в магазине. И там же отображется что из них используется в данный момент

Wolsh · 20.10.2017, 13:59

В Скайриме например считается, что на голову может быть надет только один предмет — надеваешь капюшон, обруч снимается, надеваешь шлем — снимается капюшон.
Но когда добавили расширения с новыми миссиями и новыми предметами, кто-то лоханулся и получилось так, что предметы из этой новой коллекции можно надеть "поверх" других. В частности, фалмерский шлем можно надеть поверх обруча или капюшона.
Казалось бы ну и фиг с ним, баг и баг. Но фишка в том, что предмет это не просто предмет. На него можно накладывать зачарования, которые дают нехилые бонусы к навыкам или статам. И, нацепив на голову два предмета, повышающих искусство Лучника, ты завалишь целого дракона одной ржавой стрелой.
Так что не надо тут))) Система должна быть четкой и не давать преференций свыше правил.

Добавлено через 4 минуты

Цитата:

В-третьих, создав классы для предметов, где-то в программе необходимо создать и сами предметы, т.е. экземпляры классов. Где и каким образом обычно это делается?

Да по-сути предмет это просто ID. В инвентаре надо будет показать картинку — создашь экземпляр картинки. Надо показать свойства — вытащишь из справочника свойства.
Другое дело, если у предметов есть свой жизненный цикл, если они изнашиваются при каждом применении и т.п. То есть МЕНЯЮТСЯ свойства конкретных экземпляров.

Appleman · 20.10.2017, 18:16

Цитата:

Сообщение от caseyryan

Это не гибкий подход. Что если ты захочешь добавить какой-то новый предмет, например ItemCap, вместо ItemHat? Тоже одевается на голову, но класс уже другой и в эту переменную не записать. При таком подходе придется каждый раз добавлять и новые свойства персонажу.

Ты меня неправильно понял. Если будет ItemHat, то никаких Cap-ов уже не будет, разумеется. И шлем, и шапка, и бандана будут относиться к одному наследнику Item. Итого получается ItemHat, ItemCoat, ItemBoots и так далее. А экземпляры каждого из классов - это уже сами предметы.

Цитата:

Ну, например в резделе инвентаря в магазине. И там же отображется что из них используется в данный момент

Цитата:

Да по-сути предмет это просто ID. В инвентаре надо будет показать картинку — создашь экземпляр картинки. Надо показать свойства — вытащишь из справочника свойства.
Другое дело, если у предметов есть свой жизненный цикл, если они изнашиваются при каждом применении и т.п. То есть МЕНЯЮТСЯ свойства конкретных экземпляров.

Джентльмены, вы меня по-моему неправильно поняли. Я имел в виду в каком месте кода, текста программы, создавать непосредственно экземпляры классов? То есть где писать var goodOldBandanna:ItemHat = new ItemHat и далее по тексту значения свойств?

Wolsh · 20.10.2017, 19:56

В чем его ответственность, этого экземпляра хорошей старой банданы?
Что он вообще должен уметь делать?
Не слишком ли много чести создавать для него класс?
Другими словами, что это вообще? Когда ты говоришь про этот экземпляр, что ты видишь? Что имеешь в виду?

caseyryan · 21.10.2017, 10:16

Цитата:

Ты меня неправильно понял. Если будет ItemHat, то никаких Cap-ов уже не будет, разумеется. И шлем, и шапка, и бандана будут относиться к одному наследнику Item. Итого получается ItemHat, ItemCoat, ItemBoots и так далее. А экземпляры каждого из классов - это уже сами предметы.

В чём тогда вопрос? Я целую схему написал, как это у меня работает

Цитата:

Не слишком ли много чести создавать для него класс?

А по мне так наоборот, хорошо бы класс создать для него. И там же сразу указать, какая вьюшка будет использоваться и настроить все необходимые параметры, от того, что он изменяет, до его персонального ID, который будет храниться в базе. Чтобы потом это все не прописывать там, где он создался (к примеру в инвентаре), а просто написать так:

Код AS3:

var _inventory = [
    new ItemHat(),
    new ItemCoat(),
    new ItemBoot(),
    // ...
];

Wolsh · 21.10.2017, 11:15

Я имел ввиду как то так

Код AS3:

//... Model / InventoryModel
_inventory.hat = 0xFD3490;
_inventory.boots = 0x5539A2;
_inventory.robe = 0xCA4D23;
//... InventoryView
_headSlot.add(_model.character.inventory.hat); // function add(itemID:uint)
//... InventoryCharacterSlot
this.image = Assets.getImage(itemID);
this.data = Items.getData(itemID);

Экземпляр должен что-то делать. Нет смысла в экземпляре(!) хранить какие-то неизменные данные, для этого максимум хватит класса со статическими константами. Экземпляры нужны только тогда, когда у них есть индивидуальность, жизненный цикл с сохранением изменений свойств. Если экземпляр всего лишь хранит набор неизменных свойств, то вместо класса достаточно идентификатора и таблиц со свойствами по идентификатору — тем более, когда таких "классов" подразумевается 100500 и все они хранят более-менее одинаковый набор свойств.