Глава 20 · Разработка игр с Pygame

Как устроена разработка игр

Прежде чем углубляться в Pygame — посмотрим, что такое разработка игр как ремесло: роли, масштаб и путь от идеи до релиза.

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

Роли в разработке игры

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

Кто делает игру
Гейм-дизайнер
Придумывает правила игры
Балансирует сложность
Пишет документ игрового дизайна
Программист
Реализует правила в коде
Пишет игровой цикл
Оптимизирует производительность
Художник / аниматор
Рисует спрайты и фон
Готовит анимацию персонажей
Задаёт визуальный стиль
Звукорежиссёр
Пишет музыку
Записывает звуковые эффекты
Сводит звук под события игры
Продюсер
Планирует сроки
Управляет командой
Следит за бюджетом
QA-тестировщик
Ищет баги
Проверяет баланс
Играет в игру сотни раз до релиза

Инди и AAA

Инди-игры обычно создают независимые разработчики или небольшие команды, часто без крупного издателя. «AAA» — условное обозначение крупных коммерческих проектов с большими командами, значительными бюджетами и длительным производственным циклом. Это не строгие категории с чёткой границей: реальные проекты сильно отличаются по масштабу, и немало команд находится где-то посередине.

ХарактеристикаИнди-проектКрупный AAA-проект
КомандаОт одного разработчика до небольшой или средней командыОбычно крупная команда специалистов разных направлений
Срок разработкиОт нескольких месяцев до нескольких летОбычно несколько лет
Принятие решенийРешения часто принимаются быстрее и меньшим числом людейИзменения могут требовать согласования между несколькими командами
ИнструментыГотовые движки, библиотеки и доступные инструменты разработкиГотовые или собственные технологии и внутренние инструменты
Сильная сторонаГибкость и свобода экспериментаМасштаб производства и большие ресурсы
Pygame для первых инди-прототипов
Учебные проекты этой главы написаны в том же духе, что и многие инди-игры: маленькая команда (в вашем случае — один человек), общедоступный инструмент, быстрые эксперименты. Разница между учебным проектом и реальным инди-релизом обычно не в инструменте, а в том, сколько итераций отделяет прототип от готовой игры.

Путь от идеи до релиза

Ни одна игра не появляется сразу готовой. У процесса есть распространённые стадии — в конкретном проекте их названия и границы могут отличаться, но общая логика похожа и у AAA-студии, и у одного человека с ноутбуком:

Концепт
идея, ключевая механика
на бумаге или в голове
Пре-продакшн
план, оценка объёма работы
выбор инструментов и технологий
если механика не работает — переделать концепт
Прототип
проверяет саму механику
минимум кода, часто одноразового
показывает, каким будет качество релиза
Vertical slice
небольшой готовый кусок игры
близко к качеству финального релиза
Продакшн
основной объём кода и контента
уровни, персонажи, звук
Альфа
в конкретном проекте критерии могут отличаться
обычно: основной функционал уже есть, тестирование внутри команды
Бета
обычно: контент почти не меняется
тестирование снаружи, охота за багами
Релиз
игра выходит к игрокам
жизнь игры продолжается после релиза
Пострелизная поддержка
патчи, баланс, новый контент
Мяч, отскакивающий от стен, — это уже рабочий прототип: минимальная механика, которую можно попробовать. Это один из распространённых вариантов пути от идеи до релиза — не единственно верная схема.
Прототип и vertical slice — разные задачи
Прототип отвечает на вопрос «работает ли сама идея» — код в нём почти всегда одноразовый, а качество картинки и текста не имеет значения. Vertical slice отвечает на другой вопрос: «как будет выглядеть и ощущаться готовая игра» — это уже небольшой, но полноценный кусок, близкий к целевому качеству, и он часто заодно проверяет производственный конвейер проекта. На практике команда может выстроить техническую архитектуру (раздел 20.26) раньше, ещё на этапе прототипа, а задачи прототипа и vertical slice — пересекаться: разные проекты организуют эти стадии по-своему.