feature/effects #37
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "feature/effects"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
эффекты, что случайно походу вышли полными по тьюрингу ¯_(ツ)_/¯
😭
как будто в сборку от зверя зашел, ей богу
пропиши у себя в повершелл или куда там:
шиза
да норм всё
в первом условии мы складываем силу и стаки как в дивинити если эффекты одинаковые, во втором условии перед циклом мы проверяем одинаковые ли тэги (суммирование сломается, если да), ну и в цикле мы проверяем на наличие сумм
неприкольная структура данных для этой задачи. Из нее всякие поиски и удаления за линейное время. Нам ведь они не нужны, да? Да?
еще менее прикольная структура данных. Таблица с ключами-таблицами - это сомнительно
насчёт
effectsPriority, он необходим для определения порядка применения эффекта к персонажу, мы это обсуждалитаблица с ключами-таблицами я согласен, это сомнительно, но я посчитал это достаточным для суммирования с соблюдением закона коммутативности с не слишком сложной проверкой на наличие суммы
другой вариант это сделать я придумал конкатенацией тэгов, но там тяжело с порядком этой самой конкатенацией, зато не таблица-ключи
из-за коммутативности достаточно хранить сумму только относительно одного эффекта из пары
(ef1, ef2). При наложении эффектов в любом порядке делать две проверки: есть ли запись о сумме(ef1, ef2)или(ef2, ef1).ну тут фактически это и делается, я вот правда не придумал как эту пару сохранить иначе
опять же конкатенацией тэгов? нужна функция конкатенации, что превратит
bleedingиaversion_to_deathвbleeding&aversion_to_death? не знаю насколько это лучшелично я не вижу больших проблем с таблицами-ключами, как бы сомнительно это не выглядело, ведь фактически оно исполняет роль простого иммутабельного кортежа (аля pair в хаскелле)
может есть какие-то технические сложности с этим, о которых я не знаю, что сильно скажутся на производительности?
ну да, да, так действительно проще
вроде оно
некрасиво, потому что данные разного уровня и типа оказываются смешаны. Еще неявно запрещает иметь эффект с тэгом
sums.А потом мы используем эту таблицу со всем подряд, чтобы создать ее версию без
sums? Логика мне не очень ясна.нет, не надо. До тех пор, пока ты не хочешь, чтобы у разных персонажей были разные возможные эффекты.
Хотя даже так - не надо.
упадет, если вообще существуют суммы с
effect, но не существует конкретно суммыeffect + ef. Будет то попытка обратиться к null по индексу, то вызвать его как функцию.уф
@ -0,0 +34,4 @@if not birthStatement then return end-- проверяем эффект на возможности суммирования (aka противоречия)for i, ef in ipairs(self.effectsPriority) doif ef == effect thenВсё таки позволяет через наложение сильного короткого эффекта поверх слабого длинного получить и сильный, и длинный эффект одновременно?
да, мы вроде так и договорились по итогу
Так вроде смысл реферата по DOS сводился к тому, что так делать не надо? Мы сделали разные выводы?
Так вроде смысл реферата по DOS сводился к тому, что так делать не надо? Мы сделали разные выводы?
получается, ты сделал
видимо ¯(ツ)/¯, я предположил так сделать из-за всех этих скрытых механик, где ты переопределяешь бесконечный эффект конечным и тд
а поддержка бесконечных эффектов же не присутствует в каком-то дополнительном виде, кроме как не указывать эффекту момент потери стака?
да, можно добавить просто какое-то магическое значение по типу -1 ради ui, ну или сделать флаг для этого
@ -0,0 +72,4 @@self.effectsProperties[effect] = nilfor i, ef in ipairs(self.effectsPriority) doif ef == effect thentable.remove(self.effectsPriority, i)ладно, это ужас, но не ужас-ужас
по академически я должен был написать линейный поиск через цикл while, но я необучаемое быдло 🤡
академически у тебя не должно быть линейных поисков вообще, в этом-то и суть
а у тебя получается внутри линейного
for i, ef in ipairsлинейныйtable.remove. Это не ужас-ужас, потому что ты гарантируешь срабатываниеtable.removeне более одного разаэтот моментик я бы тоже переписал
типа красиво-алгоритмически - это все на тегах и все за O(1), кроме последовательного срабатывания всех эффектов (очевидно)
думаю, хотя бы для этого система тэгов не пригодится (надеюсь)
ну если я правильно собираю в голове ход мыслей, то нужны адекватные теги (уникальные; один тег к одному эффекту), и отдельно группы тегов (один ко многим). Например, чтобы объединить 15 версий невидимости в одну группу "невидимость" и не давать выбрать таких персонажей в таргет
это переусложнение, которое уже ближе к реальному геймдизайну, где, как обычно, боссы могут иметь немного другие версии тех же самых эффектов
нам же эти же тэги пригодятся для спеллов в конце концов, для их систематизации
не вижу необходимости иметь одну общую систему тегов для спеллов и для эффектов
не думаю, что это такое уж переусложнение, мы же не только ради эффектов это делаем в конце концов
типа можно, но пока не знаю, зачем
вай нот? dry и всё такое
тогда будет нейминг "spell_myspell" и "effect_myeffect"
так-то у нас не стоит задача по тегу понимать еще и тип объекта, у нас для этого инструменты языка есть, не на бейсике пишем
справедливо
фактически у нас как будто есть таблицы в реляционной СУБД Microsoft Access: spells и effects.
мы и так понимаем, что это разные таблицы. В рамках разных таблиц айдишники не обязаны быть уникальными
типа другое дело что у нас у characters айдишники номерные, а у статических данных - строковые. Но это по историческим причинам и потому что, как бы, статические данные типа спеллов и эффектов мы как раз хотим находить по удобному идентификатору, а динамические типа персонажей - не хотим
ну да, да, очевидно
у нас персонажи вообще в роли энтити, там со строковыми тэгами не выйдет
короче нормальная архитектура вроде
@ -0,0 +84,4 @@--- Принимает таблицу, в ключах которых тэги эффектов, которые мы хотим просуммировать, и в значениях которых функция,--- возвращающая булево значение: применять ли эффект после суммирования.--- @type table<string, table<string, fun(owner: Character, effect1: Effect, effect2: Effect): boolean>>лучше алиас сделать для гигафункции
@ -0,0 +1,230 @@local utils = require "lib.utils.utils"local taskUtils = require "lib.utils.task"Почему это вообще в папке со спеллами?
я не придумал куда в другое место это запихать, не в либ же кидать 🥵
@ -0,0 +141,4 @@}, effect)function newEffect:beforeBirth(owner, intensity)if not data.beforeBirth then return taskUtils.wait {}, true endок, это интересный способ создать пустой таск. Я даже не знал, что так можно 🥵
вообще семантически правильный способ это сделать -
task.fromValue()даже так
@ -0,0 +146,4 @@return task, statementendfunction newEffect:afterBirth(owner, intensity)оно явно не должно так дублироваться.
вообще-то дефолтные методы ты и так определил в
effect.хотя логичнее было бы сделать "если обработчика события нет, то не обрабатываем событие".
это итог того, что я отказался от нилов в функциях
хотя полагаю это можно сократить, я не тыкал этот момент
@ -0,0 +220,4 @@--- дип сравнение эффектов--- @param other Effect--- @return booleanfunction newEffect:__eq(other)так я не понял, все таки эффекты сравниваются глубоко? а зачем, если два эффекта с одинаковым тегом не могут произойти? или могут?
кроме того, добавление таблицы в таблицу как ключа, т.е.
effects[newEffect] = 'foobar'не будет проверять__eq.эффекты сравниваются глубоко как раз потому, что мы можем иметь два эффекта с одинаковыми тэгами, но с разными функциями например
это позволяет нам например не прописывать ему доп суммы, если суть у них одна и та же, но это фактически костыль и нам надо писать нормальные тэги для эффектов (чтобы отсортировать доты, шизоэффекты и тд)
у тебя костыль не в ту сторону. Это надо делать два одинаковых эффекта с двумя разными тегами тогда. А то теги перестают быть тегами
получается что даже банальная проверка "есть ли на персонаже такой-то эффект" будет генерировать UB
да! но суммы сравнивают именно тэги, поэтому оно работает i suppose
надо короче переписать под нормальную систему тегов, но полагаю система тегов слишком большая, чтобы писать её в ветке с эффектами и надо делать отдельную ветку
но как(ать)
хз ub выкидывать он не должен, мы же там вроде перекидываемся по итогу ссылками на одну и ту же таблицу
теги суть уникальные, они дают возможность однозначно получить по строке ожидаемый объект
да ты прав, я чёт опять перемудрил
у меня где-то в голове было всё делать на тэгах, но я не понимаю что меня остановило
возможно факт того что я писал всё это в кфс и там диваны не удобные
@ -0,0 +89,4 @@--- Принимает таблицу, в ключах которых тэги эффектов, которые мы хотим просуммировать, и в значениях которых функция,--- возвращающая булево значение: применять ли эффект после суммирования.--- @type table<EffectTag, table<EffectTag, SumFunc>>Этот алиас имеет слишком общее название, у аннотаций глобальная область видимости 👎
чорт