Русский
Русский
English
Статистика
Реклама

Indie

История разработки The Light Remake. Часть 1

07.09.2020 20:15:27 | Автор: admin


Приветствую, читатель! Меня зовут Сергей, я являюсь инди-разработчиком компьютерных игр. В моем портфолио имеется уже несколько инди-проектов, часть из которых была самостоятельно выпущена в Steam. Игра Свет или The Light, вышедшая в 2012 году, была моей первой пробой пера, открывшей путь в мир игровой разработки. Проект распространялся бесплатно, но реакция публики и отзывы игроков подарили мне серьезную мотивацию для дальнейшей работы. The Light стал для меня чем-то вроде философской притчи о человечестве и его судьбе. Сюжет абстрактен и не преследует каких-то конкретных целей, это лишь возможность поразмышлять на обширную тему.

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




О чем речь?


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

Часть 1.


Первоначальная версия игры в уже далеком 2012 году была собрана на Unity 4.2. Тогда в моем информационном поле еще не было разговоров о PBR материалах, рефлекшн пробах и других актуальных сейчас методах. Базовые шейдеры в Unity были весьма простыми и не блистали особой реалистичностью. Конечно, можно было дописать множество дополнительных элементов, вроде отражений по френелю, но тогда шейдерное программирование для меня было тайной за семью печатями. Основным используемым шейдером был Normal Bumped Specular и AlphaTest diffuse для объектов с прозрачностью (листья деревьев, фигурные металлические решетки).

Рилтайм тени отсутствовали, почти все освещение было запечено в текстуру и разрешение этих теней местами было очень низким. Запекание света ко всему прочему свело практически к нулю эффект рельефа от Bumped Specular шейдера, в результате чего при ближайшем рассмотрении объекты больше походили на плоский картон.

Картинку в значимой степени преображали постэффекты на камере, в частности Bloom и Color Correction. Они добавляли красок и разнообразия, хотя и были местами слишком навязчивыми.



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

Спустя 7 лет на любое свое творение глядишь уже другими глазами. Технологии сильно ушли вперед, изменился инструментарий, последние версии движка Unity значительно отличаются от предшественников. В связи со всем сказанным выше перенос проекта с 4 версии на версию 2017 (решил остановится на ней в силу ряда причин) является достаточно долгой и кропотливой работой. К тому же, учитывая тот факт, что первоначальный проект и игрой полноценной называться не мог (большинство действий в игре осуществлялись с помощью одного скрипта с функцией триггера), нужно было с нуля писать всю логику, взаимодействие с объектами, инвентарь, систему меню, систему сохранений, достижений, настройки и т.д. В общем, меня ждал весьма масштабный объем работы!

Начало. Шейдеры и свет


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



Новый Standart
Было принято решение начать с замены старых шейдеров на новый PBR Standart. В предыдущих статьях на тему разработки 35ММ я уже упоминал (ссылка) о новом типе PBR шейдеров (Physically Based Rendering), что подразумевает физический правильный рендеринг. Новый материал Standart уже не имеет привычного из прошлых версий o.Gloss и o.Specular, здесь у нас карта металличности (o.Metallic) и Smoothness. Также, имеется больше слотов для текстур различной категории. К примеру, у нас появляется возможность добавить карту Occlusion для мягких затенений. Эффект очень полезный, поскольку позволяет подчеркнуть объем и затенения в тех местах модели, куда света попадает меньше. Без этой карты и лайтмап текстура объекты смотрятся плоско и нереалистично.



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



Растительность
После замены основных материалов я перешел к растительности. В оригинальной сборке игры был использован стандартный Alpha Test шейдер без спекуляра и Normal Map. Конечно же, данное положение вещей в 2019 году меня не устраивало. Можно было купить или найти на просторах интернета готовое решение, есть целые паки с шейдерами и готовыми моделями со множеством фитч, имитацией колыхания на ветру и т.д. Но уже традиционно я в таких вопросах пытаюсь разобраться сам и экспериментирую. Это что-то вроде спортивного интереса. За основу моего нового Vegetable шейдера был взят референс Toon Ramp из учебной статьи Unity.

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



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



