Тестируйте апдейты (особенно оптимизационные)

Мне кажется очевидным, что делая любую оптимизацию — нужно её проверять. И проверять на бою. Но сегодня меня удивили комментарием под статьёй :) Поэтому я решил написать несколько базовых советов, которые знает каждый лид :)

1. Ничего не меняем перед релизом

Даже если очень хочется, даже если это очень оптимизирует или что-то ещё делает. Правило перед релизом всегда простое. Правятся только криты. Всё остальное не трогаем

2. Обновив настройки, версию, юнити — прогнать тест

Все кто работают в студиях или работал с крупными проектами знают. Что нельзя обновлять версию Unity просто так. Сначала нужно сохранить репозиторий, потом помолиться, потом запустить и удивиться если ничего не сломалось. Тоже самое с настройками которые аффектят весь проект. Сохранились. Создали ветку. Внесли. Проверили что всё работает. Вмержили

3. Работа маленькими изменениями

Зачем нужно часто коммитить? Многие пишут-пишут и коммитят раз в неделю. И это плохо. Так как нет проще способа найти баг и исправить — как пройтись бинарным поиском по коммитам "где не сломано" (особенно сложный, допустим появившийся не из-за кода, а из-за изменения версии либы в функционал который тестится редко) Пройдясь и найдя на каком коммите сломалось, если коммит — это изменение в паре скриптов и ещё какая-то фигня, всегда легко найти "а что изменилось")

А то я увидел коммент и был в шоке. Судя по тексту человек на проде без теста применил советы из статьи на хабре. Боец без страха и упрёка, смельчак каких поискать. Но и при этом вывод сделал неправильный "не трогайте настройку". А не, да настройка полезная, но если её поставить то может сломаться Х. Высокая степень оптимизации на то и высокая, что ей надо пользоваться аккуратно :)

Argo Lite

Пока ковырял алгоритмы укладки графов и искал разные материалы для статьи по 3д укладкам нашёл прикольный опенсорсный инструмент для визуализации графов в браузере https://github.com/poloclub/argo-graph-lite Выглядит достаточно прикольно, хотя немного и сложноват. Я не нашёл какие-то разные схемы укладки и отображение, но как простенькая тулза с несколькими прикольными фишками выглядит интересно :)

Мануал для тех артистов от Unity

Сама книжка тут https://resources.unity.com/games/unity-for-technical-artists-key-toolsets-and-workflows. А сказать хочется вот о чём) Круто что юнити начали делать мануалы с обзором функций для разных задач. Допустим из мануала по 2д я был не в курсе о ряде функций которые подвезли. Давно с 2д не работал. Хотя меня удивляет, что это называют иногда прям книгами. Это не книги — это мануалы :)

Dark Asset

Прикольный пост о применении Unity в кинематографе. Так сказать рассказ от VFX артиста :) Такие штуки с "виртуальным продакшеном" и трекингом камеры для съёмки + совмещением с изображением с хромакея я разок делал. Технологически это сейчас довольно просто. В целом забавно как игровой движок который я ещё помню воот таким с 4-ой версии стал применяться в самых разных задачах :) Хотя понятны преимущества реалтайма для продакшенов. Когда в реальном времени можно прикинуть, как будет выглядеть кадр без недели рендера или не подгонять кадр под то, что "было снято"

https://blog.unity.com/entertainment/dark-asset-vfx-previs-to-final-pixel

Классный туториал с VFX дракона https://dtf.ru/u/35827-evgeniy-seregin/1405100-povyshaem-socialnyy-reyting-delaem-nefritovyy-drakon-unity-vfx

Как подготовится к собеседованию :)

Просто великолепный видос и канал. А если говорить серьёзно я не собеседовался уже 6 лет, так что даже не знаю что там спрашивают. За это время только собеседовал разработчиков :) Помню только собеседование в мейле когда-то давно, меня зачем-то на рендер программиста спрашивали свойства хеш функции. Прошло 8 лет, а я до сих пор не знаю зачем ответ на этот вопрос может пригодится рендер разрабу :)

https://www.youtube.com/watch?v=5bId3N7QZec

Красивый эффект «появления» мира

