«Паттернизируй это». Делая игру в соло. Часть 5

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

В предыдущей серии. Ну и ещё 3 части.

👋

Вспомнился мне тут один знакомый, с которым мы как-то работали вместе.

Он немного младше меня по возрасту и существенно младше по опыту, так как относительно недавно перешёл в программисты из банковского аналитика. Так вот помню, как он с грустью шёл на своё рабочее место после очередного общения с тимлидом и на мой вопрос всё ли с ним окей, я получил потрясающее «Я вообще не понимаю, что он говорит».

Знакомо, да?

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

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

Лично мне всегда казалось, что сама суть ведущего специалиста подразумевает умение и желание помочь и твоё высокомерие здесь нахер никому не упало.

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

К чему я это вспомнил? А вот к чему.

Как по мне, лучшего времени для разработки игр ещё не было.

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

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

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

Правда никакой «умный чатик» не избавит вас ни от анализа, ни от необходимости понимать фундамент того, о чём вы спрашиваете, потому как ИИ очень часто выдумывает, а при длительном диалоге даже с мастером запросов легко уходит в сторону, накрывая медным тазом весь контекст разговора, который вы тщательно выстраивали.

Что использовать? Да, в общем-то, всем давно известное:

А уж какой эти штуки пишут код... я даже стал немного сочувствовать тем, кто вовлечён в процесс найма.

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

По степени качества и по частоте ответов от ИИ, я бы раскидал это так:

Вариант, при котором правки были бы не нужны мне не встречался, за редким исключением, когда нужно было проверить гипотезу или же код являлся одноразовым.

Если вернуться к теме статьи, то посоветовать что-то трудно, кроме, разве что, не акцентировать внимание на C# в Unity, а стараться изучать C# как таковой, даже не смотря на тот факт, что Unity до сих пор использует Mono под капотом.

К счастью, терпеть осталось недолго. Что-то мне подсказывает, что переход состоялся бы раньше, если бы руководство и нехилая часть сообщества (особенно на официальном форуме) не представляли бы из себя невыносимо упёртых тормозов. Свидетели LTS ссаные, переходить-то всё равно пришлось.

Есть даже мнение, дескать программист игровой логики может испытывать проблемы при поиске работы в других отраслях, в силу того, что бóльшую часть специфических знаний, которые появились в ходе работы в игровом движке, придётся тупо выбросить, ибо нигде больше они не нужны. Это ещё более актуально (поправьте, если не прав) для разработчиков на Unreal Engine, где за «обогащённый вариант» С++ любой матёрый «плюсовик» плюнет бывшему игроделу в лицо.

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

Может смотрел не туда.

Так или иначе, если есть твёрдое желание околачиваться в играх, то известный в узких кругах Code Monkey выложил большой курс по C# — довольно поверхностный, но для начала — более чем.

В качестве IDE я использую Rider — с некоторого времени он стал бесплатным для некоммерческих нужд с одним нюансом: неотключаемая телеметрия (в платной версии отключить можно). Если никогда не пользовались — не поленитесь почитать.

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

Но интеграция с Unity шикарная, надо отдать должное.

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

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

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

Интересно обстоят.

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

На тему изучения я бы посоветовал две вещи:

При этом можете не стесняться спрашивать нейросети на предмет уместности того или иного решения (иной раз подсказывают они вполне годно).

Как бы я не радовался «Блендеру» как примеру и возможностей и красивого пользовательского интерфейса, и как бы я не хотел сделать всю игру не отходя от кассы, что-то хорошее из этого точно бы не вышло.

Но это возможно.

Я было даже попытался освоить UPBGE (продолжение BGE — игрового движка, который некогда был встроен в Blender), но после общения с разработчиками, которые на любой вопрос, связанный с будущим движка, отвечают что-то вроде «мы здесь энтузиасты, делаем всё на энтузиазме ради энтузиазма», я решил своё время на это не тратить.

Правильно сделал, в общем-то, но если найдётся время и желание, рекомендую потрогать — это интересно.

Пришлось взять себя в руки и принять тот факт, что связка Maya + ZBrush + RizomUV + Substance Painter/Marmoset + Unity/Unreal Engine существует и пользуется спросом не просто так (безотносительно того, хорошо это или плохо). Если Blender ещё может подвинуть первые три (особенно когда работаешь один), то альтернативы остальным при любом шаге влево или вправо превращаются в дрочево и рассказы о том, на каком большом энтузиазме тут все работают.

В плане материалов для обучения мало что изменилось с первого раза, так что можете смело перечитать — все источники сохранили свою актуальность.

Что изменилось, помимо всего прочего, так это мои навыки в 3D. Это я накидал, когда только осваивал Blender...

..это уже некоторое время спустя, но всё там же:

..а это уже в Unity на URP рендере:

Как бы там ни было, по кайфу осознавать, что задуманное в голове, когда я только начинал разработку, реализовалось лучше, чем я мог предположить. Особенно ввиду того, что я решил делать всё сам и прибегать к помощи готовых решений только в крайнем случае.

Работал в Blender + Substance, кое-где используя Marmoset для запекания (он просто быстрее), но не сказал бы, что его стоит включать в список обязательных инструментов в одиночной разработке.

Что ещё хотелось бы отметить, так это необходимость разбираться в настройках экспорта/импорта если хочется предостеречь себя от лишних проблем. Как я уже говорил, от этого процесса никуда не денешься. Это бесит. Возможно USD — решение вопроса, но я с ним не работал:

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

А вот ACES, как способ сохранить предсказуемость цветового профиля между ПО и правда работает. Во всяком случае все мои выкрутасы в Substance Painter отлично уложились в Unity.

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

Любопытно, как игровой движок меняет отношение к структуре проекта (когда ничем другим, кроме программирования ты не занимался), ведь структура, по сути, не одна, а целых три:

Как реализована поддержка C# в Unity мне в принципе не нравится.

Терпеть-то недолго осталось конечно, но раз в 10 минут ты обязательно натыкаешься на 20 лет наследия и какие-кто абсолютно конченные решения в проектировании местного API. Не упоминая уже в утиль слитое соглашение имён, как, например, в Unity.Mathematics, где, якобы, разработчики дали возможность «быстро итерировать» между C# и HLSL и «унифицировать» математику между CPU и GPU.

Ну-ну... нууу-нууу блять.

Штош, приходится работать с тем, что есть, и заворачивать это всё в какое-никакое именование (не только скриптов, а в целом) и архитектуру, ввиду чего было интересно проверить как сюда вписывается «Вертикальный срез», который не раз скрашивал мои рабочие будни. В этот раз он меня тоже не подвёл: консолидация в каждом из «срезов» не только логической фичи, но и всех сопутствующих ассетов, оказалась охренительно удобной.

Показывать не буду — выбор архитектуры должен делаться исключительно исходя из тех реалий, в которых работаете вы, а не какой-то хер из интернета.

Не ну если очень хочется, можете постучаться в личку, пообщаемся.

Я использую Unity 6 и его примочки в виде Resident Drawer (документация и по-проще) и Adaptive Probe Volumes (документация и по-проще). Обе штуки шикарны в использовании, правда APV требует времени, чтобы привыкнуть и научиться использовать встроенные средства для борьбы с артефактами.

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

Правда портал в ад они всё равно открыли.

Как-то так.

В остальном работа идёт полным ходом и рассказать точно будет о чём. На что посмотреть — тоже.

Подписывайтесь.

Писалось под:

Stromae & Pomme — Ma Meilleure Ennemie