К сожалению, в таком режиме автоматическая отрисовка задней стороны полигона методом Cull Off давала не очень корректный результат, поэтому Backface пришлось добавлять вручную в редакторе. Далее к шейдеру была добавлена карта Normal и Specular. Использовать модель освещения PBR шейдера и подключить Reflection Probes (зонды отражений) мне уже не удалось, но с помощью масок и Emission карты была добавлена имитация Ambient Occlusion. Ну и наконец, крайне необходимо было все это дело оживить и придать растительности движения. С помощью функции Vertex и той же маски нужные области плашек с листвой начинают оживать. За основу смещения вертексов взят пример Normal Extrusion with Vertex Modifier из мануала Unity.



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



Свет
Значительно был изменен подход к самому устройству освещения в сцене. В оригинале весь свет был запечен в лайтмапы, а рендеринг работал в режиме Forward. В ремейке важным аспектом было использование реалтайм света для возможности изменения времени суток. Режим рендера был сменен на Differed. Главный источник света (солнце) использовался в режиме Mixed, направленное освещение и тени рисовались а реалтайме, а глобальное освещение запекалось в текстуры. Это позволяло менять уровень освещенности и направление, но при этом сохраняло эффект мягкого глобального освещения и рефлексов, которые всегда придают картинке дополнительного реализма. Запекание лайтмап-текстур происходило не для всех объектов, в основном для крупных и более-менее простых. Мелкие и сложные для создания развертки оставались динамичными и подсвечивались либо лайт -пробами, рефлекшн пробами, либо просто базовым амбиент лайтом ( который указывается в главных настройках освещения). Запекание осуществлялось Progressive лайтмапером.







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



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

Также, при смене времени скрипт настраивал нужный цвет для постэффекта Global Fog, поскольку в дневное время туман должен выглядеть как светлая серо-голубая дымка, а в ночное иметь более темный, почти черный тон.



Модели и новый контент


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







Близлежащие строения, в которые раньше нельзя было попасть, были переработаны и стали доступны для игрока. Внутренняя планировка главного здания была также изменена. Помимо переработок старого контента был добавлен и новый, например модель автобуса ПАЗ, игровой автомат, автомат для продажи газировки, пазл электрощиток, гермоворота в подвале, предметы инвентаря и т.д. Часть контента была создана самостоятельно, некоторые же модели были заказаны на аутсорсе.



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

Эффекты и нестандартные шейдеры.



Вода



С каждым новым проектом хочется учесть нюансы, на которые ранее закрывались глаза. Общая картина создается из отдельных деталей и даже не особо важные элементы могут повлиять на восприятие. Плюс, это в некотором роде челлендж каждый раз улучшать что-то, с чем уже работал. Особенное удовлетворение доставляет самостоятельный поиск решений, а не использование готовых ассетов. Во всех предыдущих проектах мне приходилось работать с водой. Как правило это был достаточно простой вертексный шейдер, который не реагировал на игрока и освещение в сцене. За основу был взят Mirror Reflection с Unity Wiki, который являлся примером реализации зеркала.



Поверхность была динамичной за счет смещения вертексов (имитация волн), но всегда слишком однообразной и несколько скучной. Путем проб и ошибок для проекта Свет мне удалось создать Surface вариант аналогичного шейдера, который как и образец может: принимать текстуру зеркального отражения от скрипта Mirror, деформировать вертексы для имитации волн, записывать экран в Grabpass текстуру для создания преломлений под водой, иметь мягкие Alpha края при пересечении с геометрией ( depth fade). Также для эффекта реакции на игрока в шейдер передается информация о координатах положения игрока. В точке координат рисуется динамичное пятно, которое имитирует всплески, когда персонаж находится непосредственно в толще воды. Самое же главное, что позволил Surface шейдер принимать освещение от любых источников света. Таким образом вода кажется более осязаемой, объемной субстанцией и позволяет поиграть с ней с помощью эффектов освещения.



Каустика
Еще одной важной деталью стало создание эффекта каустики световых отражений, падающих на поверхности. В темноте затопленных водой подвальных туннелей этот прием был просто необходим. Эффект создан с помощью объекта Projector и светящегося материала с анимированной текстурой. В шейдере смешивается 2 текстуры каустики, которые смещаются в разных направлениях, в результате создается эффект динамики. В большинстве своих шейдеров для экономии я обычно применяю текстуры-маски, содержащие в себе 4 канала (RGBA) каждый для определенной цели. В канале R может быть основная текстура, в канале G более мягкие световые пятна, а в канале B текстура шума для искажения рисунка каустики.



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



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



