«Потерявшийся в сетях». Делая игру в соло. Часть 3

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

В предыдущей серии.

👋

Эта статья должна была выйти месяца три назад, однако новый прототип настолько не получился, что показывать такое в приличном обществе (а DTF — это приличное общество) никак было нельзя.

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

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

Суть мне не понравилась.

Те, кто долго работают в IT знают, что всё основное было придумано лет 40—50 назад, а сейчас мы только и делаем, что боремся с разного рода «обёртками», вгоняя всеми любимую корпоративную разработку в мир костылей. Туда же ломятся вчерашние выпускники курсов, делая этот «мир» вообще невыносимым: наворачивая библиотеку за библиотекой, при этом сильно удивляясь, когда ты пытаешься узнать, понимают ли они вообще что делают.

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

Особенно воодушевляют написанные умными людьми статьи или, собственно, сами умные люди, которые говорят:

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

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

Какие там 8K (вы б ещё про летающие автомобили вспомнили), будете на портативках сидеть как миленькие, ибо «вечные 720p» — наше будущее.

К чему я это всё?

К тому, что не успел я испытать радость от нового вида деятельности, как меня с порога встретил пресловутый «AAA-пайплайн», похоронив все представления о том, что в 3D может быть какая-то романтика.

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

Ладно, романтика в 3D, всё таки, присутствует и, на мой скромный взгляд, находится именно на этом этапе, когда даже с минимальным набором знаний можно смоделировать... ну, практически, всё.

Это если мы говорим об игровых ассетах. Если брать, например, продуктовую визуализацию, то там дела обстоят по-другому.

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

Обычно, это, примерно, так:

В каком-то смысле я бы, даже, назвал этот процесс естественным.

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

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

Короче, вместо борьбы с самим собой я решил поступить так:

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

..он мне просто не нравится.

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

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

Дизайном тоже, но суть вы поняли.

Что касается «места», то вычислять примерную мощь целевых устройств с поправкой на движок, разрешение экрана, количества анимаций, визуальных эффектов, вызовов отрисовки, и производительность кода — такое себе занятие. Тем не менее, если брать за нижнюю границу Steam Deck, то по разным оценкам сцена может содержать около 500 тысяч полигонов (я так неграмотно имею ввиду треугольники) и что-то вроде 15 уникальных материалов чтобы быть отрисованной в 60 кадров в секунду.

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

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

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

На этот счёт есть вполне дельный совет:

Такой совет с подвохом.

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

Короче говоря, «нормально делай — нормально будет».

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

Ну, или это сделали за вас производители железа.

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

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

Я настолько презираю этот процесс, что даже писать о нём стыдно.

Опять таки, не потому, что не разобрался. Разобрался. Более того, при наличии правильных инструментов это, даже, в какой-то степени весело.

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

Ощущается всё это как натуральный костыль, всякий раз заставляя задаваться вопросом:

Я понимаю, почему так сложилось и понимаю, что ничего нового нас особо не ждёт, так как, фундаментально, процессы обработки 3D графики не меняются уже десятилетия, а производители «железа» и программных комплексов просто едут по накатанной. Менять это всё означает изменить всю программно-аппаратную платформу и ментальную модель с очень неясным результатом, в то время как деняк будет потрачено много, а количество нытья от пользователей и разработчиков превысит все допустимые пределы.

