Вопрос по проектированию

[caseyryan]

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

По-моему мы говорим об одном и том же) Просто я не назвал это InventoryCharacterSlot

[Appleman]

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

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

За схему респект, по коду всё понятно, на ус намотал. И да, на свой исходный вопрос твоё видение я получил. Просто из твоего ответа мне показалось, будто бы ты решил, что для каждого предмета я собираюсь делать по классу. Вот применительно к этому я написал о возможном непонимании с твоей стороны. Моя логика была (и пока остаётся), что создавая подклассы к общему классу предметов Items мы удачно разграничивает предметы по типам. И если у нас есть по одному предмету в руку, на голову и на ноги, то соответствующие "слоты" в классе персонажа - это свойства, относящиеся к тому или иному типу, ровно по одному для каждого.

И второй вопрос был в том, что если у нас планируется 5 разных конкретных шапок, то в моём понимании (пока последний пост Wolsh-а не прочитал), для каждой где-то должна фигурировать команда 'имя переменной':ItemHat = new ItemHat. И так 5 раз для наших пяти предметов. Потом для каждого задаём набор свойств. Я спрашивал, где конкретно всё это нужно прописывать. Чтобы в итоге в программе появилось 5 переменных, в каждой из которых содержалось бы по экземпляру класса ItemHat с различным набором свойств. А дальше с ними уже работать.

Или сам подход - ересь?

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

Чёрт, а ведь и правда! Я не думал с этой точки зрения. Даже твои посты читая, лишь с третьего допёр, о чём речь И да, в нынешнем диздоке у всех предметов набор свойств неизменен на всём протяжении игры.

Но всё равно вижу 2 аргумента в пользу классов. Во-первых, наличие класса позволяет заложить основу для более сложного поведения, если по ходу разработки и тестирования будет понимание его необходимости, взять хотя бы тот самый износ предметов, о котором ты писал ранее. В случае с идентификаторам процесс отыгрывания назад может быть очень болезненным. И второе - это гарантия от того, что трусы не будут надеты на голову. Опять же твоя была мысль о предпочтении Strong-типизации, а не String-типизации.

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

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

//... Model / InventoryModel
_inventory.hat = 0xFD3490;
_inventory.boots = 0x5539A2;
_inventory.robe = 0xCA4D23;

Скажи, пожалуйста, какой кайф в такой записи? 0xCA4D23 - ни фига же не понятно, что имеется в виду. Почему не задать какие-то осмысленные идентификаторы? Я ведь правильно понимаю, что эта абракадабра - идентификатор для справочника свойств?

[caseyryan]

Скажи, пожалуйста, какой кайф в такой записи? 0xCA4D23 - ни фига же не понятно, что имеется в виду

Это не абракадабра, а просто шеснадцатеричная запись uint. FlashDevelop генерирует такой шеснадцатеричный код для цвета при нажатии Ctrl + Shift + K

[Appleman]

А какой смысл в этом контексте задавать код для цвета?

[caseyryan]

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

А какой смысл в этом контексте задавать код для цвета?

Просто как пример того, что это разные свойства

[Wolsh]

По-моему мы говорим об одном и том же)

Ну, я подразумевал, что InventoryCharacterSlot это действительно Класс, представляющий ячейку для амуниции героя в окне Инвентаря. То есть там 5 или 6 или больше этих слотов для разных типов амуниции. Вот они действительно должны "уметь что-то делать" — размещать картинку, показывать название и характеристики вещи. Но вот эти самые картинка, название и х-ки вещи вовсе не обязаны быть экземпляром этой самой вещи, они могут храниться в справочниках по идентификатору, который вы обозвали "цветом" ))
Тут в чем красота то... Что во все время игры нет никаких экземпляров трусов и носков, они не жрут где-то в темноте память. Даже если игра с видом не от первого лица и на персонажа надо напялить этот шлем, все-равно он просто картинка (или даже 3D-модель) — это забота Вьюхи, эта картинка НЕ ХРАНИТ каких-то магических свойств этого шлема и его сопротивления помятости — это дело Модели, так что они в принципе не могут быть одним экземпляром. Об этом я спрашивал "что ты видишь когда говоришь об экземпляре".
Тот подход, который выглядывает из-за ваших спин когда вы настаиваете на экземплярах, подразумевает какие-то жуткие вещи: что например если у игрока в рюкзаке валяется 6 кинжалов, 4 книги, 33 бутылки, кусок хлеба, драконий глаз, 4 медвежьих какашки и мельхиоровое колечко, то вся эта гадость должна быть СОЗДАНА в виде экземпляров и жить в памяти весь рантайм, вообще ничего не делая. Кому и зачем это нужно? Я серьезно рекомендую подумать о необходимости такого безобразия.

[Appleman]

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

храниться в справочниках по идентификатору, который вы обозвали "цветом" ))

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

вся эта гадость должна быть СОЗДАНА в виде экземпляров и жить в памяти весь рантайм, вообще ничего не делая. Кому и зачем это нужно? Я серьезно рекомендую подумать о необходимости такого безобразия.

Да уж... Не поспоришь. Тогда по твоей логике выходит, что класс Items таки есть, но как "статичный", где в пачке public static массивов хранятся идентификаторы трусов, носков и медвежьих какашек с набором значений для их свойств. Верно?

[caseyryan]

