реализация инвентаря и экипировки персонажа

[DEVORON]

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

В этом нет смысла. Если что-то надето, его надо просто снять. Глупо выводить какие-то окна с сообщениями "Вы не можете надеть шлем, пока не сняли шапку". Шапку надо просто автоматически снять и надеть шлем. Поэтому знать какие-то тру не имеет смысла, должна храниться ссылка на надетый предмет, чтобы тут же его передать в функцию-ликвидатор, которая освободит слот(ы) и пересчитает бонусы

Как раз этот способ позволит знать, какие слоты заняты, а какие-нет, но при этом держать в общем массиве предмет двойного назначения. Предположим, мы хотим положить предмет куртка(который претендует на два слота - голова и туловище). Смотрим, заняты ли эти значения - да, заняты. Потом ищем в списке предмет, который может их занимать - находим шлем и находим кофту. Скидываем оба в инвентарь. Устанавливаем куртку. Значения флагов не меняем.

Выдавать сообщение о том, что их надо снять или нет - это уже на усмотрение автора.

[Appleman]

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

Ну здесь же две разные задачи: считать эффекты и разбираться с возможностью добавления новой вещи. Вполне оправдано иметь разные "базы данных" — реестр вещей и реестр слотов — для этих разных задач.

Да, и правда. Давайте тогда пока сосредоточимся на задаче правильного распределения слотов под шмотьё различной конфигурации.

Можно ещё технический вопрос? Сделал пока для примера 3 слота в 2х слоях. Но есть важный нюанс. Например, на торс можно надеть куртку, а сверху на неё защиту (т.е. два слоя), а на ноги - только сапоги (носки с портянками реализовывать не планируется ), то есть тут всего один слой предусмотрен. Получается, что для некоторых "точек" все слои "открыты", а для каких-то - нет. С учётом данных нюансов никак не могу решить, в каком виде организовывать эти самые слоты в классе-менеджере снаряги.

Вариант 1. Сделать просто свойства

// В классе менеджера снаряги
private var _torso1: Equipment;
private var _torso2: Equipment;
private var _feet1: Equipment;
 
public function get torso1() : Equipment {return _torso1}
 
// В справочнике идентификаторов модели
public static const WEARABLE_LAYER_CLOTHES: uint = 1;
public static const WEARABLE_LAYER_ARMOR: uint = 2;
 
// В классе предмета одежды - футболки
private var _layer: uint = IDs.WEARABLE_LAYER_CLOTHES;
private var _slots: Vector.<String> = new <String>["torso"]; 
 
// Опять в классе менеджера снаряги в момент надевания
public function putOn(item: Equipment) : void
{
var slots2occupy: Vector.<String> = item.slots;
for each (var slotID:String in slots2occupy)
     {
      if(this[slotID + String(item.layer)) 
      //Дальше что-то делаем
      }
}

Идея, полагаю, понятна. Плюсы: имеем чёткую типизацию, а также разметку, куда можно надевать, а куда нельзя: как по точкам, так и по слоям. Минус: простыня сеттеров и геттеров

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

[RedHead90]

Зачем хард-кодить каждый слот, прописывая для каждого свою переменную? Получается, что для каждого типа экипировки придется писать свою логику, зависимую от этих переменных? Словарь слотов будет более гибким и элегантным решением. С таким подходом ты в будущем даже сможешь легко добавить четырехруких персонажей, ампутацию конечностей или отращивание пальцев в следствии радиации простым редактированием словаря вместо того, чтобы городить наследников Character под каждый конкретный случай. А чтобы не было "пиши чего хочешь куда хочешь", можно просто добавить проверку на существование нужного слота у персонажа.

[Appleman]

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

А чтобы не было "пиши чего хочешь куда хочешь", можно просто добавить проверку на существование нужного слота у персонажа.

Как?

Возможно я ошибаюсь, но в моём представлении Dictionary - крайне либеральный класс. Допустим, у нас есть слот, в который ничего не записано (slot1), и слот, которого не предусмотрено (slot2). Результатыобращения будут одинаковыми:

if(dictionary[slot1]) // false. Слот создан, но в нём null
if(dictionary[slot2]) // false. Такого слота нет и не предвидится.

[RedHead90]

Давно с чистым as не работал, но если не изменяет память, то делается это так

if(slot1 in dictionary) {
    //слот существует
}

хотя, думаю, можно просто чекать на ненулевое значение

if(dictionary[slot1] != null) {
    //слот существует
}

ну и еще у всех объектов в as3 есть метод hasOwnProperty, но он вроде бы только со строковыми свойствами работает и определен в прототипе

if(dictionary[slot1]) // false. Слот создан, но в нём null

а зачем создавать слот без данных? Я бы сделал ключем в словаре строку или числовой индетификатор, а значением специальный класс Slot, который в свою очередь содержит свойство item. А вот это свойство уже может быть либо null, либо ссылкой на надетый предмет.

Но если уж очень хочется, то первый вариант проверки, что я привел, должен возвращать true, даже если dictionary[slot1] == null, но при этом сам ключ существует

[Wolsh]

К слову, "false. Такого слота нет и не предвидится." это не null, a undefined.
И да, if(slot1 in dictionary){} будет проверять НАЛИЧИЕ свойства в словаре.
В остальном мне не нравится, особенно эти конкатенации строк, да еще с преобразованием числа в строку, какой-то первобытный хаос, простите. Зачем нужен Dictionary, я так и не понял. Чтобы записывать в него что-то, не предусмотренное классом-менеджером?)) А кто будет знать, что это что-то туда записали, и сможет его оттуда вытащить и учесть?
"Хардкодить", если что — это жестко забивать неизменные ЗНАЧЕНИЯ вместо использования переменных.
То есть, когда box.width = 200; а не box.width = stage.stageWidth / 8;
А упорядоченный набор свойств это просто порядок в проектировании. И то, что в данном случае этот список свойств (слотов) КОНЕЧЕН, однозначно намекает на неуместность "бесконечных" динамических коллекций — справочников и векторов.
Решение, что слоты не надо делать двух типов: однослойные и двухслойные, а просто иметь второй слой как продолжение перечня слотов — мне нравится. Я бы так и сделал — chestArmor, chestCloth, красота. Перчатки одни, тапочки и шляпка тоже. Все ясно и понятно. "Для четырехрукого" придется сделать наследник этого менеджера, куда деваться. Сигнатура метода putOn() от этого не изменится.
"простым редактированием словаря вместо того, чтобы городить наследников" — ну а словарь ты где будешь "редактировать" под четырехрукого или беспалого? (хотя, вижу уже конструктор менеджера, принимающий параметрами кол-во пальцев, рук, ног и голов))).