Обожаю технически простые штуки, но сделанные со вкусом :) По сути трипланарный dissolve с подсветкой edge на маске, но выглядит очень эффектно https://80.lv/articles/real-time-space-transformation-in-unity/

Что почитать по рендеру?

Таки я собрался с силами и написал статью с полезным, на мой взгляд, списком литературы чтобы разобраться или прокачаться в реалтаймовой компьютерной графике. Одну книжку я недавно увидел как раз в чате https://news.1rj.ru/str/unity_cg и она мне понравилась, если рассматривать её "для начинающих". В общем мало ли кто-то искал что почитать. Надо будет собрать такое же по ИИ и прочим разделам тяжкого труда Unity разработчика :)

P.S. Ну и превьюшка теперь мне нравится, не просто картиночка, а "со смыслом" :)

Unity всё ещё работают над интеграцией .Net CoreCLR JIT runtime

По сути вчерашний пост в блоге юнити про AnimationEvent именно про это. Но возможно вы пропустили или не в курсе. А о чём речь и зачем это вообще надо? Немного есть про это тут, но хочется добавить от себя.

Поговорим немного про рантаймы Unity. По сути сейчас их два. IL2CPP и Mono. С первым ничего не случится. Посмотрим какие платформы будут поддерживать Core CLR, но точно на него переедут десктопные платформы. А в чём разница?

1. Моно мёртв

Конечно Unity поддерживает свою версию моно по сути, так что это не совсем тот моно. Но CoreCLR — это будущее .Net которое активно развивает Microsoft. Он кросплатформенный, он в х2-х10 раз быстрее чем Mono и оперативно получает все последние фичи .Net. Он лучше, чем .Net Framework по множеству причин и т.п.

2. А что с IL2CPP?

Так как его трудно поддерживать под несколько платформ он может быть недостаточно оптимизирован и в данном случае так же проигрывать CoreCLR в производительности.

3. Span

Это есть в статье, но Span<T> супер полезная штука. Это возможность безопасно работать с неуправляемой памятью (в отличии от того же unsafe) что бывает достаточно полезно и открывает возможности для множества безопасных оптимизаций

Так же улучшенный GC и много чего ещё. В общем работа над интеграцией CoreCLR судя по всему идёт и это круто)

Репликация в сетевых играх

Репликация один из таких противных терминов, который слишком многое значит. Поэтому сложно искать информацию по подобным вещам. А сегодня я наткнулся на старую, но интересную статью-обзор по сетевой репликации и её принципам.

Сразу вспомнилась серия статей, которая так же неплохо разбирает принципы построения сетевого кода.
Часть 1 — общий обзор
Часть 2 — про топологии сеток
Часть 3 — про локстеп и роллбек

У автора ещё классная серия статей про то, как он делал MMO

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

Нормальные люди ночью — спят
Я — готовлю материалы к статье о том, как в тильду засунуть AR блоки

Многие несправедливо не любят тильду без причины, а у меня теперь есть к ней вполне конкретные претензии. Которые я изложу завтра в честь хэллоуина :) Так как в целом я люблю тильду, у меня на ней были сделаны раньше многие сайты. Календарик, студии. Но вот то, что туда нельзя на хостинг сайта залить никакие вообще файлы — это отличное решение, чтобы просто бесить. Так как нужно иметь отдельный свой хостинг без проблем с корсом. С USDZ я ещё как-то обошёл это через гугл диск (бюджетное решение для тех у кого нет своих серверов). А вот с глб — не получилось

Ну в общем детали завтра в статье, а пока "из первых рук" для подписчиков репозиторий с примером и ссылка на результат (работают только на мобилках) :) Так что если вам нравится эстетика праздника, но тыквы нет, то я вам подогнал AR тыкву :)

Дополненная реальность в Tilda
https://habr.com/ru/post/696300/

Статья конечно вообще никак не связана с Unity, зато связана с моей областью интересов — дополненной реальностью. Конечно помучаться с тильдой мне пришлось, и делается там это по сути "костылём", так как свой сервер всё равно пригодится бы. Но делается :) У меня несколько проектов и лендосов на тильде. Что сайт компании https://foxsys.pro/ (пока, скоро будет его большой апдейт), что сайт календаря http://gamedev-calendar.ru/ Ну и всем весёлого хеллоуина, кто тоже любит эстетику этого праздника :)

