Столько новых лиц :) Хотя и знакомые есть :)

Скоро тоже буду там сидеть. А то я в люди не выходил очень давно :)

Отстрелялись :) Фотку со сцены выложу позже, когда они будут :)

Доказательства что на сцене мне даже микрофон дали :)

Организация архитектуры для игр
https://devsdaddy.hashnode.dev/organizing-architecture-for-games-on-unity-laying-out-the-important-things-that-matter

Неплохая обзорная статья по архитектуре и архитектурным паттернам. Можно долго спорить на тему того, что «у игр своя специфика архитектуры» и т.п. Но я пока такого не замечал. Все MVC, MVP, MVVM вполне уместны и полезны в геймдеве, если разбираться что это за звери и с чем их едят. А разбираться в этом разработчику необходимо.

Конечно моим любимым принципом всегда остаётся KISS. Так как по опыту не знание архитектуры делает понятный спектр проблем. А вот «знание» архитектуры и оверинжениринг — это то, на что чаще говорится: «Да проще с нуля написать, чем понять как это вообще работает».

#новости

ИИ в Unity — GOAP
https://www.youtube.com/watch?v=T_sBYgP7_2k

Классное обзорное видео про GOAP с хорошими примерами объясняющими, что такое акторы, планировщик, действия, цели, сенсоры и так далее. В общем сохраним тут.

#новости

Про пространственные вычисления
https://blog.unity.com/engine-platform/spatial-computing-with-owlchemy-labs

Пост в блоге на мой вкус ни о чём. Я в целом не люблю "высокопарный" текст, который звучит сложно и солидно. При этом абсолютно непонятно. Но зато я узнал про Gaussian Splatting. И наткнулся на любопытную статью на эту тему на хабре.

А в общем в этом посте в блоге видна главная проблема XR и в прошлом, и видимо в будущем. Все говорят: "Смотрите какие крутые технологии появились". А не то зачем они вообще хоть кому-то нужны. Даже тот же сплаттинг.

— "Мы умеем делать 3д пространство по одной фотке!".
— "Очень круто, а зачем это надо?"

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

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

#новости

Теория вероятностей в играх
https://habr.com/ru/articles/806851/

Итак. Кто-то пишет про математику, и я мимо пройти не могу. Статья в целом кул как научпоп, только хочется чуть подправить один момент на тему казино.

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

Классический гсч вроде Unity.Random или C# предсказуем. По сути это детерменированный алгоритм, в котором нет никакой энтропии, который выдаёт цепочки чисел в зависимости от сида. И собственно это так называемый псевдо гсч. И очевидно, что если с тем же сидом можно повторить последовательность выпадаемых чисел, то можно было бы достоверно предсказывать результат. Помимо скандалов, что в рандомах были баги и распределения там были неравномерны. То есть результат в казино можно было бы угадать, а казино это не нужно :)

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

#новости

Про память в С#
https://devsdaddy.hashnode.dev/memory-optimization-in-c-effective-practices-and-strategies

Неплохая статья о работе с памятью в C#. По сути в разработке игр у нас 3 основых ограничения в плане того что можно сделать. CPU Bound, GPU Bound и Memory Bound. Поэтому их работе надо разбираться. Хотя с памятью происходят чуть ли не главные ошибки и недопонимания. А тут неплохой обзорчик написан 🙂

#новости

Куда пропал?

В этом месяце мне исполнилось 30 лет :) И если от работы отпуск я устроить себе даже в теории не могу, то от блога решил немного отдохнуть. Но скоро я вернусь! Вообще в день рождения я люблю подводить какие-то промежуточные итоги года. В год получается две такие отсечки. День рождения и новый год.

В целом год начался бодро. Много работы, много дел. Вообще этот год удивительный, так как много проектов было начиная с января. Обычно я работать начинаю где-то к марту. А сейчас много работы прям сразу.

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

А так, 30 лет всё же юбилей, подведём итог некоторый того, что я успел сделать до 30-ти.

Преподавать в двух вузах
Создать компанию
Разориться пару раз
Сделать больше 100 проектов
Попытаться запустить около 5-ти разных брендов
Написать 48 статей на хабр
Организовать и закрыть свой митап по Unity
Сделать свой небольшой блог
Пройти на позицию с зарплатой в 1.5кк в месяц и не пойти на неё (скорее было интересно тяну ли я на такую рыночную оценку)