Добавлено через 7 минут
И да, в Скайриме, например, хоть и нет четырехруких и беспалых, решили проблему тупо не создавать: персонаж может носить только ОДНО кольцо. Ну и один амулет, естественно, хотя теоретически ты мог бы обвеситься ими как новогодняя елка.

Добавлено через 15 минут
А, и еще там хитрый финт — щиты относятся к одежде, хотя берутся в руку как оружие и — внимание — занимают слот оружия, причем со своей логикой: если герой держал двуручный меч или лук, щит его убирает совсем. Если было два одноручных (там есть двурукий режим по-македонски)), то заменяет оружие левой руки (да еще и может использоваться как оружие, что уж вообще другая история). Я собственно хотел намекнуть на взаимосвязь Equipment и Оружия. Но, впрочем, если в игре щитов не будет, то и фиг бы с ним.

[RedHead90]

Wolsh, ну даже если список свойств конечен, что делать, если я, например, хочу сделать не казуальный Скайрим, а хардовую РПГ, где перс может на каждый палец нацепить по 3 кольца, навесить на себя 10 амулетов и напялить 5 рубашек под 3 кофты?)) Городить портянку с миллионом переменных? Да даже если слотов будет всего 5 без всяких вариаций, сам факт того, что мы имеем 5 свойств одинакового типа говорит о том, что это какая-то типизированная коллекция. Зачем писать кучу переменных и классов-наследников там, где можно написать всего пару тройку классов и создавать нужные нам наборы в любое время в рантайме?

А если мне надо, например, вычислить степень покрытия персонажа броней, т.е. пройтись по всем слотам, это как будет выглядеть? Что-то типа

var coverage:Int = 0;
 
if (equipment[head] != null)  coverage += 1;
if (equipment[torso] != null)  coverage += 1;
if (equipment[shoulders] != null)  coverage += 1;
if (equipment[arms] != null)  coverage += 1;
if (equipment[hands] != null)  coverage += 1;
if (equipment[legs] != null)  coverage += 1;
if (equipment[foots] != null)  coverage += 1

Или же все таки придется дублировать слои в какой-то массив, чтобы я мог пробежаться по ним в цикле?

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

Словарь - это лишь самый простой пример. Очевидно, что лучше делать свою обертку. И никаких конструкторов с кучей параметров не надо, а всего то несколько методов типа getHuman():Slots, getFourHandedHuman():Slots, getKolobok():Slots. И никаких наследников, только композиция.

[Wolsh]

RedHead90, ну ты просто не очень внимательно читал топик. Я как раз предлагал в менеджере экипировки иметь два списка:
1) вектор надетых предметов, никак не упорядоченный, тупо для перебора всех и подсчета суммарных величин типа общего резиста брони или общего веса, или прочих разнообразных эффектов (и этот список должен быть вектором или массивом именно потому, что он переменной длины и обслуживается как беспорядочная куча, кто-то входит, кто-то выходит, номера ячеек не несут никакой информации, важна лишь возможность быстрого перебора).
2) упорядоченный список слотов, из которого мы могли бы узнать, что конкретно надето на конкретную часть тела. Этот список а) конечен и б) не требует перебора ибо сами по себе слоты не имеют каких-то индивидуальных свойств для подсчета. Что считать? Сколько слотов занято? Кому и зачем это нужно? И хотя я не настаивал, что это должны быть публичные свойства экземпляра менеджера, ничего плохого в таких геттерах (то есть только для чтения) я не вижу. Но можно и один метод сделать, принимающий строковый ID слота и возвращающий предмет (или опять же, только ID предмета), если так удобней в общей архитектуре. Стоит ли заводить для этого списка динамический Справочник? — я так и не вижу смысла. Этот список нужен исключительно для обслуживания внутренней логики менеджера "чтобы надеть ЭТО, нужно снять ТО".

*еще одна интересная фишка в TES — бонус за комплект: предполагается, что если все элементы брони из одной серии (стеклянная кираса, стеклянные сапоги, стеклянные перчатки, стеклянный шлем, стеклянный щит) то не мешают друг другу, хорошо подогнаны в местах стыков и не имеют "дыр", что повышает и удобство и степень защищенности).

[RedHead90]

Wolsh, ну если делать один метод с айдишником слота, тогда тем более не вижу смысл городить переменные. А упорядоченный список переменных, если нужен, я бы сделал списком констант этих айдишников.

ибо сами по себе слоты не имеют каких-то индивидуальных свойств для подсчета

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

З.Ы. никак не разберусь, как выделить ник в сообщении на этом форуме? Нажимаю ответ, но ник адресата не добавляется

[Wolsh]

Ну а просто в тексте выделить — болд + цвет