Инвентарь

[rdr144]

Здравствуйте. Хочу реализовать простейший инвентарь, допустим просто в виде списка предметов, но не могу придумать как сделать например стак одинаковых предметов, или как этим предметам между собой взаимодействовать. Хотел чтобы предметы можно было подбирать, выбрасывать, использовать их и тд, но прикинул, получается какой то совсем уж запутанный код, с кучей перекрестных ссылок и вообще трудночитаемый. В общем, если есть у кого то ссылки на примеры игровых инвентарей, или хотя бы схематически объясните как это делается, помогите чем сможете. И тут же, дабы не плодить темы, теоретический вопрос, что с точки зрения ООП лучше и "правильнее", много классов с небольшим количеством кода или один класс с большим количеством?

[MikroAcse]

Сначала изучите основы. Ответ придёт к Вам сам.

[Akopalipsis]

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

[Wolsh]

Задавая такой вопрос, Вы очевидно предполагаете, что все игры делаются одинаково, предметы в них представлены одинаковым образом и архитектура практически идентична. Иначе мы должны быть телепатами, чтобы знать Вашу архитектуру и хотя бы концепцию "предмет" в этой архитектуре. Начнем с простого: у Вас MVC? С чем проблема — с Моделью инвентаря, логикой, или с его Видом? Сам вопрос какой-то ни о чем: инвентарь и есть просто список предметов, обычный массив/вектор. "предметы можно подбирать" это "добавить в массив", "выбрасывать" это "удалить из массива", "использовать" это вызвать метод use(), "взаимодействовать" это вызвать метод combine() и передать ему два "ингредиента".
Какой вопрос, такой ответ, уж извините. Я видел не так уж много игр, десятка два, и не могу вспомнить двух одинаковых инвентарей.
По второму вопросу — один класс это как бы вообще не ООП. Суть ООП как раз в умении абстрагировать, то есть делить всю кучу на отдельные Объекты (классы), каждый из которых несет одну определенную ответственность. Много классов — хорошо, но все должно быть в меру. Необязательно заводить отдельный класс для "верхней однопиксельной полоски в рамочке текстового поля", а иногда очень глупо выглядят любимые многими собственные "разработки" специальных классов-загрузчиков типа ImageLoader или XMLLoader. Надо хорошо представлять, что могут "родные" классы и где абсолютно не нужны бессмысленные самописные обёртки.

Почитать: SOLID

[Babylon]

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

[expl]

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

Бывает 2 типа предметов:

1. предметы, определяющиеся только их типом и не хранящие временных параметров
Т.е. либо есть предмет "Меч типа sword_01", либо нет, никаких потёртостей, повреждений, ничего у него нет. Т.е. если вручили его персонажу, то он не меняется, его можно только выкинуть
Такие объекты можно "стековать" прямо внутри инвентаря.

Параметры такого меча обычно описываются в справочнике и он идентифицируется только типом "sword_01" - т.е. нельзя получить 2 разных объекта спросив меч типа "sword_01".

Поэтому при добавлении в инвентарь достаточно сравнить тип и увеличить счетчик, если меч уже лежал

2. Предметы, у которых что-то меняется, например портятся со временем
Их внутри инвентаря "стековать" нельзя, надо просто хранить каждый отдельно - а то чудеса начнутся: "Я положил в инвентарь целый меч, а получилось 2 поломанных"

Но! Геймдиз вас обязательно попросит отобразить их как будто они "стекуются" в окне инвентаря или ещё где-нибудь.
Для этого в InventoryWindow, а не в Iventory, берёте и перебираете все "нестекующиеся" предметы, кладя в слоты соотвествующего типа(эти слоты принадлежат только окну) и считая количество предметов одинакового типа.
А то, что лежит в Inventory при этом не правите.

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

И тут же, дабы не плодить темы, теоретический вопрос, что с точки зрения ООП лучше и "правильнее", много классов с небольшим количеством кода или один класс с большим количеством?

Хорошо что вы понимаете, что слово "правильнее" надо брать в кавычки
На моей сугубо субъективной практике:
- Класс размером более 500 строчек становится сложнее править
- Чем меньше классов - тем лучше

[rdr144]

Спасибо большое всем за ответы) Основы то я знаю, просто практики не хватает. expl, вот это как раз то, что нужно)