Как уже отмечалось выше, почти все базовые поверхности в сцене используют модифицированный вариант Standart PBR shader. В некоторых добавлены маски с различными вариантами пятен для дополнительной детализации Albedo текстур. Поверхностям вроде асфальта или брусчатки добавлена маска пятен для имитации дождевых луж. Шейдер напольной плитки в главном здании имеет дополнительную карту для отражений, которые рисуются скриптом Mirror аналогично водной поверхности. Для оптимизации в прорисовку отражений включены лишь базовые и крупные объекты, а на определенном расстоянии рендер отражений выключается.

Туман/дым
Важная деталь, которую мне хотелось учесть при создании ремейка это динамичный туман и влияние на него освещения, в частности света фонаря. В более ранних работах основным шейдером для дыма и тумана был стандартный Particle blend и его модификации. Это вертексный шейдер, который хорош в плане производительности, но совсем не реагирует на свет. Отображение тумана с таким материалом будет всегда одинаковым в тени и на свету, его нельзя подсветить фонарем и выглядит это не всегда привлекательно и натурально. В задуманных мной подземных катакомбах дымка должна была высвечиваться фонарем из темноты, подчеркиваться динамичным освещением. Для решения этой задачи был использован шейдер из бесплатного Ассета. Высокой производительностью шейдер похвастать не может, но визуально со своей задачей он отлично справился.



Декали
Еще одним важным моментом стал поиск подходящего шейдера для декалей. В игре планировалось множество всевозможных граффити, которые чаще всего устанавливались с помощью старенького плагина decal system ( еще со старой версии Unity 4.6). Для граффити, надписей и знаков был создан большой атлас размером 4096 на 4096. Изображения на декалях полупрозрачные и отрисовываются в режиме Transparent alpha, поэтому в случае с динамическим освещением они не всегда выглядят адекватно, поскольку стандартный альфа шейдер не способен принимать тени.

Для решения задачи был создан специальный двухпроходный шейдер. В первом проходе рисуются темные части изображения, во втором светлые методом смешивания Blend DstColor One. Я могу не совсем верно понимать метод отрисовки, поэтому воздержусь от подробных объяснений, но желаемого результата удалось достичь: в тени изображение утопает во мраке, а на свету проявляется и даже играет красками. На производительность двухпроходность шейдера влияния не оказала, поскольку Decal system изначально объединяет все декали в один большой меш. Наверно есть более оптимальные способы, но такой вариант мне вполне подошел.





Земля/трава
Еще один двухпроходный шейдер был создан для поверхности земли. Сама территория на локации сделана геометрией в 3d max. Но для отрисовки травы дополнительно был создан террейн. Пришлось вручную подгонять высоты террейна в нужных местах, чтобы они соответствовали рельефу местности. Затем отрисовка самого террейна была выключена а на поверхность кистью наносилось несколько вариантов заготовленных мешей травы. Родная трава на террейне жутко нагружает сцену в плане производительности, поскольку она не батчится и каждый элемент создает дополнительный вызов отрисовки ( возможно кто-то меня поправит, если я не прав), но подобный метод крайне удобен в плане работы. Густота травы не высока и в тех местах где ее нет, очень бросается в глаза простота поверхности. Как раз в связи с этим в качестве эксперимента я использовал двухпроходный шейдер, о котором говорилось выше. Первый проход обычная непрозрачная геометрия, второй немного приподнятый дубликат поверхности в режиме Alpha test. Грубо говоря, дополнительно рисуется копия поверхности земли/ травы с жесткой прозрачностью и смещенными вверх вертексами. Такой метод несколько дополняет плоскую траву и создает иллюзию дополнительной детализации и объема.



Свет за окном
За окнами главного здания в некоторых местах были размещены односторонние полупрозрачные спрайты для имитации засветов. Также, в постэффекте Global Fog имеется параметр яркого белого тумана, который активируется по мере движения героя вглубь здания. То есть, при нахождении персонажа в темных коридорах корпуса, окружение за пределами плавно приобретает белесое свечение. Это создает достаточно красивый художественный эффект и позволяет подчеркнуть ближний и дальний план.



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

История разработки The Light Remake. Часть 2

21.09.2020 12:22:00 | Автор: admin


