BeaRLibItems - удобный менеджмент предметов в рогалике

Форум библиотеки BeaRLib

Модератор: Apromix

Аватара пользователя
kipar
Сообщения: 2081
Зарегистрирован: 10 мар 2010, 13:16
Откуда: Москва

Re: BeaRLibInv - инвентарь и "кукла" персонажа

Сообщение kipar » 12 фев 2017, 17:12

altmax писал(а):
12 фев 2017, 14:44
Идеально конечно бы подошла sql база данных, но в данном случае это больше похоже на забивание гвоздей микроскопом. Хотя если предметов в игре прямо ну очень много, плюс у них бывают разные характеристики, возможны улучшения, крафт, разборка на составные части - возможно посмотреть и в сторону базы данных.. С базой данных вообще было бы удобно работать - выбрал из ней все предметы, относящиеся к броне уровней например 5-8 и несколько случайных предметов из выборки раскидал по уровню. А из массива придется методом перебора выбирать различные группы элементов.
Как раз в этом случае будет не очень удобно. для базовых предметов допустим всё просто - поля известны, таблица готова. Ну или несколько таблиц, если у оружия 3 параметра, а у брони 7. А если урон генерится из некоторого диапазона, улучшения могут иметь разное 2-3 случайных параметра, а могут давать принципиально новое свойство, а могут блокировать переменное число других улучшений, крафт влияет на разные характеристики, то во-первых нет никакого "набора всех вещей", каждая вещь генерится алгоритмом, соответственно от выборок не будет никакого толку, всё равно любая работа будет только с индивидуальным предметом. А во-вторых каждый предмет окажется размыт по куче таблиц(для базовых вещей, для улучшений, для связи одного с другим, для влияния крафта), для создания и удаления будет модифицироваться каждая из этих таблиц, в итоге скорее всего даже по производительности будет проигрыш.
Ну и удобство вообще отдельный вопрос. Конечно хорошая ORM обертка может приблизить удобство работы с бд к работе с обычными полями, но то что эти ORM вообще существуют намекает что изначально работа с бд все-таки сложнее и неудобнее, да и с ORM все равно будут моменты когда надо учитывать структуру таблиц.
И да, свою перв вторую игру я на базе данных делал. Потому что в книжке по дельфи как работать с бд хорошо объяснялось, а как читать бинарные файлы - не очень. Ну и редактор данных изкаробки. И в принципе да, работало. Но в целом по-моему это остается "микроскопом по гвоздям", в сложной игре система предметов усложняется не в ту сторону для которой базы данных удобны.

Аватара пользователя
Apromix
Мастер
Сообщения: 1092
Зарегистрирован: 04 июл 2011, 10:44
Откуда: Украина, Черновцы
Контактная информация:

Re: BeaRLibInv - инвентарь и "кукла" персонажа

Сообщение Apromix » 12 фев 2017, 17:43

altmax писал(а):
12 фев 2017, 14:44
То что лежит на полу - оно как бы относится больше к карте уровня, т.е. на каждом тайле есть, список, где храним лежащие там предметы. Если ничего нет, то он просто пустой, но он есть в структуре, описывающей тайл. Храним только id вещи.
Есть второй метод, когда один список для предметов на карте (на полу, в сундуках и т.д.). Удобно сохранять и загружать только один список. Чтобы узнать, что находится в конкретном тайле [X][Y], просто пробегаемя по списку и выбираем предметы с координатами X Y тайла.
Идеально конечно бы подошла sql база данных...
База хорошо, но нужен способ попроще.
Изображение Изображение

Аватара пользователя
Oreyn
Сообщения: 297
Зарегистрирован: 07 авг 2013, 14:59

Re: BeaRLibInv - инвентарь и "кукла" персонажа

Сообщение Oreyn » 12 фев 2017, 18:29