Децентрализация как высшее благо

Я не фанат криптовалют, DAO, Web3.0 и прочего. Я всё никак не могу понять зачем делать неэффективно то, что работает эффективно централизовано. На VC была отличная статья на тему того же NFT. Но меня скорее удивляет тотальная маркетинговая мантра децентрализации. Помню тот же старый аргумент, что международные переводы банками идут 3 дня, а крипта несколько минут. И всё это ногами идёт из непонимания технологий. Банковские переводы так долго идут из-за законодательств и трансграничных переходов, а не так как это так долго считается. Крипта просто пока не соблюдает законы :)

Децентрализованные системы, как показала практика, менее эффективны чем централизованные. Чисто даже с точки зрения производительности. То есть на мой взгляд централизованные соблюдают некий неплохой баланс между надёжностью и быстродействием. Они не требуют невообразимого количества мощностей и ресурсов. Они просто работают)

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

Ну как говорится посмотрим, что из этого выйдет :)

Перфекционизм — это зло

Многие в работе падают жертвой перфекционизма. Своего или чужого. Чтобы много успевать и делать — рецепт довольно прост. Не мучать результат до посинения)

Иногда мучать результат полезно, да и когда время или бюджеты есть, то почему бы и нет. Мне по работе приходится периодически набрасывать какие-то картиночки. Да, что тут далеко за примером ходить. (Картинки будут ниже) Сейчас я конечно визуалы получше набрасываю, но первый логотип календаря я сделал за 10 минут. И с ним я набрал 300 подписчиков в этот канал.

Если брать что-то посвежее, то вторая картинка была сделана мной картинками со стоков и заняла минут 20. И тоже отлично подходит для иллюстрации идеи и концепта. Или же вот такой концепт, который в последствии превратился в один из самых красивых наших AR проектов был собран за час вечером.

К чему это я? Да, концепты, которые неделю делали дизайнеры. Вроде такого раннера, концепта игры квеста или такого концепта виртуального тура — визуально круче. Они много раз были полезны команде без портфолио (из-за NDA) чтобы объяснить, что "что-то мы таки умеем". Но как показала практика нескольких лет, и то что собрано на коленке за час отлично работало. Зато такое я мог собирать под каждого клиента и быстро. А не отправлять в ожидание на неделю)

И такое встречается во всём. Правда в том, что всем плевать насколько вы старались. Особенно на старте. Это просто проще объяснять на визуалах, но не стоит забывать такие вещи и разработчикам. Заказчику или бизнесу плевать насколько оптимально работает функция, если это до этого удовлетворяло пользователя. Пользователю плевать насколько красивая у вас архитектура. Если тех лид парится, что у него сессия вылетает по памяти через 3 часа, а средний пользователь играет в игру 2 минуты — бизнесу плевать. Если арт лид парится, что у персонажа какая-то не такая поза, а 85% пользователей этого даже не заметит — бизнесу плевать. Пока 15% пользователей — это не миллионы. Перфекционизм полезен уже в успешных продуктах и там он нужен, особенно на стадии оперирования. На запуске же вы без таких заморочек будете двигаться в разы быстрее.

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

Поговорим про метавселенные

Почему я не верю в метавселенные, как в концепт? По тому, как его формулируют :) Многие кто работают с метавселенными с точки зрения бизнеса не знают «истории». Я люблю как примеры тот же децентраленд (тупо пузырь с аудиторией в 10к пользователей) Но есть пример в разы лучше) Роблокс :) И что с ним не так?

Да всё с ним так, просто это «уже было». Прикол роблокса не в метавселенной, а в том что это неплохая песочница. И такая песочница уже была, и называется она майнкрафт. Проблемы таких песочниц обычно в том, что «король может быть один» :) С майнкрафтом многие конкурировать пытались, но успех был и не близким. И что в роблоксе, что в майнкрафте основное это не иммерсивные технологии. А возможность создания контента. Поэтому приводить роблокс как пример успешного проекта-метавселенной для меня странно :)