Приветствую, читатель! В первой части статьи, посвященной разработке The Light Remake в общих чертах был рассмотрен процесс переноса игры на новую версию Unity. Я немного рассказал об используемых шейдерах и эффектах, о том, какие решения были реализованы в работе со светом, какой дополнительный контент был создан, какой контент из старой версии был переработан и т.д. Во второй части речь пойдет о других аспектах разработки, о постэффектах, структуре проекта, работе со звуком, оптимизации и прочих нюансах.

Часть 2


Постэффекты


При переносе проекта на новый движок было принято решение оставить старые методы реализации постэффектов, которые использовались в более ранних версиях Unity. Работа с ними для меня была более понятной и я мог вносить необходимые изменения в сам процесс обработки картинки.

Гамма

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

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





Volumetric light

Очень важным элементом в данном ремейке стали постэффекты, связанные со светом. В старых версиях Юнити был очень симпатичный эффект объемных солнечных лучей Sun Shaft. Однако его функционал был ограничен, ведь он мог быть привязан лишь к одному источнику света в сцене.

В какой то момент мне на глаза попался очень занимательный эффект объемного освещения Volumetric lights Он позволяет создавать очень приятное, плотное свечение и лучи, которые могут исходить из разных источников. Атмосфера в сцене становится более объемной, объекты начинают утопать в легкой воздушной дымке, что меня крайне впечатлило. Единственным минусом стала высокая ресурсоемкость эффекта. Тем не менее, я решил его применить и благодаря Volumetric light удалось создать приятный свет от солнца во всей сцене, а также мистические направленные пучки света в отдельных местах: в коридоре на старте игры, в помещении с воробушком. Также эффект использовался для подчеркивания акцентов на светящихся ночью фонарных столбах, в эпизоде с проектором, в бойлерной для усиления света из окон, в финальной сцене вознесения персонажа к свету.



SSAO и SSR

Другими наиболее тяжелыми эффектами стал SSAO (Ambient Occlusion ), создающий мягкие затенения по углам и под поверхностями, без него сейчас никуда. Также был добавлен SSR (Screen Space Reflections ), с которым правда было много проблем еще на этапе разработки. SSR создает имитацию отражений на глянцевых поверхностях, в результате чего можно получить симпатичные рефлексы на кафельной плитке, металле и т.д. Проблема в том, что эффект оказался очень тяжелым и понижал FPS на моем железе почти в два раза. Путем некоторых манипуляций в коде постэффекта мне удалось немного снизить качество рассчета и несколько улучшить производительность. В целом частота кадров стала приемлемой, но в некоторых условиях (например при включенном Vsync) SSR вызывал периодические фризы и рывки при движении персонажа.



Другие

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



Кстати говоря, сейчас при работе с графикой часто вспоминается мой личный опыт обучения в художественной школе, где нас учили подчеркивать контрастные тени под объектами, отображать рефлексы на поверхностях предметов и накладывать в работе с пейзажами дымку на горизонте для подчеркивания воздушной перспективы. Теперь-то я знаю, что это все было SSAO, SSR и Global Fog!

Как это работает?


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

Система

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

Поскольку игра состоит по большому счету из одной локации, я решил не заморачиваться с подгрузками сцен, префабов и компонентов, разместил все необходимое в одной главной сцене. Были созданы контроллеры, которые управляют всем необходимым, переключают настройки, сохраняют игру и считывают сохраненные данные, считывают тексты для субтитров и записок из специального файла в корне игры и т.д. Для простоты реализации как и в прошлых играх было решено использовать систему сохранения в чекпоинтах. На локации находится несколько десятков интерактивных объектов вроде дверей, геймплейных предметов, керосиновых ламп и т.д. Для каждого сохранения необходимо записать идентификаторы состояния объекта, представляющие из себя обычно Int переменную. Например, дверь закрыта и заперта на ключ: DoorOpen o, DoorLocked 1. Не буду вдаваться в подробности относительно программерской темы, поскольку мои навыки в этой области несколько специфичны и поверхностны, однако, для реализации собственных проектов вполне достаточны.

Два финала

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



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

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

Субтитры и локализация