Apromix писал(а):
12 фев 2017, 17:43
Есть второй метод, когда один список для предметов на карте (на полу, в сундуках и т.д.). Удобно сохранять и загружать только один список. Чтобы узнать, что находится в конкретном тайле [X][Y], просто пробегаемя по списку и выбираем предметы с координатами X Y тайла.
Идеально конечно бы подошла sql база данных...
База хорошо, но нужен способ попроще.
Предметы ссыпаные на один тайл и в инвентаре игрока/моба ведут себя одинаково в вопросе складывания в стаки, или ведения перечня предметов. Так что я встраивал в каждый тайл возможность создать там инвентарь и хранить его по ссылке, даже если предмет выброшен только один.
Также при реализации отталкивался от возможных запросов к поиску по предметам на карте.
Их в общий чертах два: что за предметы лежат в клетке Х У? и найти предмет по критерию из всех предметов, что лежат на всех клетках карты.
Для оптимизации этих запросов карта хранит ссылку на инвентарь лежащих предметов в структуре каждого тайла. Что дает возможность быстро обратиться по Х У.
И, дублирует ссылку на инвентари с больше чем 0 предметов во внутреннем общем списке. По которому и ищет перебором, если нужно найти предмет по свойству, а не по координатам.
Добавление/удаление предметов на карту возможно только через единые точки входа (функции), которые и контролируют чтобы информация конкретно велась и в тайлах и в общем списке.
По сути точно так же нужно хранить и мобов, и другие сущности на карте.

Это внутренняя кухня поиска карты. Дальше можно еще более изощрятся с типа оптимизацией. Если ты по карте ищещь ближайшую от заданной координаты Х У сущность в радиусе Н клеток. Ты выбираешь - по карте или по списку искать, проверяя что больше Н^2 или длинна списка.

Зачем вам база? Чтобы она запросом c WHERE выдавала результат быстрее чем перебор, там нужно в индексы упарываться. Да и сколько там предметов на карте? Ну сотня. Это же пшик. Было бы их 5000 я бы может сказал - база. Не трогайте карьерный катерпиллер чтобы окопать клумбу.

Аватара пользователя
Apromix
Мастер
Сообщения: 1092
Зарегистрирован: 04 июл 2011, 10:44
Откуда: Украина, Черновцы
Контактная информация:

Re: BeaRLibInv - инвентарь и "кукла" персонажа

Сообщение Apromix » 12 фев 2017, 19:51

По предметам на земле такие функции:

Код: Выделить всё

type
  TItem = record
    ID, X, Y: Word;
  end;

type
  TItems = array of TItem;

function Ground_Clear(): Boolean;
function Ground_Count(): Integer;
function Ground_Count_InTile(AX, AY: Word): Integer;
function Ground_Items(): TItems;
function Ground_Items_InTile(AX, AY: Word): TItems;
function Ground_Items_Append(AItem: TItem): Boolean;
Как видно из record одним ID не отделаться :) Каких методов работы с предметами на земле не хватает?
Изображение Изображение

Аватара пользователя
kipar
Сообщения: 2081
Зарегистрирован: 10 мар 2010, 13:16
Откуда: Москва

Re: BeaRLibInv - инвентарь и "кукла" персонажа

Сообщение kipar » 12 фев 2017, 20:22

Если использовать в интерфейсе библиотеки открытый массив (который array of TItem без указания длины), то ниоткуда кроме паскаля ее использовать будет нельзя. Поэтому отдельно функция возвращающая число (уже есть) и отдельно - возвращающая элемент по индексу.

Еще не хватает удаления предмета из клетки (видимо по индексу). И очистки клетки.
Ну и передавать во все функции "ид_карты", чтобы можно было сделать несколько уровней на которых лежат предметы. Хотя если там внутри x и y не ограничены то можно просто в пространстве уровне разделить (в смысле x = Nуровня*1000+x), но это не так удобно.

Аватара пользователя
Apromix
Мастер
Сообщения: 1092
Зарегистрирован: 04 июл 2011, 10:44
Откуда: Украина, Черновцы
Контактная информация:

Re: BeaRLibInv - инвентарь и "кукла" персонажа

Сообщение Apromix » 13 фев 2017, 17:50

Залил версию 0.1 на гитхаб: https://github.com/bearlib/inv

В папке Demo программа, демонстр. работу библиотеки.
Изображение Изображение

Аватара пользователя
Cfyz
Сообщения: 760
Зарегистрирован: 30 ноя 2006, 10:03
Откуда: Санкт-Петербург
Контактная информация:

Re: BeaRLibInv - инвентарь и "кукла" персонажа

Сообщение Cfyz » 13 фев 2017, 19:13

Я сейчас мысль выскажу, только вы не обижайтесь =|.

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

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

А вот с инвентарем по-моему не так, потому что система менеджмента предметов занимает близкое к центральному место в архитектуре приложения и в механике игры. Для сколь-нибудь сложных сценариев внешняя схема скорее всего станет инородным телом.

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

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

Аватара пользователя
Apromix
Мастер
Сообщения: 1092
Зарегистрирован: 04 июл 2011, 10:44
Откуда: Украина, Черновцы
Контактная информация:

Re: BeaRLibInv - инвентарь и "кукла" персонажа

Сообщение Apromix » 13 фев 2017, 19:53

И соглашусь, и не соглашусь :D
Скрытый текст: ПОКАЗАТЬ
Велосипеды я изобретать умею, правда как они катаются мне не слишком интерессно после, ну да лано :)

После того как БрэйкМиТандер показал на гуглмаркете свою игрушку про зомби (недавно же было), я наконец взял волю в кулак и поинтересовался, что же это такое гейммейкер 8 (не студия который). Я и раньше пробовал его скачать и поглядеть, но что-то вечно мешало. Все оказалось настолько просто, что я быстренько все разобрав, и поняв, насколько узко в этой норе, заинтересовался написанием расширений для него, которые плагины. Для начала я начал искать, что уже написано. И скажу я вам написано много, причем там люди не стеснялись изобретать велосипеды, разные, часто повторяя друг друга, часто шагая напролом. Просматривая очередную поделку (плагин), меня не покидало чувство "а нафига? вот нафига такое делать?" Но все равно было интерессно поглядеть, потрогать руками, понять логику. Видимо такая там комюнити :D

Это я веду к тому, что мы не хуже, что попытаться сделать стоит. Что-то же должно получиться. Даже если не взлетит :D
Конкретно по кирпичику Inv. С самого начала я понял, что реализация инвентаря, чтобы он получился универсальным, должна быть более абстрактной. Только так. Дальше уже разработчик дописывает вывод на сцену списков, котрые он получил из библиотеки, сортирует их как ему хочется и т.д. Можно сказать, что это сырой кирпичик, которому еще нужно придать нужную форму и затем использовать в своей игре.
Изображение Изображение

Аватара пользователя
kipar
Сообщения: 2081
Зарегистрирован: 10 мар 2010, 13:16
Откуда: Москва

Re: BeaRLibInv - инвентарь и "кукла" персонажа

Сообщение kipar » 13 фев 2017, 21:28

Но это оказалось неудобным, так как в итоге приходилось держать две копии данных, в удобном приложению формате и в формате объекта-карты для FOV, постоянно перенося флаги туда и обратно.
Не знаю что там у вас неудобно, у нас всё работает! Можно хранить даные в map и просто обернуть map_get\set чтоб выглядело как будто данные класса читаешь.
Хотя для чего-то более серьезного чем 7drl возможно придется вытаскивать флаги и хранить у себя, но тоже особой проблемы не вижу - после генерации вытащил данные, для fov\pf пару флагов оставил и обновляешь. В общем какую-то свободу отнимает у разработчика это конечно отнимает, но всегда есть альтернтивный механизм каллбаков для искушенных, а кого-то и в таком виде устроит.
С Inv теоретически должно быть также, кто хочет - использует библиотечную систему хранения, кому не нравится - организует свою у себя. Но в случае карты польза от библиотеки ясна - генерация уровней, фов, поиск пути, освещение. А в случае с inv я таких аргументов не вижу.

Аватара пользователя
Cfyz
Сообщения: 760
Зарегистрирован: 30 ноя 2006, 10:03
Откуда: Санкт-Петербург
Контактная информация:

Re: BeaRLibInv - инвентарь и "кукла" персонажа

Сообщение Cfyz » 14 фев 2017, 01:00