В общем чем я только не занимался если подумать. Хотя всё равно самым запомнившимся является почему-то то, что в школе я был в топ-3 гильдий европы в World Of Warcraft. Сейчас надо бы подумать, кем я хочу стать когда вырасту. Ну продакшен то мой (как основной вид деятельности) никуда не денется, это понятно. Но можно чем-нибудь ещё заняться. Вариантов много, время можно найти. Весь этот год я по моим меркам отдыхал. Но наверное отпуск затянулся, так что пора возвращаться в свой стандартный режим жизни.

#мысли

Миграция json файлов
https://habr.com/ru/articles/808515/

Миграция пользователей — самое вкусное. Примерно наравне с совместимостью версий схем апи. Разработчиком во многом быть просто на самом деле, но есть задачи от которых хочется рвать волосы на голове. Это миграции, совместимости и развозить зависимости. Я больше всего люблю последнее правда. Особенно во времена с деревянными игрушками, когда Gradle был попроще и техник было поменьше. Решили вы добавить в проект фаербейс и эластик сёрч. И две недели вы не разрабатываете игру, а пытаетесь понять, как так разнести зависимости, чтобы всё обратно заработало. Ладно. Это лирика.

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

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

В древние времена XML, когда JSON ещё не стал популярен, проблема решалась штукой, если не изменяет память, под названием xstl шаблоны. То есть мы вообще не касаемся понятия классов и типов, не плодим сущности с точки зрения кода и обозначенные автором проблемы. У нас это некая структура (графовая), которая собирает данные и по шаблону их переносит. То есть по сути у системы есть три составляющих. Версия, схема данных этой версии, схема миграции к следующей версии. Если такую систему развивать и поддерживать, то можно мигрировать пользователей, которые не входили в игру годами. Думать оно будет долго, пока через все шаблоны прогонит, но справится.

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

P.S. Ну и да. Проблему стоит одну обозначить. Я тут подумал чуть больше. У решения автора есть одна ключевая проблема. Это code-first решение. И как только версий станет 100, там такое количество кода странного для обратной совместимости будет. Что шаблонные форматы миграции кажутся всё-таки лучше. Но для чего-то простого, со сроком жизни в год-полгода почему бы и нет.

#новости

Гриша-бизнесмен: Конец? Часть 1

Вот я походил по встречам. Их было много. И вроде казалось что всё выравнивается. Я решил, что мне нужно выходить из продакшена. Так как когда я остался один у руля, я забрал на себя ответственность по всем задачам. А я не умею в полумеры. Поэтому если я и раньше работал много, то в тот момент я просто жил в режиме "проснулись и работаем, пока меня не вырубит". Спал я мало, зато работал много. И это приносило результаты. Но по-мимо этого я потихоньку начал сходить с ума.

В целом классно, что в это приключение я попал когда мне было 25 лет. Потому что сейчас я уже не уверен, что вывез бы такой темп работы. Каждый день, часов по 14, без выходных. Но мной двигали в те времена ещё мечта о студии, ответственность перед ребятами которые на меня работают. Поэтому выгорание было непозволительной роскошью. Что самое забавное добить меня событиям в жизни получилось со второго раза. Перед новым годом я был никакой, так как одновременно произошла куча событий. Расход с партнёром, расставание с девушкой, проблемы ещё и семейные. В те времена я был разбит, так как казалось, что просто вся жизнь вокруг рушится и непонятно что делать. Но за пару месяцев я привёл голову в порядок, а пока она была не в порядке работал чисто на автопилоте.

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

И вот 24 миллиона лидов. Ну я думаю слетит даже 80% будет хорошо и понятно что делать дальше. Касса выровняется с текущими контрактами в паре. Будет запасик нанять ещё человека в продакшен. И поедем дальше. Но существуют непредсказуемые проблемы. На дворе 2020 год. А все контракты были для ПМЭФ. Ну и если кто не помнит что произошло — произошёл ковид. И ПМЭФ отменили. Бывает что отваливается большой % контрактов. Но ни разу за всё время в бизнесе у меня не было, чтобы когда бюджеты обсуждены отвалилось 100%. Кроме этого раза. В общем обычно у меня всегда было 50% конверсии в среднем по году. Если мы обсудили сумму, то в половине случаев контракт доходил до подписания. Это было тяжело. Пару месяцев, как я привёл голову в порядок, так как все проблемы выше были в декабре 2019 года, и такой хук справа, который я никак не ожидал.

В следующей части я уже расскажу, что я сделал и чем всё закончилось в приключении под названием Foxsys. Ставьте 🔥, если интересно что же там было дальше.

#приключения

Сравнение сборщиков мусора в Unity и .NET
https://habr.com/ru/articles/811201/