Если мы возьмём тот же майнкрафт, то средний возраст аудитории там 24 года, хотя есть миф, что это школьники :) И это неплохо, но это значит, что это не самая платящая аудитория. Но засчёт чего эта аудитория формируется? По сути за счет контента, который аудитория создала. То есть отличие от того же WoW и т.п. Не в свободе действий, не в каких-то технологиях)

Просто представьте, что в вашей игре можно делать мини-игры) И мини-игры делает миллион пользователей, который делится ими со своими друзьями. У мини-игр нет того ретеншена, лтв и прочих метрик крупных игр. Но ни один продакшен не выпустит столько игр на супер лояльную аудиторию. Прикол роблокса и майнкрафта в том, что это конвееры, которые заинтересовали огромные аудитории, чтобы за эти конвееры сесть. Один из таких же конвееров «нашей молодсти» — это гарис мод :)

Но бизнес почему-то упорно пытается продать успешность этих платформ за заслугу VR :) Единственный проект который можно так рассматривать — это VRChat, но там и аудитория соответствующая, ниже чем во многих паблик каналах дискорда :)

Интересное упражнение

Я люблю заниматься всякой фигнёй для разминки. Так как делаю кучу всякой фигни (разве что удивительно, что не выпустил пока ни одной именно своей игры за 8 лет работы на Unity) я люблю иногда разминаться старыми стартаперскими замашками. И для проектов часто нужно оценивать целевую аудиторию :) Но чаще всего люди оценивают от «позитива» типа кто пользователь моего проекта, игры или продутка. Иногда забавнее пойти от обратного «кто точно не будет пользоваться моим продуктом». Скажем любители ААА и графена точно не будут играть в небольшую инди визуальную новеллу :) И так сегментировать и вычёркивать циферки. Точную цифру остатка так получить нельзя безусловно, но просто полезно бывает понимать свои проблемы и слабые стороны. Часть их них даже бывает решаема :)

Дженерики очень опасная штука

Эххх, помню я несколько лет назад, когда в коде у меня ещё были всякие мысли типа "ух как я придумал" и когда было желание писать "красивые конструкции". Сколько я весьма странных вещей строил на дженериках. Я не люблю и почти не используют дженерики. Нет, конечно мы все используем дженерики в сетевых методах, во всём что связано с десериализацией, с коллекциями (типа объектного пула). Но дженерики чаще зло.

Но почему? Ведь удобно реализацию определять ниже по иерархии вызовов нежели делать это в самом классе, если есть такая возможность. И у меня тогда встречный вопрос. А чем это отличается от: Object, абстрактного класса и интерфейса? (как можно понять варианта три из-за параметров аля where) За исключением того, что их вы можете конкретизировать и определить на любом шаге и в любом уровне иерархии? Выигрыш в производительности на дженериках без кастов обжекта к конкретному типу конечно будет, но тем не менее

Проблема не в самих дженериках, а в том какой соблазн возникает их использовать там, где это не надо. Есть ещё такая проблема "а правильный ли код я пишу?". Когда программисты переживают "а пишет ли так кто-то, а корректно ли это?". Мне кажется из-за этого сложилась какая-то абсолютная нелюбовь к операторам as или is в коде. Так как в одно время их было как-то не модно юзать, и что код плохой если приходится так что-то определять. Но никого не смущало, что с архитектурной точки зрения дженерики — это ровно тоже самое по своей сути)

А что же лучше дженериков? Да почти всегда интерфейсы. Там конечно тоже свои нюансы, и если ответственность вашего класса манипулировать какими-либо ссылками и больше ничего не делать, то хороший вопрос зачем тут конкретизировать интерфейс, а не делать совсем абстрактно? Потому что переиспользование кода — это красивый миф. Особенно всяких супер абстрактных конструкций. Не потому, что это невозможно. А потому что очень долго реально проектировать что-то, что будет применимо в контексте любой системы. А в рамках одной долго разрабатываемой системы — это бывает очень опасно, так как изменения одного объекта прошивают вообще всю систему, что ведёт стабильно к неочевидным багам и техдолгу. Ведь это же тоже в некотором смысле связывание и централизация кода, только логикой поведения какого-то модуля. И в огромном проекте не всё можно покрыть тестами и заметить. А сейчас уже не нужно так экономить память устройства, чтобы ещё 1кб кода был проблемой :)