Войти
Инди-ЮнитиФорум

Мастер класс по хорошему коду в юнити (9 стр)

Advanced: Тема повышенной сложности или важная.

Страницы: 18 9 10 1128 Следующая »
#120
15:12, 23 сен. 2020

круто - тока уже готовое все есть и даже целую философию под это дело напридумывали - в вольном переводе звучит "все есть поток".
И уже написали и даже портировали на хренову тучу языков реализации и даже целые фреймворки (так не любимые tac) понаписали :)
я рад что ты открыл для себя реактивку :)

тока там еще дофигища возможностей кроме тупой реактивки.
Но это все лишнее для геймдева - пусть в интерпрайзе голову себе ломают, мы продолжим говновкодить по старинке.


#121
15:13, 23 сен. 2020

kipar
ну то есть ничем по сути, разница лишь в отложенной проверке .. ни а каком парсинге речи нет ..

#122
(Правка: 15:25) 15:16, 23 сен. 2020

patsanchik3
> я рад что ты открыл для себя реактивку :)
я бы ее закрыл вообще ... все что мне надо я могу сделать за те же пару минут, без чужого гавнокода .. я по прежнему утверждаю, что мои первые решения лучше, это я сделал для любителей засирать код, по крайней мере не совать это решение куда надо куда не надо "мол на всякий случай" ... может от силы 0.1% случаев нуждаются в таком свойстве, но не больше ...

patsanchik3
> круто
вот то то же, на этом и остановимся думаю

Кстати, такое решение, только без обобщенного типа я реализовал сразу как перешел на С#, а было это где то в 2000-ных, и именно для интерпрайза, пруф, спустя годы был написан
#123
15:20, 23 сен. 2020

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

#124
(Правка: 15:32) 15:22, 23 сен. 2020

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

#125
15:29, 23 сен. 2020

tac
> ну то есть ничем по сути, разница лишь в отложенной проверке .. ни а каком
> парсинге речи нет ..
Никакого парсинга и нет, а в варианте из #93 есть.

#126
15:31, 23 сен. 2020

kipar
> а в варианте из #93 есть
где?

#127
15:51, 23 сен. 2020

tac
в обработчике OnChange. Надо будет брать первый параметр и сравнивать его с теми которые нужны соответствующему подписчику, потом брать второй параметр и приводить к нужному типу. Лишняя работа.

#128
16:09, 23 сен. 2020

kipar
это да, но по мне это лучше чем загаживание кода, впрочем можно выбирать ... если использовать с умом мой вариант класса ChangeProperty<T>, а не загаживать все и всегда, вполне решение ...

#129
16:32, 23 сен. 2020

tac
Ну да, в #119 уже вполне себе реактивность. Возможно еще пару штрихов надо добавить чтоб с массивами корректно работать.

В JS она красивее выглядит т.к. не надо ChangeProperty<> писать а просто любой объект можно реактивным делать, но у строгой типизации свои плюсы.

#130
20:47, 22 окт. 2020

Сегодня распрощался с еще одним человеком. Вроде и есть опыт (правда культуры ни какой), но совершенная зашоренность на модели MVC ... ну что же это за дичь, за чем вы ее тащите в Юнити с этими нелепыми реализациями. Кажется люди не понимаю для чего вообще нужно MVC и когда его применять. И это свойственно даже мидлам ... а иногда и сеньерам, хотя скорее по возрасту, а не по опыту в архитектуре ...

#131
11:40, 23 окт. 2020

