Григорий Дядиченко

https://www.youtube.com/watch?v=qiAiVa0HtyE классный туториал созданию расщелин в земле. В целом весь канал довольно интересный :)

Туториалы — это целое искусство Надо запомнить простое правило. Как только вы говорите: "да пользователи поймут" — не поймут. Вообще не поймут. И это нормально. Ну то есть иногда это срабатывает весьма неочевидно, и это проблема туториала, а не пользователя. У вас всегда должен быть туториал, объясняющий каждую запятую. Потому что это одна из основных причин из-за чего пользователи не будут играть в игру — они не поняли, как играть) В моменты запуска каждый знает, что ты просто живёшь в аналитике. Смотришь где по какой причине был отвал пользователя. И как примеры не понимания возьмём для примера эту игру https://whitelabelgames.ru/game/ar-bow Казалось бы туториал на месте, всё вроде в порядке. Но туториал уже притерпел небольшие изменения. Изначально текст на первом слайде был: "Стреляйте по шарикам нажимая на экран." Но как я посмотрел по аналитике не все пользователи догадались о том, что нужно зажимать, и от зажатия лук натягивается сильнее. Поэтому текст переделался на "Стреляйте по шарикам нажимая на экран. Удерживайте экран зажатым, чтобы выстрел был сильнее.". И да, судя по аналитике и времени на каждом слайде — люди читают такие тексты Второе чего я вообще никак не ожидал. На первом слайде у нас есть скриншот из игры. И один пользователь вчера упорно пытался выстрелить нажимая на эту картинку. В конечном итоге он разобрался, но вот пример "да тут всё понятно". Иногда поведение пользователей бывает весьма неочевидным :) Конечно лучше работают интерактивные онбординги или вроде того, чтобы объяснить что-то пользователю. И делать их не то, чтобы супер сложно. Но игра тут очень простая, и у туториала есть одна хитрая цель "развлекать пользователя, пока грузится юнити". Вместо того, чтобы 5-10 секунд смотреть на загрузку, он как раз проходит обучение. И это по сути один из трюков, как можно скрыть загрузку в подобных кейсах, и не потерять пользователя потому что он не хочет ждать :) Ещё в вебе можно так же поверх делать авторизацию, если она необходима для игры и многие другие трюки :) А почему туториалы искусство? Ну на самом деле это больше искусство аналитики и плейтестов на игроках, которые не делали эту игру. Так как самостоятельно всё учесть почти нереально. При разработке глаз замыливается и многое начинает казаться очень очевидным)

Интересный доклад про освещение https://youtu.be/F3hIculYFwM

Интересная фишка яндекс метрики Это связано с продуктом :) Почему ещё прикольная фишка — выносить интерфейс из WebGL Ну первая причина довольно проста — это шрифты. Со шрифтами в рендером их в WebGL есть нюансы, как и с рендером векторной графики Но одно наблюдение, которое для меня стало любопытным — это вебвизор. Вебвизор не видит webgl, но видит интерфейс на нативе. Поэтому можно предположить, как играл игрок, и какие части игры нужны поправить, как именно произошёл отвал. У нас там онбординги так же рисуются поверх вебгл нативом, поэтому так же видно, как пользователь проходил онбординг Это важно, так как у Unity есть нюанс того, что сложные игры (скажем с 3д), могут грузится долго. А нативный интерфейс мы можем отрисовать моментально, поэтому одна из целей онбординга была — скрыть загрузку. И как видно по вебвизору — она часто справляется, многие долистывают его до конца, когда игра уже загрузилась :) Интересное наблюдение на тему анализа поведения игроков в веб играх так сказать :)

Небольшой анонс продукта Наконец-то я рад сообщить, что мы доделали первую версию продукта http://whitelabelgames.ru/ Промо-игры и Playable Ads под заказ. Если вы знаете, кому это может быть полезно — поделитесь с ним ссылочкой :) Это был долгий и сложный путь, но в целом продукты делать весело. Самой сложной частью было наверное выстроить сам процесс. Игры там довольно простые и маленькие, не все допилены пока до логического финала, но многие уже готовы именно для рекламы) С луком очень залипательно получилось, хотя и довольно просто. Можно всё было сделать конечно быстрее, но продукты — это всегда путь проб и ошибок :) Хотя я уже давно больше занимаюсь бизнес решениями, но от игр так просто не уйти XD

Прикольный урок по созданию чёрной дыры через VFX и Shader Graph. Довольно быстрый и простой :) https://www.youtube.com/watch?v=FlE8e1JwVzs

