Прототипирование — это очень круто

Когда-то давно я преподавал в ВШБИ курс прототипирования. Преподавать в целом полезное дело, просто у меня сейчас слишком много дел, чтобы этим заниматься (куча проектов, разработка и запуск нескольких своих продуктов вроде https://whitelabelgames.ru/) Поэтому честно говоря ну не до того. Ещё тут чёт писать и рассказывать :) В общем не суть :)

Когда я готовил курс я перерыл просто тонну материалов по прототипированию и сам прошёл несколько таких курсов. И как же много вещей можно проверить, посмотреть и т.п. прототипом, и как же редко у нас пользуются прототипированием. Это полезно в согласованиях, полезно для понимания того, как будет работать проект, да может быть прикольно в качестве "тимбилдинга". Помню во времена студентом партнёром Microsoft мы из лего, чет собирали. Но в общем собирать бумажные прототипы занятие довольно прикольное. И да, сейчас есть много инструментов прототипирования, можно прототипировать прям в Unity, но игры отлично прототипируются и на бумаге, да и приложения тоже, особенно UI. В разы дешевле напечатать картинки, чтобы подержать в руке "устройство", которого у тебя нет физически. Но почему-то в РФ я чаще всего видел 3 проблемы

Прототипированием не пользуются

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

Прототипы делают супер сложными

Очень часто проблема в прототипировании, что то что называют прототипом вот ещё чуть-чуть докрутить и можно в продакшен. Прототип должен быть сделан максимально "на глаз", и должен быть выкинут

Прототипы развивают

И это самое страшное, и следует из прошлого. Прототип нужен для того, чтобы сделать его максимально быстро и дёшево, и выкинуть. Прототип который делается 2 недели — это не такой частый кейс. Ну то есть это не прототип механики, это системный прототип. Даже я такие делаю под заказ для различных корпораций, где может быть месяц разработки прототипа, но там на продакшен систему нужно 2-3 года и этот "прототип", это чуть ли не MVP или Proof of Concept. Просто крупные компании могут себе позволить за него заплатить и выкинуть его, когда проверят то, что им надо. А вот то, что мы что-то запрототипировали и потом продолжили докручивать, и перенесли в прод — это в среднем очень плохо, и лучше так не делать

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

Интересный ролик по GPU анимациям

Так как в SkinnedMeshRenderer не работает батчинг и гпу инстансинг бывает полезно запечь анимации в текстуру и использовать. В ролике как раз объясняется такая техника. Да и в целом всегда полезно помнить такую вещь, что текстура — это просто массив данных, и как по примеру с параллакс маппингом, нормалями и т.п. в ней можно хранить много интересного помимо собственно цвета)
https://www.youtube.com/watch?v=KUuuXowdYyM

Отсутствие информации — это тоже информация

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

Так, а к чему заголовок то? Сегодня поговорим про бинарную сериализацию, и в целом про одну забавную идею, которая много где используется. Разберём для этого классическую задачку. У нас есть массив [0, 1, 0, 1, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0,2]. Но чтобы задача не была такой сухой представим что это трасса в раннере где:

0 — свободный кусок трассы
1 — это препятствие, которое нужно перепрыгнуть
2 — финиш

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

Итак, допустим наши числа — это инты. Инт в C# — это Int32, то есть 4 байта. В нашей трассе 15 символов, то есть 60 байт. Но с числами "0", "1" и "2". мы можем сразу взять не тип int, а тип byte. Он весит 1 байт, так что суммарно мы выиграли в 4 раза, то есть до 15 байт. Можно ли ещё что-то сделать?

Во-первых, так нам не нужен финиш в виде отдельного числа, так что отбросим 2. Осталось 14 байт. А вот второе уже будет посложнее. Чуть-чуть изменим кодировку. Байт принимает значения от 0 до 255. Для упрощения мы считаем, что любая трасса начинается с хотя бы одного 0 (по сути в раннере в начало мы всегда можем поставить пустой блок, и это ничего не испортит игроку) И так как у нас всего 2 типа "пустое" и "с препятствием", то мы можем ту же самую трассу вполне записать как

[1, 1, 1, 2, 1, 1, 7] — что уже в типе байт займёт 7 байт вместо 15. Суть такой кодировки к том, что мы знаем что наша трасса начинается с нуля. И знаем что есть только 2 типа. Поэтому каждая цифра массива означает сколько значений следующего типа дальше.

Сначала у нас 1 ноль (то что трасса всегда начинается с нуля важно, чтобы тут не было разночтений)
Потом одна единица
Потом один ноль
Потом две единицы
Потом один ноль
Потом одна единица
И потом семь нулей

И вот мы с 60 байт снизили вес нашей трассы до 7 байт. То есть в почти в 10 раз. И на большом масштабе это уже имеет большое значение. Если же данные не индексируемы можно вообще не писать то, что не представляет ценности. Таким образом в целом созданы многие алгоритмы сжатия. Есть алгоритмы сжатия которые находят паттерны в файлах или данных и составляют словари, которые уже состоят из меньшего числа символов чем паттерн и дальше файл представляет из себя такой словарь + серию сериализованных ключей

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

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