Статья рассказывает о различиях в работе сборщика мусора .Net и Unity. А так же о том, что Unity использует Boehm-Demers-Weiser (BDW) сборщик мусора. У инкрементального GC в Unity есть несколько узких мест, включая вызовы GC, фрагментацию памяти и затруднения при работе в режиме инкрементального GC. Ну, а фрагментация является важной проблемой, так как в отличии от GC .Net сборщик мусора в Unity не поддерживает сжатие памяти.

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

#новости

Гриша-бизнесмен: Конец? Часть 2

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

Собственно у меня было основных варианта. Первый, продолжить работать и постараться не сойти с ума. Искать новые рынки и как выровняться. И вернуться к плану как только позволит состояние студии. Второй, закрыть студию. Ситуация была такой, что у при закрытии контрактов была возможность закрыть студию "по-человечески". Расплатиться со всеми подрядчиками, выплатить всем ребятам их зарплаты и по доп. окладу на поиск новой работы (там по выручке получалось около 2 миллионов с остаточных контрактов). Что довольно забавно, сам я в этом случае оставался должен банкам и друзьям где-то 2 миллиона. Но основной долг составляли кредитки. Так как пока у меня была студия жил я в среднем на 100к рублей в месяц, а в последние месяцы вообще жил только на свои кредитки.

И так как я безумно устал я выбрал второй вариант. Собрал ребят, обрисовал ситуацию, кому смог — помог найти новую работу и ушёл в закат. А точнее говоря я примерно пол года пил вино и смотрел аниме. Обожаю стального алхимика. Я конечно зарабатывал какие-то деньги, чтобы потихоньку закрывать долги. Занимался консалтом, вернулся в фриланс. Но вот итог великого приключения под названием Foxsys. Стартовал я пусть и без капитала, но с какими-то сбережениями, с девушкой, с партнёром, со съёмной квартирой в хорошем районе Москвы, завтраками в кофемании, элитным спортзалом и т.п. А закончил я за три года работы один и с парой миллионов долгов переехав в комнату к родителям. Конечно я получил огромный опыт, благодаря которому сейчас мне живётся во многом проще. И у меня весьма смещённое понятие того, что такое "проблемы".

Позже я выровняюсь и всё раздам. Но это совсем другая история. Могу её рассказать за 100 🔥 :) Это уже будет начало истории моего текущего формата работы.

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

#приключения

Сампл матч-3 на URP от Unity
https://blog.unity.com/engine-platform/2d-puzzle-match-3-sample-gem-hunter-match

Это нам надо. И VFX, и применение нормалмап к игровым объектам. Помню я с кем-то пил на какой-то геймдев конфе и мы обсуждали, что люди любят матч-3 по принципу сорок. Всё блестит, взрывается, перестраивается, милллиард комбо. Vampire Survivors в целом это доказывает из последнего. И тут видимо помимо генератора уровней и простого интерфейса даже с этим немного поморочились. В общем на досуге надо будет разобрать :)

#новости

О работе рендера в 3д играх
https://devsdaddy.medium.com/how-it-works-3d-games-a-bit-about-shaders-and-how-the-graphics-pipeline-works-in-unity-2f9fb1a404c0

Простенькая обзорная статья про рендер. Есть ряд полезных ссылок, но в общем скорее скомпилированный набор информации из разных мануалов. Для новичков может быть полезно.

#новости

Про производительность и профайлинг
https://medium.com/huawei-developers/discovering-the-secret-to-fluid-gameplay-an-in-depth-exploration-of-unity-performance-profiler-607dd3d74a1d

Классная статья про профайлинг. Разбор узких мест, связи с лайфсайклом юнити, типа «узких горлышек» и обзор инструментов анализа. Для среднего Unity проекта этого прям даже достаточно, хотя это не все существующие приколы. По крайней мере категории того, как можно убить что CPU, что GPU.

Аж даже флешбеки были о том, про что тут нет. Профайлер классная штука, но он совершенно не умеет работать с огромными массивами данных. Поэтому вообще говоря о профайлинге перфоманса, лучше уметь работать с System.Diagnostics и Stopwatch.

Я когда-то довольно часто под заказ на Unity визуализировал графы. В них были 1000 вершин. С графикой там всё просто. GPU Instancing наше спасение. Да и не все вершины обязательно рисовать. Плюс с физикой для кликов по вершинам я тогда разработал простенькую систему рейкастов, так как Unity была сильно уж прожорливой :) Но в какой-то момент у меня появились фризы. В чём было дело уже не помню, но я разобрался.

