Не ошибается тот, кто ничего не делает

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

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

У меня в памяти просто ярко отпечаталось две вещи, из-за которой я с большим скепсисом отношусь к понятию "да это элементарно". Реакция на эту статью https://habr.com/ru/post/359106/, но более ярким было другое.

5 лет назад я вообще не понимал, как работает сеть. Понял я сеть, когда прочитал эту книжку https://news.1rj.ru/str/dyadichenkoga/54 Но в те времена я был инди с горящими глазами, ходил по хакатонам, на DevGamm и White Nights. И в какой-то момент я очень захотел сделать что-то вроде тавер дефенса с непрямым управлением с двумя игроками играющими друг против друга. Важно понимать, что количество и качество уроков сейчас в разы выше, чем в те времена. Да и в целом количество материалов. Собственно по юнити ничего не было, и я пытался сделать это как-то на кривой козе по урокам шарпа. И ничего не работало. Точнее у меня работало, а на двух устройствах (я брал ноут соседа по общаге) — нет. И всё дело было, как оказалось потом, в фаерволе. Я написал небольшую заметку про суть тут https://noxatra.ru/firewall-setup-tutorial.html Я просто случайно как-то наткнулся на объяснение, так как тогда это не гуглилось

Ура. Я могу показать это? Ну не совсем. Я ещё хотел, чтобы потом можно было дать архивчик на флешке кому-нибудь, чтобы он мог дать поиграть в демку по p2p. Вдруг издателю понравится игра, и он захочет со мной сыграть. (Эхх, эти времена моего студенческого инди, с играми которые я ща на коленке за неделю соберу, но тогда казалось очень крутым) И тогда я не разобрался, как мне выстроить p2p соединение, так как я в целом не понимал, как работает NAT. Хотя для этой задачи достаточно знать термин STUN и вся информация пробивается за 10 минут. А найти нормальный стан сервер, да и поднять его, задача на 1-2 дня для сеньор разраба)

Поэтому я уверен в существовании "проблемы профессионалов". Они считают многие знания тривиальными, так как для них они стали таковыми. Они не понимают, зачем периодически повторяться и говорить о каких-то темах, так как забывают что всегда появляются новые новички, которым никто ничего не объяснял. Поэтому я люблю больше рассказывать про простые вещи и писать на простые темы с простыми примерами :)

Абстракции усиливают цетрализацию

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

Это не нарушение ООП, не увеличение связности, паттерны остаются на месте. Просто это косвенная связность реализаций. Поэтому чем абстрактнее код, тем он централизованней :)

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

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

Пример неочевидного знания

Тут опять начнём с истории. Мой путь в игровой индустрии начался с раннеров. Когда я только выиграл с ребятами хакатон 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

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

Небольшой анонс продукта

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

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

Интересная фишка яндекс метрики

Это связано с продуктом :) Почему ещё прикольная фишка — выносить интерфейс из WebGL

Ну первая причина довольно проста — это шрифты. Со шрифтами в рендером их в WebGL есть нюансы, как и с рендером векторной графики

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

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

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

Туториалы — это целое искусство

Надо запомнить простое правило. Как только вы говорите: "да пользователи поймут" — не поймут. Вообще не поймут. И это нормально. Ну то есть иногда это срабатывает весьма неочевидно, и это проблема туториала, а не пользователя. У вас всегда должен быть туториал, объясняющий каждую запятую. Потому что это одна из основных причин из-за чего пользователи не будут играть в игру — они не поняли, как играть)

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

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

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

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

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

Эххх, ностальгия, сегодня что-то вспомнились времена митапов, когда я делал Unity Moscow Meetup)

Уже несколько лет прошло с тех времён) Это было прикольно, в пике там собирались человек под 200, в какой-то момент к нам пришли MSI и помогли с едой на мероприятии, заказав на всех пиццу. К сожалению это отнимало много времени, и пришлось выбирать чем заниматься, своей студией или митапами) Они правда к тому моменту уже были переименованы в CGDevs, но это ещё и забавная история)

Так как я завёл корп аккаунт, и на нём был ютуб канал, то когда я решил закрывать всё, то решил больше не платить гуглу) Потому что митапов нет, и деньги тратить жалко. Но я вообще не подумал, что ютуб канал удалится, поэтому все видео записи с митапа пропали. Остались только с CGDevs, так как его я завёл на личный аккаунт. Было очень обидно. Но тогда ещё помню 360 видео набирало популярность, поэтому операторы просто принесли и поставили камеру) Так что единственный эксклюзивный артефакт той эпохи на ютубе пока остался :) https://www.youtube.com/watch?v=d-FR61OrNL8

Прикольный туториал по VFX, который отлично подойдёт для сейф поинтов или бонусов в игре :)

https://www.youtube.com/watch?v=oaDetLRJ0qQ

Как я понимаю программирование?

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

Зачем нужен продюсер?

Внезапно не кодерская тема, но тем не менее про это стоит написать :) Сейчас я всё же программист в меньшей степени)

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

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

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

Не изобретайте свои форматы

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

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

Векторные форматы — это сложно, поэтому там столько всего? Да нет, пример другого простого векторного формата — это меш и obj. Это LDraw про который я писал статью https://habr.com/ru/post/433364/ Да в целом многие 3д форматы проще чем SVG. Формат хранения 2д векторных картинок ставший стандартом хранения векторных изображений) Мы храним легковесные иконки, ну нам нужен фреймворк! :)

Ладно. Вернёмся к изначальной теме. Почему свои форматы это плохо? И что важнее когда это плохо?

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

