Прежде чем углубляться в Pygame — посмотрим, что такое разработка игр как ремесло: роли, масштаб и путь от идеи до релиза.
Мяч из прошлого раздела уже прыгает — самое время отступить на шаг назад и посмотреть,
в какой мир мы только что вошли. Разработка игр (гейм-девелопмент, геймдев) — это не один
навык, а ремесло на стыке программирования, дизайна и искусства. Небольшую игру вполне может
создать один человек — вы только что это сделали. По мере роста проекта обычно растёт и
число специализированных ролей, а крупные коммерческие игры создают большие команды.
Роли в разработке игры
В крупной студии за каждую из этих ролей отвечает отдельный человек или целая команда;
в инди-проекте один и тот же человек часто совмещает три-четыре роли сразу — и вы, работая
над мини-проектами этой главы, уже побывали в роли программиста, дизайнера и тестировщика
одновременно.
Кто делает игру
Гейм-дизайнер
Придумывает правила игры
Балансирует сложность
Пишет документ игрового дизайна
Программист
Реализует правила в коде
Пишет игровой цикл
Оптимизирует производительность
Художник / аниматор
Рисует спрайты и фон
Готовит анимацию персонажей
Задаёт визуальный стиль
Звукорежиссёр
Пишет музыку
Записывает звуковые эффекты
Сводит звук под события игры
Продюсер
Планирует сроки
Управляет командой
Следит за бюджетом
QA-тестировщик
Ищет баги
Проверяет баланс
Играет в игру сотни раз до релиза
Инди и AAA
Инди-игры обычно создают независимые разработчики или небольшие команды, часто без
крупного издателя. «AAA» — условное обозначение крупных коммерческих проектов с большими
командами, значительными бюджетами и длительным производственным циклом. Это не строгие
категории с чёткой границей: реальные проекты сильно отличаются по масштабу, и немало
команд находится где-то посередине.
Характеристика
Инди-проект
Крупный AAA-проект
Команда
От одного разработчика до небольшой или средней команды
Обычно крупная команда специалистов разных направлений
Срок разработки
От нескольких месяцев до нескольких лет
Обычно несколько лет
Принятие решений
Решения часто принимаются быстрее и меньшим числом людей
Изменения могут требовать согласования между несколькими командами
Инструменты
Готовые движки, библиотеки и доступные инструменты разработки
Готовые или собственные технологии и внутренние инструменты
Сильная сторона
Гибкость и свобода эксперимента
Масштаб производства и большие ресурсы
Pygame для первых инди-прототипов
Учебные проекты этой главы написаны в том же духе, что и многие инди-игры: маленькая команда (в вашем случае — один человек), общедоступный инструмент, быстрые эксперименты. Разница между учебным проектом и реальным инди-релизом обычно не в инструменте, а в том, сколько итераций отделяет прототип от готовой игры.
Путь от идеи до релиза
Ни одна игра не появляется сразу готовой. У процесса есть распространённые стадии — в
конкретном проекте их названия и границы могут отличаться, но общая логика похожа и у
AAA-студии, и у одного человека с ноутбуком:
Концепт
идея, ключевая механика
на бумаге или в голове
↓
Пре-продакшн
план, оценка объёма работы
выбор инструментов и технологий
если механика не работает — переделать концепт
↓
Прототип
проверяет саму механику
минимум кода, часто одноразового
показывает, каким будет качество релиза
↓
Vertical slice
небольшой готовый кусок игры
близко к качеству финального релиза
↓
Продакшн
основной объём кода и контента
уровни, персонажи, звук
↓
Альфа
в конкретном проекте критерии могут отличаться
обычно: основной функционал уже есть, тестирование внутри команды
↓
Бета
обычно: контент почти не меняется
тестирование снаружи, охота за багами
↓
Релиз
игра выходит к игрокам
жизнь игры продолжается после релиза
↓
Пострелизная поддержка
патчи, баланс, новый контент
Мяч, отскакивающий от стен, — это уже рабочий прототип: минимальная механика, которую можно попробовать. Это один из распространённых вариантов пути от идеи до релиза — не единственно верная схема.
Прототип и vertical slice — разные задачи
Прототип отвечает на вопрос «работает ли сама идея» — код в нём почти всегда одноразовый, а качество картинки и текста не имеет значения. Vertical slice отвечает на другой вопрос: «как будет выглядеть и ощущаться готовая игра» — это уже небольшой, но полноценный кусок, близкий к целевому качеству, и он часто заодно проверяет производственный конвейер проекта. На практике команда может выстроить техническую архитектуру (раздел 20.26) раньше, ещё на этапе прототипа, а задачи прототипа и vertical slice — пересекаться: разные проекты организуют эти стадии по-своему.