Для ремейка был проработан новый для меня подход к локализации и вообще отображению текстов и сообщений. Точнее, подход этот ранее уже был использован в проекте 7th Sector, однако там объемы контента были значительно меньше. За основу взят метод сохранения данных в хмл документ. Вся текстовая информация для локализации изначально хранится в xml файле в корне игры. Сообщения поделены на группы и имеют индивидуальную метку, принадлежат определенным категориям и определенным языкам. Для переноса строки я решил использовать символ ( * ), а для начала нового сообщения ( # ).



В нужный момент ( при выборе языка и старте сцены) контроллер считывает всю текстовую информацию, делит ее на строки и отдельные группы и записывает в своего рода библиотеку или словарь. Затем уже отдельные скрипты считывают эту информацию, например при открытии меню или активации субтитров на экране. Система мне лично показалась удобной и самое главное понятной. Она позволяет достаточно легко ввести новый язык и вносить изменения в уже имеющийся текст.

Звук


Некоторая часть базовых звуков была перенесена из оригинальных исходников. Амбиент, звуки пения птиц, звук кинопроектора и т.д. было решено оставить для сохранения узнаваемости проекта. Однако, требовалось большое количество и нового контента. Были добавлены звуки самого персонажа, шагов, активируемых предметов, дыхания героя в определенных моментах, эффекта сердцебиения и т.д. Большее разнообразие было внесено в набор звуков окружения, добавлен стрекот кузнечиков, рандомные звуки падения предметов и хлопков дверей. Кстати говоря, на добавление шума цикад или кузнечиков меня вдохновили пейзажи новой Half Life Alyx, в которой очень здорово передана атмосфера жаркого летнего дня. Некоторое время наслаждался, прослушивая и просматривая на Youtube записи с амбиентами из City17.

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

Целым пластом ответственной и кропотливой работы стало создание саундтрека. Композиции в оригинальном проекте не были лицензионными, это был набор из треков Ludovico Einaudi, композитора Thomas Newman и OST из игры Afraid of monsters. Тем не менее, обычно нам западает в душу то, что мы услышали впервые, например оригиналы треков чаще всего кажутся более приятными, чем их ремиксы, по крайней мере для меня. В данном случае при создании новых композиций очень хотелось сохранить стиль и атмосферу оригинальных треков. С данной задачей, как мне кажется, отлично справился композитор Дмитрий Николаев, с которым мы уже работали ранее над игрой 35MM. Особое впечатление на меня произвел новый взгляд на динамичную композицию, звучащую во время показа кинофильма в лекционном зале. Трек сохранил оригинальный энергичный и немного психоделичный стиль, стал звучать свежо, но узнаваемо. Кстати, сам кинофильм тоже был сильно переработан и включал в себя много нового материала. Контент для видео более тщательно выбирался во избежании нарушения авторства, а часть фрагментов была создана самостоятельно.

По ссылке можно посмотреть первоначальный видеоролик, используемый в оригинальной игре 2012 года.



Хотя в игре нет диалогов, нашлось место и для голосовой озвучки. Помощь в записи оказал Всеволод Петрыкин, уже участвовавший ранее в проекте 35ММ и подаривший свой голос главному персонажу Петровичу. Его речь можно услышать из громкоговорителей в момент появления самолетов, из телефонной трубки в эпизоде с запуском ракет и по радио, на втором этаже главного корпуса.

Оптимизация


Одной из наиболее болезненных тем и задач в работе над ремейком стала оптимизация. Так вышло, что почти все проекты, созданные мной ранее на старой версии Unity ( 4.6) были достаточно просты в плане нагрузки на железо. Игра 35ММ на моей карте GTX 970 местами выдавала 200- 300 fps в достаточно сложных и загруженных сценах. Оригинальный Свет, собранный на еще более ранней версии движка показывал FPS еще выше. Но при переходе на Unity 2017 частота кадров просела в 2-3 раза. Понятно, что сцена стала намного сложнее, добавились просчеты света и отражений, дополнительные постэффекты и т.д. но настолько разительного снижения производительности я не ожидал. Загвоздка в том, что даже убрав из сцены практически все наполнение, показатель FPS у меня не поднимался выше 200-300. Это полупустая сцена, Карл! Была проведена большая работа по упрощению некоторой геометрии, созданию Lod групп, настройке Occlusion culling и т.д.



Также камерам с помощью скрипта назначалась дистанция отсечения определенных слоев. Для реализации использовался пример из мануалов Unity. Объекты разных размеров были присвоены отдельным слоям, которые перестают рендериться, если камера находится слишком далеко. Мелкие объекты, вроде банок, мусора, деревянных обломков, книг отсекаются после 20-30 метров. Более крупные после 60-80. Все перечисленные меры позволили значительно снизить число Drawcalls. В среднем количество вызовов отрисовки в сцене колеблется в диапазоне 800 2000 DC. Количество полигонов в кадре не превышает 1 миллиона.



Отсечение светильников

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

Немного деталей


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



  • Сама текстура карты и подписи к ней рендерится в движке отдельной камерой. Для этого в сцене отдаленно от места действия находится префаб со схемой и текстами. Префаб рендерится специальной камерой в режиме рендер в текстуру, а текстура отправляется уже в материал карты. Это позволяет динамически менять язык и обновлять его на самой карте. Также это дает возможность легко добавить новые элементы, например во время нахождения персонажа в темных астральных лабиринтах с телевизорами изображение на карте меняется и появляются жутковатые черные каракули.



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

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



  • В катакомбах в одном из мест используется прием зацикленного коридора или петли. Похожая задумка была реализована в игре STALKER Зов Припяти на локации, где располагался Оазис. Когда мы попадаем в определенный триггер, скрипт переносит нас в почти такой же коридор, но уже зеркально и в обратном направлении. В результате, блуждая по туннелям мы несколько раз выходим в один и тот же зал. Телепортация не всегда срабатывает корректно, поэтому можно заметить резкий скачок и изменение дымки/ тумана перед собой.

  • Специально для проекта был снят видеоматериал с видами реальной территории, взятой в качестве референса 3 корпус Московского Гуманитарного университета. Из материалов был смонтирован ролик, который стал секретным бонусом, доступным после прохождения игры. Для проникновения на территорию пришлось перелезать через старый бетонный забор. При переброске бойцов в целевой сектор ни одни штаны порваны не были.



  • Почти к финалу разработки проекта в качестве эксперимента мной был создан шейдер сосуда с жидкостью, аналогично бутылкам с жидкостями из Half Life Alyx, которые были добавлены с патчем. Качество не сравнимо, но выглядело все равно интересно. Я был настолько вдохновлен, что решил добавить бутылку в проект. Взять в руки ее нельзя, но можно несколько раз пошевелить, после чего она упадет на стол. По ссылке можно посмотреть небольшую демонстрацию.



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



Парочка мыслей


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

Желаю всем удачи, творческого вдохновения и высокого FPS!
Подробнее..

Микрокосм, демоверсия

23.10.2020 18:08:20 | Автор: admin
Всем доброго дня, в какой бы галактике вы не находились.
После череды итераций прототип космической jrpg, разрабатываемый на Godot engine, дорос, наконец, до первой демоверсии. Доступны win64 и linux варианты. Ниже подробности о том, что было, что стало и куда летает маленький звездолёт.


Каркас


Наброски базового геймплея сформировались довольно быстро, когда я перешёл от продумывания основных положений концепции к сборке игрового прототипа внутри игрового движка. Сначала появился стартовый экран, сцена глобальной карты с движением и возможностью вызова инвентаря. Тогда же была продумана некоторая начальная архитектура как именно грузить отдельные модули и обмениваться информацией между ними.
Затем появился экран сражения, запускаемый сначала по отдельной кнопке, а позднее привязанный к столкновению с врагами. Позже добавился экран планеты, у планет к тому времени появился информатор на глобальной карте, куда и была добавлена кнопка посещения. От информатора в свою очередь отпочковались прочие виды интерактивных объектов, например станция, не подразумевающая входа на свой внутренний экран, но иногда имеющая какой-то внешний функционал с возможностью что-то нажать или выбрать. Или подбираемые ресурсы космическая пыльца.
Далее требовалось реализовать максимально возможную партию героев (выбирая между 3-мя либо 4-мя, я выбрал всё-таки концепцию партии из 3-х), что и было сделано. В процессе добавилось отображение повреждений, выбор целей для атаки, немного музыки.
На этом этапе можно было уже выкладывать мини-демку, но я решил сначала доработать проект до более комплексного состояния, чтобы было лучше понятно, что это вобще такое и как оно примерно должно работать. Попутно добавив немного контента и каких-то украшательств, типа озвучки действий, анимаций.

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



Развитие прототипа


Рассмотрим различные области, в которых происходило это развитие:

Бой

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

Отображение повреждений поначалу было реализовано через 3д-представление вывод вьюпорта со строкой урона на обращённый к камере полигон. Это более менее работало, хотя реализация технически мне не очень нравилась, так как с вьюпортом всё немного заморочено нужно вешать его поближе к корню сцены, чтобы не возникало сбоев и проверять как выглядит эффект чуть сложнее, чем с просто выводимой 2д-строкой. Поэтому много вьюпортов заводить не хотелось, я обходился всего одним, перемещая выводящий его полигон куда нужно, попутно увеличивая/уменьшая. А ведь надо думать и о том, что когда-то появятся способности, наносящие массовые повреждения и потребуется выводить как минимум три значка с уроном одновременно (хотя и тут можно исхитриться, сделав как бы анимацию-волну из одного и того же объекта или уж завести ещё пару вьюпортов).
Однако, когда я добавил в прототип режим полного экрана, то там цифры повреждений стали заметно так размываться, поэтому ещё сильнее захотелось рассмотреть иные варианты отображения урона. В принципе я мог бы просто фиксировать камеру в бою, но я зачем-то продолжаю до упора сохранять возможность вертеть ею в моменты между ожиданием действия.
Поэтому в итоге я переписал вывод урона. Теперь 2д-строчки цепляются к проекции позиции 3д-объекта. Хотя тут тоже есть свои нюансы, например, если отвернуть камеру, то они продолжат показываться или если их выводить беспрерывно в каждом кадре, то есть возможность подвесить текущую камеру в одном положении, но это уже решаемо.

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

Корабли и враги

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

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

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

Способности и персонажи

Если корабли являются неким аналогом главных героев, то перевозимые ими персонажи являются неким аналогом оружия этих героев. Одним из важных моментов, который хотелось отразить в проекте это использование системы идентификаторов, которые дают эффект неслучайной случайности, а при более широком использовании могут работать на генерацию псведо-сюжета. Говоря по-простому, у персонажей, кораблей и врагов есть специальные ID, позволяющие рассчитать результат взаимодействия любых этих объектов и как-то его использовать.
На данный момент использование этого результата следующее. Во-первых, у каждого персонажа и корабля возникает эффект совместимости. То есть, оказавшись на борту корабля, персонаж может, например, начать паниковать, уснуть, или не понимать как обращаться с его системами. Сейчас просто в окошке инвентаря выводится результат связи корабль-пассажир и возможный дополнительный эффект, ею накладываемый. Но на участии персонажа в бою это пока никак не отражается.
Непосредственно в сражении персонажами можно атаковать через опцию Экипаж. Это не просто совершение персонажем какого-то конкретного действа, вроде конкретного магического заклинания или выстрела из оружия. Это некая ситуация, повлекшая за собой определённое количество потерь со стороны противника. Здесь работает уже связь пассажир-враг, которая интерпретируется окружающим миром (в данном случае космическим сектором) в одно из девяти последствий: #СВЕТ, #ТЬМА, #МУЗКА, #ТЕОРИЯ и так далее. То есть игрок может ассоциативно представить, что сделал персонаж, что получилось последствие с такой формулировкой (а может и не представлять ассоциации дело необязательное, тем более они всё-равно сами по себе работают где-то в фоне). У каждого врага соответственно есть уязвимости или стойкость к определённого вида последствиям. Возможно, в дальнейшем применение системы идентификаторов ещё более разрастётся. Например, на тех же планетах могут действовать их собственные ауры смыслов, видоизменяющие таблицу интерпретаций, но сначала нужно реализовать там какие-то события, в которых участвовали бы идентификаторы.

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

Предметы

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

Экран планеты и задания

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

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

Прочее

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

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

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

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

Демоверсия


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

Ранний тестовый вариант локации, где различные планеты и враги размещены более плотно, доступен в альтернативном, менее отлаженном, режиме игры all ships test. Там сразу доступен выбор из 10 существующих кораблей (в активную партию можно брать до трёх), больше героев/грузов и распределены они иначе. Могут возникать некоторые наложения внутриигровых параметров после выхода из одного режима и переключения на другой.

Нововведения последнего обновления показаны в новом ролике, где помимо геймплея добавлены элементы тизера.

Видеонарезки некоторых предыдущих обновлений








Загрузить архив демки можно здесь (dropbox):

Win64 версия (50 Mb)

Linux версия (52 Mb)

Управление:

WASD полёт, мышь вращение камеры
Enter открыть/закрыть инвентарь во время полёта в космосе


Кораблики: 1 Скиталец, 2 Спира, 3 Авангард, 4 Дева Яга, 5 Мухх, 6 Стелла, 7 Тринити, 8 Отомо, 9 Аквамарин, 10 Гиибель.

Подробнее..

Немного о нашей безымянной студии и о том, что мы делаем

31.01.2021 22:19:51 | Автор: admin

Привет всем! Пока мы, на самом деле, безымянная студия и проект, который делаем имеет техническое название "CGDrone". Сегодня мне захотелось написать эту короткую статью. Понимаете, замучался от всей этой работы со скетчами, цветами, алгоритмами и исправлением багов во вращениях, которые реализованы с помощью кватернионов. Последние, к слову, меня порядочно побили.

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

Начало

Дело было в институте, конец магистратуры. Мы с моим товарищем из параллельной группы решаем создать свою супер-пупер 3D-головоломку от первого лица. Такую что просто ну просто бомба и огонь. Надеюсь вы поняли меня. Почему решили делать игру? У меня есть опыт в рисовании, закончил школу с ИЗО уклоном, у напарника есть опыт в создании 3D-моделей. Ну и оба мы программисты как-никак, поработали в фирмах в т.ч. игры делали. Почему головоломку? Потому, что нам нравятся головоломки.

Работу мы разделили примерно пополам ну или делали кто что может. С одной стороны, если в команде 2 человека, то делить работу можно пополам! Удобно же :) И на контроль за результатами работы всех разработчиков не так много времени уходит как, скажем, ушло бы если бы в нашей команде было 30 человек.

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

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