1. Много готового

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

2. Хорошие стандарты вытачивались годами и они обобщены специально

Я понимаю, что у новичков есть мнение "ща я придумаю лучше и всех порву". Сам такой был по крайней мере. И придумать лучше в контексте конкретной задачи несложно. Просто это будет никому не нужно. Стандарты делаются не супер оптимальными, но зато общими, устойчивыми, оттестированными огромным комьюнити. И предоставляются с огромным набором инструментов в довесок. Вот реализовал я тот же парсер LDraw для Unity. Есть такой же для блендера и т.п. Ща с новыми знаниями может по оптимизирую даже его, и добавлю фич (хотя бы цвета в vertexColor шейдер писать для примера). Но помимо этого с другой стороны есть огромное креативное комьюнити, которое делает чертежи таких моделек из которых можно генерить 3д. Разукрашенное, с цветами, хоть персы марвел. И всё потому, что креативным людям дали стандарт

Но конечно же бывают крайности. Просто они бывают реже чем принято считать. Когда я в вузе занимался математическим моделированием, то там 5-10% оптимизации на своём кастомном формате могло превращаться в дни расчётов, и такое тоже есть. Но в геймдеве это супер редкость, когда вам вместо того же bson нужен свой бинарный формат. Вместо rudp свой кастомный протокол передачи данных по сети. Вместо png — свой формат картинок

И тут есть ещё одна оговорка. Интерпретация стандартов. Вы можете кастомизировать стандарт не отходя от него (как программисты) Допустим у вас паллитра в игре, что вам не нужны все 32 бита ргба, вам достаточно всего лишь 2 бит, чтобы записать все цвета игры (то есть у вас 64 цвета). Тогда в одну 32 бит ргба текстуру мы можете записывать 16 картинок. И потом кастомным парсером доставать их на рендер уже в нормальном виде. При этом у вас будут всё так же работать алгоритмы сжатия и прочие инструменты, так как это всё ещё png картинка с точки зрения системы. Лучше фантазировать и экспериментировать с таким, чем придумывать свой новый супер формат)

Компьют шейдеры

Compute Shader — это очень мощный инструмент. Они позволяют делать cущюю магию. В основном с симуляциями и отображением миллионов объектов

Сейчас конечно чаще, если задачу решает VFX граф, то используют VFX граф, который основан на компьют шейдерах (поэтому он работает не на всех платформах) Но в целом, тут как всегда. Зная низкий уровень, можно делать в разы больше. Хотя и медленнее писать :) В целом вот прикольное видео с рассказом общим про комьют шейдеры https://www.youtube.com/watch?v=BrZ4pWwkpto

Допустим одна из типовых задач решаемая компьют шейдерами — это отрисовка форматов типа ply (облако точек) Реализация пасс трейсинга. Которое разбирается в этой статье http://three-eyed-games.com/2018/05/03/gpu-ray-tracing-in-unity-part-1/ и многое другое :) Причём, так как отрисовка миллионов точек на хорошей гпу стоит не дорого, то получается делать очень красивые динамические эффекты с огромным числом точек :) В общем очень полезная штука)

Очень интересно смотрящийся шейдер https://www.youtube.com/watch?v=kr_tdKCT2Xs

Unity Render Streaming

Что-то на неделе я задался идеей сделать свой AR стриминг. Идея его довольно проста в своей сути:

1) Отправляем с устройства позицию камеры в сцене (+ записываем в память кадр видео с таймштампом, и позицию отправляем с ним же)
2) Рендерим Unity сцену исходя из полученной позиции камеры
3) Возвращаем фрейм из Unity с альфа каналом + таймштамп
4) Склеиваем 2 кадра (из юнити и видео)
5) Отправляем результат в очередь на вывод

Дальше регулируя задержку вывода в зависимости от сети и широты канала можно получить неплохой эффект. Но так как, я люблю стандарты, то писать свой протокол стриминга мне не особо хочется. Поэтому я решил поискать "а что есть готового?" И наткнулся на очень интересный пакет. Из коробки конечно он не совсем нужный функционал покрывает, но делает скажем так 80% работы. Это https://docs.unity3d.com/Packages/com.unity.renderstreaming@3.1/manual/

Сделано там всё на основе WebRTC, у него есть ряд довольно странных багов (скину скрины ниже) Но в целом для прототипа идеи попрёт. И главное вывод можно делать хоть в браузер. Хоть куда хочется

Почему важно, что он основан на WebRTC? Протоколов стриминга на самом деле много, но более менее стандартными являются RSTP, HLS, LL HLS, RTMP, RTMP Tuned, DASH, SRT и так далее. И все они в отличии от WebRTC имеют в среднем задержку более секунды. А мы же хотим "почти реалтайм")

У WebRTC же с другой стороны так же есть проблема. Он поддерживает 24 битные цвета без альфа канала. Но в целом, если мы на цветовую информацию отдадим по 6 бит на цвет, то альфу как-нить запихнём. Стандартные плееры будут конечно выводить чушь, но вот кастомный — скушает и не подавится. Что можно сделать шейдером, даже не меняя сам энкодинг-декодинг. Просто интерпретировать по-другому информацию о цвете на гпу при выводе

В общем если дойду до чего-то вменяемого, залью реализацию этого дела на гитхаб) А пакет в целом рекомендую поковырять, он любопытный :) Для моей же идеи мне кажется нужно ковырять https://docs.unity3d.com/Packages/com.unity.webrtc@2.4