Как и где люди будут играть?
Опишите задуманную игровую сессию: сколько она длится, каким способом игрок управляет игрой, какой у него экран и в какой ситуации он находится. Несколько минут в автобусе и долгий вечер за рабочим столом приводят к совершенно разным играм и разным планам разработки игры. Важны и привычки игроков. В одни жанры обычно играют долгими сессиями и с полным вниманием, в другие — урывками, в короткие перерывы, одной рукой. Если проектировать под не ту привычку, потом это сложно исправить правками интерфейса.
Для клавиатуры с мышью, геймпада и сенсорного экрана управление продумывают отдельно. Мышью легко сделать точный щелчок, а палец закрывает часть экрана и попадает гораздо менее точно. Определите, что должно оставаться читаемым и быстро реагировать на самом маленьком экране, который вы собираетесь поддерживать.
Если вы ориентируетесь на несколько платформ, запишите, какие части игры общие, а каким нужна отдельная реализация или подача: например, меню, управлению камерой и экранным подсказкам. Так команда с самого начала понимает, где её ждёт дополнительная работа.
Какие системы проверить заранее?
Соберите типичную сцену — с обычным для игры количеством персонажей, эффектов и элементов интерфейса — и измерьте производительность на том оборудовании, которое собираетесь поддерживать, включая слабые устройства. Узнать посреди производства, что игра не работает плавно на целевых телефонах, — один из самых дорогих сюрпризов для команды.
Если в игре предусмотрен сетевой режим, проверьте свои допущения о работе сети на ограниченном сценарии, в том числе что происходит при обрыве связи или повторном подключении игрока. Сохраните эту типичную сцену и прогоняйте её после крупных изменений: так проблемы с производительностью обнаруживаются сразу, а не перед самым выпуском.
Решите, как устроены сохранения, аккаунты и прогресс, прежде чем обещать игрокам продолжение игры на другой платформе. Запишите технические ограничения и список устройств, чтобы производство графики и дизайн уровней не шли вперёд на допущениях, которые оборудование не выдержит.
Что нужно каждой платформе для выпуска и поддержки?
Ведите для каждой платформы свой чек-лист выпуска: подпись сборки, сведения для магазина, тестирование и поддержка после выпуска — там, где это применимо. У каждого магазина свой порядок подачи и свои правила. Сроки проверки и требования к материалам для карточки тоже отличаются, поэтому закладывайте время на каждую платформу отдельно.
Требования к монетизации, контенту и платежам каждый раз сверяйте с действующими правилами платформы: они различаются между магазинами и со временем меняются. Тестирование на устройствах и работы по совместимости закладывайте в план с самого начала, а не вспоминайте о них в конце. Это касается и каждого обновления после выпуска.
Общий движок позволяет повторно использовать много кода, но не отменяет отдельной приёмки и отдельной эксплуатации для каждой поддерживаемой платформы. Каждая добавленная платформа — это обязательство, которое придётся выполнять и после запуска. Если вы планируете добавить платформу позже, оставьте для этого возможность в архитектуре — например, отделите обработку управления от игровой логики, — но не обещайте сроков, пока первая платформа не станет стабильной.
Чек-лист: выбор платформы игры
- Опишите игровую сессию и поддерживаемые способы управления.
- Определите, что должно оставаться читаемым и отзывчивым на самом маленьком поддерживаемом экране.
- Проверьте типичные сцены на целевом оборудовании, включая слабые устройства.
- Решите вопросы сохранений, аккаунтов и сетевой игры до того, как обещать игру на нескольких платформах.
- Подготовьте отдельные проверки приёмки и выпуска для каждой платформы.
Пример: тактическая игра на двух платформах
Прототип тактической игры проверяют с мышью и с сенсорным управлением на небольшом экране. Команда записывает, что выбору отрядов и управлению камерой на каждой платформе нужны разные решения.
Первую платформу выбирают по результатам проверки взаимодействия и производительности. Вторую оценивают позже как отдельное решение о разработке — со своим управлением, тестированием и планом выпуска. Так команда не обещает вторую платформу, пока не знает, во что обойдётся её поддержка.
