Dictator: Glory Fatherland
Возьмите на себя роль правителя республики Свекловии, которую разрывает гражданская война между девятью регионами. Объедините свою страну вокруг столицы, не потеряв доверие граждан.
Возьмите на себя роль правителя республики Свекловии, которую разрывает гражданская война между девятью регионами. Объедините свою страну вокруг столицы, не потеряв доверие граждан.
Всем привет! Это девлог игры The Last World. Игра разрабатывается одним человеком. Во второй части рассказываю про технические моменты и немного механики. Критика, предложения, советы и вопросы по теме приветствуются.
Заранее прошу прощения за длинный пост, я старался максимально минимизировать его, давая больше визуального сопровождения.
ССЫЛКИ
Прежде чем продолжить читать длиннопост, подпишись в сообщество, плиииииз. А также не забудь добавить игру в Желаемое!
О ЧЁМ СТАТЬЯ
В прошлой статье я рассказал немного про игру The Last World и вскользь затронул её механики. Кто не знаком с ней, прошу ознакомиться, это займет 5 минут. В этой статье (часть 2) пойдет речь о механиках и некоторых других аспектах игры. Кто не знаком с первой частью стать #2 - она тут.
ТОРГОВАЯ ПЛОЩАДКА
Игрок добывает, производит, перерабатывает и копит, а дальше куда, что делать со всем этим добром? Для этого была добавлена космическая торговая площадка, на которой можно купить, продать или обменять ресурсы. На космической торговой площадке будут свои правила ведения бизнеса.
Первая версия окна торговой площадки. Может быть изменена.
Для доступа к космической торговой площадке нужна постройка – Торговая Площадка. Грузовые шаттлы будут сбрасывать груз при выгрузке и забирать, при загрузке. Грузовые шаттлы можно арендовать у торговцев, пока не будет введена орбитальная станция - основная база игрока.
В игре The Last World все цены предметов привязаны к ценам базовых ресурсов и рассчитываются автоматически, в зависимости от стоимости производства или переработки. Также торговцы могут накинуть какой-то процент на товар при продаже или скинуть процент, при покупке.
В целом, система торговли имеет огромный запас прочности, так что её можно улучшать и улучшать.
ИГРОВЫЕ СЕТЕВЫЕ ИНСТРУМЕНТЫ
Я не хотел нагружать мозг игрока, а тут ещё и конвееры делать нужно. Решил уйти от традиционного построения конвеерного мира переносом всего в "игровую виртуальность" обозвав это всё "сетями". Итак, в игре есть 3 сети – конвеер, электросеть и трубопровод. Все они независимы друг от друга и живут отдельно.
Переходя в режим инструментов, игрок переходит в "чертёжный режим". Там он будет соединять линиями постройки, которые хочет подключить к сети. Всего есть 5 подинструмента – линия, мост, считыватель, удалить элемент сети и удалить целую сеть. Целой сетью считается непрерывные участки этих самых линий. Всё просто и понятно. Хотите подключить две постройки между собой – соедините их линиями.
ТЕХНОЛОГИЧЕСКОЕ ДРЕВО
Всего в игре The Last World будет 3 древа технологий – основное, юнит и постройка.
В качестве построения основного древа я выбрал вертикальное вниз исполнение. При этом технологии, которые недоступны игрок всё же видит и может посмотреть, что же там интересного или нет.
По основному древу технологий игрок продвигается сверху вниз и вбок, проходя по всем разделам он открывает каждую технология не обязательно в определенном порядке.
Технологии исследуются в специальных постройках – Исследовательская Станция. В качестве "горючего" она принимает местный аналог "колбочек" называемое - чип-грант. Чип-гранты можно произвести или купить на торговой площадке.
Технологические древа юнита и построек ещё не готовы и находятся в процессе разработки.
СТРОИТЕЛЬСТВО
Во время размещения построек необходимо учитывать несколько факторов – можно ли строить на воде, граница локации, а тут есть дерево, гора, пересечение построек и тп. Постройки можно вращать на 90 градусов при размещении, что придаёт немного больше гибкости планирования. После размещения постройки переместить постройку будет невозможно – только удалить и построить вновь.
Во время размещения постройки производится много вычислений на пересечение с объектами сцены. На самой большой локации размещается около 140 чанков и проверять пропы этих чанков на столкновение нет смысла, достаточно лишь найти 4 ближайших чанка и проверить их. Одним из соображений уменьшения размера чанка с увеличением размера локации является эта самая проверка столкновений.
Чтобы удалить постройку можно воспользоваться двумя путями – вызвать контекстное меню и удалить, или использовать инструмент вверху экрана. Этот инструмент позволяет удалить множество построек – наведи и кликни.
СВЕТ
В игре The Last World будет много источников света в ночное время суток. По сути, сколько построек, столько и источников света. Т.к. игра делается с использование URP а там, да и не только там, на 1 объект может светит только 8 источников то возникает вопрос – как так и где решение?
Решением оказался URP differed, это сравнительно новая функция поэтому я не до конца разобрался что это и с чем её едят. Единственное, что при переходе на неё нужно будет немного редактировать кастомные шейдеры. Теперь я могу светить на объект (а это у меня был в основном террейн) хоть +100500 раз.
ИНВЕНТАРЬ
Ну вот и подошли к самому интересному, по моему мнению, это система инвентаря. Я уже писал, что каждый юнит, постройка имеет свой отсек для хранения предметов. Для юнита это модули – передний и задний отсеки, в которые можно складировать предметы разных размеров. Для построек – это размер самой постройки, её габариты и вместимость. На наземную лампу ведь не сделаешь размер отсека в 40х40 ячеек…
Инвентарь в игре представлен в виде ячеек. Все предметы имеют вес. Вес представлен в виде размера, которые они занимают в инвентаре. С предметами можно производить манипуляции – вращать, перемещать, стаковать, разъединять, удалять, в общем всё, чтобы было комфортно пользоваться инвентарем. Само перетаскивание и прикрепление предметов реализовано по принципу – Drag and Drop.
Помимо ячеистых систем есть и слотовые, на которые можно поместить только один предмет, определенного класса. К таким относятся слоты модулей юнита.
Работа с инвентарем неимоверна сложная, запутанная и интересная. Считаю, что разработку любого проекта нужно вести от самого сложного к простому, так можно быстро отсеять ненужный функционал. Как говорят – глаза боятся, а руки делают.
У некоторых дронов также присутствует отсек для хранения ресурсов. Им он необходим для работы, например, для добывающих дронов. Во время игры можно посмотреть содержимое этого отсека через контекстное меню. Окно с содержимым доступно только для просмотра. Этот же функционал доступен и для персонажей.
К слову о контекстном меню или "мини-меню" - в игре мини-меню можно вызывать практически на всех слотах, предметах, юнитах, построек и тп. Тут уже нужно экспериментировать и тыкать на всё подряд, чтобы понять, можно ли вызвать мини-меню. Позже я упрощу этот поиск использованием подсказок в виде "tooltip".
В игре будет много предметов, которые можно найти, создать, добыть, купить или обменять. Какая-то часть из них не будет нести особой ценности, они будут нужны лишь для заработка или коллекционирования.
Есть предметы с эффектами, например, модули для юнитов, которые будут бустить один или несколько параметров. Также в игре присутствуют и модули для построек, которые также могут увеличить или уменьшить какие-либо параметры постройки. Например - очень полезная штука для очищающей станций, если раньше постройка могла очистить за 1 секунду только 1 ресурс, то после добавления модуля сможет очищать уже 3 ресурса за то же время (но при этом расходы увеличатся).
Помимо обычных (твердых) предметов в игре есть и ещё несколько типов – газообразные и жидкие. Они не имеют оболочки и на прямую с ними игрок не сможет взаимодействовать. Хранить такие ресурсы нужно отдельно в цистернах. Также такие ресурсы можно разлить в бочки и перевозить на большие расстояние или использовать в производстве, при необходимости.
Для юнита и инструментов есть такие модули, которые могут хранить в себе другие модули (имеют функционал контейнера). После прикрепления этого модуля к юниту или инструменту, все дополнительные модули автоматически загрузятся на свои места.
ЕЩЁ НЕМНОГО
В данный момент работаю над погодными условиями. Пока будет несколько типов погодных условий:
* Sunny или Clear – чистая, солнечная погода с небольшим количеством облаков и легким ветерком;
* Cloudy – облачная погода, яркость от источника света будет снижена на %, ветер чуть сильней чем обычно;
* Rainy – много густых облаков, сильный дождь, сильный порывистый ветер (вероятность 50%), увеличена вероятность встретить разряды молний, густой туман (вероятность 50%), яркость от источника света будет снижена на большой %;
* Storm – больше густых облаков, очень сильный дождь, выпадение града (вероятность 50%), большая вероятность встретить разряды молний, очень сильный порывистый ветер, яркость от источника света будет снижена на очень большой %;
* Snow – больше густых облаков, средний снег, выпадение града (вероятность 50%), сильный порывистый ветер, яркость от источника света будет снижена на большой %, густой туман (вероятность 50%);
* Snowstorm - больше густых облаков, очень сильный снег, выпадение града (вероятность 50%), большая вероятность встретить разряды молний, очень сильный порывистый ветер, яркость от источника света будет снижена на очень большой %;
* Sandstorm – небольшое количество облаков, очень сильный порывистый ветер, песчаные бури.
Также усердно работаю над созданием странички в магазине Steam. В обозримом будущем есть планы улучшить визуал Конструктора, сделать платформу и добавить больше статистики и многое другое…
Критика, предложения, советы и вопросы по теме приветствуются.
Спасибо за инвестированное время! Присоединяйтесь в сообщество и следите за ходом разработки, буду вам рад!
ССЫЛКИ
Много лет назад я занимался созданием маленьких Flash игр и публиковал их на сайте Newgrounds. Сейчас я делаю полноценные игры для ПК.
На сегодняшний день у меня 4 законченных коммерческих игр в Steam, и самая последняя из них — выпущенная в 2021 году Pilie Pals, о процессе создания которой я расскажу в этой статье. Я работал над игрой всего примерно 6 месяцев, по вечерам после работы и на выходных.
Оригинал статьи на моём сайте, с ссылками на другие связанные статьи: https://kircode.com/ru/post/how-i-make-games-in-my-own-3d-ga...
Pilie Pals — это игра-головоломка, в которой игрок возглавляет группу милых существ, способных складывать в стопки и носить разные предметы, и даже друг друга.
Я занимаюсь дизайном, программированием, графикой, звуками и музыкой в одиночку. Мне это нравится, и таким образом я могу часто переключаться с одного вида деятельности на другой, благодаря чему не теряю интерес к разработке игры.
Я написал собственный 3D игровой движок YUME, используя Haxe, C++ и OpenGL, и на данный момент он используется тремя моими играми. Подробности и причины создания собственного движка приведены в отдельной статье (подробности на сайте). Такой подход меня вполне удовлетворяет, и я не планирую его менять.
Разработка Pilie Pals
В начале разработки Pilie Pals я скопировал папку проекта своей предыдущей игры Phantom Path и удалил все ресурсы и файлы кода, связанные с игрой. Остался "чистый" движок, с которым можно экспериментировать, чтобы создать прототип следующей игры.
Перед тем, как описывать создание Pilie Pals, я объясню несколько главных принципов работы моего движка.
Хранение игровых данных в текстовых файлах
Мой движок почти полностью основывается на внешних данных (data-driven). Это значит, что я создаю набор файлов с данными, а движок их читает и обрабатывает.
Я стараюсь избегать жёсткого прописывания чего-либо в исходном коде игры. По возможности, вся информация хранится в отдельных файлах: игровые объекты, уровни, переводы текстов, визуальные и звуковые эффекты, и даже некоторая игровая логика, написанная на собственном языке сценариев YumeScript (подробности на сайте). Большая часть данных хранится в формате JSON.
Самое большое преимущество такого подхода заключается в том, что я могу создавать и править игру, не выходя из неё. При изменении какого-либо файла с данными движок автоматически перегружает ту часть данных, которая изменилась, без необходимости перезапускать или пересобирать что-то вручную. То же самое происходит с другими ресурсами, например, с текстурами, 3D моделями и звуками.
Ещё один плюс — это потенциальная поддержка пользовательских модификаций игры. Для Pilie Pals это не так актуально, но это область, которую я хотел бы изучить в будущем.
Сущности
Два главных компонента сцены игры в моём движке — это сущности и карты.
Сущность — игровой объект, который я описываю в JSON файле, чтобы впредь создавать экземпляры объектов такого вида. Например, персонаж игрока — это сущность.
Файл описания сущности содержит информацию:
- Какие 3D модели содержит данная сущность, и как их отображать
- Какие анимации могут совершать модели этой сущности, и как осуществляются переходы из одного состояния в другое
- Какие эффекты может запускать данная сущность
- Какие звуки может воспроизводить данная сущность
- Какие области соприкосновения есть у данной сущности
- Какие у сущности могут быть состояния, и каково поведение сущности в разных состояниях
- Другие данные для использования в игровой логике: специальные тэги, группы, и т.д.
Каждый персонаж, дерево, ящик, элемент игры и декораций — это отдельная сущность.
Стоит отметить, что у каждого экземпляра сущности есть собственная машина состояний, и у каждого состояния есть последовательность действий, которую сущность может проигрывать.
Например, можно задать состояние "walk" (ходьба) для сущности персонажа игры, и последовательность действий этого состояния может содержать команды, которые запускают нужную анимацию 3D модели, проигрывают звуки шагов и показывают эффект поднимающийся с земли пыли. Всё это описывается в текстовом файле, который можно редактировать и сразу тестировать, и это сильно ускоряет процесс разработки.
Карты
Карта — это файл данных, который содержит описание расположения сущностей. В этом файле также есть многоуровневая сетка "плиток", из которой можно построить ландшафт. Я не меняю файлы карт вручную — карты создаются с помощью встроенного редактора.
Так как движок знает всю информацию о сущностях, которые располагаются на карте, он в состоянии автоматически оптимизировать некоторые вещи. Например, если сущность является статичной и никогда не двигается (например, дерево или ландшафт), то движок автоматически объединяет её вместе с другими статичными сущностями, которые используют одинаковую текстуру, и создаёт одну общую 3D модель. Это значительно сокращает количество отображаемых видеокартой объектов, что сильно улучшает производительность игры.
Игровая логика
Некоторая часть игровой логики может быть описана в текстовых файлах, но она используется только для создания игровых сценариев, а не основной функциональности игры. Такая логика, как система соприкосновений, поведения искусственного интеллекта, правила игрового процесса и т.д. — программируется в исходном коде Haxe, который превращается в C++ при компиляции.
Есть 2 категории файлов кода, связанных с логикой:
- Процессоры логики сущностей — могут быть присоединены к отдельным сущностям, используются для обработки индивидуальной логики объектов (например, искусственного интеллекта). Не каждой сущности нужен процессор логики
- Ядро — одиночный класс, который описывает общую логику правил игрового процесса.
Первый месяц: Прототип
У меня была идея о пошаговой игре-головоломке, в которой игрок может управлять сразу несколькими персонажами, способными поднимать и переносить всякие предметы. Логика игры должна была быть пошаговой, потому что я хотел записывать каждый игровой шаг, чтобы дать игроку возможность отменить свои шаги, т.е. вернуться в прошлое.
Сначала я написал ядро логики и реализовал пошаговую систему. Для каждой сущности, которая является частью головоломки, ядро выставляет состояние.
Игрок может выделить персонажа и выполнить действие (например, переместиться, или поднять предмет), которое меняет состояние игрового мира. Игра потом вычисляет, является ли возможным новое состояние мира (например, не столкнулся ли игрок с препятствием), и проверяет, нужна ли какая-либо реакция на это изменение, со стороны других элементов головоломки (например, если игрок положил какой-то предмет на кнопку, то у кнопки должно измениться состояние на "нажатая"). Если все проверки пройдены, то изменения применяются и добавляются в историю шагов.
Игрок может отменить последний шаг, просто вернувшись в предыдущее состояние мира.
В этом заключается основная функциональность игрового ядра. На самом деле, всё немного сложнее, потому что мне нужно обеспечить плавные, анимированные переходы между состояниями, позволить элементам быть переносимыми другими элементами, и делать другие интересные вещи — но всё это добавляется к базовому "фундаменту" логики игры.
Реализация такой системы и всех крайностей заняла у меня примерно неделю. Оставшееся время заняли размышления о том, какую игру я хочу сделать. В это время у меня появилась идея о том, что персонажи могли бы переносить других персонажей, и даже создавать стопки из друг друга.
Я создал 4 уровня игры, используя мой существующий редактор карт, чтобы убедиться, что игровой процесс действительно интересный. Результат мне понравился, и я продолжил разработку.
Второй месяц: Графика
Теперь у меня был рабочий прототип игры, и можно было начинать экспериментировать с художественными стилями. Я остановился на мультяшном визуальном стиле, и весь месяц занимался созданием 3D моделей, анимаций, эффектов, интерфейса, переходами, и т.д. Игра разбита на 5 тематических миров.
Я использую Blender для создания 3D моделей и анимаций, и GIMP для создания текстур.
Пластиковый вид игры достигнут с помощью написанного мною шейдера, который применяет заранее приготовленные данные об освещении к моделям. Работает это так: берётся заготовленная картинка освещённой сферы, применяется к некоторым частям модели, смешивая цветовые данные текстуры на основе нормалей модели в пространстве экрана.
Идея такого эффекта появилась у меня после работы с программами 3D моделирования и скульптуры. Подобный эффект в таких программах иногда называется MatCap. Мой подход заключается в том, что я смешиваю такой приём с традиционными алгоритмами освещения в реальном времени. Получается интересный эффект, который обрабатывается видеокартой очень быстро.
До и после применения предварительно "запечённых" данных освещения к моделям.
Третий месяц: Полировка
Весь месяц я улучшал User Experience игры: добивался плавности анимаций, хорошей чувствительности управления, чистоты графических элементов, удобности интерфейса.
Было реализовано меню паузы, меню выбора уровня, система последовательности уровней и системы сохранения — практически весь этот функционал у меня уже был создан для предыдущих игр, поэтому можно было повторно использовать часть этого кода, откорректировав некоторые визуальные вещи.
Работать над интерфейсами довольно утомительно, но плохой UX раздражает игроков, поэтому важно сделать всё правильно с самого начала.
Я решил сделать отполированный, полноценный "вертикальный срез" как можно быстрее. Таким образом я смог бы проверить, как бы выглядел готовый проект. Так как в игре на тот момент было мало контента, можно было свободно вносить глобальные изменения без особых проблем.
Четвёртый месяц: Музыка, звуки и демо версия
Я пишу музыку и создаю звуки в виртуальном модульном синтезаторе SunVox. Я — самоучка, и создание музыки у меня занимает довольно много времени.
В моём движке есть система динамического звукового окружения, которая может генерировать окружающий шум в реальном времени, используя подготовленные звуки (например, шум волн или крики птиц), меняя их частоту и воспроизводя в разных направлениях и в разных комбинациях. Эта информация описана в отдельном JSON файле.
На тот момент у меня была полностью "отполированная" игра, в которой было всего 4 уровня. Я создал ещё 6, и выпустил демо версию игры.
Так я стал собирать отзывы от игроков на ранней стадии разработки, и смог на их основе улучшить User Experience игры.
Примерно в это время я добавил систему подсказок в игру. О ней я подробно написал в отдельной статье (подробности на сайте).
Пятый и шестой месяцы: Контент игры
Следующие два месяца я делал новые уровни, добавлял новые игровые элементы, используя ту систему сущностей, которую я описал выше. В исходном коде игры уже практически не было никаких изменений, потому что ядро игры уже было полностью готово.
Эти два месяца я в основном работал в редакторе карт.
Вывод
В целом я удовлетворён результатом.
В начале разработки игры у меня уже было довольно чёткое представление о том, какую игру я хочу сделать. Поэтому процесс разработки прошёл намного плавнее и быстрее, чем обычно. Так я осознал важность наличия чёткой цели с самого начала.
Также оказалось хорошей идеей сделать отполированный вертикальный срез как можно скорее. Таким образом, я мог начать делать скриншоты, видео и даже выложить демо версию хорошего качества всего после 4 месяцев работы. Я получил несколько полезных отзывов от игроков ещё до того, как большая часть контента была готова, поэтому было проще вносить изменения, ничего при этом не ломая.
В этот раз я практически ничего не менял в ядре своего движка, и большая часть времени ушла непосредственно на создание игрового контента. Я буду продолжать использовать свой движок в будущих проектах.
Эту статью я написал в 2017 году. Речь идёт об игре Speebot, которая сейчас доступна в Steam. После публикации этой статьи, на данном движке было создано и выпущено ещё две игры — Phantom Path и Pilie Pals.
Оригинал статьи: https://kircode.com/ru/post/how-i-wrote-my-own-3d-game-engin...
Я разрабатывал эту игру с января 2016 года в своё свободное время в одиночку. Мною выполнено всё программирование, дизайн игрового процесса, создание графики и музыки. Кроме того, я написал собственный игровой движок с нуля.
Люди часто спрашивают меня, почему я решил создать свой движок, когда на рынке доступно множество бесплатных универсальных движков. Есть много причин, и о них я попытаюсь рассказать в этой статье.
Одним из самых больших преимуществ собственного движка является абсолютный контроль кода. Есть возможность настроить его именно так, как это нужно для конкретной задачи. Такой узкоспециализированный движок получается оптимизированным для конкретного типа игр и работает быстрее и надёжнее, чем универсальный движок.
Универсальные игровые движки называются так, потому что они предназначены для общего использования, и в них заложены функции, которые не всем нужны. Это неизбежно приводит к "раздуванию" кода, и к замедлению производительности игр.
Второе преимущество — это контроль самого процесса разработки. Я считаю, что инструментарий должен быть по-максимуму удобным для разработчика. Что является удобным — зависит от самого типа данной игры. Например, для Speebot — это встроенный редактор уровней, который позволяет быстро создавать новые уровни и незамедлительно их тестировать.
Решение использовать собственный движок позволяет мне интегрировать мои собственные инструменты таким образом, чтобы мне было проще и быстрее создавать контент.
Ещё один большой плюс: не нужно соглашаться с условиями лицензии стороннего движка, подписывать договора и платить проценты от прибыли.
Ну и наконец: написание собственного движка — это очень интересно.
Разработка движка началась в январе 2016 года. Я назвал его YUME ("мечта" по-японски). Он написан на Haxe, C++ и OpenGL. Я использую модифицированную версию библиотеки Lime, которая включает в себя несколько полезных функций, например, позволяет загружать ресурсы и открывает доступ к OpenGL.
Вот так движок выглядел после первой недели разработки.
До начала создания движка я почти ничего не знал о разработке 3D игр. Нужно было разбираться в OpenGL читая документацию, форумы и уроки, предназначенные для других языков (Java и C++). Через пару месяцев у меня получился довольно стабильный 3D-визуялизатор.
Кроме самого 3D-визуализатора, нужно было с нуля создать множество разных систем: 2D-визуализатор, машину состояний, систему временных шагов (об этом позже), систему интерфейсов, систему управления мышью, клавиатурой и джойстиками, динамические тени, 3D звуковую систему (используя OpenAL), загрузку моделей (в собственном формате, основанном на IQM), "скелетные" анимации, иерархию объектов, эффект зеркального отражения в реальном времени, отображения текста и так далее.
В конце концов, получилась 3D библиотека, которую можно использовать для чего-то конкретного. Многое из того, что я перечислил, присутствует и в других движках, но в YUME есть несколько отличий. Одно из них — система временных шагов.
Система временных шагов гарантирует, что движок обрабатывает и показывает кадры игры с определённым интервалом. В YUME нет ограничения по количеству кадров в секунду, т.е. нет привязанности к 30 или 60 кадрам в секунду. Частота кадров может быть любая, а игра всё равно будет работать с одной и той же скоростью, потому что частота обновления логики не связана с частотой обновления экрана. На компьютерах разных мощностей может быть разная производительность, и время для показа одного кадра может быть любым. А логика всегда привязана к частоте 62.5 циклов в секунду (16 миллисекунд на каждый цикл). В этом основной принцип системы временных шагов, хотя есть некоторые крайние случаи.
В результате: на более слабых компьютерах уменьшается частота кадров в секунду, но на игровой процесс это не влияет.
Ранняя версия YUME.
У меня была готовая библиотека, но пока ещё не движок. Пришла пора начать разрабатывать игру, и принимать решения о нужных функциях. К тому времени у меня уже было несколько идей, и я знал, что хотел попробовать поэкспериментировать с 3D "плитками".
Я начал создавать систему игровых уровней, которая использовала что-то похожее на 2D плитки (tilemaps), но с одним дополнительным измерением. Получается, что уровень можно сложить из "кубиков", как конструктор. Я создал редактор карт, чтобы ускорить процесс создания уровней. В итоге этот редактор попал в финальную версию игры и доступен каждому игроку.
Движок автоматически определяет, какую 3D модель использовать для отображения каждой плитки, в зависимости от соседних плиток. Придумал способ, как объединить все плитки в одну общую 3D модель, чтобы видеокарте не нужно было рисовать каждую плитку индивидуально. Вся карта рисуется за один раз, что очень сильно улучшает производительность.
Уровни можно редактировать и тестировать сразу. Для продуктивности — то что нужно.
Я написал простую систему игровой физики и начал экспериментировать с игровым процессом. Через несколько недель был готов первый прототип игры, в котором игрок мог перемещать цилиндр по 3D уровню.
YUME продолжал развиваться параллельно с разработкой Speebot (примерно в это время я выбрал такое название для игры). Было найдено и устранено несколько проблем с архитектурой движка, добавилось несколько новых функций: физика, частицы, отражения на поверхности воды, инструменты для анимации камеры, интерактивные объекты... Постепенно библиотека эволюционировала в игровой движок.
Я продолжал добавлять новые элементы игрового процесса, оставляя элементы, которые казались мне интересными, и избавляясь от лишнего. После некоторых экспериментов с художественным направлением графики игры я создал персонажа в Blender — маленького робота с одним колесом. Персонаж нарисован и анимирован в мультяшном стиле.
В это время я уже работал в основном над самой игрой, а не над движком. Я продолжал создавать новые уровни, декорации, персонажи и элементы игры.
В конце 2016 года я сделал паузу от разработки игры, и посвятил несколько месяцев изучению и практике написания музыки. У меня нет музыкального образования, но это — моё хобби. У меня уже был небольшой опыт в композиции музыки для моей предыдущей игры Hypnorain, но я хотел улучшить свои навыки, поэтому снова погрузился в изучение музыкальной теории. Для композиции музыки я использовал программу SunVox, которая является виртуальным модульным синтезатором. В финальной версии игры Speebot всего 23 трека, которые вместе составляют более часа оригинальной музыки. Я удовлетворён результатом, и продолжу улучшать свои навыки для следующей игры.
После этого я концентрировался на создании новых уровней, добавлении новых игровых элементов, написании музыки и устранении ошибок. Такой подход к разработке игр мне по душе. Если мне становится скучно заниматься одним и тем же делом, я переключаюсь на другой вид деятельности, и поэтому не теряю интереса к разработке игры.
После выпуска нескольких демо версий, обработки отзывов от игроков и улучшения игры, Speebot был выпущен в октябре 2017 года. В финальной версии игры 200 уровней, 4 мира, редактор пользовательских уровней, несколько дополнительных режимов игры, и много другого дополнительного контента.
Самое сложное при разработке игры было сохранять мотивацию и интерес на протяжении всех 20 месяцев. Работать над игрой мне удавалось только по вечерам после университета и работы, и по выходным дням. Но всё равно, это было очень интересно.
Всем привет! Это девлог игры The Last World. Игра разрабатывается одним человеком. Во второй части рассказываю про технические моменты и немного механики. Критика, предложения, советы и вопросы по теме приветствуются.
Картинку выше в разрешении 4К можно найти в VK или Discord.
Заранее прошу прощения за длинный пост, я старался максимально минимизировать его, давая больше визуального сопровождения.
ССЫЛКИ
Прежде чем продолжить читать длиннопост, подпишись в сообщество, плиииииз. А также не забудь добавить игру в Желаемое!
О ЧЁМ СТАТЬЯ
В прошлой статье я рассказал немного про игру The Last World и вскользь затронул её механики. Кто не знаком с ней, прошу ознакомиться, это займет 5 минут. В этой статье пойдет речь о механиках и некоторых других аспектах игры.
Статью разделил на несколько разделов:
* визуальная составляющая – цвет, стилистика, UI;
* конструкторы – моддинг юнитов и инструментов, модули;
* генераторы – world, terrain, props, resources, grass;
* торговая площадка;
* игровые инструменты;
* древо технологий;
* строительство;
* инвентарь – юнит, постройка.
* немного от себя
ВИЗУАЛЬНАЯ СОСТАВЛЯЮЩАЯ
Стилистика игры The Last World – это грань между реализмом и научной фантастикой. На реалистичность не хватит сил и времени, а делать лоупольный мультик нет желания, поэтому взор пал на что-то среднее.
С цветами всё намного сложней, первые года 3 проект был покрыт дымовой завесой. Серые тона были во всем от UI до 3D моделей. В то время я ещё не знал, как правильно работать с цветами, как их подбирать и как они сочетаются между собой. После прочтения книги (Иоханнес Иттен: "Искусство цвета"), которую мне посоветовал друг, я начал смотреть на свой проект иначе. В итоге определил 3 основных цвета и 2 вспомогательных. К примеру, для UI я выбирал из холодных оттенков. В целом результатом доволен, внешне стало намного приятней.
Чем проще UI, тем лучше, главное не перестараться. Особенно это касается интерфейса, с которым взаимодействует игрок и очень часто. Всегда присутствует желание запихать всё в одну строчку, поэтому необходимо тщательно отсеивать информацию.
Касательно построек – каждая из них имеет с десяток параметров и выводить их всех нет смысла, в итоге, вывел на панельку общие параметры и немного уникальных для каждой из построек. Лучше всего читается картинка + текст, нежели текст + текст, а еще будет лучше, если добавить поверх этого всего функцию "tooltip - подсказка”.
Главное меню также выполнено в скромном стиле – есть кнопки, юзабельный задний фон и много свободного пространства, на котором можно разместить разного характера информацию, например – новости или ближайшие анонсы.
Большинство игровых панелей и окон можно перемещать по экранному пространству (если присутствует красная полоска в самом верху панели\окна).
Любая панелька в игре минималистична, она содержит максимум необходимой информации. При необходимости цвета всех панелей можно поменять через код, в котором определены основные цвета, с помощью цветового кода.
Прибегнул к такой хитрости т.к. вручную менять цвет каждой панельки проблематично, достаточно лишь раз сменить его и программа сама всё обновит.
Главное UI, где расположены мини-карта, кнопки строительства, технологий и т.п., всё довольно просто и понятно. Расположение было выстроено ровно так, чтобы игрок не терялся и не чувствовал себя скованным. Другие подобные игры и их опыт очень сильно помогли в этом. Большинство этих панелей можно скрыть, тогда будет ещё больше пространства для обзора.
КОНСТРУКТОРЫ
Как писал в первой статье – все уникальные юниты являются модульными, поэтому нужен инструмент, чтобы можно было их редактировать. Система моддинга персонажей (или Конструктор) является одной из основных механик The Last World. Конструктор позволяет собрать персонажа из десятков (а может и больше) механических частей. Полноценный (далее основной) конструктор доступен из главного меню игры. В нём можно создать новый пресет по заготовленному бланку, загрузить сохраненный или дефолтный пресет, а также сгенерировать рандомный, чтобы позже можно было его выбрать при старте новой игры.
Работа с конструктором проста – есть модель и есть иконки (слоты), которые прикреплены к модели. Нажав на иконку появляется список со всеми доступными модулями для него. Игроку нужно лишь выбрать его, кликнув на иконку, и после модуль прикрепится на основную модель.
Я планирую сделать, чтобы все модули имели параметр доступности – если игрок исследует модуль в игровой сессии, то этот модуль будет считаться открытым и доступным в основном конструкторе, пока игрок не обнулит свою статистику.
Во время игры у игрока будет возможность воспользоваться конструктором из инвентаря персонажа, но на этот раз он будет ограничен в функционале. Для доступа к конструктору необходима постройка - Мастерская. В режиме моддинга будут динамически меняться характеристики персонажа, в зависимости от модулей, которые установлены на нём.
Если окно конструктора не доступно, то редактировать юнита можно через инвентарь, там присутствуют все необходимые слоты, которые дублируются в конструкторе. Однако некоторые слоты будут заблокированы и редактировать их можно только в конструкторе, на что будет указывать специальный индикатор.
Что касается инструментов юнита то тут примерно всё то же самое, за исключением того, что редактировать их можно только в игре и для доступа к конструктору не нужна будет Мастерская.
Есть несколько способов редактирования инструмента – первое это окно моддинга, второе перетащить и прикрепить, и третье - открыть окно обзора предмета и удалить интересующий вас модуль, который был установлен на него. После того как модуль будет прикреплен или удалён иконка инструмента обновится – сделает рендер картинки иконки предмета, внутри проекта это называется "динамическая иконка".
Специфические или редкие модули для юнитов нужно будет искать или покупать на торговой площадке, только тогда они "глобально" откроются для игрока, и он сможет использовать их в конструкторе. Некоторые модули можно будет изготовить в Мастерской.
Во время работы с конструктором в игре он будет пытаться найти все подходящие модули к этому слоту в инвентаре персонажа (конструктор не будет учитывать модули, которые находятся внутри предметов-контейнеров). Также для модулей персонажа доступна функция быстрого экипирования\разыкипирования через контекстное меню, для модулей инструментов такое сделать нельзя.
При перетаскивании модуля инструмента, иконки инструментов в инвентаре персонажа будут подсвечиваться, указывая на то, что они совместимы. Для модулей персонажа доступна схожая функция, но на этот раз будут подсвечиваться совместимые слоты. Помимо этих индикаторов есть и другие, к примеру, если на инструменте нет критических модулей (без которых он не может работать) то иконка будет подсвечена красным цветом. Такой инструмент будет невозможно взять в "руки" персонажа.
ГЕНЕРАТОРЫ
Кропотливо расставлять деревья по локации или набивать сундуками какие-нибудь катакомбы это не про The Last World. Я старался всё перевести в машинный код, тем самым облегчив себе работу на будущее. И уменьшить размер сборки на выходе (сейчас вся сборка весит примерно 7Гб, чем дальше - тем больше).
Уникальность всего этого замысла в том, что при одном и том же seed, на любом компьютере, должна генерироваться точно такая же планета и, если игрок выберет одну и ту же локацию, то дерево будет стоять на том же месте.
Итак, первая генерация, с которой сталкивается игрок - это планета. Планета представляет собой гексагональную тайловую сферу. Выбрал именно такую реализацию исполнения планеты, мне нужны были тайлы без лишних деталей (аналогом является игра RimWorld). Количество тайлов на самой большой планете может достигать 1млн.
После генерации сферы генерируются биомы. На просторах интерната есть очень хорошая статья по генерации биомов. В дальнейшем буду работать над погодными условиями с использованием уже полученных карт высоты, влажности и тепла.
Спустившись на поверхность планеты, мы спотыкаемся об ещё несколько алгоритмов генерации. Первая - это сама генерация поверхности, тут хочу поблагодарить Sebastian Lague, ютюбера, за то, что направил на путь истинный и подал несколько хороших идей по генерации поверхностей.
Изначально планировалось сделать бесконечную локацию, но в последствие столкнулся с проблемой переполнения памяти из-за большого количества хранимых данных и проседанием производительности, из-за частой генерации новых чанков. В результате эта идея перекочевала в отдельные локации с фиксированными размерами.
Поверхность делится на чанки, в зависимости от размера локации, варьируется и размер чанка. Чем больше локация, тем меньше чанк (это связано с оптимизацией. На больших чанках размещается огромное количество пропов и компьютеру сложно их постоянно скрывать и показывать, когда камера удаляется на расстояние). Для пропов я использую LODs, а также использую автоматическое скрытие вместе с чанком, когда камера удаляется на расстояние.
На каждый чанк прикреплены пропы сцены, которые тоже генерируются рандомно. К слову о генерации пропов, есть много методов генерации – это и Perlin Noise и Simple Noise и тд и тп, по мне, лучшим вариантом стал Poisone Disk, т.к. он может заполнить область действительно рандомно и без видимых повторяющихся паттернов, главное не ставить слишком маленький шаг итерации, иначе будет бесконечность. Пропы привязаны к высоте слоя локации, чем выше слой, тем плотней генерация пропов.
Позже генерируются горы, ну или то, что игра называет горами. Они генерируется островками с использованием Perlin Noise.
За горами идет генерация точек ресурсов по всей локации, их два вида – наземные и подземные. Если подземные можно сгенерировать в любом месте на карте и не делать практически никаких проверок, то с наземными немного другая история, для них нужно учитывать много факторов – вода рядом или нет, рядом есть залежи или нет и многое другое, на что нужно обратить внимание.
После генерируется плоскость для воды, ничего особенного, однако тоже генерация сетки.
Самым последним генерируется трава, занимает больше всего времени. Трава генерируется на каждом чанке отдельно для оптимизации, хотя я подумываю объединить их и отправить на параллельный поток, пока идет загрузка и игрок не видит локации. Для генерации травы использовал два сгенерированных массива шума – один для высоты травинки, другой для паттерна. Трава генерируется с использованием Perlin Noise, а затем применяется шум для небольшого разброса по поверхности.
ЕЩЁ НЕ КОНЕЦ!
Т.к. сайт не позволяет загружать больше графического материала, то вынужден разделить статью на 2 части. Продолжение второй части опубликую чуть позже, чтобы не засорять эфир.
Осталось осветить:
* Торговая площадка;
* Игровые сетевые инструменты;
* Технологическое древо;
* Строительство;
* Свет;
* Инвентарь;
* Немного дополнительного материала.
Критика, предложения, советы и вопросы по теме приветствуются.
Спасибо за инвестированное время! Присоединяйтесь в сообщество и следите за ходом разработки, буду вам рад!
ССЫЛКИ
Не забывайте подписываться в сообщество и следить за новостями. А также не забудь добавить игру в Желаемое!
Новости двухнедельной давности, но лучше позже чем никогда. На Пикабу такого не попадалось мне. А если уже - было рыцари свежего спасут пикабу от дублирования своими минусомётами, я не против) К делу:
Есть эдакая игра про космос, от людей (а не компаний, это отдельная история) которые делали замечательные игры. GoF 2 например. Кто следит за игрой - знает что игру делают довольно давно. Игра нынче в раннем доступе, и к финальной версии планировался в ней и Русский язык. И вот недавно, разработчики решили заявить, что Русский язык отменяется. (Есть у нас нынче мода на запрет всего Русского, ибо Русский язык - не язык, це собачий гавк и всё такое. Ну вы и так в курсе, пост не об этом.)
Естественно, RU сообществу это не понравилось, и игру начали закидывать говнегативными отзывами в стим. А потому что какого хрена? Разработчики обещают русскую локализацию, много времени работают (А игры делать они умеют), продают игру с обещанием позже перевести на русский язык, и внезапно шлют РУ сегмент лесом. И ведь большинство таких отзывов от игроков с временем от нуля до нескольких часов игры. А игру больше года делают (с 18 января 2021). Т.е. её покупали дабы поддержать разработку.
К слову, недели не прошло, как подобных отзывов накопилось достаточное количество, чтобы заметно пошатнуть рейтинг игры который был ранее довольно высок, и разработчики передумали. К отзывам которые как пример указаны в новости по ссылке ниже, уже есть комментарии разработчиков. А именно:
"Русская локализация НЕ отменена, как мы говорили в предыдущих объявлениях. Русская локализация по-прежнему планируется и будет реализована в полном релизе или раньше."
Очень жаль, что такие талантливые разработчики могут качнуть свою лодку в след за политикой. Если кто играл в GoF 2 и не слышал про нынешнюю игру - это будет геймплей старой доброй игры в новой и современной обёртке. С блекджеком и дамами.
https://ixbt.games/news/2022/04/04/razrabotciki-everspace-2-otmenili-russkii-yazyk-igru-pokupayut-ctoby-ostavit-negativnyi-otzyv-v-stea.html
Привет! Я являюсь членом gamedev студии Exbyte и сегодня хотел бы поведать вам о нашей еще не вышедшей игре Abyss Protection, в частности что это такое и с чем едят tower defence, приправленный глубоким лором, ярким мультяшным стилем и почти бесконечным количеством разнообразных уровней, но прежде о нас!
Exbyte Studios зародилась в самой пучине пандемии, а именно осенью 2020 года, когда коронавирус решил, что отправится на учёбу вместо студентов университетов и институтов после закончившихся летних каникул. Историю появления студии можно поистине соотнести с библейской, у нас также было первое слово, но слово это было: “Пень”. Да да, короткий неказистый, возможно немного трухлявый пень, который в один из пасмурных вечеров моделировал один из наших будущих 3д дизайнеров. Что-то в этом пне было настолько глубокое, настолько проницательное и завораживающее, что заставило оставшуюся команду, на тот моменту еще являющуюся горсткой однокурсников, покумекать и единогласно решить – “Студии быть!”.
Начавшаяся с пня череда удачных случайностей, продолжилась, возможно даже многократно усилившись. Ведь какой шанс, что в этой самой горстке однокурсников найдётся и талантливый управитель, который готов взять бремя game дизайнера, а затем повести всех за собой, и начинающие кодеры, которые схватывали всё налету, к тому же, что еще более удивительно выбравшие один и тот же язык программирования в качестве хобби, и много-много кто еще. Все эти люди словно шестерни встали на свои места в огромном механизме и в его жерле пошла работа над созданием множества прототипов.
Но хорошо всё бывает только в сказках… Тогда еще только новорожденная студия пошла по пути многих подобных и чуть не утонула под толщей собственных амбиций. Первый проект было решено не учить ползать, а сразу отправить в полёт. Он представлял из себя огромного размера сетевую игру жанра ММО, данжи, разнообразные по виду и сложности механики, сюжет, который показал бы всем sci fi проектам, где зимуют жнецы и ситхи, карта с кучей биомов и городов – всё это должны были сделать 8 человек, которые несколько дней назад примерили на себя роль сотрудников небольшой инди студии. Тогда вопреки количеству работ общий уровень воодушевления возобладал над общим уровнем здравомыслия, и процесс начался. Начался бодро, каждый прогрессировал на глазах, но от этого общее поле задач также становилось ясным и четким, уходил туман новичков, который скрывал холмы, нет, горы требующего внимания, а между тем бюджет нашей студии (как и сейчас) составлял чистый энтузиазм в количестве одна штука, бутерброд с колбасой в количестве одна штука. Дабы сотрудники не умерли от голода/обезумели/разбежались было принято решение сосредоточиться на небольших проектах, что позволило ещё больше отточить навыки на совершенно разных стилях, механиках и в последующим довести одно из таких поделий до сносного состояния. Да, как вы уже догадались этим проектом стал Abyss Protection.
Первоначально никто и не мог представить, что из всей кипы прототипов (А их и правда не мало) появится на свет именно этот. Ведь будем честны towerdefence далеко не самый популярный жанр с, в целом, уже устоявшейся формулой. На рынке по сей день можно встретить крайне мало проектов, которые бы решили бросить вызов золотому стандарту жанра и потеснить трёх его монументальных слонов своими жирафами. Но, прежде чем говорить о жирафах стоит немного да задеть тех самых слонов. И первый это тактика. В течение 100% времени игрового процесса вы должны быть максимально сосредоточены: на карте, пребывающих и пребывающих силах противника, ваших ресурсах и юнитах. Все эти данные нужно держать в голове и вместе с этим умело жонглировать ими как первоклассный фокусник. Какие типы врагов стоит уничтожить как можно быстрее, какие волны пока стоит “не замечать” чтобы расправиться с наиболее опасными, какие юниты наиболее эффективны в данной ситуации – все эти постоянные вопросы создают напряжение, а вместе с ним соответствующий интерес. Ведь, согласитесь, когда последняя дружеская стрела поставила точку в этой истории, когда упал последний негодяй чувство эйфории и своего гения тактики мгновенно повышает уровень эндорфина. Жить становится лучше, жить становится веселее.
Второй слон — это причина необходимости тактики и каких-либо действий в мире tower defence в целом – ваш дом, ваша крепость. Зачем предпринимать какие-либо действия для защиты от супостатов, когда за вашей спиной нет…Ничего, ни крепости, в которой ваш герой совсем недавно пил хмельное бок о бок со своими солдатами, ни города, в котором ждёт та самая. Поэтому, думаю, этого слона можно даже назвать игрообразующим, ведь без мотивации любое действо будет казаться бессмысленным. И, наконец, третий слон – прогрессия. На протяжении всей своей истории человечество развивается, преодолевая всё новые и новые трудности. Суровые климатические условия, огромные расстояния на Земле, в космосе, а в будущем возможно и во времени. Развитие одна из главных целей каждого человека и в играх всё работает абсолютно также. Улучшение юнитов, крепости позволяет уничтожать и выдерживать атаки всё более и более исполинских противников, которые на первых уровнях одним своим видом говорили…Нет, кричали о вашем полном поражении. Это определенно добавляет гормонов радости в их общую копилку.
Итак, все слоны измерены и описаны, теперь очередь жирафов. В самом начале я сказал, что мы собираемся именно что потеснить, а не низвергнуть трёх фундаментальных животных, потому что они работают, но работают неидеально. Сюжет и лор – одно из того, на что мы решили обратить внимание. В Abyss Protection роль “крепостей” и “городов” заняли феоды – части великого королевства, расколовшегося из-за ужасного катаклизма. Отныне феоды раскиданы по разным измерениям, и вы как единственный наследник престола должны отыскать каждый из них и выхватить из лап ужасных врагов. Каждый феод будет обладать уникальной историей, собственным путем развития и неповторимыми героями, что окажут помощь в вашем нелегком деле. Также своими действиями вы сами определите кем являются злостные захватчики и какие цели они скрывают. Индивидуальность игровому процессу будет придавать не только история, но и генерация. Каждое измерение, появление врагов и феод будут процедурно создаваться на новом уровне, в купе с количеством эффектов, разнообразием ассетов, врагов и апгрейдов, которое со временем будет только расти – повторяющиеся ситуации становятся абсолютным исключением.
Все эти нововведения благополучно повлияют на итоговый игровой процесс, сделав его насыщеннее и живее, а убедиться в этом вы сможете совсем скоро, а именно – 2 мая, в день выхода игры. Подписывайтесь, чтобы следить за новыми новостями и событиями. Спасибо!
Справились? Тогда попробуйте пройти нашу новую игру на внимательность. Приз — награда в профиль на Пикабу: https://pikabu.ru/link/-oD8sjtmAi
Пристальный взгляд на первые 15 часов геймплея
Archolos — официально одобренная модификация Готики, которую несколько лет делали рукастые польские парни на государственные деньги. Мод является самостоятельной игрой, основанной на старом движке Готики 2 из начала нулевых. На данный момент имеет более 8500 положительных отзывов в Steam.
Попробуйте прочитать это слово с первого раза (overwhelmingly positive — подавляюще позитивные )
Игра самостоятельна, погружена во вселенную Готики и абсолютно бесплатна. Делаю обзор в очень спорной манере: сейчас я примерно на первой трети (15 часов). Почему так? — Именно здесь большинство игр во вселенной Готики раскрываются на полную и не успевают превращаться в гринду. Возможно, подход спорный, но хочется поделиться эмоциями именно сейчас. При полном прохождении появится вторая часть обзора — если такой контент будет кому-нибудь нужен на Пикабу.
Немного истории
Мод существует в инфополе готоманов достаточно долгое время. Следил за ним на Youtube с самого зарождения канала. Та монументальность и достаточно профессиональный подход к съёмке рекламного контента к производству мода долгие годы наводили на мысль, что всё происходящее в блоге обманка шарашкиной конторы, которая пилит государственные инвестиции и делает красивые презентационные ролики с полей разработки. Профессиональная аудиозапись озвучки всех NPC настоящими актёрами, огромный мир, расширение крафта, продолжительный сюжет наводили на мысль о том, что это поделие существует и работает по модели моде Skywind (перенос Morrowind на движок Skyrim).
Skywind делается только ради красивых презентаций и для наполнения портфолио работающих над модом. Своеобразная кузница моделлеров и художников. Учитывая то, что скайвинд не выйдет никогда, я скептически смотрел на тот же самый Archolos, нервно ожидая забвения. Тем более, странное решение использовать движок 18-летней давности ещё больше наталкивал на подобные мысли.
не я один так думаю (коммент с сайта DTF)
Я был неправ. Мод вышел и получил все возможные пользовательские похвальбы. Представляете, что можно ожидать от кучи профессионалов, которые взяли до дыр заученный движок и решили напихать в него чего душе угодно на современных машинах и с достаточно современным подходом к созданию контента в играх? — Получилась стилизованное под ретро-графику инди, до упора напиханное контентом.
Персонажи и квесты
Одна первая деревушка обладает большим количеством квестов и персонажей, чем целый Старый лагерь из первой Готики. В первом же поселении декоративных и безымянных NPC по типу „Фермер“ и „Стражник“ просто минимальное количество. Их примерно 20 % от именных персонажей, которые обладают уникальными репликами и задействованы в квестах. Практически каждый торговец или учитель имеет ветку квестов и обладает набором рецептов для готовки или крафта. Игра (перестаю называть её модом из уважения) сделана даже насыщенней, чем Elex от создателей Готики. Перейдём от количества к качеству.
Готовка: шашлык всему голова
Реплики написаны без графоманства, наполнены шутками, очень конкретны и понятны в момент дачи задания. К счастью, в отличие от оригинальных игр, каждое действие снабжается более подробным пояснением в дневнике. Ситуаций по типу: „а что мне сейчас делать“ — практически не возникает. Читать очень приятно, но у меня для вас очень плохие новости. Если вы совсем не знаете польского… Шучу, если вы не знаете хотя бы английского на пред-среднем уровне, то вам здесь делать нечего. Мод изначально делался и полностью озвучивался на польском. Какой-то перевод на русский найти возможно, но я не вникал в его качество.
Древность движка
Ощущается древне
Ощущается древне, зато есть рыбалка
Геймплей
Мало чем отличается от второй готики в плане боёвки, но я играл с управлением из Готики 1. Уж очень мне нравится эти архаичные действия через ЛКМ для фиксации цели и клавиши WASD чтобы направлять удары и ставить блоки. Ощущается не новее движка, но если вы будете воспринимать Archolos как инди игру с оговорочками — то даже от такого действа можно получить некоторое извращённое, но всё же удовольствие. Не забывайте сохраняться на почти каждом действии в игре и будет не так больно.
Не смотря на древность движка, паркурить можно прекрасно. Кое-где игра мир становиться чуть ли не вертикальным на манер Dark Souls I
Насыщенность событий поражает. Практически всегда есть чем заняться. Игровой цикл сбалансирован на удивление хорошо. Мы можем поболтать с NPC, исследовать местность, пособирать лут, подраться с монстрами и всегда в этом цикле получить продвижение по основному сюжету и по сторонним квестам, обязательно немного подкачавшись после каждой сессии. Проект одаривает опытом куда щедрее, чем оригинальные Готики.
Оцените наполнение куцого интерьера, в этом весь мод во всех остальных аспектах: небольшой по размеру, но очень щедрый на мелочи.
Ни один из элементов игрового цикла не провисает за весь мой игровой опыт в 15 часов. Если где-то дальше игра провалиться в динамике, то я обязательно отмечу это в следующем, окончательном обзоре. Именно поэтому статья написана примерно на трети игрового опыта: на данном отрезке времени Архолос стоит того, чтобы оказаться в вашей игровой библиотеке. 15 часов — достаточно жирное время для разнообразного геймплея у современного Action RPG, который не сваливается в самоповторы и гринду. А вы что выберете: 100 часов воды или 15 часов гущи?
Графика
Повторюсь, если вы будете воспринимать Archolos как инди игру с оговорочками — то даже от такой графики можно получить некоторое извращённое, но всё же удовольствие. Главное, привыкнуть.
Атмосферно, но очень на любителя
Звук и музыка
Мне очень тяжело играть со включенной польской озвучкой и при этом сосредоточиться на английском тексте. Это проблема скорее не звука и музыки, а восприятия информации конкретно у меня. Если вы можете проходить стресс-собеседования с давлением от нескольких интервьюеров, то вам будет не сложно сосредоточиться на получении информации здесь.
Я отключил все голоса, над которыми трудилось множество талантливых польских актёров, поэтому для меня Архолос стал похож на просмотр фильма „CODA: Ребёнок глухих родителей“ — мод был немым.
Конкретно мои ощущения от игры, как от просмотра данного кино
Музыка состоит из множества специальных треков от мододелов и адаптированных оригинальных композиций из 1-3 частей. Ничего фантастического нет, но музыка выполняет свою задачу. Об остальных звуках сказать нечего, так как они напрямую взяты из Готики 2.
Баги
За 15 часов — один вылет на диалоге.
Вывод за 15 часов
Геймплей: отлично
Графика: на любителя
Звук: немой
Музыка: приемлемо
Интерфейс и управление: древние
Вердикт
Качайте, играйте, пробуйте. Подойдёт всем готоманам, любителям суровых РПГ и особым ценителям архаичных геймплейных извращений.