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

[Appleman]

Други! Я наконец добрался до практической реализации инвентаря для своей игрухи. Даже скорее не просто инвентаря, а инвентаря экипируемого. Просьба посмотреть и покритиковать то, что по итогу придумалось. Опирался я на вот эту схему от caseyryan и вообще последние 3 страницы обсуждения в той ветке. Говорю я сейчас исключительно о Модели.

1. Точно выбрал подход с отдельным деревом классов для предметов, где на вершине будет Item, а все остальные - расширяют его. Таким образом, для экипируемых предметов будет подкласс типа Equipment.
2. От исходной идеи сделать разметку точек экипировки персонажа с жёсткой привязкой типа помещаемых туда наследников Item:

// В классе персонажа
private var _pants: Pants; // слот для штанов 
private var _coat: Coat; // слот для курток

пришлось отказаться. Ведь стоит только попытаться надеть комбинезон и всё "ляжет"
3. Вместо этого предусмотреть в каждом предмете класса Equipment вектор идентификаторов мест, куда надевать. Тут будут мои любимые строковые ID. Например: ["head"] для шапок или ["torso", "legs"] для комбинезона.
4. В классе персонажа завести массив или вектор, принимающий наследников Equipment, куда будет помещаться всё "надетое". Метод equip(equipItem: Equipment) будет проверять, нет ли в массиве экземпляров с совпадающими ID и при необходимости удалять имеющиеся.

Вроде всё красиво. Смущает пока только тот факт, что самого перечня доступных точек экипировки (руки/ноги/голова/торс) в таком подходе вообще нигде не зафиксировано. Он по факту будет складываться из суммарного перечня ID "надетых" (т.е. добавленных в массив) шмоток. Нормально ли это? И где мне такой подход может аукнуться?

Буду признателен за комментарии, особенно со стороны игроделов.

[Wolsh]

Мне всё же кажется, что иметь массив "точек" со ссылками на экипированые вещи было бы оптимальней, чем перебирать каждый раз ВСЕ вещи, сравнивая строковые идентификаторы (которые ты конечно забъешь в константы). В таком подходе изначально заложены ненужные действия, типа проверки шапки, уживается ли она с сапогами. Если же будет реестр по "точкам", для экипировки сапог ты будешь проверять только обувь, не дергая 10 раз статические константы в цикле по массиву.
(в TES кстати есть такой класс как мантия с капюшоном, забирающая сразу 3 слота — шапку, куртку и штаны. Кроме того, экипировка делится на Одежду и Броню, что дает более сложные условия, типа если герой наденет хотя бы один предмет из класса Броня — имеющий резист к физическому урону — его способность использовать магию сильно падает, ну и торговцы могут покупать одежду но не броню, или наоборот, или и то и другое).

[Tails]

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

Смущает пока только тот факт, что самого перечня доступных точек экипировки (руки/ноги/голова/торс) в таком подходе вообще нигде не зафиксировано.

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

[Appleman]

Wolsh, мне тоже интуитивно так больше нравится. Но только в голове пока на принципиальном уровне не укладывается. От слова совсем

Мне всё же кажется, что иметь массив "точек" со ссылками на экипированые вещи было бы оптимальней, чем перебирать каждый раз ВСЕ вещи, сравнивая строковые идентификаторы (которые ты конечно забъешь в константы).

Непонятно, в каком виде хранить этот список "точек". Если массив, да ещё и со ссылками, то получается каждая "точка" - это некий самостоятельный объект?

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

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

в TES кстати есть такой класс как мантия с капюшоном, забирающая сразу 3 слота — шапку, куртку и штаны

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

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

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

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

Tails, я это не про диздок, а про код говорил.

[Godwarlock]

Appleman покажешь, что там у тебя за игра такая? Пару скринов хотя бы) Интересно. Можешь в лс даже)

[Appleman]

Godwarlock, интерес бывалых льстит, но показывать пока решительно нечего. Из визуализации только главный экран боя, всякие портреты-шкалы персов, да пара статус-иконок. Я всё пока над игровой логикой карпею.

Wolsh, мне кажется, я начинаю соображать, что ты хочешь мне посоветовать. Смотри, я правильно понимаю, что у персонажа мы делаем вот такие "полиморфные" слоты:

// в классе Character
private var _slotHat: Equipment;
private var _slotTorso: Equipment;

Теперь если мы хотим надеть шляпу, то отбираем все экземпляры наследников Items -> Equipment -> Hat, проверяем, что записано в слоте _slotHat и впихиваем туда ссылку на наш экземпляр шляпы. При этом, если у нас, к примеру, куртка с капюшоном, то она хоть и экземпляр Coat, без проблем "пропишется" сразу в 2 слота, т.к. все они их общего супертипа. Это ты имел в виду? Верно я понял твою идею?

И ещё... Если один и тот же экземпляр может "прописаться" в нескольких слотах, то придется ещё решать проблему расчёта эффектов, получаемых от предметов. Чтобы дважды не посчитать.

[Wolsh]

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

Добавлено через 2 минуты
Про кольца и амулеты не забудь))))

[Appleman]

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

Ну, в Характере у тебя итак целая портянка свойств.

О да! Меня уже самого пугает. Из-за этого уже всю систему статус-эффектов вынес в отдельный статус-менеджер (что кстати уже оправдало себя, так как выяснилось, что статус-эффекты могут действовать не только на персонажей).

Про кольца и амулеты не забудь))))

Слушаюсь, товарищ командир!

У меня ещё тупой вопрос. Не даёт мне покоя потенциальная проблема с двойным счётом эффектов от шмотья, занимающего сразу несколько слотов, которую я выше упомянул (типа куртка с капюшоном "болтается" и в torso, и в head). Как лучше: завести отдельный массив, куда тупо сваливать всё "надетое" и считать суммарный вес/эффекты по нему или заморачиваться с логикой при анализе содержимого слотов?

[DEVORON]

Мне думается, что у персонажа скорее всего 1 голова, две ноги, 2 руки(10 пальцев для колец), 1 туловище. Если это куртка с капюшоном, то она занимает два слота - туловище и голову. Если это кофта/майка/нагрудный доспех - только туловище.
+ несколько слотов под амулеты
+ какой-нибудь пояс для артефактов или что там потребуется.

Предмет сам о себе говорит для каких слотов он предназначается. И при установке уже забиваем слоты предметом. Точнее даже нет никаких слотов. Есть интерфейс - и он будет отрисовывать все шмотьё по своим местам, если внешний вид персонажа, который тоже отрисует все шмотье по свойствам шмотья, есть какой-нибудь менеджер установки шмотья, который сообщит, что невозможно надеть куртку с капюшоном, потому что уже надета шапка и кофта(т.е. для Head и Body/Torso установлено значение true - занято). Не вижу смысла в разных слотах-массивах, если есть предметы с двойными свойствами. Скорее, один массив + булевы значения слотов занятости.

[Wolsh]

Скорее, один массив + булевы значения слотов занятости.

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

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

Не даёт мне покоя потенциальная проблема с двойным счётом эффектов от шмотья

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

Добавлено через 10 минут
При добавлении одёжки-мультислота тоже будет парадокс: типа удалил шляпу и добавил в этот слот мантию с капюшоном. Но она заняла и слот куртки и слот брюк, а тебе надо проверить эти слоты после шляпы, потому что в мантии указаны три занимаемых слота. Ты проверяешь слот куртки и удаляешь мантию))) и добавляешь ее в слот куртки? а потом та же история со слотом штанов. Удаляешь мантию из слота штанов и добавляешь туда мантию. Процессы то не всегда одноточечные, иногда они пошаговые))) Но ты разберешься.