DOD буткэмп от Unity

Не знаю, будет ли это лучше туториалов от Turbo Makes Games, но попробовать стоит.
Я уже ковырялся с DOTS еще до 0.5 версии, когда было страшно даже палкой в нее тыкнуть, а единственным тутором был 4-х часовой видос от otus'а, где за это время чувак успел научить кубик двигаться по клику...
Чуть веселее этого был древний видос с DevGamm'а где лид Moonlight Mouse рассказывал что делать RTS на DOTS «легко и просто», но я до сих пор не уверен что пойму этот доклад, если пересмотрю еще раз)
Кстати, Moonlight Mouse это будущие Door 407, создатели великой и единственной настоящей игры на DOTS - Diplomacy is Not an Option) Не смотря ни на что, очень хорошей игры, которую имхо можно было бы сделать быстрее и лучше без DOTS (тем более без DOTS того времени)

Кстати, DevGamm полон мемных роликов, давайте 10 🔥 под этим постом и я покажу своего devgamm'ного любимца)

Джуны и архитектура

Хороший пост от Олега, подсвечивающий важную проблему начинающих специалистов.

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

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

Даже у меня встречались пара менторят после известных курсов (там что-то про "коробку навыков"), которые с горящими глазами рассказывают про чистую архитектуру, но с трудом побеждают Rigidbody…

Однако есть мой личный набор правил для начинающих, выполняя которые можно избежать большинства проблем с кодом:

1️⃣ не пишите классы длиннее ста строк. Это, конечно, в меньшей степени относится ко всяким Composition Root и Entry Point‘ам. Но в остальном настолько раздутый класс означает, что вы засунули в него очень много ответственности и скоро в нем будет трудно разобраться. А значит, вы начнете дописывать туда все новый код и очень скоро сотня строк станет тысячей) В будущем вы отойдете от этого, когда начнете больше разбираться в цикломатической и когнитивной сложности кода, но до первой сеньорной зарплаты вполне легко докатиться на этом правиле.
2️⃣ не пишите классы с количеством зависимостей больше 5. В целом все аналогично предыдущему пункту. Здесь мы сразу и заодно заметим проблему всяких 💩синглтонов и сервис локаторов💩 - зависимости на них придется искать по всему коду. А при DI или прямом пробросе зависимостей пришлось бы всего лишь посмотреть в конструктор или метод, заменяющий оный в монобехах.
3️⃣ по необходимости отделяйте предметную логику от фреймворка (то есть, от монобехов). Вне зависимости от размера и жанра проекта предметная логика и фреймворк - это вещи, которые могут развиваться независимо друг от друга. А значит и не надо давать возможность себе и остальным ломать игру целиком во время мелкой правки в ui или наоборот.
Я говорю "по необходимости" так как порой может не иметь смысла. Если положение игрока вы смотрите по его transform'y, а цель для движения и скорость - через NavMeshAgent, то дублировать эти данные в отдельный класс может стоить дороже чем брать из компонентов напрямую.
4️⃣ придерживайтесь принципа IoC, то есть не пытайтесь в модель данных прокинуть зависимость на фреймворк (например, на UI или любые Monobehaviour классы). Как часто говорил великий Григорий, что хорошая игра должна уметь работать даже в консоли.

Таким образом из «архитектурных ошибок» у вас останутся только неправильно вывернутые или циклические зависимости. А их исправление займет от силы несколько часов на промежутке из нескольких месяцев разработки.

И ставьте🔥если нравятся длинные посты прямо на канале, а не во всяких хабрах)

- Понимаешь, стейт машины, они как лук
- Воняют? Доводят до слез?
- Нет, слои. У лука есть слои и у стейт машины есть слои
Пишите в комментарии, откуда отсылка

Наконец-то этот день настал! Расписал в статье, почему мне так ненавистен ИИ на стейт машине)
Готов ловить гневные комментарии и игнорировать их на следующих площадках:
Хабр
DTF
Pikabu

Кстати хотел прикрепить к статье какой-нибудь хороший видос по реализации Behavior Tree на русском, но чет не нашел ничего вразумительного. Если знаете такие, то киньте тоже в комментарии. А если не знаете, то ставьте 🎄чтобы я вам заснял такой)

Да и в целом, тема игрового ИИ, видимо прогреваемая этим бумом нейросеток, очень популярна. Но все почему-то прячут контент по ней: Otus на закрытых марафонах про них рассказывает, K-Syndicate делает закрытый "мастер класс" по Utility AI. Поэтому ставьте 👻, если хотите качественный и бесплатный контент по игровому ИИ!