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

И зачем холивар устраивать. Фанатов все равно не переубедить. Причем с обоих сторон. Обозначили свою позицию и пусть думают что хотят.

ЗЫ: я сторонник patsanchik3 и cNoNim, но tac то вас тоже фанатами считает...

Проблема в том что ТС имея весьма ограниченные познания в весьма сложном предмете пытается критиковать и уж тем более учить других как надо (о чем намекает само название темы и тон автора), поэтому вполне естественно что ему корректно возражают и приводят аргументы в пользу других подходов.
Скриптинг коим несомненно в совершенстве владеет автор темы (что он вероятно докажет каким нибудь опен сурс демо проектом) имеет место быть во многих случаях:
- быстрое прототипирование
- кодинг не программистами
- жесткие временные рамки
и т.д.

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

seaman
> Обозначили свою позицию и пусть думают что хотят
м-да, наверное так ...

patsanchik3
> Очевидно что у ТС нет опыта таких разработок, что совершенно не оправдывает его
> категоричные суждения в области в которой он абсолютно не силен.
а ты говори за себя, с такими кривыми подходами, очевидно обратное - что судишь не понятно о чем

patsanchik3
> есть другие подходы которые окупают себя лишь на значительной дистанции по
> времени, большому объему кодовой базы и значительном количестве разработчиков
> одновременно работающих над проектом
1. Большой объем - это в случае, если делается на одном фреймфорке не одна игра ...
2. Количество людей не влияет
3. Представленное извращенное понимание - не являются "другими подходами" пригодными для фреймфорков

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

Говорить о сферических конях в вакууме, действительно больше не будем.

tac
Ты полностью игноришь мои потуги свести обсуждение к теме ECS.
По мне так пока ты не опишешь свое отношение к этому вопросу, дальнейшие беседы несколько лишены смысла.
Просто надо опhеделиться Юнитеки бестолковые и не шарят раз отказываются от монобехов в рантайме в пользу ECS?
Или мы чего то не понимаем.

Просто ECS приносить не эфемерную пользу в виде буста производительности и в какой то мере улучшает код. Так как говнокодить размазывая код по куче монобехов не получается.

А ECS особенно PureECS это полный отказ от монобехов

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

Банальный вопрос, как думаешь, что лучше дернуть 1000 раз конструктор, какой то новой сущности, и за инстанцировать ограниченное количество префабов используя пулировани.
Или в лоб заинстанцировать 1000 префабов?
Конечно пулирование можно использовать и с префабами, но вот тока с префабами такой лютый говнокод получается, при котором о каком то качестве кода даже говорить смешно.
Нарушаются все принципы C# которые тока возможны, конструкторов нет, имутабельных полей нет, передача информации в объект при конструировании осуществляется через гланды.

О чем тут вообще дискутировать?

А вообще фанатики Юнити такие фанатики юнити...
Юнити неумело в полиморфизм в сериализации обычных классов, все кричали "Да это фигня, оно ни когда не нужно"
Но прошло 500 лет и Юнитеки выкатили SerializeReference
Юнити не умело в генерики в сериализации вообще, все кричали "Да вы просто не умеете готовить генерики не нужны, можно просто наследоваться от генериков и будет щастье"
Но прошло 500 лет и Юнитеки выкатили сериализацию генериков
Теперь оказывается и UnityEvent можно по нормальному сеарилизовать... и вдруг окажется что дикшионари можно за сериализовать по нормальному... Но tac же по любому считает что дикшионари в сериализации не нужно да?

А потом сами юнитеки подтверждают, что не правильно иметь 100500 монобехов которые каждый фрейм дергают свой Update.
Надо диспатчить обновления из одного места. А потом выкатывают ECS, в котором update заменен на симуляцию систем ECS ворлда.
Но когда кто то и без юнитеков отделяет высоконагруженный код от юнити оказывается, что это сферический конь в вакууме.

var controller = go.GetComponent<PlayerController>();
controller.Health = 100;
Object.Destroy(go);
Debug.Log(controller.Health); // Что выведется тут?
Debug.Log(controller == null); // Что выведется тут?
Debug.Log(controller.transform.position); // Что выведется тут?

cNoNim
> Просто надо опhеделиться Юнитеки бестолковые и не шарят раз отказываются от
> монобехов в рантайме в пользу ECS?
можно по подробнее, где они отказываются, и как?

cNoNim
> пока ты не опишешь свое отношение к этому вопросу

ссылку ломает форум, поэтому так

https://docs.unity3d.com/Packages//manual/index.html

This difference in organization is one of the key differences between an object-oriented and a data-oriented design

Я люблю чистый ООП, DDD - я не перевариваю, это бред. Соответственно, этой выдержки, где данные пытаются отделить от поведения - является катастрофическим нарушением ООП, и не может быть расценено как нечто-то полезно ... дальше про ECS я предпочту не знать. 

tac
> можно по подробнее, где они отказываются, и как?
https://learn.unity.com/tutorial/what-is-dots-and-why-is-it-impor… c2a002094eff1
на тоби тутор

tac
> Соответственно, этой выдержки, где данные пытаются отделить от поведения -
> является катастрофическим нарушением ООП, и не может быть расценено как
> нечто-то полезно ...
срочно удоляй юнити пока не поздно )

https://unity.com/dots

tac
я кстати боюсь порвать тебе шаблон... но у юнитеков в DOTS кастомная сериализация

cNoNim
> Ответь плиз на вопрос
да у них, в этом случае много багов, часто юнити просто валится (раньше часто было при сравнении на null). Я так поступаю с неким классом Item, который вначале весит на геймобъекте в сцене, потом его подымает персонаж и он идет в инвентарь.

можно проверить, я уже не помню все особенности, но

Debug.Log(controller.Health); // 100
Debug.Log(controller == null); // не null, а вот геймобъект null, в каких то версиях тут валилась юнити
Debug.Log(controller.transform.position); // будет эксепшен ... оно и очевидно, это трансформ объекта, а не компонента

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

tac
> Debug.Log(controller.Health); // 100
> Debug.Log(controller == null); // не null, а вот геймобъект null, в каких то
> версиях тут валилась юнити
> Debug.Log(controller.transform.position); // будет эксепшен ... оно и очевидно,
> это трансформ объекта, а не компонента
ответ не правильный, садись два
до сути проблемы ты даже не добрался
в качестве подсказки
Debug.Log(controller.name); // что выведет?