Apromix писал(а):люди не стеснялись изобретать велосипеды, разные, часто повторяя друг друга, часто шагая напролом. Просматривая очередную поделку (плагин), меня не покидало чувство "а нафига? вот нафига такое делать?" <...> Это я веду к тому, что мы не хуже, что попытаться сделать стоит. Что-то же должно получиться.
Может быть тогда бóльшую пользу принесет не конкретная реализация, а стоящая за ней теория? Что за инвентарь и какой он бывает (бесконечный, конечный по количеству, конечный по весу, может даже вариант с многоклеточными предметами a la Diablo), какие нюансы встречаются (группировка, сортировка, добавление-удаление с сохранием позиции-шортката, вложенные инвентари), хитрости всякие (реиспользование объекта-инвентаря для хранения предметов в клетке карты и в сундуках), примеры реализации на популярных языках с иллюстрациями.
Apromix писал(а):реализация инвентаря, чтобы он получился универсальным, должна быть более абстрактной. Только так. Дальше уже разработчик дописывает вывод на сцену списков, котрые он получил из библиотеки, сортирует их как ему хочется и т.д.
Вот собственно о чем я и говорю, разработчику все равно придется писать работу с предметами — вывод, сортировка, обработка всяких эффектов-статусов. Для этого придется держать это все в приложении, как ни крути. В обычных массивах и списках, то есть все уже под рукой. Так что же именно будет делать библиотека? Должна же быть какая-то конкретная цель.

kipar писал(а):Можно хранить даные в map и просто обернуть map_get\set чтоб выглядело как будто данные класса читаешь. <...> возможно придется вытаскивать флаги и хранить у себя, но тоже особой проблемы не вижу - после генерации вытащил данные, для fov\pf пару флагов оставил и обновляешь.
Там два момента:

1. Обращение к полям через границу .dll — это медленно даже в C, а в случае с некоторыми языками типа Python — очень медленно. Это допустимо для разовых операций типа упомянутой выгрузки сгенерированной карты, но для расчета кучи LOS или динамического освещения — жирновато будет. Гипотетически есть способ сделать доступ без накладных расходов, но он потребует сильного колдунства и толстого слоя оберток.
2. Постоянные сбросы-обновления всего часто оказываются просто излишни, потому что те же флаги можно хранить в основной карте и читать-заполнять в коллбеках. При этом альтернативные варианты взаимодействия (коллбеки, списки точек) еще и трогают только необходимые данные, не нужно заполнять все впрок, мало ли потребуется.

То есть в качестве центрального хранилища оно не подходит, хотя для передачи данных между частями — еще куда ни шло. Как минимум, может выступать в роли клея для генератора уровней, все лучше чем ничего. Еще наверное можно использовать для более частных вариантов алгоритмов с разовым возвратом кучи результатов, скажем если сделать расчет и суммирование освещения на всем уровне за один библиотечный вызов.
Cfyz теперь - наглая морда.

Аватара пользователя
kipar
Сообщения: 2081
Зарегистрирован: 10 мар 2010, 13:16
Откуда: Москва

Re: BeaRLibInv - инвентарь и "кукла" персонажа

Сообщение kipar » 14 фев 2017, 08:39

Cfyz писал(а):
14 фев 2017, 01:00
1. Обращение к полям через границу .dll — это медленно даже в C, а в случае с некоторыми языками типа Python — очень медленно. Это допустимо для разовых операций типа упомянутой выгрузки сгенерированной карты, но для расчета кучи LOS или динамического освещения — жирновато будет. Гипотетически есть способ сделать доступ без накладных расходов, но он потребует сильного колдунства и толстого слоя оберток.
2. Постоянные сбросы-обновления всего часто оказываются просто излишни, потому что те же флаги можно хранить в основной карте и читать-заполнять в коллбеках. При этом альтернативные варианты взаимодействия (коллбеки, списки точек) еще и трогают только необходимые данные, не нужно заполнять все впрок, мало ли потребуется.
Так и не надо всё время обращаться. Если хранить информацию только в карте bearlibmap, los c освещением рассчитывать средствами библиотеки(которая должна работать с bearlibmap напрямую а не через get\set), то пользователю потребуется вытаскивать оттуда информацию только для вывода на экран (примерно 80*25 раз за кадр), ну и для разных проверок того что под курсором\прямо по ходу игрока. И сбрасывать\обновлять надо только если карта динамически меняется, это нечасто происходит и вообще не во всех играх есть.