Пример неочевидного знания Тут опять начнём с истории. Мой путь в игровой индустрии начался с раннеров. Когда я только выиграл с ребятами хакатон https://habr.com/ru/company/microsoft/blog/239885/ , мне захотелось выучить юнити и научиться делать игры :) (Боже мой, на 4pda даже остался пост) XD https://4pda.to/forum/index.php?showtopic=661944 Ну короче говоря, когда я пришёл устраиваться в 2016 году в Nekki — у меня уже была игра в сторе XD И у неё даже было под 50-100 скачиваний! И саундтрек (который сделал мой одногрупник) Аж на 15 минут! С одной трассой) В те времена это казалось супер круто) При этом у построения раннера была гениальная идея. Трасса генерировалась так, что я слушал песню, под бит прыгал, а потом ставил редактор на паузу и выгружал полученный префаб) И вуаля — трасса готова XD В общем не умел я делать раннеры, но как говорится много желания, отсутствие страха и 3 недели (да писал я его 3 недели) работы, и у тебя есть игра в Google Play :) И аккаунт разработчика оплаченный со стипендии :) И вот я прихожу устраиваться на работу. И попадаю на проект Vector 2 https://play.google.com/store/apps/details?id=com.nekki.vector2&hl=ru&gl=US Аля геймдизайнером. И там уже раннер делается по взрослому) Конечно речь пойдёт немного про другие раннеры, не такие сложные как вектор, но суть +- одна, и правда это не только для раннеров) Так вот, это для меня тривиальное знание, так как я делал в своё время в целом много раннеров. Чистый рандом — это скучно. Раннер нужно делить на куски трассы, делать множество интересных кусков с разной сложностью (чем активнее и больше нажатий нужно для прохождения куска, по отношению с его длинной, тем он в среднем сложнее) И дальше хоть конечная, хоть бесконечная трасса собирается рандомом из этих кусков. И получается интересный раннер. Если сделать таких кусков штук под 100, то пользователь не заметит даже этой тайловости) И казалось бы концепт простой, реализация элементарная. Но на самом деле когда ты сидишь перед чистым листом, без опыта и не знаешь с чего начать, это знание сильно упрощает жизнь. Конечно жанр ранеров уже не так популярен, но тем не менее, если хочется сделать интересный раннер, то делается он именно так. Так проще и баналсировать, и настраивать, и регулировать вовлечение игрока :) P.S. Если кому-то интересен трек, то можно послушать в старой группе в вк https://vk.com/hyplion

Абстракции усиливают цетрализацию Когда-то давно я обсуждал на работе в KamaGames (я там работал несколько лет назад) абстракции и почему они зло. В целом мне очень понравился один аргумент — абстракции усиливают централизацию. Код должен быть простым, и нигде не нужно уходить в крайности. Для любого примера можно придумать крайний контр пример) Но представим что у нас есть абстрактная фабрика создания объектов. И мы решили её абстрагировать так, что её наследники или кто-то ещё создают в игре противников, и создают предметы в игровом магазине. Она же простая, просто создаёт объекты. Система растёт, усложняется, приходят новые разрабы, которые уже 150 раз забыли или не знают про эту связь. И что-то меняют в логике базового класса так, что в магазе работает как надо, а противники спавнятся неверно) И вот мы получили, «я изменил это, а сломалась вообще другая часть системы». Хотя всё на паттернах, по солиду, по ооп :) Это не нарушение ООП, не увеличение связности, паттерны остаются на месте. Просто это косвенная связность реализаций. Поэтому чем абстрактнее код, тем он централизованней :) Другой край разработки, это наоборот полная децентрализация. На каждый чих свой класс, куча дублирования, очень много времени на разработку каждой фичи) Но за это вы получаете (с опять-таки норм архитектурой) замечательную устойчивость кода к изменению. Так как системы ничего даже косвенно не связывает :) Поэтому правда где-то посередине :) Обобщения должны руководствоваться не логикой кода, а логикой человека. Магазин и противники — разные в своей сути, так что я считаю, что удобнее разделить их реализации совсем :) Но в целом ничего плохого в обобщении и закладывании такого риска нет :) В архитектуре многое вопрос вкусов :)

