Никто не пробовал?
Использовать ScriptableObject экземпляры как handlers. То есть наоборот, чтобы они не хранили дату объекта. Максимум - настройки метода. То есть, например OutOfBoundsDeathHandlerSO : IDeathHandler
И там простой чек. Да, в метод надо закидывать Character, остальное можно узнать из всяких DI инъекций или синлтонов или eventbuses или иных фишег. Плюсы: можно накидывать алгоритмы в композиционную абстракцию в виде экземпляров в инспекторе. Более того, можно делать их несколько с разными настройками расчётов.
Я чёт такое не встречал, SO driven Райана Хиппла - совсем про другое, имхо, там путаница с srp. Я именно про SO-handler подход.
Вижу плюсы
1) Ультра удобный механизм композиции
2) можно формировать композицию с разными настройками расчётов
3) в SO можно закинуть другие SO. Использовать древовидный подход композиции.
Минусы
1) всегда закидывать данные в метод, чтобы их обрабатывать.
2) не получится закинуть ссылки из сцены в so. Но это не минус, было бы можно - нарушило бы идею.
Ремарки
1) Правильно задавать роли, нейминг, ну как всегда...
Я так делаю иногда, ну жить можно вполне. Допустим у меня в проекте всякие форматтеры так сделаны, иногда еще всякое разное.
Прям вот весь проект я так не делал ни разу, но какие-то части работали вполне.
Недостаток тот же, что и у всех подходов, завязанных на редакторы. Больше мерж-конфликтов, труднее спалить на код-ревью косяки, сложнее дебажить, связи неявные из IDE.
Increaser
Недостаток тот же, что и у всех подходов, завязанных на редакторы. Больше мерж-конфликтов, труднее спалить на код-ревью косяки, сложнее дебажить, связи неявные из IDE.
И ты мне писал,что в Юнити проблем нет.
https://gamedev.ru/code/forum/?id=292868&page=6&m=6117621#m79
А вон оно как выходит. Когда проект стал сложнее тетриса.
Не договариваешь балаболка и преукрашиваешь(ещё одна особенность Юнити-боев).
Increaser
> Больше мерж-конфликтов
Не пон о чём речьIncreaser
> труднее спалить на код-ревью косяки
Не знаю. Имхо, такой подход позволит наоборот атомизировать, мелко нарезать ответственности обработчиков. Не? Я теоретизирую, т.к. сам не пробовал.
ronniko
> Вон оно как выходит. Не договариваешь балаболка(ещё одна особенность Юнити-боев).
Сра ч он такой)
Dmitry_togliatti
хз, если у тебя геймдиз такое любит и продуктивен при конструировании игры на основе таких "кирпичиков", то может норм. но если делаешь игру сам, или ГД описывает функционал текстом и параметры конфигурит - настраивать компизицию хэндлеров из кода вроде удобнее, а тогда SO (для композиции) не нужны.
ronniko
в каком месте это "фунадаментальные проблемы, мешающие сделать аналог сталкера"?
kkolyan
в каком месте это "фунадаментальные проблемы, мешающие сделать аналог сталкера"?
Сделай аналог сталкера, а потом обсудим какие возникли у Юнити проблемы.
А то на словах всё прекрасно, а на деле
https://cubiq.ru/dvizhok-unity/?ysclid=mi7d4tq1u7294954882
ronniko
зачем мне это? чтобы что-то доказать истеричке, не способной осмысленно связать два поста?
kkolyan
То есть кроме как убежать в кусты и орать от туда истеричка, больше у тебя нет аргументов ? :)
Смешно.
Думал ты более адекватный , но ошибся.
ronniko
> А то на словах всё прекрасно, а на деле
> https://cubiq.ru/dvizhok-unity/?ysclid=mi7d4tq1u7294954882
сам-то читал? материал по ссылке скорее рекламирует юнити, чем наоборот.
kkolyan
> настраивать компизицию хэндлеров из кода
Не, не удобно. У меня сейчас так. Что-то типа Type<T>[] GetHadlers () where T: IHandler.
Это потом в абстр методе надо писать. Не очень. С SO чище в теории. И опять же можно тонко настраивать в разных экземплярах всякие Trereshold и прочие расчётные тулзы.
ronniko
Сделай аналог сталкера, а потом обсудим какие возникли у Юнити проблемы.
Уже сделали, называется Escape From Tarkov. Кстати в статье что ты скинул там список игр очень интересный, ты долистал до него?
ronniko
> И ты мне писал,что в Юнити проблем нет.
Ты совсем с головой не дружишь что ли. В твоем "движке", прости господи, вообще нет редактора поди, или такой, что лучше бы и не было. Да и мержить ничего не надо, потому что это никто не будет использовать
ronniko
> А вон оно как выходит. Когда проект стал сложнее тетриса.
> Не договариваешь балаболка и преукрашиваешь(ещё одна особенность Юнити-боев).
У тебя нет и проекта уровня тетриса в релизе
kkolyan
> в каком месте это "фунадаментальные проблемы, мешающие сделать аналог сталкера"?
В его больной головушке
Dmitry_togliatti
> Не пон о чём речь
Ну у любой логики в редакторе проблема с мержами. Вот один поменял чейн SO, и другой. В итоге мердж конфликт. В IDE мержить проще простого, YAML уже посложнее, и можно упустить больше.
Уже сделали похожую игру на Сталкер, называется Escape From Tarkov.
И как всегда Юнити адепты не договаривают многого.
https://dtf.ru/id3184745/4317076-problemy-escape-from-tarkov-posl… eleza-v-steam
Increaser
В его больной головушке
моя ты рыба. Дайка я тебя в очередной раз ткну носом.
В целом: релиз Tarkov 1.0 на Steam оказался более драматичным, чем праздничным. Да, есть потенциал, и идеи у Battlestate Games смелые, но реализация подкачала. Игроки хотели новую стабильную эру — получили вайп-хаос с багами, отключёнными фичами и подозрительными банами.
Increaser ну что ? Юнити корабли лави́ровали, лави́ровали,да так и не вы́лавировали :)
Dmitry_togliatti
не совсем понял, каким образом композиция из кода порождает больше кода. если тебе при композиции из инспектора не нужно
> Что-то типа Type<T>[] GetHadlers () where T: IHandler.
> Это потом в абстр методе надо писать
то зачем это при композиции из кода?
ronniko
но релиз тем не менее состоялся и вполне успешен. вердикт: фундаментальных проблем, мешающих создать аналог сталкера - нет. о том что в юнити совсем нет проблем - это ты сам придумал.