Изобретение велосипедов

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

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

Поэтому размышлять и изобретать велосипеды классно. В коммерции я предпочитаю сначала "погуглить" решение задачи, чтобы просто не тратить лишнее время, но на досуге почему бы не поизобретать велосипеды?) Плюс изобретение велосипедов по-моему опыту учит "правильно гуглить", что является чуть ли не 50% работы современного разработчика. В общем изобретать велосипеды весело. Да и когда "сам придумаешь", сразу понимаешь "что ты придумал", пусть оно даже уже есть :)

Выбрался из дома

Иногда у Unity свой путь

Юнити меня всегда немного поражало удивительным навыком забивать на стандарты. Причём на свои же. Когда-то было хорошим тоном делая ассеты делать релизы в виде unitypackage. И если майкрософт в своих пакетах для юнити делал всё чин по чину, с версиями, с пакетами. Типа скажем MRTK SDK, всегда можно было скачать любой версии с примерами для любой версии, и это пакет майкрософта) А для сравнения ARFoundation нужно было клонировать правильные коммиты в репозитории самого фаундейшена, и самих самплов)

Ну не суть, теперь появился новый прикол. Ковыряясь в hdrp я нашёл, как Unity решили поступить с картами Roughness, AO, Metallic и т.п. Идея прикольная, всё в одну текстуру на разные каналы — кайф. Но как всегда есть нюанс — удобство) Юнити предлагает идти и обрабатывать карты в фотошопе XD И казалось бы, почему не сделать инспектор и постпроцесс билда, или по аналогии со спрайт атласами постпроцесс отдельных текстур в одну перед плей модом. Но это же для слабых духом, сильные в фотошопе делают текстуры)

В общем я сделал простое редакторное окно, которое позволяет генерировать эту текстуру в редакторе. Так сказать для подписчиков Early Access. Чуть позже подкручу документацию, подключение пакетом, инструкцию как пользоваться. Но всё просто в целом. В верхней панели открывается окно в вкладке MaskTexGenerator и дальше в окне, либо в режиме Label кидается папка с текстурами и лейблами (не советую этот режим пока, он требует документации), либо в режиме Object просто кидаются текстуры, которые потом объединятся в единую разнесённую по каналам. Может кому-то этот реп сэкономит время. Потом для полноты ещё докину старый прикол с записью Roughness в альфу https://github.com/Nox7atra/MaskTexGeneratorWindow

А причём тут свой путь и стандарты? Так как софт моделлерский обычно не поддерживает такое, и это нужно делать руками. Многие я вообще замечал, что не знают куда сунуть Roughness карту, когда им её отдают, и тупо её не используют. Хотя в стандарт шейдере и pbr рендере она важна для визуала)

Дописал-таки небольшую статью про VFX Graph и вихри https://habr.com/ru/post/668332/

Прикольный сайт-книга по ИИ в играх http://www.gameaipro.com/

В целом игровой искусственный интеллект — это часто система принятия решений, которая существует в виде двух форм и их модификаций. Behavior Tree и Finite State Machine. Что-то более сложное часто представляет более научный интерес нежели реально используется в играх. В большинстве игр иллюзию искусственного интеллекта создают километровые файлы конфигурации. Но в целом тема глубокая и интересная. И я понял, что в статьях я её как-то не касался. Надо будет написать материал по ИИ в Unity, где запрототипировать 2д битву с боссом, чтобы показать способы настройки и организации ИИ в том же платформере) Ну конечно если не брать базовый пример ИИ в Unity в виде Navmesh и Pathfinding :)

Интересная работа про траву

https://publik.tuwien.ac.at/files/PubDat_220935.pdf

Прикольный туториал по VRX на Skinned Mesh https://www.youtube.com/watch?v=yW1uXjnq14Q

Lua в модах

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

В код нельзя пускать ни геймдизайнеров, ни игроков. Код штука тонкая, его можно сломать, нарушить неочевидные оптимизации и в целом, это то место где не программистам в нормальном проекте делать нечего. Геймдизайнеры по сути те же разработчики модов, только в виде кор гемплея и игровых механик, могут для настройки игры пользоваться редакторами и скриптовыми языками, типа того же Lua, но они не должны лезть в код

В чём плюсы луа?

— Его быстро учить (я нашёл вообще замечательную ссылку)
— Его часто используют для модов Roblox из последнего. World of Warcraft и многие другие игры брали за основу луа, так как он простой. А значит мододелы и игроки его знают (хотя бы иногда, в отличии от вашего замечательного своего языка). Даже в TableTopSimulator используется Луа https://steamcommunity.com/sharedfiles/filedetails/?id=842872619
— У него есть бесплатные и открытие интерпетаторы типа https://github.com/moonsharp-devs/moonsharp
— Это именно скриптовый язык, который не оброс миллиардом фреймворков и комьюнити программистов