tac
> совершенная зашоренность на модели MVC
так это норм, сейчас люди хеллоу ворлд без класса не могут написать (и вроде в C# это и не получится).
Тут безполезно что то обьяснять. Надо признать что мир программирования изменился. в не лучшую сторону.

#132
(Правка: 15:34) 15:09, 23 окт. 2020

Пробовал провести аналогию с MVC в геймдеве, ну такое (ниже) ... думал, поможет "убрать зашоренность с глаз", к сожалению, нет - некоторые не хотят когда разрушаются их стереотипы ...

Так вот - если такое непреодолимое желание делать по шаблону MVC, надо понимать что сцена в юнити это не View, Monobehavior - вам не враг, чтобы от него избавляться в Model ... а все по другому

0. Все View/Model/Controller - это наследники от Monobehavior - независимые классы (связи между ними нет ничего плохого получать на старте через GetComponent)
1. Сцена хранит Model - по сути обычные "невизуальные" классы с игровой логикой (которую и нужно декомпозировать), например, AgentController
2. View - это то что происходит на сцене с персонажами, т.е. работа с аниматорами, состояниями персонажей, и связка с GUI ... например, это AgentState
3. а контроллер это управление в игре -  InputController, над AgentController

да, немного не обычно ... но надо просто взглянуть на это глазами игрового персонажа - все его состояния (будь то анимация или внутренние статы, часть из которых идет в HUD) - это "визуальное отображение", перехваты управления от игрока - это контроллер, а его сердце Model - игровая логика (бизнес-логика в терминах MVC) персонажа лежит на сцене.

да, иногда вообще и MVC понимают привратно, под моделью понимают лишь данные, нет, господа - это бизнес-логика.

Бонус. Расскажу, почему MVC в геймдеве вообще не место.

Для этого надо понимать, где ему место. В обычных финансовых программах. Есть повод отделить визуальную сторону дела (окно в Windows или сайт в браузере) от бизнес-логики. Для чего это делается? Исключительно для повторного использования !! Разные клиенты, или в разных срезах (в разных представлениях на окнах - просмотр/редактирование) - одно и тоже хочется видеть по разному, при том что данные и бизнес-логика остается та же. Бывает и наоборот, отображается  одинаково, по сути блоки банков посредника и получателя, но бизнес логика их заполнения/расчетов разная. Поэтому появляется контроллер который связывает визуальные блоки с той или иной бизнес логикой, а части остаются все те же, но по разному настроенные. И заодно, перехватывает управление пользователя и по разному его связывает с бизнес-логикой.

Вот для чего это надо.

Почему такое не нужно в геймдеве?

Да потому что, вам в 99% никогда не понадобится повторное использование. HUD в играх элементарен, наверно ничего сложнее инвентаря в играх нет. И уж вряд ли вы будете для персонажа Васи, а для персонажа Пети - отображать GUI по другому, с частично теми же компонентами, но расположенными по другому ... на вас обрушится геймдизайнер, что вы только запутываете игрока.
Аналогично и все остальное ... у вас вырожденная визуализация, а раз так то схлопывается все - остается только бизнес-логика, она же игровая ...

#133
16:39, 23 окт. 2020

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

Юнити поддерживает скрипты на c# (как раньше поддрежтивал аналог javascript и pyton) - но юнити всего лишь платформа "real-time 3D development platform" а не новый язык программирования.

Убери код вообще (используй тот же Bolt или Playmaker) - и нет вообще проблем с кодом (правда появляются совсем другие проблемы :)

а требования именно к хорошему коду +- всегда и везде одинаковы (независимо от языка и сферы применения):
- количество матов на единицу времени при прочтении кода
- простота сопровождения и расширения
- тестируемость
- и т.д.

#134
(Правка: 18:07) 18:05, 23 окт. 2020

patsanchik3
> хороший код для юнити чем то
> должен специфично отличаться от хорошего кода как такового
совсем нет, я так не считаю. Использование тех или иных подходов, зависит от задачи, а геймдев все же специфичная задача, в отличии от финансового ПО. Еща раз дело не в юнити, а в задаче ... но такие как вы думают, что можно пушкой заколачивать гвозди.

patsanchik3
> тестируемость
такой ценности не существует ... ваши фантазии

Страницы: 18 9 10 1128 Следующая »
Инди-ЮнитиФорум

Тема закрыта.