Страница 5 из 6

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

Добавлено: 21 фев 2017, 09:49
Apromix
Cfyz писал(а):
20 фев 2017, 17:01
Какова цель библиотеки, какие конкретно задачи она призвана решить?
Сделать менеджмент предметов и игре более удобноиспользуемым/удобновстраиваемым и тд.
Cfyz писал(а):
20 фев 2017, 17:01
Еще раз акцентирую внимание, что с высокой долей вероятности это тупиковый путь. Любая, хотя бы чуточку не укладывающаяся в систему идея или механика все ломает. Потому что никто не будет держать половину свойств предметов в приложении, а половину -- в библиотеке. И если данные уже есть в приложении, то зачем их дублировать куда-то еще? Завести и использовать поле в классе предмета проще и производительнее, чем записывать-парсить данные через посторонний API.
Пока я иду по сценарию добавления новых необходимых полей TItem (как описанный више пример с прочностью предмета durability).
Cfyz писал(а):
20 фев 2017, 17:01
Если некоторый менеджер предметов сможет взять на себя работу по хранению, структуризации (группировка и сортировка), разнообразному представлению (списком, деревом, графом), обработке (получению за один вызов общего веса, суммарных модификаторов защиты/атаки/etc., списка аур надетых предметов, да чего угодно), интеграцию с картой (дропнуть/поднять/бросить), сериализацию и десериализацию...
Примерно так я его в идеале и представляю.

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

Добавлено: 21 фев 2017, 11:15
Cfyz
Apromix писал(а):Сделать менеджмент предметов и игре более удобноиспользуемым/удобновстраиваемым и тд.
Давайте будем честными, это настолько общие слова, что они не дают ни малейшего представления. Я же не просто так жира ради спрашиваю, прямой ответ на этот вопрос -- это уже шаг в сторону ТЗ. Это хоть какая-то формализация требований исходя из которых уже можно пытаться проектировать систему. "Более удобноиспользуемым" чем что? Чем более удобно? Это не такая завуалированная издевка, ведь именно эту разницу и нужно будет реализовывать. Вот например...
Apromix писал(а):Пока я иду по сценарию добавления новых необходимых полей TItem
А что будет, если необходимого поля в библиотеке не окажется? Если предполагается заносить их в некие нестрогие Options, то зачем тогда остальные поля? Если Options не предполагает всей функциональности (например, не посчитать сумму), то что делать если поля нет, а функциональность все равно нужна?

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

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

Добавлено: 21 фев 2017, 18:46
Apromix
Я согласен со всем вышеописанным :)

Чем проще получится библиотека, тем она окажется удобней. Так я думал раньше. Теперь я не уверен, что API библиотеки будет простой. По ходу разработки некоторые моменты приходится заносить в структуру TItem. Они могут содержаться и в (виртуальной?) текстовой переменной Options, но как оказалось, их присутствие в TItem намного удобней. Неожиданно :) С этим приходится мириться. Насколько показывает мой опыт это лучший способ решать абстрактные задачки. Тем более ТЗ не был составлен изначально, врядли он будет и дальше, просто я делаю либу более спонтанно, пытаюсь рвануть с разбегу, безо всяких там ООП и тд. Просто.
Cfyz писал(а):
21 фев 2017, 11:15
что делать если поля нет, а функциональность все равно нужна?
Сложный вопрос (если я правильно понял вопрос). На ум приходят плагины с нужным функционалом к библиотеке. Но это будет слишком :D Остается только или не пользоваться либой, или взять ее код и допилить что нужно (на это я расчитываю в будущем, всех берлиб, а не конкретно Items).

Options (или как там еще можно обозвать эту строку) дана на откуп пользователю. Может использовать, или нет. Вот в это поле можно впихнуть любую абстракцию, какую конечно невозможно предугадать в процессе разработки библиотеки. Да и зачем знать, для чего именно будет использовать это поле предмета автор рогалика?

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

Добавлено: 27 фев 2017, 19:39
Apromix
Сегодня полностью доделал стекинг для предметов. Для этого нужно указать для предмета поле Stack - макс. число предметов в пачке. Затем количество - Amount. Если вдруг предметов будет больше Stack, автоматически разобъется на нужное число стеков.

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

Добавлено: 28 фев 2017, 14:48
Apromix
Версия 0.3. В основном добавлен стекинг вещей. Дальше в планах вес, объем и прочность.

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