Просто если брать другие интерпретируемые языки. Тот же Python. Да, под него тоже есть забавные тулзы, типа https://ironpython.net/ (пиши на питоне используя .Net фреймворк, даже с юнити можно связать при желании) Или http://pythonnet.github.io/ И как интерпретируемый язык, его можно в целом грузить в рантайме и обрабатывать построчно. Можно в установочнике игры поставить (на ту же винду) Пользователю питон, пип, чёрта в ступе) И научить его ML, вместо написания модов для игры XD

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

Конечно есть ещё Lisp или как его ещё называют язык смайликов или Forth. У которых так же легковесные интерпретаторы) Но они не сравнятся по популярности с Луа, да и по удобству) В общем рекомендую ознакомится с луа на досуге :)

Идеально :)

https://youtu.be/sW9npZVpiMI

Игры про хитрости

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

1. Geometry Dash — там музыка не подстраивается под игрока, но трасса выверена по ритму. Когда-то давно я такое строил просто на слух. Так как в далёком прошлом у меня за плечами 7 лет музыкалки по классу скрипки, конструктор представлял из себя то, что я просто под музыку нажимал пробел, ставились препятствия, а потом я сохранял результат. Это очень долгий путь. И неточный, так как нельзя нажать пробел моментально) И я думаю разумнее такие ритм-трассы строить попросив саунд дизайнера (либо самостоятельно) выделить биты из трека, сделав визуализатор саунд вейва, который от скорости движения будет менять свою длинну, и расставлять прям по битам в треке. В разы быстрее и удобнее)

2. Beat Saber — тут уже по разрезанию кубов идёт дополнительный бит сочетающийся с треком. И казалось бы, использовать подход выше и всё хорошо. Суть +- та же, под биты расставить кубы, да пусть режут в своё удовольствие, по коллизии воспроизводить звук. Но ритм штука такая, что чуть опоздал и уже не звучит) Поэтому тут делается ещё одна дорожка с битом саунд дизайнером, сочетающимся с треком. И кубы ставятся по нему. А коллизия запускает проигрывание нужной части этого бита, в нужный момент времени в треке. По сути кубы получаются чем-то вроде маски для дополнительного саундтрека. Тогда это действительно будет хорошо звучать

К чему это я? Часто новички в отсутствии опыта стараются делать всё слишком "буквально", забывая что игры или любые другие интерактивные шутки в первую очередь должны быть не "точными", а интересными)

Простые лицевые анимации в Unity

Найду время напишу полноценную статью и свой инструмент, так как Unity в своём репертуаре. Мне иногда кажется, что ребята просто не любят рассказывать про фичи своего движка или недостаточно говорят, так как удивительно, что я разрабатываю на Unity 6 лет и постоянно нахожу что-то прикольное. Просто Unity разработчик — это не разработчик, а археолог. Вторая беда Unity — это просто патологическая не любовь к стандартным решениям. Почему-то в их пакете всё сделано "по-своему", так что наверное я всё же чуть позже оформлю свой пакет для +- той же задачи. Хотя чего удивляться, я всегда говорю, что: "у Unity свой путь". Так вот. Есть такой прикольный пакет. Он позволяет достаточно дёшево записывать простые лицевые анимации с помощью айфона. Я в целом люблю такие инструменты для инди и небольших студий, которые не могут себе позволить камеры по 10к$ и другой очень дорогой софт для "взрослого трекинга". А упрощать процесс создания контента надо всем. Цены бы Unity не было делай они часть своих пакетов на отъе... Ну да не суть)

Этот пакет, пусть и довольно странный с точки зрения рига, позволяет записать анимацию в Unity анимации (меканимовские) и использовать в своём проекте. Поэтому рекомендую поковырять на досуге, мало ли вдруг пригодится. Ниже скину видео, как работает. В целом меня всегда радует демократизация технологий, хотя я и не прощу эплу покупку IKinema Orion, так как благодаря ему раньше можно было собрать сетап за 3к$ и делать такой фуллбади мокап, что для игр и небольших проектов — кайф . Может показаться, что 3к$ — это много, пока ты не знаешь, что настоящая фулбади мокап студия стоит по 5-10к$ за камеру, а их нужно саааамый минимум 3. А со всей переферией там выходит 50-60к$, что уже может быть ощутимой частью бюджета проекта. Если конечно ещё xsense и подобные, стоящие по 4к$ за костюм (что не дешевле). Но у них ещё и свои нюансы. В общем раньше покупаешь Vive, комп, несколько Vive tracker и лицензию на Ikinema orion за 500 фунтов. И с этим уже можно работать)

Если кому-то интересно, то я могу побольше рассказывать про трекинг, про дешёвые инструменты трекинга, компьютерное зрение (в контексте применения к проектам на Unity), да и в целом технологии, которые стали сильно дешевле за последние 10 лет. Так как всё-таки с этим я был в основном связан последние 6 лет. Систем много, технологий много, и некоторые из них по карману даже небольшим студиям и командам. Та же лицевая запись с айфона, отличный пример. Да, качество не Faceware безусловно, но работать в целом можно :) И если нужно несколько блендшейпов для диалогов, или набор анимаций для простенького синематика по-быстрому сделать, то это вполне неплохой путь)

Разработчики спорят о том, какой движок лучше) Отличный сериал кстати

https://www.youtube.com/watch?v=-axORNoikkI