Основное что я тогда обнаружил — когда у тебя в память загружен конфиг json на 1000 вершин графа, дип профайл сходит с ума и дико виснет. По нему вообще нереально что-то понять. Поэтому я начал прокладку логов и часиков, чтобы понять «где болит» по логам. Особенно учитывая то, что болел алгоритм укладки графа в пространстве (ведь граф надо не только нарисовать, но ещё и показать красиво в пространстве). А он вообще жил в своём потоке. Помню мне тогда приглянулась идея того, что вершины графа — это магниты, а рёбра — это пружины.

Но кроме таких весьма редких кейсов статья в целом разбирает то, что может пригодится в среднем, если игра тормозит.

#новости

Гриша-бизнесмен: Выводы

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

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

Когда я организовывал юнити митапы в Москве, я вообще был мидл разрабом, который только окончил вуз и денег у меня особо не было. Большая часть денег так сказать уходила на квартиру и еду, и решение каких-то дополнительных жизненных проблем. Тем не менее без бюджета на продвижение я собирал на митапе, пусть и на бесплатном, по 100-200 человек. Каким образом? Сначала мы составляем таблицу потенциальных групп в вк, каналов, блогеров и т.п. где мы можем рассказать про митап. Потом мы пишем каждому что мероприятие бесплатное и давайте я ещё в инфопартнёров логотипом на сайте митапа добавлю. Заходим в тильду и верстаем там сайт. Разбираемся с мейлчимпом и организовываем рассылки. У меня их было 3: успешная регистрация, за неделю до ивента и за день до ивента. И я сидел и всё это самостоятельно верстал, настраивал, со всеми договаривался и так далее. И это чисто продвижение. Без найти площадку и найти спикеров. То есть для запуска одного митапа раз в квартал я тратил думаю часов 100-150 своего времени.

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

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

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

Переключаться между рынками, видеть некоторые предпосылки будущих проблем, думать как сглаживать риски — так как какая-то фигня происходит всегда. Что самое забавное главное отличие текущей деятельности от студийной — я занимаюсь по итогу сейчас побольшей части играми на Unity. А во времена студии у нас больше было образовательных и индустриальных задач. Тренажёров и т.п. Они сейчас тоже есть в какой-то доле, так как стек технологий тот же самый по сути. Но тем не менее игры сейчас основа.

И на этом историю до 2020 года можно закончить. Дальше уже были прогулки по лесу с глубокими размышлениями, вино с аниме сутками, понимание что делать дальше и так сказать новый запуск деятельности уже в совершенно другом формате. Напонимаю про 100 🔥 на прошлом посте. Но и на этот накидать не возбраняется :)

#приключения

Отправка данных из Unity в Google Forms хаком
https://www.youtube.com/watch?v=WM7f4yN4ZHA

Прикольный способ, чтобы собирать обратную связь или сообщения о багах в игре. Но опасный безусловно, как и любое решение подобного класса. Главный риск, который нужно проговаривать в таких решениях — это их работоспособность в долгосрочной перспективе. Любой подобный "хакинг" вместо использования официальных API обладает одной важной проблемой. Гугл чёт поменяет в работе сервиса и всё сломается. С официальным апи такого не пройзойдёт

И сколько же у меня ностальгических проектов. И я делал давно подобные штуки. Я же разработчик как никак. А разработчик по определению должен быть что называется "странно ленивым". Любой разраб хочет автоматизировать всё. Странно ленивым, потому что потратить 2 часа вместо того, чтобы сделать руками за 5 минут — это милое дело. Так что лень разработчика весьма специфична.

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

Дальше к этому всему я написал мобильное приложение, которое нужно было чтобы "модерировать мероприятия" + парсинг дат мероприятия был ненадёжным, так как в формах нет сбора данных формата DateTime. И к этому приложению я прикрутил телеграм бота, который в свою очередь одобренные посты отправлял в личку для публикации в трёх случаях. Когда оно только прошло модерацию, в еженедельный дайджест и в ежедневный (если мероприятие проходит по датам).

Поэтому ведение канала у меня не отнимало особо много времени. И когда-то я хотел его даже продать со всей айти обвязкой кому-нить, так как уже понимал что не буду вести. Но потом стало впадлу и я положил всю инфраструктуру (плюс оплачивать сервера в амазоне сейчас гемор, а переводить в мою инфраструктуру в РФ было впадлу опять-таки). И в целом до того момента пока я не положил эту историю, она работала без интеграции гугл драйв апи в приложение. Мне кажется с той же локализацией в играх можно поступать +- так же, если она хранится в гугл таблицах.

#новости