Тот подход, который выглядывает из-за ваших спин когда вы настаиваете на экземплярах, подразумевает какие-то жуткие вещи: что например если у игрока в рюкзаке валяется 6 кинжалов, 4 книги, 33 бутылки, кусок хлеба, драконий глаз, 4 медвежьих какашки и мельхиоровое колечко, то вся эта гадость должна быть СОЗДАНА в виде экземпляров и жить в памяти весь рантайм, вообще ничего не делая. Кому и зачем это нужно? Я серьезно рекомендую подумать о необходимости такого безобразия.

Разница между твоим подходом и подходом с хранением всего в экземплярах только в расходе памяти на этот самый экземпляр-обертку, который отжирает небольшие крохи. Сами картинки/модели все равно должны храниться в памяти. Когда игрок заходит в магазин, он должен сразу увидеть все эти вьюхи. И их там будет не 5 или 6, а все доступные. Ощущение от игры резко портится, если все необходимые вьюхи в магазине начинают подргужаться по нажатию кнопки. Это то место, где все должно работать плавно и красиво, так что тут на памяти не сэкономишь. Поэтому я не вижу смысла хранить все раздельно и каждый раз запрашивать по ID нужную картинку или модель в одном месте, текст с описанием в другом, а параметры в третьем, когда всё это легко передается одному экземпляру и сам Item представляет из себя некое подобие копмозиции.
Ещё один момент почему все экземпляры должны храниться в памяти - это то, что в многопользовательской игре, к примеру, невозможно предусмотреть какой экземпляр оружия или амуниции будут использовать другие игроки и при необходимости на их аватаров нужно тоже это все одеть сразу и без задержек, опять же, в угоду этим самым положительным ощущением от игры

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

[Wolsh]

Ощущение от игры резко портится, если все необходимые вьюхи в магазине начинают подргужаться по нажатию кнопки.

Ни слова не было о подгрузке. Естественно, все изображения в памяти, мы же (или только я?) предполагаем что они внедрены в swf, "заэмбжены" и рассортированы. Конечно, битмапдата лежит себе в памяти и экземпляры, ссылаясь на нее, не отжирают каждый память под битмапдату. Но вот остальные свойства, выражаемые в подавляющем большинстве своем числами и текстом, у каждого экземпляра будут индивидуальной копией, заполненной из той самой таблицы о которой говорил я, и при том у всех одинаковой. И тут я вспоминаю, как из одной пещеры в Скайриме вынес 360 "яиц коруса" (такое насекомое). И как только в одном из трех моих домов, только в одном из сундуков в алхимической лаборатории, у меня десятки наименований ингредиентов хранились в количествах, измеряемый в К: 1К, 5К и тп. То есть ТЫСЯЧАМИ "экземпляров". Я понимаю, что не в каждой игре такие возможности для стяжательства)))) Я вообще никогда не настаиваю на окончательной правоте "только так и никак иначе". Я просто хочу показать что есть и альтернативные способы, не всегда стоит доверять решению "в лоб". В том же Скайриме, в той же алхимии, сочетаются оба подхода. Есть ингредиенты: всевозможные субстанции, которые можно как покупать в алхимических лавках, так и собирать с растений, трупов животных и тп. У каждого ингредиента есть 4 эффекта (изначально игрок не знает ни одного и вынужден смешивать их вслепую, набираясь опыта). Чтобы получилось зелье, необходимо смешать 2 или 3 ингредиента; при этом какие-то их эффекты должны совпасть — тогда они проявятся у полученного зелья, а игрок получит новую запись в свою "книгу рецептов". Эффектов довольно много, поэтому ингредиенты весьма редко совпадают "методом тыка". Но речь не об этом) У зелья, которое будет создано, эффект будет иметь некое числовое выражение силы: время действия и мощность, например "снижение магии цели на 100 единиц на 43 секунды". Эта сила зависит от навыка Алхимия персонажа, и меняется буквально в процессе "химиченья".
Итак, получается что ингредиенты не имеют никаких уникальных для каждого "кусочка" свойств: есть только 4 эффекта, полностью одинаковые для любого "экземпляра" данного ингредиента. Выходит, что экземпляры здесь явно избыточны.
Зелья наоборот имеют индивидуальные характеристики силы, и без экземпляров здесь не очень то обойдешься (тем более что они существуют не только в инвентаре персонажа, их можно продать и несколько дней спустя увидеть в ассортименте магазина в том же состоянии). Теоретически, это конечно тоже можно решить "записями в индивидуальной табличке инвентаря", без экземпляров. А вот такое действо, как "выбросить" из инвентаря на землю и, вернувшись через пару дней, подобрать бутылку с тем же самым зельем — тут уже возникают вопросы "как".

[caseyryan]

Не знаю как в скайриме, не играл, но если бы я делал подобную систему, то все равно использовал бы экземпляры, ибо не вижу технической разницы между зельями, которых может быть тысячами или какими-то предметами надеваемыми на игрока в единственном экземпляре. У экземпляра просто может быть свойство quantity, в которое и будет записываться количество, которое есть у игрока. И по факту экземпляр всё равно будет один, но игрок будет думать, что их много. А при необходимости можно создать другой экземпляр и указать другое количество. Можно то же самое на примере патронов рассмотреть. Купил игрок 200 патронов для автомата, но это же не значит, что тут же создалось 200 экземпляров патрона. Нет, экземпляр "Патрон" так и будет один в магазине, но quantity будет 200.
С "оберткой" всегда удобнее работать, чем с записями в отдельно. Обертку создал и забыл, никаких заморочек. А запрашивать каждое свойство отдельно очень неудобно