[12] Unreal Engine 5 C++ Developer: Learn C++ & Make Video Games | Actor Forward Vector
В данном видео зададим направление выстрела сферой, которую создали ранее, по направление куда смотрит игрок.
В данном видео зададим направление выстрела сферой, которую создали ранее, по направление куда смотрит игрок.
Прогнозы для некоторых студий неутешительные.
О том, какая ситуация образовалась в российском геймдеве, в интервью изданию App2Top рассказал Сергей Беляев, сооснователь студии Infusion Games, известной по мобильному киберпанк-шутеру Cyber Wars.
С весны 2022 года у всех студий возникла проблема с тем, чтобы переводить деньги в Россию. Компании справляются с этим по-разному, отметил Беляев. Одни платят в рублях, другие — используют «серые» схемы для того, чтобы доставлять финансы в страну, третьи — «находятся под крылом гигантов вроде VK».
Однако большинство студий, которые находятся в России, работают «по остаточному принципу». Управляющие таких компаний надеются, что им удастся получить инвестиции, и за счёт этого завершить проекты.
Сотрудники в таких компаниях зачастую даже не подозревают, что денег на счетах хватит ещё на 1-2 месяца, а потом всех уволят.
Как правило, инвестиций они не находят. Еженедельно кто-то закрывается, и всё больше разработчиков оказываются безработными.
Сергей Беляев, сооснователь Infusion Games
По словам Беляева, в текущих условиях работать продолжают те студии, которые быстрее адаптируются к ситуации, в том числе числе находя «серые» схемы. В начале весны 2022 года компании часто искали посредников в Евросоюзе и платили им деньги, чтобы те переводили финансы в Россию. При этом комиссия тогда составляла до 20%.
Студии, которые не находят выхода из сложившейся ситуации, закрываются. Беляев отметил, что потерявшие работу сотрудники активно ищут другие должности даже с уменьшенной зарплатой.
Для примера: год назад нам за три месяца удалось найти всего около 50 кандидатов на должность 2D-художника. У каждого были огромные зарплатные ожидания.
Этим летом мы открыли ещё несколько вакансий на эту должность. За месяц на них откликнулось почти 1000 человек с гораздо более низкими ожиданиями по зарплате.
Сергей Беляев, сооснователь Infusion Games
Сооснователь Infusion Games прогнозирует, что в ближайшие несколько месяцев оставшиеся в РФ студии закроются, поскольку у них закончатся деньги. Сам Беляев вместе с другим сооснователем компании находится в Турции, поскольку развивать бизнес, находясь внутри страны, стало слишком трудно.
После февраля невозможно стало развивать европейскую компанию, находясь физически в России. Увы.
Сергей Беляев, сооснователь Infusion Games
В интервью Беляев также рассказал, что после укрепления рубля нанимать российских разработчиков стало дороже, чем западных. По словам специалиста, при этом не все соискатели понимают ситуацию, и не снижают свои запросы по зарплате.
Год назад Unity-разработчики уровня Senior воротили носом от офферов в 350 тысяч рублей на руки, требовали больше. Учитывая все налоги, отчисления и прочие расходы, сотрудник мог выйти, грубо говоря, в 700 тысяч рублей минимум.
Когда за доллар стали давать 52 рубля, внезапно выяснилось, что подобный специалист обходится в 13 500 долларов в месяц. Это уже за гранью конкуренции с любым западным специалистом.
Сергей Беляев, сооснователь Infusion Games
Источник Dtf.ru
В данном видео рассмотрим default pawn и сделаем выстрел сферой
Часть 9. О том как играть в настольную игру СУПЕРТАНК
Описание правил нашей игры СУПЕРТАНК коротко, будет звучать так:
Кубики действий (прототип)
2. Разыгрывает выпавшие на кубиках действия:перемещает танк по клеточкам;
стреляет;
строит или убирает препятствия;
получает бонус;
использует бонусы.
Игровое поле с выложенными тайлами местности, штабами и расставленными танками для начала игры (прототип)
Задача игрока разрушить штаб противника, или перебить врагов так. чтобы у него кончились жизни.
Счетчик жизней сторон (прототип)
3. Выбирает карту Приказа - Приказ определяет очередность и варианты доступных действий в следующем раунде.
Карты Приказов с выложенными жетонами танков (прототип)
4. Передает ход игроку выполняющему следующий по очереди Приказ.
Мы провели больше сотни игровых тестов в поиске варианта основной игровой петли. Мы стремились добиться, чтобы корневая механика была простой, короткой и ее формулировка умещалась в 3-4 предложения. Рассматривался вариант с одновременным выбором действий игрокам и последующим разыгрыванием этих действий. В итоге этот вариант вылился в отдельный прототип.
Прототип одновременным выбором действий
Тестировался вариант с разыгрыванием карт с предопределенным набором действий.
Прототип с предопределенным набором действий
Но нам хотелось чтобы в корне геймплея игры было понятное действие знакомое с детства, доступное игрокам с разным уровнем опыта игры в настольные игры. В итоге пришли к тому, что самым приятным игроку будет такое действие как бросок кубиков. Это привычное действие для тех, кто играл в настольные игры в детстве - ходилки-бродилки, и не искушен сложными механиками современных настольных игр. Бросил кубики и разыграл, то что выпало. Причем игрокам дается выбор какие кубики бросать. Кубики присутствуют в двух наборах - зеленые и синие. В зеленом наборе выше шансы выкинуть на кубиках действия перемещение, в другом наборе выше шансы получить действие строительство или получение бонуса.
Другой механикой нашей игры стал выбор очередности хода. В этой механике заложен еще один слой решений, т.к. этот выбор решает, каким по очереди игрок будет ходить в раунде. Ходи первым или вторым, получаешь шанс подбить танк противника раньше чем он подобьет тебя, но будешь ограничен в выборе доступных действий. А если ходишь последним в раунде, то бросишь четыре кубика действий и выберешь какие из них разыграть. Также очередность определяет, какие действия игрок разыгрывает со 100% вероятностью, а какие только если они выпадут на кубиках. Игроки каждый ход принимают решение в зависимости от ситуации на игровом поле.
Третья игровая механика – это перемещение по клеточкам в лабиринте. Это наглядная механика, по сути переложение механики оригинальной игры в настольную. Там тоже было игровое поле состоящее из квадратных клеточек и танки перемещались по ним. Было важно занять тактически правильную позицию на игровом поле, чтобы отстреливать вражеские танки, не подставляться под выстрелы самому, защитить напарника и штаб. Хотя в процессе тестировались прототипы в которых, например танки перемещались не по клеткам, а по зонам, как например монстры ходят в игре «Повелитель Нью-Йорка».
Прототип с перемещением по зонам как в «Повелитель Нью-Йорка»
А для искушенных игроков в настольные в игре присутствует продвинутый режим. В этом режиме в каждом танке сидит Генерал и дает танку уникальные способности. Игрок создает свою команду, комбинируя между собой свойства разных Генералов, используя их сильные и слабые стороны.
Карты Генералов с прописанными свойствами (прототип)
Так же в этом режиме добавляются три новых вида бонуса, которые могут круто изменить баланс сил в игре:
"пистолет" - бонус который превращает танк сразу в СУПЕРТАНК. Вы разрушаете любые препятствия, наносите двойной урон и получаете дополнительную броню;
"граната" - позволяет самоуничтожить свой танк, но при этом нанести урон всем врагам вокруг вашего танка;
"кораблик" - дает дополнительную броню и помимо этого дает способность перемещаться по клетками с водой.
Бонусы граната, пистолет (СУПЕРТАНК) и кораблик
В данный момент разработка игры уже на финальной стадии. Мы тестируем свойства Генералов, их различные комбинации и так же различные варианты выкладки стартового ландшафта игрового поля. Работают художники над оформлением коробки и правил. Уже совсем скоро будут готовиться печатные макеты и мы приступим к заказу и изготовлению пластиковых компонентов.
Сообщество проекта настольная игра СУПЕРТАНК по мотивам танчиков для Dendу
Часть 1. Вводная по нехитрые детские развлечения 90-х
Часть 2. Как возникла идея сделать из приставочной игры настольную
Часть 3. О пиксель-арте и визуальном стиле игры
Часть 4. Про точки фана оригинальной игры и поиска их в настольной игре
Часть 5. Продолжение про механики оригинальной игры BATTLE CITY и их перенос в настольную
Часть 6. Про пиксель-арта оригинальной игры
Часть 8. Про фишки танчиков в настольной игре. Разработка и производство
Привет! Расскажи немного о себе и о проекте The Epic.
Привет, Меня зовут Алексей Илюхин, я основатель студии Far Far Games. С 2019 года мы занимаемся разработкой the Epic. Изометрической Action RPG в сеттинге славянского эпоса. В течение двух лет мы разрабатывали проект самостоятельно, без сторонней поддержки, а в конце 2021 года вышли на полноценную разработку, что поспособствовало трансформации проекта.
Мы полностью всё пересмотрели — от геймдизайна до визуального кода — и фактически стёрли всё, что было до этого, начав проект с нуля.
Мы намеренно отказываемся от нарочитой «лубочности», но при этом в лоре, деталях, отдельных квестах видно культурное влияние скандинавского и славянского эпоса. Фэнтезийный мир игры выдуманный, но в нем прослеживаются различные исторические прототипы.
Как появилась идея создания ? Как все начиналось?
Идея создания проекта появилась еще в 2014 году и в целом была на поверхности. Все начиналось с самой истории и проект который, к слову, назывался «Былина» задумывался как фильм.
К сожалению, тогда на амбициозное фэнтази не выделяли финансирование, хоть нам тогда и удалось найти именитых наставников, из затеи ничего не вышло. Мы отложили идею с миром the Epic до лучших времен и в 2019 году вернулись к ней с новыми силами и пониманием того, что это будет игра, а не фильм.
Тогда, как водится, все началось с нарабатывания опыта за собственные деньги. В течение двух лет мы смело совершали все возможные ошибки, которые только можно совершить, но при этом проект начинал обретать финальные очертания.
Обрастая командой, опытом и аудиторией, мы медленно двигались к старту полноценной разработки, которая началась в июне 2022 года. Фактически, полноценно проект разрабатывается всего три месяца, хоть ранее мы уже успели познакомить аудиторию с персонажами, моделями, артами, серией роликов. Хочется еще раз отметить, что все, что мы успели сделать тогда практически полностью ушло в стол, думаю, можно сказать, что the Epic - это новый проект, построенный на опыте Былины. Да, мы оставим часть нарратива, монстров, даже некоторых персонажей, но их история будет изменена, как и история всего мира в целом.
Какими источниками вдохновлялась команда? Возможно книги, игры фильмы? Почему именно они, и как они повлияли?
В основном вдохновлялись историей региона, сказками, былинами, сказаниями. Конечно, на нас сильно повлияла и продолжает влиять современная популярная культура. Мы точно не претендуем на историческую точность, т. к. не делаем историческое произведение. С уважением относимся к культурным нитям тех стран из которых что-либо заимствуем, стараясь не делать этого бездумно, оголтело и в ноль. Мы считаем, что можно заимствовать целыми блоками, а можно опираться на детали.
В целом, работая в креативной индустрии, нужно понимать, что процесс создания (креатива) — это процесс сборки. Креатив — это комбинирование различных блоков человеческой культуры, опыта во что-то новое. Невозможно придумать то, чего ты не видел раньше, в любом случае ты будешь опираться на ассоциации разного уровня.
Есть гипотеза, что прототипом Бэтмена является Нью-Йоркский мясник по имени Билл Смитт, но вообще, глобально фигуру мстителя в маске популяризовала Эмма Орци написавшая классический приключенческий роман Алый Первоцвет. История о британском аристократе и роялисте действующем на территории Франции в эпоху Террора. Главный герой, сэр Перси Блейкни, в повседневной жизни изображает изнеженного денди, заинтересованного только в моде и фасонах фрака, и параллельно с этим ведёт активную подпольную деятельность по борьбе с Французской революцией.
Перед заморозкой каждого крупного блока проекта, мы проводим масштабное исследование, одно только исследование арт стиля и концепта заняло у нас около шестидесяти страниц текста.
Вы и команда. Кто эти люди и как они входили в состав разработки? Сейчас вы продолжаете расширяться, и вскоре анонсировали новый набор сотрудников. Каков отклик? Приходят из комьюнити или все же большинство это именно те, кто увидел вакансию еще не зная о проекте?
Мы выросли из пяти энтузиастов до штата в двадцать человек примерно за три месяца. Половина этих людей было у нас в «резерве». Аутсорсеры с которыми мы работали над проектом ранее фактически просто вышли в штат. При этом остальных мы искали на рынке.
Можно сказать, что отклик достаточно высокий. Через неделю после публикации вакансии 3D артиста мы получили около двухсот откликов, что достаточно много, мы все еще не разобрали все.
При этом мы периодически берем талантливых джунов и учим внутри, у нас есть такой опыт и он показывает свою эффективность на некоторых позициях. Конечно, к нам приходят люди из сообщества, так мы нашли технического директора (еще год назад), Олег, респект тебе).
Недавно вот взяли очень крутого левел артиста, тоже из комьюнити. Вообще, откликов довольно много, мы стараемся отвечать всем, но заранее хочется попросить прощения у тех ребят кому не ответили вовсе. Иногда просто не хватает времени на обратную связь.
Разработка, как она виделась с самого начала. Какие изменения были привнесены в процессе? Что оказалось сложнее, что проще, а что просто весело? Проблемы и переход на новый движок (расскажите подробнее).
Вообще не секрет, что разрабатывать игры — это сложно. Не все сразу это понимают, думают, что это весело, мы тут сидим, играем, обсуждаем фичи, смеемся и вообще супер друзья.
Это не так, индустрия разработки — это бизнес и процесс разработки должен работать как и любой бизнес, согласно бизнес процессам. Мы очень четко это понимаем и стараемся строить работу так, чтобы всем было комфортно и все работало на общий продукт. Не всем это нравится, некоторые молодые специалисты не понимают почему их заставляют работать с 10 до 19, отмечаться в таск трекере, присутствовать на еженедельных собраниях и работать по спринтам.
Конечно, с такими людьми приходится быстро расставаться. Нужно понимать, что любая мелочь внедренная в игру - это время перемноженное на деньги. Любой персонаж — уникальный персонаж — стоит денег, тут речь не только о модельке.
Придумать, внедрить в лор, обосновать с точки зрения геймдизайна, записать анимации, проработать квест дизайн, озвучить, да даже убить его — стоит денег. Это целый пласт работы и то, что кажется простой моделью, превращается в крыло от самолета. Именно по этому все нужно стараться продумать, десять раз обсудить и принять четкое решение, зачем мы это делаем, и какую пользу это принесет проекту. Проблем с переходом на новый движок у нас вообще не было т. к. мы фактически начали разработку с нуля. Некоторые пишут: «мол, чо там переходить, нажал кнопку и понеслось». К сожалению, это не так, а в нашем случае нужно понимать, что мы не просто перешли на UE5, а начали на нём разработку.
Визуал заметно выделяется авторским стилем. Как и почему вы к нему пришли?
Ну, как я и говорил выше, мы проводили исследования. Это тема для отдельного, большого разговора на самом деле. Что мы смотрели, на что обращали внимание, на что ориентировались. Можно сделать интервью с нашей арт командой, я думаю, что они с радостью поделятся.
Звуковое и музыкальное сопровождение. Как создается звуковой мир Былины и ее мира Гардарики? На что делаются акценты, где черпается вдохновение?
А он не создается пока. Мы на раннем этапе разработки и у нас только прикидки разные. Но сейчас может быть не канон, удар ниже пояса, отписка, но мы хотим взять фолк мотивы смешанные с современным пост хардкором типа Deftones, Loathe.
Геймплей. Расскажите о выбранном жанре и его ключевых механиках, почему был выбран именно он, какие преимущества и наоборот сложности он принес с собой.
Вообще мы делаем Action RPG и конечно акцент у нас именно на Action. Основной упор у нас сделан на боевую систему, которую мы значительно переработали с предыдущей итерации. Сейчас вся боевка the Epic построена вокруг сложной системы комбо и магии. Тут изначально важно было понять как сделать правильную, красивую, липкую боевку в изометрии, сочетать ее со сложной системой анимации, магии и способностей да еще и так, чтобы использование этих способностей не прерывало комбат флоу.
Плюс нужно держать в уме, что мы делаем игру в открытом мире, но сделать живой открытый мир, как это делают столпы индустрии, с многомиллионными бюджетами мы не можем. Тут тоже приходится искать решение, жертвовать размерами локаций, делать их компактнее, но более наполненными, придумывать дополнительные системы, которые могут оживить мир без необходимости реализации сложных симуляций, на разработку которых могут уйти ,без преувеличения, годы.
Баг, пасхалка, фича. Забавные, курьезные моменты во время разработки. Возможно, какие-то смешные или странные идеи, или случайности которые происходили с командой/в игре и были оставлены/пришли в голову и были добавлены в игру?
Ну, тут пока поделиться нечем, т.к. мы чистим все баги. Но например за основу внешности тяжелого противника в снежном биоме мы взяли Стаса Борецкого, а вся композиция боевого отряда напоминает Труса, Балбеса и Бывалого.
В каком состоянии проект находится сейчас? Когда можно приблизительно ожидать релиз?
Сейчас проект находится на стадии прототипа, который мы планируем закончить в конце сентября, на этом фоне мы организуем ограниченные плей-тесты боевой системы (наверное ближе к октябрю, как почистим баги). Релиз мы планируем в 2024 году.
Обращение к будущим игрокам от Вас и студии. Что-то, что вы бы хотели сказать каждому, кто готовиться прикоснуться к проекту, перед тем как он начнет играть.
- Не ждите исторической достоверности;
- В игре не будет «Ура Патриотизма», отечественных сказок, к которым вы привыкли с детства. Да, эпос лежит в основе проекта, но мы комбинируем образы, не делаем зеркальное отражение. На этом фоне комментарии про отсутствие бород у некоторых персонажей кажутся странными);
- Ваша поддержка помогает нам чувствовать уверенность и работать лучше;
- Смело прикасайтесь к проекту, скоро мы обновим сайт и там будет форма для записи на плей-тесты.
Вот такой вышла наша небольшая беседа с, напомню, Алексеем Илюхиным - основателем студии Far Far Games, о проекте Былина(The Epic).Надеемся, что уже скоро в наши руки попадут и плей-тесты, и ранний доступ, и еще не раз мы сможем поговорить с Алексеем и членами команды.
А ты, дорогой читатель, не забывай чекнуть страничку проекта, а, возможно, даже стать его частью!
Материал подготовил Иван Тимошин.
Источник
Подпишись, чтобы не пропустить новые интересные посты!
ПОДДЕРЖАТЬ АВТОРА
Всем привет, меня зовут Виктор Щепкин, я работаю Team Lead’ом в Allods Team, которая входит в состав MY.GAMES и уже насчитывает целых 14 студий. В этом тексте я расскажу про особенности работы с Unreal Engine, а также подробно опишу, какие решения и процессы мы используем при разработке проектов:
— как мы используем Unreal Engine Modules и Plugins;
— cross-sharing технических решений;
— про стандартизацию и валидацию данных;
— и многое другое.
Отдельно хочу отметить cross-sharing технических решений. Сейчас в Allods Team ведется активная разработка нескольких проектов на Unreal Engine, поэтому мы всегда заинтересованы в том, чтобы не только обмениваться опытом, но и делиться конкретными техническими решениями, которые появились в ходе работы над проектами. Это значительно упрощает процесс самой разработки и экономит ресурсы.
Все, что я расскажу ниже — это исключительно наш личный опыт, а когда речь идет о личном опыте, то всегда можно найти, что можно улучшить или с чем-то поспорить. Поэтому не стесняйтесь писать свои мысли и предложения в комментариях, я с радостью почитаю про вашу практику, а также отвечу на ваши вопросы.
Unreal Engine Modules и Plugins
Мы считаем, что при работе с Unreal Engine можно и нужно придерживаться модульности: вместо того, чтобы проект состоял только лишь из одного основного модуля, мы стремимся использовать множество независимых системных модулей — это позволяет формировать наши проекты по принципу конструктора, состоящего из системных модулей, что помогает нам легко переносить целые фичи из проекта в проект.
Чтобы достичь модульности, мы используем возможности, которые нам предоставляет Unreal Engine:
1) Unreal Engine Modules — коллекции классов, которые могут входить в состав как проекта, так и плагинов. При этом важно учитывать, что реализация Unreal Engine Module может быть только на C++, поэтому если мы хотим вынести какой-либо блюпринт как некую часть модуля, то для этого мы создаем отдельный плагин.
Unreal Engine Modules мы используем в случаях, когда вся логика может храниться в одном модуле. Например, наш Character Stats System Module представляет собой базовый набор атрибутов GAS’a, компонентов для работы с ними, а также набор вспомогательных функций, который мы используем при реализации базового представления персонажа, его характеристик и боевой системы.
Важно учитывать, что Unreal Engine Modules, которые мы разрабатываем и которые находятся в проекте, могут зависеть только от движка и от плагинов, но ни в коем случае не друг от друга! Такие зависимые вещи должны находиться в Unreal Engine Module самого проекта.
2) Plugins — коллекции кода (в виде Unreal Engine Modules или Blueprints) и/или данных (ассетов).
А вот плагины мы используем в случаях, когда речь идет о разработке более комплексных фичей, которые сложно уместить в один Unreal Engine Module. Или же когда фича, помимо самого Unreal Engine Module, содержит в себе какой-либо контент. Например, наш Compass Plugin — это плагин, состоящий из Compass Module, в котором находится реализация поведения игрового компаса, а также из Widget, который является базовым UI-представлением компаса. Этот Widget можно использовать на этапе прототипирования как готовое решение из коробки, а в последующем как шаблон для реализации своего уникального UI-представления.
Модульный подход лежит в корне cross-sharing’a технических решений между проектами, поскольку мы можем использовать готовую фичу на другом проекте. И при необходимости мы улучшаем и расширяем наши наработки. Таким образом, мы существенно экономим время и ресурсы при разработке и прототипировании проектов.
Coding Standard
Прежде чем говорить о стандартизации кода, следует подчеркнуть, что у нас внутри работают независимые друг от друга команды, у каждой из которых есть своя история, свой опыт и набитые шишки, а соответственно, и свои стандарты. Но в основе этих подходов лежит общая стандартизация кода от Epic Games.
Выбор основного стандарта кода от Epic Games обусловлен тем, что мы не стали изобретать велосипед, а применили существующий стандарт, с которым каждый день встречаются разработчики на Unreal Engine. За счет этого при найме новых сотрудников у нас нет необходимости переучивать их на наш уникальный стандарт. Но если кто-то не знает стандартизации кода от Epic Games, то он быстро этому обучится, потому что будет встречать его 90% времени (стоит учитывать, что Epic Games в исходниках движка не везде соблюдает свои же стандарты — все же они такие же разработчики, как и мы с вами, и им тоже не всегда хватает времени на вычитку).
Кроме того, если вы пишете собственный стандарт кода, то, скорее всего, его будет сложно использовать, потому что он далеко не всегда будет устраивать всех разработчиков в разных командах. Лучше брать что-то более обобщенное, что уже было придумано до вас.
Что касается документации самого стандарта, то в качестве основы мы используем документацию от Epic Games, но в разных командах есть незначительные отличия в виде расширений или улучшений. Я крайне не советую все это переносить в свою документацию по следующим причинам:
— документация быстро разрастается, из-за чего сложно найти нужную часть;
— так как прогресс не стоит на месте, документация быстро становится out-of-date;
— подобного типа документы обычно хранятся в отдельном месте(например, в Confluence), а не рядом с кодом, с которым работает разработчик;
— ну и давайте будем честны — мало кто читает документацию, потому что на это зачастую не хватает времени.
Вместо этого в качестве документации мы используем код, хранящийся в отдельном плагине, который содержит в себе Unreal Engine Module и ассеты. Ассеты содержатся в виде блюпринтов, в которых также находится описание стандартизации кода — это важно, потому что стандартизация кода блюпринтов никак не должна отличаться от обычных стандартов, которые используются при разработке на C++ в Unreal Engine.
Такой подход лучше всего проявил себя при код-ревью, потому что у нас больше нет необходимости кидать ссылку на документацию и заставлять сотрудника что-то там искать — нам достаточно указать на строчку кода в CodingStandard.h или CodingStandard.cpp.
У разных команд есть отличия в стандартах, но они не слишком сильные:
— порядок и стиль написания #include;
— правила комментирования функций и переменных;
— порядок и использование Metadata Specifiers.
Data Standard
Мы считаем, что если есть стандартизация кода, то должна быть и стандартизация данных (ассетов). Но речь идет не о блюпринтах — для них у нас есть Coding Standard. В стандартизацию данных входят следующие вещи:
— стандартизация наименования контента (Naming Conventions);
— стандартизация структуры папок проекта;
— стандартизация мешей;
— стандартизация текстур;
— стандартизация уровней.
В случае со стандартизацией данных у Epic Games нет конкретного стандарта, а есть лишь набор рекомендаций, да и те разбросы по множеству статей в документации. И здесь на помощь приходит комьюнити, которое по большей части решило проблему.
Но вот в отличие от Coding Standard, Data Standard у нас задокументирован в Сonfluence — по этой причине Data Standard сильно зависит от проекта и может меняться под него. Да, есть некоторые общие вещи, которые всегда будут похожи у разных проектов, но все-таки большая часть стандартов всегда будет отличаться. Вот некоторые примеры:
— стандартизация наименования контента — быстро разрастается под проект, особенно если разработка ведется в парадигме Data Driven Gameplay. Это происходит из-за того, что при использовании только префиксов DA_/DT_ для именования ассетов с данными, появляются проблемы с их поиском и фильтрацией;
— стандартизация мешей — основные правила, что описаны в Style Guide, сильно дополнены, например, правилами именования сокетов;
— стандартизация текстур — максимальное разрешение текстуры сильно зависит от платформ, для которых разрабатывается проект.
Data Validation
Поскольку у нас есть стандартизация данных, то должна быть и их валидация. Валидация данных — это инструмент, который позволяет следить за тем, чтобы в проектном репозитории всегда хранились только валидные и правильно оформленные данные. В первую очередь при валидации данных мы смотрим на следующие вещи.
1) Соответствие данных актуальным стандартам:
— в реальности разработчик не может все держать в голове или постоянно смотреть в документацию;
— не забываем про проблемы документации стандартов, которая часто и быстро меняется вместе с проектом. Также помним, что документацию далеко не все читают.
2) Данные, хранящиеся в репозитории, должны быть валидными — то есть не содержать ошибок или предупреждений.
3) «Эффект бабочки» — это явление, при котором мельчайшие изменения в одном файле могут повлечь проблемы в других связанных файлах.
Для валидации данных у Epic Games уже есть готовое решение (даже несколько) в виде Data Validation Plugin. Подробнее об этом и о том, что мы валидируем, вы сможете прочитать в нашей следующей статье, которая выйдет в ближайшее время, а пока пройдемся только по ключевым местам.
Прежде всего мы валидируем:
1) Любые данные — Naming Convention. Хороший нейминг помогает разработчикам легче ориентироваться в проекте. Если каждый начинает использовать свой собственный нейминг, то это превращается в очень сложную задачу и, как правило, заканчивается дублированием данных.
2) Любые импортируемые данные. Все исходные данные, которые импортируются в проект, должны быть размещены на специальном виртуальном диске, который является представлением контентного репозитория. Мы не допускаем пути импорта с рабочего стола!
3) Блюпринты. Больше всего внимания мы уделяем ошибкам и предупреждениям. Если с первыми все понятно, то вот по поводу вторых стоит уточнить. Может показаться, что предупреждения, которые выдает движок — это не так уж страшно. Но на самом деле это не так — если вы игнорируете предупреждения, то готовьтесь к тому, что когда-то, и скорее всего, в самое неподходящее время, такое предупреждение превратится в ошибку. И поскольку с момента, когда появилось предупреждение, до его трансформации в ошибку, могло пройти много времени, цена поиска проблемы и ее устранения может быть слишком высока.
4) Variables (в блюпринтах). Часть нашей стандартизации кода, все системные переменные, нужно помещать в отдельную категорию и сопровождать их комментариями. Это необходимо для того, чтобы контент-мейкеры понимали, какие данные изменять можно, а какие являются системными и лучше их не трогать.
5) Textures. В работе с ними важно следить за тем, чтобы разрешение сторон текстуры всегда было кратным степени двойки. Также важно, чтобы размер текстуры не превышал пороговое значение, заданное под проект. Например, если мы делаем проект для мобильной платформы и загружаем туда текстуру разрешением 8К, то это приведет к большим проблемам с текстурной памятью, а такое встречается очень часто.
6) Static Meshes. Проверяем UV, избегаем overlapping, ну и посматриваем на валидность LOD’ов.
Сам процесс валидации данных запускается при помощи клиентского Git Hook — он запускает сommandlet, который проверяет каждый файл, указанный в коммите.
Source Code/Data Management
Все проектные данные хранятся в двух различных репозиториях:
— проектный репозиторий — тут мы используем Git, естественно, поверх которого стоит Git LFS;
— артовый репозиторий с исходниками (речь идет о любых исходниках, в том числе и о гигантских PSD), для которого мы используем SVN.
Почему мы в Allods Team используем Git, а не Perforce? К сожалению, у меня нет конкретного ответа — так исторически сложилось что ли. Но я успел поработать с Perforce в рамках разработки проекта на Unreal Engine и вот мое личное мнение: что Git не очень справляется со всеми возложенными на него задачами (речь идет именно о работе в связке с Unreal Engine), что Perforce не огонек. К сожалению, серебряную пулю никто так и не сделал (ну или я не в курсе), везде есть свои плюсы и минусы. Единственное, чем Perforce подкупает — это готовые технические решения от Epic Games. Но даже сейчас все это легко перекрывается отличными Open Source решениями.
Интересное наблюдение: все чаще и чаще слышу о том, что часть разработчиков перебирается на Plastic SCM. Я с ним не работал, поэтому если у вас есть опыт взаимодействия, делитесь им в комментариях, очень интересно почитать.
Теперь про SVN — художникам с ним проще работать (да и большинство художников только с ним и работали). Но на этот счет у нас в команде есть правило: любой художник, работающий над проектом, должен знать хотя бы основы Git — pull/push/branch и кого звать, когда происходит конфликт.
Зачем художникам все это? Художники (тут речь больше о 3D Artist’ах, художниках по текстурам, иногда о UI Artist’ах и так далее) отвечают за свой контент от самого начала разработки до полной интеграции контента в проект, поэтому им нужно знать Git. Конечно, у нас есть технический художник, который занимается интеграцией и автоматизацией этих процессов, но дело не в этом — художникам нужно понимать и видеть, как их работа выглядит в самом проекте после того, как применяются постпроцессы и шейдинг. Поэтому достаточно важно, чтобы художники самостоятельно умели интегрировать в проект свои наработки, в том числе и заливать их (порой даже в свои экспериментальные ветки).
Ну и вторым плюсом является более простой sparse checkout: когда нужна конкретная папка, можно достать только ее (ну и контент в ней), а не выкачивать весь репозиторий разом. У нас даже есть пример того, когда это может пригодиться. Допустим, у кого-то из Allods Team появилась задача посмотреть старые артовые наработки Skyforge, а все они весят 4 Тб. Если бы они были в Git, то пришлось бы качать все 4 Тб,что заняло бы примерно неделю. Откуда я знаю, сколько времени на это уйдет? Как-то раз пришлось скачивать полностью все исходники.
По этой причине арт у нас в SVN, а проект — в Git.
Git
Как я ранее уже написал, мы используем Git Hook’и, и помимо клиентского хука для валидации данных, у нас множество различных серверных хуков. Вот описание некоторых из них:
— Commit Message может быть только на английском языке;
— Commit Message должен содержать номер задачи;
— имя файлов не должно содержать кириллицу;
— все большие файлы должны быть только в Git LFS.
Конечно же, в работе с Git мы активно используем ветки — любой разработчик может при необходимости создавать отдельные ветки и работать в них. Это особенно важно, когда речь идет о больших фичах, реализация которых изначально делается только в отдельных ветках — в них же периодически подмердживается основная ветка. А ветка под фичу попадает в основную только после проверки отделом QA.
Но есть еще один нюанс при работе команды над одним проектом в Unreal Engine: все файлы, которые мы видим в Content Browser (они являются частью проекта) — это, как правило, бинарные файлы. Что это значит для нас: если два разработчика будут одновременно работать над одним файлом, то у того, кто будет заливать свои изменения последним, обязательно произойдет конфликт. А поскольку файлы бинарные, то ему придется переделывать свою работу.
Ранее, года три-четыре назад, при работе с Git нам приходилось писать в специальный чатик, что ты забрал такой-то файл в работу и его лучше не трогать. И это было не очень удобно. Но прогресс не стоит на месте. Поскольку поверх Git у нас стоит Git LFS — мы активно используем систему локов (да-да-да, в Git LFS есть система локов файлов, которая очень похожа на таковую в Perforce.
Как это устроено. Если разработчик хочет работать с тем или иным файлом, то он должен сначала его залокать. Эта процедура зарезервирует файл только под конкретного разработчика, и никто больше не сможет залить его, пока не будет снят лок.
При этом сама процедура лока и его снятия может быть выполнена через Git Bash или любой Git Client, поддерживающий эту функцию, а также через сам Unreal Engine при помощи Source Control Plugin.
Если хотите попробовать, то вот достаточно хорошее решение для работы в движке.
Самое главное в этом процессе — научить людей снимать локи, когда они заканчивают работу. Чтобы справиться с этим, мы применили автоматизацию: после коммита происходит автоматическое снятие лока.
CI/CD
Тут не будет каких-то открытий или ноу-хау, просто раз уж я говорю обо всем по чуть-чуть, то надо и по CI/CD немного пройтись. На самом деле я сконцентрируюсь преимущественно на CI. Для начала давайте освежим, что такое CI.
Continuous Integration подразумевает частые автоматизированные сборки проекта с целью быстрого выявления интеграционных проблем. У вас всегда будет актуальная и готовая к тестам версия продукта.
Для всего этого мы используем Jenkins. Сам процесс настройки Jenkins описывать не буду, но вот несколько вещей, которые советуем сделать первым делом.
1) Система нотификаций. Не важно, каким мессенджером вы пользуетесь, нотификации сильно облегчат вам жизнь! Сборка не собралась? Надо чинить. И чем быстрее мы это сделаем, тем лучше.
2) Post Commit Build. После каждого коммита мы запускаем сборку (без деплоя артефактов), она помогает обнаруживать ошибки компиляции и сборки проекта на самых ранних этапах разработки.
3) Nightly Stable Build. В конце каждого дня мы снимаем текущий срез с основной рабочей ветки, собираем Debug Build, который каждое утро попадает в руки к нашим QA для Smoke-тестирования.
Зачем нам нужны Сommandlets, если все это можно сделать в редакторе? Во-первых, не у всех есть мощное железо, чтобы посчитать что-то быстро. Во-вторых, ошибки иногда все же случаются, например, кто-то может забыть сохранить карту вместе с рассчитанным Nav Mesh.
Автотесты
Это самая грустная часть моего текста, потому что автотесты у нас есть, но далеко не на все. Основная трудность в том, что при разработке фичи, написание качественного автотеста с хорошим покрытием всех сценариев занимает 60-70% времени от создания самой фичи. И как правило, автотесты пишут сами программисты, потому что QA, знающие Gauntlet или просто Unreal Engine в контексте разработки автотестов, очень редки. А бизнес суров, порой сложно объяснить ценность автотестов в сравнении с какой-нибудь новой игровой механикой.
Но у каждого проекта есть две части, которые обязательно нужно покрыть автотестированием — это backend и все, что связано с экономикой (в том числе и монетизация)! Без автотестов backend’a и экономики вы сильно рискуете в один прекрасный день увидеть свой сервис на сервере просто мертвым и с испорченными данными.Это в лучшем случае, а в худшем — понесете финансовые потери.
Поэтому собирайте отдельную команду из QA, которая будет писать автотесты для backend’a, потому что там слишком много кейсов, которые обычным ручным тестированием покрыть невозможно!
***
Как и говорилось ранее, прогресс не стоит на месте, а вместе с ним и мы! Мы продолжаем дальше набираться опыта и совершенствоваться, в наших планах разработка и интеграция следующих интересных вещей, о которых я расскажу в будущем:
— Clang-Tidy для Unreal Engine;
— Linter для Unreal Engine;
— интеграция системы багтрекинга в Unreal Engine.
И это лишь малая часть того, что мы разрабатываем для работы с проектами. Еще осталось много того, о чем хотелось бы рассказать, но что не уместилось в рамках этой статьи. Вот некоторые из тем:
— Derived Data Cache;
— PSO Caching;
— Multi-User Editing;
— BuildGraph.
Если что-то из этого вам интересно, то пишите в комментариях — наиболее востребованная тема отправится в печать первой. Ну а в остальном, спасибо всем за внимание, до новых встреч!
Действие нового тайтла развернется в фэнтезийной феодальной Японии.
Со стороны KOEI TECMO выступает студия Omega Force, ответственная за серии DYNASTY WARRIORS и SAMURAI WARRIORS, а издателем выступит лейбл EA Originals, ранее выпустивший такие игры, как It Takes Two и Knockout City.
Капибара Капи приглашает тебя посетить его телеграмм канал - https://t.me/+ny-_MVrxWrUzNjRi
Одна вакансия, два кандидата. Сможете выбрать лучшего? И так пять раз.
С вами подкаст “Хочу в Геймдев”, и в этот раз мы решили поговорить о профессии, которую замечают меньше остальных, но её ценность невозможно преуменьшить.
Саунд-дизайнер ведёт закулисное погружение в атмосферу игры, результаты его работы оседают в плейлистах игроков надолго. Мы можем вспомнить многие игры по музыкальному и звуковому сопровождению: Heroes Might And Magic, Elden Ring или Dark Souls или же Ori, Persona 5 и Hades. Почти каждый из читателей найдёт в памяти приятные ассоциации с трудом Саунд-дизайнера.
Подкаст провел неизменный Вячеслав Уточкин, заместитель директора Центра развития компетенций в бизнес-информатике Высшей школы бизнеса ВШЭ.
А приглашёнными гостями стали:
- Ресса Шварцвальд, основатель и директор Gameowdio, Audio-Lead в CM Games;
- Александр Хилько, аудиодиректор AK Audio, основатель XSSR Academy;
- Anton Booster, Lead Sound Designer, студии Black Caviar Games.
Предлагаем вам краткий пересказ событий:
Чем занимается сотрудник отдела Саунд-Дизайна?
Отвечает Александр Хилько:
Задачей Саунд-Дизайнера является создание уникального звукового контента, звук применения магии, звук взмаха мечом, шагов персонажа. Ещё есть Рекордисты: это люди, которые выезжают в поле, на полигоны, для записи живых звуков. Технический Саунд-дизайнер живёт на стыке инженерных дисциплин, он проектирует и создаёт звуковые системы, например для движения танка нужно создать систему двигателя, со всеми его звуками, в движении, с нагрузкой, на месте. Композиторы занимаются написанием музыки и записью инструментов. Звукорежиссёры отстраивают общий микс. А в Российских студиях востребованы мультизидачные специалисты, Аудио-дизайнеры, которые имеют навыки вышеперечисленных специалистов.
Однако есть одна специальность, которая редко встречается в отечественном Геймдеве: Аудио-программисты: они реализуют уникальные звуковые подсистемы, такие например, как пространственное распространение звука, аклюзии и дифракции звука на базе игрового движка, или же другой пример в записи звука в изометрии и голоса персонажа на разных расстояниях, ведь звук справа и слева будет равноудалён, а звук сверху будет дальше и тише.
Какие задачи на работе решает Саунд-Дизайнер на работе?
Отвечает Антон Booster:
Если в работе требуется креативный подход, мы собираемся командой и генерируем идеи. Но иногда спонтанно приходит какая-то идея, и я бегу за микрофонами беру железное ведро, начинаю бить по нему пружинками, кидаю туда шарики и камни, получаю интересные фактуры, а дальше в уже в лейринге это выливается в удивительную звуковую текстуру. Мы стараемся разделять пул задач между всеми и быть “Универсальными Солдатами”.
Отвечает Ресса Шварцвальд:
У меня в студии есть аутсорсовый продюссер, который помогает мне в координации других аусорссеров, в подготовке ассетов, и Жрец, и Жнец, как говорится. Мой подход в том, чтобы находить уникальный навык человека и заказывать то, что у него лучше всего получается и что ему нравится, чтобы получалось круто каждый раз.
Какими качествами и навыками должен обладать человек, чтобы попасть в сферу Саунд-Дизайна, в компанию или на аутсорс?
Отвечает Ресса Шварцвальд:
Софт-скиллами, базовым пониманием, если вы идёте на начальные позиции. Синтез и запись звука, навыки микса, которые можно набрать при прохождении курсов или школ, из хард-скилов.Для меня самое важное это уважение к иерархии внутри компании, без этого вы не сможете вырасти, наличие системного мышления, чтобы понимать как ваш звук будет ощущаться игроком.
Как понять, что Саунд-Дизайн это “Моё”?
Отвечает Александр Хилько:
Нет ничего лучше, чем работать в удовольствие и заниматься своим делом. Для работы саунд-дизанером нужно любить делать звук и музыку. Была история с одним из наших выпускников, который был электриком, увидел наше видео, и ему понравилось, теперь он технический Саунд-Дизайнер в Atomic Heart, ему понравилось с технической точки зрения то, чем мы занимаемся. Не бойтесь пробовать.Горящие глаза и энтузиазм с желанием одно из важных качеств в Геймдеве.
Как нужно озвучивать игры?
Отвечает Александр Хилько:
Многие допускают одну ошибку, которая не даёт их играм достичь продуктового результата. Несколько историй. Разработчики, делающие сделать хорошую игру, которую полюбят люди, далеки от звука, и хороший звук - это тот, который мы не замечаем. Существуют принципы по которому один и тот же звук, в разном сеттинге будет ощущаться иначе. И многие экономят на звуке, отдавая ресурсы в рекламу и маркетинг. Берут готовые ассеты из бесплатных библиотек. На выходе получаются игры, в которые не хочется играть.Когда вы вкладываете бюджет в графику и анимации, то считается моветоном не вложиться в звук, как в канал восприятия информации. Когда картинка и звук не сочетаются, то возникает ощущение, что на игроке экономят.
Какой технический подход используется в студии Саунд-Дизайна?
Отвечает Ресса Шварцвальд:
Документация, в которой прописаны ключевые моменты, которым должен соответствовать продукт, грамотное взаимодействие с заказчиком, и изучение конкурентов с более высоких тиров - например при разработке казуальной мобильной игры, референсами которой выступают популярные AAA проекты или популярные Инди-проекты, ориентироваться на их звук и их качество.
Какой путь избрать для попадания в Индустрию?
Отвечает Ресса Шварцвальд:
Попасть в студию и учиться у менторов, проходить образовательные курсы и повышать свой профессиональный навык, нарабатывать практику на реальных проектах, участвовать в Джемах и Интенсивах, изучать кросс-дисциплины для комплексного понимания разработки игр. Или же попытаться сделать свой игровой проект и билд, как игра будет взаимодействовать с вашим звуком.
Сколько может зарабатывать Саунд-Дизайнер?
Отвечает Александр Хилько:
От 1000$ на старте. Зарплатные вилки зависят от страны проживания, уровня квалификации и навыков. Разница между оплатой Junior и Senior больше, чем в семь раз.
Послушать выпуск целиком, разобраться в работе Саунд-Дизайнера, а может и попробовать себя в сфере (тайминг и куча полезных ссылок в описании):
Youtube, Вконтакте, Яндекс.Музыка, Castbox, Google Podcasts
Сайт подкаста с информацией обо всех выпусках: http://podcast.hsbi.ru/
Приятного прослушивания! :)
А если вам хочется не только слушать про игры, но и создавать их - приходите учиться на программу “Менеджмент игровых проектов”. За 9 месяцев вы пройдёте весь цикл игровой разработки, пообщаетесь с опытными экспертами из геймдева и получите практические знания о том, как разработать, запустить и эффективно оперировать свою игру.
Совсем скоро пройдёт Открытый лекционный вечер по Геймдизайну, где каждый желающий сможет послушать, вживую или на трансляции, лекцию наших преподавателей и сотрудников крупных игровых компаний, а авторы лучших вопросов получат ценные призы от партнёров. Узнать подробности и зарегистрироваться можно здесь.