Собственно, помимо нытья, моей основной проблемой было понимание такого концепта как Texel Density (есть годный исторический материал на эту тему от Энтони О'Доннелла) и как он соотносится с физическим размером модели и занимаемым ею местом на экране, соответственно, и с размером текстуры (есть доступно на русском). Не знаю почему, но всё это сложилось в моей голове с каким-то неадекватным количеством усилий (сильнее всего тупишь всегда над чем-то простым).

На помощь снова приходят умные люди:

В Blender'е в метрах, в Unity — тоже, в Unreal — сантиметрах.

Самое интересное, что, как я это понял, движки не считают эти единицы «реальными», так же как и, собственно, не в курсе что такое «реальность» в принципе, просто их разработчики внедрили соответствующие расчётные единицы (Blender Units, Unity Units и так далее), при которых физические подсистемы корректно взаимодействуют с объектами (свет, гравитация, столкновения и так далее).

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

Всё это — поле для экспериментов в зависимости от задачи, как, например, было с Unreal Tournament, ровно как «физический» размер модели не обязательно должен соотноситься с реальностью (как в тех же RTS).

В ином же случае всё зависит от упомянутого «места на экране». Например, ведущий канала The DiNusty Empire интересно объясняет как при увеличении размера игрового ассета идёт переход от текстурирования к шейдерам.

Ещё один этап, которого быть не должно.

Причём в избавлении от этого этапа дела обстоят чуть лучше, после того как стала появляться виртуальная геометрия в виде «анриаловского» Nanite, «мешлетов» и Mesh Shaders. Я не разбираюсь в вопросе чтобы утверждать, что вот оно — наше будущее без «запекания», я, просто, очень хочу в это верить.

Любопытно при этом, что я не раз слышал жалобы от игроков, что, дескать, игры, использующие Nanite, настолько детализированы, что в динамике у этих самых игроков глаза вытекают прямо на клавиатуру. Ещё любопытнее было слушать умных людей, которые сетовали на то, что разработчики стали просто-напросто «абьюзить» Nanite, который не создавался с расчётом на то, что его будут пихать куда не попадя. Та же херь произошла с DLSS. Так что всё это ещё большой вопрос, какое место такие технологии займут в пайплайне.

Скорее всего лесом пойдут не «запекание» и UV-развёртка, а оптимизация, которая и так уже одной ногой стоит за порогом, ибо одни костыли просто заменяются другими.

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

Кстати говоря, Marmoset умеет это делать из коробки, так что если вы один из его обладателей, вам сюда (как бонус — гайд по запеканию фасок).

Дополнительно могу посоветовать материал по работе с Custom Cage — не то чтобы частое явление, но для прокачки навыков пригодится.

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

Да и не только с шейдингом. Что говорить, если раскидывая жёсткие грани по моделям, весело улюлюкая от прелестей Hard Surface моделирования, ты с удивлением обнаруживаешь удвоенное количество вершин, от вида которого слышно как движок забивается в угол. Причём когда стучишься в пустоту, дескать, почему вдруг вершина не может хранить больше информации о нормалях, чтобы жёсткие грани не воспринимались как разрыв геометрии, даже ChatGPT грустнеет и предлагает простой пойти в хуй.

После этого, глядя на, так называемые, «лоуполи»-игры начинаешь задаваться вопросом:

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

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

Второй этап, где отсутствие творческих навыков является серьёзным ограничителем, так как порог входа в тот же Substance Painter (не говоря уже о Quixel Mixer, если вы работаете с контентом от Epic Games и их движком) чисто технически довольно низкий, а вот умение комбинировать весь инструментарий и, что самое важное, «видеть» результат ещё до того, как вы прикоснулись к клавиатуре (всегда считал это качеством ведущих специалистов) ничем иным как практикой и, в немалой степени, наличием таланта, не прокачать.

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

Из интересного могу посоветовать обучающие материалы, связанные с текстурированием больших объектов (как здания, например) с добавлением вариаций. В первую очередь, хорошо рассказывает один из художников Gears 5 — Дилан Абернети, во вторую — товарищ Даниель Ландхельм. Уже упомянутый The DiNusty Empire даёт больше информации в этом контексте по использованию множества UV-сетов на одной модели.

Мне эта информация не особо пригоди... да, честно говоря, процентов 70 информации мне, в итоге, не пригождается. Суть, как всегда, в наличии базы, без которой любое подобное начинание рискует закинуть вас в tutorial hell без каких-либо перспектив.

Здесь тоже имело место всё то, о чём я писал в разделе про Texel Density, ибо «покраска» моделей с таким расположением камеры — всё равно что в реальной жизни красить кукольный домик: никаких ухищрений, которые мне понадобились бы, скажем, в шутере от первого лица (о чём источники выше), здесь применять не пришлось.

Может вам придётся, тогда рад был подсказать.

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

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

Но не один ли хрен?

Возможно поэтому мне так симпатичен Blender, который умеет делать бóльшую часть того, что мне нужно и... ну, как-то, удачно, чтоли, комбинирует это в рамках интерфейса (с UI, особенно у движков, в принципе всё не слава Богу). Я, даже, было, обрадовался такому проекту как UPBGE, но понял, что перспективы его использования сомнительны. Если вам хочется чего-то подобного, то, наверное, Armory будет веселее.

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

Ну или разработка просто подорожает в очередной раз.

..собственно, к игре.

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

Новая статья — новое достижение (для чего блог в принципе был задуман), а, именно, я закончил все три локации «стратегического» режима, которые я хотел бы выпустить в раннем доступе. По плану надо доделать ещё пять, насколько быстро получится — вопрос.

Первой в очереди на завершение оказалась «Мастерская», прототип которой вы могли лицезреть в прошлых статьях:

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

На всякий случай напомню, что игра является, скорее, экономическим симулятором, а то ещё подумаете чего. От выживачей меня самого тошнит уже, приходится выводить эту дрянь из организма с помощью FlatOut 2.

Основных задач по «оживлению серых коробок» было две:

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

Скажем, две посадочные площадки по бокам:

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

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

Ну, как, банально, для вас, может, и банально, для меня — это новые знания.

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

Как когда-то с Logic Pro, когда из Mac'ов в нашей стране были только «хакинтоши», а обучающего материала по этой DAW не было в принципе.

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

Следующая локация — «Фабрикатор»:

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

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

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

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

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

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

Так появился «Корпус подготовки Вдохновителей — Эпсилон»:

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

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

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

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

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

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

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

На этом, пока, всё. Спасибо, что дочитали.

Результаты, как мне кажется, очень даже ничего: даже такой кривенький шаг — всё ещё шаг в направлении релиза, что радует.

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

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

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

Elysion — As The Flower Withers

P.S. Все сцены были отрендерены в Blender 4.1 на движке EEVEE. Пробовать 4.2 я пока не стал, есть ощущение что это будет существенное различие с тем, что мне сможет предложить Unity без всех этих свистоперделок в виде Raytracing. Я понимаю, что это всё можно отключить, вот и поиграюсь потом.