Аватара пользователя
Apromix
Мастер
Сообщения: 1092
Зарегистрирован: 04 июл 2011, 10:44
Откуда: Украина, Черновцы
Контактная информация:

Re: BeaRLibInv - инвентарь и "кукла" персонажа

Сообщение Apromix » 14 фев 2017, 12:27

kipar писал(а):
12 фев 2017, 20:22
Ну и передавать во все функции "ид_карты", чтобы можно было сделать несколько уровней на которых лежат предметы.
А что лучше будет? Передавать в каждую функцию ID карты. Или с помощью отдельной функции устанавливать текущий ID карты, с которым будут работать все функции, и тогда его не нужно передавать функциям?
Изображение Изображение

Аватара пользователя
kipar
Сообщения: 2081
Зарегистрирован: 10 мар 2010, 13:16
Откуда: Москва

Re: BeaRLibInv - инвентарь и "кукла" персонажа

Сообщение kipar » 14 фев 2017, 13:16

везде передавать ид карты. Иначе если придется работать одновременно с несколькими картами то надо будет устанавливать перед каждым вызовом. А в многоточном приложении еще и какую-то защиту городить. Уж лучше передавать лишний параметр там где несколько карт не нужны.

Аватара пользователя
Apromix
Мастер
Сообщения: 1092
Зарегистрирован: 04 июл 2011, 10:44
Откуда: Украина, Черновцы
Контактная информация:

Re: BeaRLibInv - инвентарь и "кукла" персонажа

Сообщение Apromix » 16 фев 2017, 09:42

Возникло море вопросов. Часть из них решил. Но вот не понятно:
  • Поскольку либа работает не только с инвентарем, как задумывалось сначала, надо ли ее переименовывать в BeaRLibItems? Ведь как вы лодку назовете, так она и ... :D
  • Нужна ли UTF-8? Либа работает с только с числами.
  • Нужна ли поддержка FreePascal'я?
  • Для последующих биндингов на другие языки как называть функции(регистр и тд.) и типы (с T или без)?
  • Нужно ли вводить по аналогии с предметами на карте в разных уровнях тоже для инвентаря персонажа? К примеру в партийном рогалике может быть несколько членов партии и у каждого может быть инвентарь.
  • Инвентарь для NPC? На ум пока приходят только NPC-торговцы, но мало ли для чего может сгодиться.
  • Какая лучше лицензия? Как лучше оформить? Можно как cfyz в терминале (в сорцовых файлах, нарпимер, биндинг для паскаля)?
Изображение Изображение

Аватара пользователя
Cfyz
Сообщения: 760
Зарегистрирован: 30 ноя 2006, 10:03
Откуда: Санкт-Петербург
Контактная информация:

Re: BeaRLibInv - инвентарь и "кукла" персонажа

Сообщение Cfyz » 16 фев 2017, 11:53

Apromix писал(а):Нужна ли поддержка FreePascal'я?
Есть у меня предположение, что разработку вам вообще надо вести во FreePascal, периодически проверяя на совместимость с Delphi. Потому что кросс-компиляция. Ну и конечно
Apromix писал(а):Delphi 7 does not support UTF-8.
это довольно печально.
Apromix писал(а):Для последующих биндингов на другие языки как называть функции(регистр и тд.) и типы (с T или без)?
Использование из других языков -- это целая проблема. Если вы хотите работать хотя бы с одним языком кроме исходного, забудьте о возврате структур из функций. Даже передача структур в функцию это боль, но ее хотя бы можно заставить работать. Возврат не будет работать никогда, только скаляры или указатели -- но возврат объектов по указателю это тоже боль.

Думаете я просто так использую строки в терминале для передачи-получения параметров? =)
Apromix писал(а):Нужно ли вводить по аналогии с предметами на карте в разных уровнях тоже для инвентаря персонажа?
Apromix писал(а):Инвентарь для NPC?
Видите, правильно заданный вопрос уже половина ответа. =)
Cfyz теперь - наглая морда.

Ответить

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 2 гостя