Статьи // dev

Разработка игры: с чего начать и потенциальные ошибки

Сергей Грачев
опубликовано: ⏰ 11
article image

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

Info

Выложил исходники счётчика и игры с главной страницы в GitHub – Проект. Там ничего особенного, но может кому-то пригодится.

Ведение

Зачем и почему? Есть несколько причин. Кому-то это интересно именно как направление разработки и профессионального развития. Хотя не все понимают, что это может быть не такое уж и весёлое занятие, как может показаться – бывает ложное представление о том, что это только развлечение. Отчасти верно, есть элемент развлечения, но ещё это бесконечный код и достаточно сложный. Те, кто до этого занимался сайтами и энтерпрайзом с табличками и формами, могут быть неприятно удивлены сложностью входа, если речь идёт о средних и крупных проектах. Тут же присутствуют и переработки, производственный ад и прочие прелести.

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

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

Диздок

Game Design Document (GDD) – это документ, описывающий основные аспекты игры, включая механику, сюжет, визуальный стиль и другие важные элементы.

Если это не какой-то быстрый проект just for fun, то стоит начать с GDD. Первая ошибка – этого не сделать, позднее всё равно придётся его писать, чтобы структурировать идеи и общее представление об игре. Он очень помогает получить общее понимание об концепции, при чём сквозное от начала до конца.

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

  • Чёткое понимание концепции игры: идея, фабула, механики, системы.
  • Сквозная сюжетная линия, которая помогает в дальнейшем выстроить плавную прогрессию и не потеряться в своих идеях.
  • Персонажи, места, предметы и мир игры с артбуком, который можно использовать при разработке.
  • Описание игрового процесса, со всеми составляющими.
  • Список задач, которые нужно реализовать, и приоритеты для них.
  • VFX, SFX, UI/UX.
  • Целевая аудитория, платформы, монетизация (если планируется).
  • Планирование сроков и бюджета (если есть).

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

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

Выбор движка и инструментов

Выбор движка зависит от масштаба вашего проекта и доступного бюджета или времени на обучение. Например, нет особого смысла брать UE для разработки простого 2D-платформера, есть более простые и бесплатные движки. Сейчас из основных можно выделить:

  • Unreal Engine – мощный движок, но требует больших ресурсов (PC) и времени на обучение. На нём остановился в конечном счёте.
  • Unity – популярный движок, который подойдёт как для начинающих, так и для продвинутых разработчиков.
  • Godot – хороший движок с открытым исходным кодом.
  • Дополнительно:

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

В основном использовал UE4/UE5. Это точно не самый простой путь и движок не для новичков, но по возможностям больше всего понравился. Желания учить новый язык (Godot) или C# (Unity) не было, поэтому остановился на нём. Что понравилось:

  • Open Source – код открыт и можно вносить изменения в движок.
  • Разработка на C++ – когда-то писал на нём и не нужно было учить с нуля.
  • Мощная система UI (UMG) – это было важно и удобно для быстрого прототипирования и разработки UI.
  • Быстрое прототипирование логики – система Blueprint‘ов. Использовал редко, но иногда проще сделать на них, чем на C++.
  • Система материалов (Material Graph) – действительно мощный и удобный инструмент для текстурирования и шейдеров.
  • Система работы со звуком (MetaSounds, ранее Sound Cue) – фактически неплохая замена коммерческим wwise и fmod.
  • Epic Games есть маркетплейс с множеством готовых ресурсов и плагинов.
  • Плагинная система – можно нормально разбивать код на модули и использовать их в других проектах. Плюс подключать сторонние.
  • И многое что ещё не перечислил, сейчас не вспомню.

Готовые ресурсы

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

