Правила лаборатории
Как описываем проверку
В протоколе указываются версия движка, конфигурация устройства, тестовая сцена, длительность прогона и способ измерения.
Условия описаны так, чтобы тест можно было повторить.
Не переносим один результат на все игры и устройства.
Различаем измерение, рабочую гипотезу и пример.
01 · Протокол тестирования
Как проверить мобильную Unity-сборку
Одна и та же сцена запускается на бюджетном, среднем и старшем Android-устройстве. В протокол включены холодный запуск, FPS, память, нагрев и размер AAB.
| Сценарий | Что измеряем | Статус |
|---|---|---|
| Пустая сцена | Базовый FPS, RAM, размер сборки | Демо: пройдено |
| 50 противников | CPU время кадра, 1% low FPS | Демо: пройдено |
| Анимация и частицы | GPU время кадра, нагрев | Демо: пройдено |
| Сохранение и перезапуск | Время операции, целостность данных | Демо: пройдено |
Пример заполнения: статусы в таблице демонстрационные и не являются результатами испытаний реальной сборки.
Протокол
- Одинаковая сборка для выпуска устанавливается на все устройства.
- Перед прогоном устройство перезагружается и охлаждается.
- Каждый сценарий выполняется три раза по десять минут.
- Фиксируются медиана, худший прогон и наблюдаемые артефакты.
02 · Методика
Как определить минимальный объём работ MVP за 90 минут
Цель сессии — оставить только то, что необходимо для проверки одной продуктовой или технической гипотезы.
Один вопрос
Формулируем решение, которое должно измениться после теста.
Один основной игровой цикл
Действие → обратная связь → награда → новое решение.
Четыре корзины
Must, Should, Could и Not now.
Критерий остановки
Заранее фиксируем выборку, метрику и условие принятия решения.
Прототип должен уменьшать неопределённость, а не изображать маленькую готовую игру.
03 · Шаблоны
Рабочий комплект до оценки разработки
Структура помогает заказчику и команде говорить об одном объём работ. Её можно перенести в документ или таблицу и заполнить до первой встречи.
| Шаблон | Что фиксирует | Результат |
|---|---|---|
| Бриф из 27 вопросов | Цель, аудитория, платформы, механики | Основа оценки |
| Одностраничный GDD | основной игровой цикл, правила, прогрессия | Общая модель игры |
| Матрица устройств | Минимальные и целевые конфигурации | целевая производительность |
| Отчёт плейтеста | Сценарии, наблюдения и метрики | Следующая итерация |
| Журнал рисков | Вероятность, ущерб и владелец | Управляемые риски |
04 · Критерии сравнения
Unity и Unreal: одинаковая сцена, одинаковая задача
Для корректного сравнения используется одна задача разработки: небольшая трёхмерная локация, персонаж, противник, интерфейс, сохранение и сборка для Windows.
| Что сравниваем | Единые условия |
|---|---|
| Время до первой рабочей сборки | Одинаковый состав функций и единый критерий готовности. |
| Время полной сборки | Одинаковая конфигурация компьютера и чистая сборка проекта. |
| Размер готовой игры | Одинаковый набор ресурсов, целевая платформа и настройки упаковки. |
| Частота кадров и просадки | Одинаковое разрешение, освещение и сопоставимое качество изображения. |
| Пиковое потребление памяти | Одинаковая сцена, маршрут прохождения и длительность прогона. |
| Сложность подготовки сборки | Фиксируется перечень обязательных настроек и операций. |
05 · Технические ограничения
Когда выбранная технология не подходит
Unity
Unreal Engine
HTML5 и Mini Apps
Мультиплеер
Офлайн-режим
06 · Разбор ошибок
Как лишний объём работ мешает первому прототипу
Если вместе с основным игровым циклом разрабатывать метаигру, несколько режимов и финальный арт, проверка главной гипотезы усложняется.
| Ошибка | Сигнал | Коррекция |
|---|---|---|
| Три режима вместо одного | Ни один не дошёл до внешнего теста | Оставить один игровой цикл |
| Финальный арт слишком рано | Дорого менять механику и UI | Вернуть временную графику |
| Нет требования к производительности | Просадки замечают перед релизом | Задать цель с первой сцены |
| Функции только добавляются | объём работ растёт каждую неделю | Новая функция заменяет старую |
Следующий выпуск
Начинаем с измерения, которое поможет принять решение
Опишите платформу, движок и главный технический риск. Предложим минимальный тест, метрики и формат отчёта до большого разработка.