Не ошибается тот, кто ничего не делает Чтож, видимо первая сегодняшняя статья будет первой заминусованной из моих 27 статей, но всё бывает в первый раз. Я уверен, что проблема в форме подачи и заголовок, потому что сама по себе информация и реп — норм :) Возможно для новичков получилось слишком сложно :) Вот что я вам хочу сказать. Мне не так интересно учить профессионалов. Профессионалы и сами всё знают, они обычно занимаются узконаправленными задачами, и кроме каких-то архитектурных вопросов. В остальном я могу скажем написать про то, "как правильно применять и реализовывать фильтр Маджевика в задачах фильтрации шума позиционного трекинга построенного на принципах визуальной одометрии", у меня даже анализ разной параметризации валялся. Только думаю, что в реальной работе это поможет 2-3 людям занимающимся подобным классом задач. Там нет идей которые можно позаимствовать, там нет концептов, там дофига матана XD У меня в памяти просто ярко отпечаталось две вещи, из-за которой я с большим скепсисом отношусь к понятию "да это элементарно". Реакция на эту статью https://habr.com/ru/post/359106/, но более ярким было другое. 5 лет назад я вообще не понимал, как работает сеть. Понял я сеть, когда прочитал эту книжку https://t.me/dyadichenkoga/54 Но в те времена я был инди с горящими глазами, ходил по хакатонам, на DevGamm и White Nights. И в какой-то момент я очень захотел сделать что-то вроде тавер дефенса с непрямым управлением с двумя игроками играющими друг против друга. Важно понимать, что количество и качество уроков сейчас в разы выше, чем в те времена. Да и в целом количество материалов. Собственно по юнити ничего не было, и я пытался сделать это как-то на кривой козе по урокам шарпа. И ничего не работало. У меня работало, а на двух устройствах (я брал ноут соседа по общаге) — нет. И всё дело было, как оказалось потом, в фаерволе. Я написал небольшую заметку про суть тут https://noxatra.ru/firewall-setup-tutorial.html Я просто случайно как-то наткнулся на объяснение, так как тогда это не гуглилось Ура. Я могу показать это? Ну не совсем. Я ещё хотел, чтобы потом можно было дать архивчик на флешке кому-нибудь, чтобы он мог дать поиграть в демку по p2p. Вдруг издателю понравится игра, и он захочет со мной сыграть. (Эхх, эти времена моего студенческого инди, с играми которые я ща на коленке за неделю соберу, но тогда казалось очень крутым) И тогда я не разобрался, как мне выстроить p2p соединение, так как я в целом не понимал, как работает NAT. Хотя для этой задачи достаточно знать термин STUN и вся информация пробивается за 10 минут. А найти нормальный стан сервер, да и поднять его, задача на 1-2 дня для сеньор разраба) Поэтому я уверен в существовании "проблемы профессионалов". Они считают многие знания тривиальными, так как для них они стали таковыми. Они не понимают, зачем периодически повторяться и говорить о каких-то темах, так как забывают что всегда появляются новые новички, которым никто ничего не объяснял. Поэтому я люблю больше рассказывать про простые вещи и писать на простые темы с простыми примерами :)

Написал по вчерашнему решению статью на habr https://habr.com/ru/post/661363/ + дописал ридми в гите https://github.com/Nox7atra/AR-Fast-Demo . Кому будет полезно — можно пользоваться :) Концепт решения в целом может пригодиться кому-то для простой утилиты для тестирования бандлов без частых пересборок. Докидывая скрипты конечно пересобирать прийдётся, но чисто можно протестировать побыстрому производительность контента на целевом устройве.

Прикольный пример применения скалярного произведения векторов https://medium.com/nerd-for-tech/game-maths-dot-product-d3f063192cd6

Пример nginx.exe в качестве поля в инспекторе, а то Telegram не позволяет всё в один пост сделать. Прошу прощения за столько вечерних нотификаций :)

Ну и собственно It's Alive! Оно работает. Правда тут нужно уточнять все нюансы, которые я завтра напишу в Readme репозитория + может сниму видео с айфона покачественнее, так как это мой тестовый Redmi Note 8, и на нём с AR не тормозит, а вот запись скринкаста ещё как :)

Не всегда нужно писать код Особенно в редакторе. В современной разработке есть очень много прикольных консольных утилит или программ. Если мы говорим про редактор (который у нас вероятно на какой-то платформе, но я работаю в основном на винде), то там можно запускать довольно много прикольного умея работать с процессами. Так как на сегодня я устал, и завтра хочу уже написать полноценный пост про штуку, что я делаю, и ридми к ней) Но сегодня скорее общая мысль https://github.com/Nox7atra/AR-Fast-Demo я делаю такую тулзу. Она отвечает за то, чтобы простенько грузить себе бандлы с графикой, чтобы не пересобирать на каждый чих проект в билд (особенно на айос) для тестирования. И поэтому я решил локально поднимать сервачок с бандлами, и иметь простенький гуй, чтобы со всем этим работать. Изначально я думал взять свою же либу https://github.com/Nox7atra/UnitySimpleHttpServer Но её надо переписывать, а конкретно поддерживать gzip, сервер там слишком топорный) Что же делать? Ну есть старый добрый nginx, который умеет очень много, но на базовом уровне весьма простой. И в целом его можно запускать кнопками в редакторе. Так что я положил его в проект, сделал простенькую обёртку и вуаля — работает :) И в этом плане в юнити очень удобно, что любой файл в проекте можно засунуть в инспектор, как UnityEngine.Object, и через AssetDatabase.GetAssetPath получить его путь. А остальное уже дело техники :)