Не поверите, но у меня набралось 2 папки со скетчами по проекту и иногда мне все еще приходится набрасывать картинки/перебирать идеи/сопоставлять обьекты. Скетчи, которые я набрасывал выглядят примерно так:

На данный момент мы опубликовали большую часть скетчей в твиттере / инстаграме.

Были еще знакомые, мы попытались подключить их к проекту. Кроме нас в команде было две девушки (дизайнеры-художники), гейм-дизайнер и программист. Через 2-3 недели программист пошел работать в крупную фирму, после попыток прописать структуру проекта и сборки одного игрового обьекта - условный обьект с "глазом" (который следит за игроком). Потом нас покинули дизайнеры. Гейм-дизайнер оказался крепким. Он был с нами до последнего, а вот результатов его работы у нас не было :)

Кстати, игра на тот момент выглядела так:

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

Еще несколько скетчей:

Коротко о некоротком, о сети

Изначально мы планировали сетевой режим. Вот что-что не стоило делать, так это сеть. Я пытался вытягиват сеть до последнего. Просто как кот вцепляется в рыбу, так и я вцепился намертво в сеть В итоге мы реализовали комнаты, уровни, сетевое взаимодействие основных обьектов. Но все это двигалось очень долго, тесты и отладка занимали тьму времени. Интерфейс игры тогда выглядел так:

Мы много чего сделали по сетевой части, в том числе и организовали сетевой чат (иконка конверта) и систему общения голосом (иконка микрофона).

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

Лучше синица в руках, чем журавль в небе

Попытки расширить команду

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

  • профессиональные художники хотят получать денюжки, а у нас есть только энтузиазм

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

  • мотивировать команду - это работа на которую затрачивается много времени

Для себя мы поняли еще одну вещь: у нас нет времени на выдачу ТЗ ребятам, которые работают на энтузиазме потому, что высока вероятность их ухода. Так что мы решили делать все сами и никого не искать, не расширять команду. У этого решения есть плюс, который я описал бы так:

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

На данный момент мы все так же усердно работаем над проектом. Сделали кучу основной работы, работаем над оптимизацией, полировкой графона, анимациями и историей.

Так же в последнее время к нам присоединился переводчик, который взялся прорабатывать сценарий :) Уже вот год работает с нами как и мы на энтузиазме.

А вот и ссылки на нас:

https://twitter.com/CGAleksey

https://www.instagram.com/cgaleksey

https://vk.com/treload

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru