Per aspera ad astra или RoadMap по вашей будущей игре. Godot 4 C# Часть 2 "Выбор графики и диз.док".

Идея - получено! Подход - получено! Не иллюзорных от мамки - получено! Продолжим!

Возвращаясь к предыдущей части RoadMap, мы собирались определиться с своей позицией в команде разработки.

Итак, я выбрал «программист-геймдизайнер».

Идём дальше.

Я инди. Что я могу в соло?

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

3D-lowpoly

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

Создаётся относительно быстро и не бьёт по карману так же, как high poly модель.

Одним из важных плюсов является анимация. Из-за системы костей не нужно рисовать тонны спрайтов. Анимировать простые модели не так сложно. Так что вариант хороший.

Также вы можете проводить ретаргетинг анимации — это позволит размножить анимацию для разных персонажей ( НПС ).

Пиксель-арт и 2D-графика

Можно рисовать самому, это не сильно сложно, однако требует много монотонной работы. Так как здесь нет костей в отличие от 3D - все положения персонажа придётся рисовать вручную. Будет это удар или бег, или ещё что — придётся рисовать всё и помногу.

ВАЖНО: Если вы сами художник, это хороший вариант для проекта. Если вы нанимаете художника, вы сильно привяжетесь к стилистике. В случае ухода с проекта художника вы рискуете либо похоронить проект, либо влететь на деньги для найма профи. Только достаточно опытные художники способны подстроиться под стиль, и то не все.

Voxel графика

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

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

Думаю, будет полезно позже отдельно проработать каждый визуальный стиль, но пока остановимся на самом простом - 2D.

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

Дизайнерский документ ( диз.док )

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

Базово необходимо заложить основу в виде разделов, чтобы было удобно ориентироваться.

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

1. Общее описание

  • Жанр - Tower defense
  • Движок - Godot 4.4
  • Визуальный стиль - 3D lowpoly
  • Платформа - WIN, MacOS, Linux
  • Уникальное торговое предложение (USP): Что выделяет игру на рынке?

2. Геймплей

  • Основная механика: Как играется? Пример: «Прыжки по платформам + головоломки».
  • Управление: Клавиши/геймпад/тач.
  • Прогрессия: Как развивается сложность?
  • Система сохранений: Чекпоинты/автосохранения.

3. Персонажи

  • ГГ (протагонист): Способности, архетип (воин/маг и т.д.).
  • НПС: Роль в сюжете/игромеханике.
  • Враги: Типы, поведение, слабости.

4. Уровни

  • Структура: Линейные/открытые?
  • Пример уровня: Схема с врагами, платформами, секретами.
  • Дизайн-правила: Например: «Каждый уровень содержит 1 скрытый предмет».

5. Экономика и предметы

  • Валюты: Золото, очки, ресурсы.
  • Инвентарь: Как хранятся предметы?
  • Апгрейды: Улучшения персонажа/оружия.

6. Интерфейс (UI/UX)

  • HUD: Что отображается на экране?
  • Меню: Главное меню, пауза, настройки.
  • Подсказки: Обучение игрока.

7. Графика и звук

  • Стиль: Референсы (например, «как в Hollow Knight»).
  • Анимации: Персонажи, эффекты.
  • Саундтрек: Жанр музыки, звуковые эффекты.

8. Технические требования

  • Движок: Godot.
  • Платформы: Минимальные системные требования.
  • Сторонние инструменты: Tiled (для карт), Aseprite (для пиксель-арта).

9. План разработки

  • Этапы: Прототип → Альфа → Бета → Релиз.
  • Сроки: Ориентировочные даты.
  • Команда: Кто за что отвечает?

10. Риски и альтернативы

  • Слабые места: Что может пойти не так?
  • Запасные варианты: Упрощение механик при нехватке ресурсов.

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

Спасибо за внимание!

2