Сейчас сильно помогают нейросети, которые могут генерировать модели (3D), текстуры/спрайты (2D), анимации, звуки и т.д.

  • С 2D всё давно уже довольно хорошо и в большинстве случаев можно обойтись своими силами. Особенно полезно при генерации артбука для диздока или референсов.
  • В случае с 3D, всё ещё есть проблемы, но прогресс очень заметен в последнее время. Уже можно использовать сгенерированные модели в качестве задников без сильной доработки. Если интересен сам процесс, то можно посмотреть в сторону тех, кто занимается 3D-печатью. Там как раз есть варианты генерации сначала проекций через Nano Banana, а потом на их основе 3D-моделей.
  • Персонажей можно анимировать в том же Mixamo. Большую часть анимаций оттуда забирал.

Несколько примеров маркетплейсов, где можно найти готовые ресурсы для игр и движков:

Процесс разработки

Здесь ваш лучший друг, это GDD (Game Design Document) и декомпозиция задач из плана работ. При этом основная идея – двигаться от простого к сложному, и не пытаться реализовать сразу всё. Как пример, сначала делается blockout (заготовка). Это может быть уровень с простыми кубиками, на котором проверяются механики, прогрессия и так далее. То есть движение происходит сначала вширь, а потом уже по каждому элементу вглубь. Самое главное проверить саму идею игры и то, что она хорошо работает. Если есть проблемы, то сразу можно пересмотреть её и сделать правки, так как на следующих этапах будет всё сложнее. Так же важно понимать, что все элементы игры должны быть взаимосвязаны. То есть если вы делаете механику, то она должна быть связана с прогрессией, сюжетом, визуалом и так далее.

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

Ещё один важный момент, это удобство работы с движком. Если выбор неудачный, то на борьбу с ним можно потратить много времени без полезного результата. Например, много времени (дни) потратил на LibGDX пытаясь сделать разные вещи, аналог которых в UE занимал минуты или часы. Стоило ли оно того? Думаю, нет. При этом не стану врать и у UE хватает проблем, но они в основном связаны с тем, что движок относительно сложный и требует много времени на освоение. Это к слову о том, что жалуются на UE5 и его производительность. UE – это огромный комбайн с большим количеством функционала, который попросту избыточен и может быть отключен. Но не все могут и хотят заниматься подобной оптимизацией.

Так же нужно упомянуть инструменты для прототипирования. Про другие движки не скажу, но в UE есть такая вещь какBlueprints, которая позволяет создавать логику без написания кода. Это очень удобно если нужно быстро что-то проверить. Например, я их ещё использовал в качестве альтернативы скриптам – игра с элементами CCG и алгоритм применения карты описывался на Blueprint без кода. В них же скрывается и ловушка – они хороши для прототипирования и нетребовательной к производительности логики. Впоследствии их обязательно нужно переписывать на C++, что естественно не всегда делают, получая лаги при их выполнении.

Ну и сам процесс разработки всё-таки отличается от создания всяких сайтиков и формочек. Необходимо понимать, что все расчёты и логика взаимодействия должна укладываться, как минимум, в 16ms (60 FPS) на кадр. Это значит, что если вы делаете что-то сложное в tick (UE), то это будет проблемой. Придётся думать, как это оптимизировать, менять подходы в разработке. А UE, например, отрисовывает в одном потоке в общем случае (как в общем-то и большинство движков). Это на самом деле неплохо, позволяет по другому взглянуть на разработку и искать более оптимальные варианты решения различных задач и расширяя общий кругозор. Появляются новые понятия, вроде дизайна DOD (Data Oriented Design), архитектуры ECS(Entity Component System), различные алгоритмы (графы, пространственные структуры, BFS, A*, физика и т.д.). Со всем этим так или иначе придётся разбираться.

Публикация игры

После того как игра готова, её нужно опубликовать. Тут мало что могу сказать. Если живёте в стране не под санкциями, то вариантов достаточно, это магазины Steam, Epic, Google Play, App Store. Они все, как правило, берут комиссию от 10% до 30%. Всё зависит от того, какую платформу вы выбрали.

Если в стране под санкциями, то либо локальные площадки с небольшим охватом. Для инди, это скорее всего ничего не принесёт. Или становится киприотом :)

Заключение

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

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

Gamedev Essentials Devmix
GameDev 1 из 2
Создание трёхмерного тумана войны →