Добавлено: 28 фев 2017, 16:15
Apromix
Не скачался у меня MinGW :oops: Поэтому вторым языком я решил сделать C#. Начал писать биндинг (как пример взял соотв. биндинг с терминала), но опять же наткнулся на динамические массивы. Как их реализовать в C#?

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

Добавлено: 28 фев 2017, 17:38
karagy
Apromix писал(а):
28 фев 2017, 16:15
Не скачался у меня MinGW :oops: Поэтому вторым языком я решил сделать C#. Начал писать биндинг (как пример взял соотв. биндинг с терминала), но опять же наткнулся на динамические массивы. Как их реализовать в C#?
А что ты разумеешь под "динамическими массивами"? В дельфе (не в семёрке, посвежее) - это просто массив размещаемый в памяти-куче и с ARC. И всё. Перед использованием ему надо делать SetLenght(array, len). По окончании использования - SetLength(array, 0). И он совсем не умеет сам увеличиваться по мере заполнения. Для него нет COW, в отличие от строк. Т.е. если тебе понадобится копия массива - придется явно вызвать функцию array1 := Copy(array2). Динамическим его назвали в дельфе именно из-за ARC.

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

Добавлено: 28 фев 2017, 18:01
Apromix
Спасибо! Да, это логично, что нету никаких динамических массивов, они так называются только в паскале.

Меня больше интересует, как изменить паскалевский код библиотеки, чтобы было удобно делать биндинги на другие языки. В данном случае C#.

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

Добавлено: 28 фев 2017, 18:09
karagy
karagy писал(а):
28 фев 2017, 17:38
А что ты разумеешь под "динамическими массивами"?
Apromix писал(а):
28 фев 2017, 18:01
Спасибо! Да, это логично, что нету никаких динамических массивов, они так называются только в паскале.
Ты так и не ответил на вопрос.
Вообще-то есть всё в современных языках (и в паскакале тоже). Но что-бы найти нужное - надо знать что ты имеешь ввиду.

Я долго не втыкал - зачем в дельфе динаррэи, пока не увидел пример:
TStringHelper.Split
Там ты объявляешь динаррэй строк (фактически массив ссылок на строки, но так как строки c ARC + COW, то все живут комфортно), дергаеш сплит, который сам родит массив, заполнит результатом и вернет ссылку на него. По необходимости - используешь этот массив строк в этой функции. Потчищать не надо. По завершении области видимости ARC сам его грохнет (если, конечно, ты явно не удержишь ссылку на него где-нибудь). И всё. Дёшево и сердито.

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

Добавлено: 28 фев 2017, 18:20
Apromix
Вот мой ответ на вопрос)))

Как дельфист может воспринимать "динамический" массив? Точно так, как он реализован в самой дельфи :)

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

Добавлено: 28 фев 2017, 18:29
karagy
Тут можно глянуть на нутро динарреев и строк (современные дельфи) Internal_Data_Formats .
Строка - моё почтение! Cовместимость с ASCII-Z, совместимость со старыми короткими строками из турбо-паскакаля.

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

Добавлено: 01 мар 2017, 05:58
kipar
karagy писал(а):
28 фев 2017, 17:38
И он совсем не умеет сам увеличиваться по мере заполнения.
Сам может и не умеет (а кто умеет), но можно делать setlength увеличивая и уменьшая его, при этом значения элементов сохраняются. Получается аналог TList/vector, но с ARC.

А из длл да, никак не передать. Обычно библиотеки одной функцией возвращают число элементов, а второй - i-й элемент. Код на C# будет либо создавать список (List) и заполнять его с помощью этих двух функций, либо каждый раз вызывать эти функции когда нужен доступ к элементам.

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

Добавлено: 01 мар 2017, 06:13
Apromix
Мне предложили переделать либу, чтобы она оперировала строкой, в которую передавать json/получать json. Стоит за это браться?

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

Добавлено: 01 мар 2017, 07:29
Apromix
Насчет прочности у предметов. Логика мне подсказывает, что у стаковых предметов (монеты, стрелы, зелья) не может быть прочности. Или я не прав?

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

Добавлено: 01 мар 2017, 07:43
Darkness
Apromix писал(а):
01 мар 2017, 07:29
Насчет прочности у предметов. Логика мне подсказывает, что у стаковых предметов (монеты, стрелы, зелья) не может быть прочности. Или я не прав?
По идее же стрелы ломаются с некоторым шансом. Если это выводится за рамки механики "прочность", то её быть не должно, имхо.