Немного экспериментов с новым доступом к камере AR Foundation :) Вокселизацию пространства стало делать в разы удобнее и элегантнее :) Буквально 200 строк кода :) В воксельном мире даже бардак смотрится стильно :)

А я и не знал про эту фишку в ARFoundation, теперь без плясок с бубном видимо можно переводить фрейм камеры устройства с GPU на CPU :) Это прям мегафича, потому что так в разы проще дружить те же ARKit + QRCode, ARKit + OpenCV. Ещё и с параметрами можно конвертировать чтобы откинуть инфу о цвете или же сделать даунскейл — кайф :) Просто с юнити и компьютерным зрением всегда была такая проблема, что очень тяжело нормально получить данные о кадре камеры и приходилось плясать с бубном :) А не все алгоритмы работают на GPU https://docs.unity3d.com/Packages/com.unity.xr.arfoundation@4.1/manual/cpu-camera-image.html

Роадмап Unity 2022 на GDC Которая выжимка самого интересного, что рассказали: 1. Наконец-то можно будет указать, где хранить пакеты и мультиселект. Мелочь, но когда нужно пачками отключать билтин пакеты и функции — отсутствие мультиселекта бесит) Ещё бы можно было в хабе создавать свои тимплейты манифеста пакетов - я был бы просто счастлив. Знаешь что тебе в проекте всегда нужен один, указал в манифесте, создал такой тимплейт, проект создался с нужными пакетами. Но мечтать не вредно, хотя может как-нибудь введут. Технически с текущей системой это довольно просто. А сейчас приходится это делать ручками 2. Кастомизация поиска — кайф 3. Поддержка хоткеев с мышью в редакторе — хотеть 4. Про URP вообще ничё интересного — "всё будет лучше" и "покажем как надо на нашей игре" 5. HDRP — рейтрейсинг в 4к и варианты материалов это любопытно 6. VFX Graph — улучшение инструментария, что всегда кул 7. Прикольные улучшения для энвайремент артистов 8. Adaptive Probe Volume доедет до URP 9. Деформации, спрайт свап и инвёрсная кинематика в движковом инструменте для создания 2д анимаций 10. Sprite Shader API — хотеть. Конечно шейдера и сейчас можно писать, но с плясками с бубном. Если сделают удобнее — кайф 11. Улучшения Memory Profiler — кайф Я взял только то, что интересно мне, так что рекомендую глянуть если что) Ещё может и не зря юнити дропнули проджект тайни. Так как по тому, о чём речь, их идея сделать, чтобы Unity можно было без всяких пакетов использовать для легковесных WebGL игр. Ну поживём — увидим :) Сам ролик: https://www.youtube.com/watch?v=jBK4evXbsI4&list=PLX2vGYjWbI0TMJrYFmLi-inr7DiIkGO4W&index=4

Обожаю спотлайты того, что делают разные команды на Unity. Там много очень красивых вещей :) https://www.youtube.com/watch?v=eGMMPMSVmVA

Мини анонс, что для канала WIP Я подумал, что будет прикольно на сайте оформлять сниппеты сразу с WebGL визуализацией того, что он делает + текстовым описанием Так можно будет оформлять шейдера (правда не все в вебе будут работать конечно, поэтому надо наверное предусмотреть замену на видео), оформить так паттерны и многое другое. Осталось собрать удобный веб тимплейт :) И написать пост процессор билда, который по конфигу будет генерировать это) Потому что пихать C# ход в html или hlsl руками — это дико неудобно Если считаете, что так будет полезно и наглядно — ставьте 👍 или 🔥 :) Просто объяснения паттернов в телеге простым языком — это конечно хорошо, но наверное где-то должна быть их компиляция с возможностью посмотреть и в интерактивной форме лучше вкурить о чём речь :)

О, новые покемоны + тамагочи в AR :) https://www.playperidot.com/en Зачем в механике тамагочи AR мне не совсем понятно, но будем посмотреть) Вдруг Niantic придумали что-то интересное :)