Управление разработкой мобильных игр.

Предисловие
О чем я буду говорить?
Одновременная разработка под группы телефонов
Метрика по арту
Для кого я буду говорить?
Project Managers, Lead Developers
Top Management и руководители компаний

Постановка проблемы
А что хочет рынок?
Одновременный запуск игры на многих операторах
На brew и java одновременно
А почему?
Максимизация прибыли
Brew: 35% NA Mobile gaming sales
Java: 65%
Рекламные компании

Структура доклада
Перед разработкой
Классификация телефонов
Способы разработки мобильных игр
Разработка
Art Functional Point
Планирование сверху
Реализация одновременной разработки
Brew and Java Game Frameworks
Тактика тестирования Reaxion
Документы
Project Diary
Project Results

Часть1. Классификация телефонов
Stage: Уровень дизайн (screen size)
Platform: Необязательная группировка по техническим характеристикам (heap, jar, performance)
Substage (референс, мастер): Группа телефонов на которых будет работать один билд.
Handset (порт, SKU): Конкретный телефон

Часть1. Способы разработки мобильных игр
C Top версии
(+) Наибольшее достижимое качество
(+) Уменьшение графики делать быстрее и проще чем увеличение
(-) Разработка почти с нуля middle или low-end engines
(-) Необходимость уменьшать heap usage
(-) Необходимость уменьшать jar usage
Итого:
Длительное и болезненное
портирование под mass-market
телефоны.

Часть1. Способы разработки мобильных игр
C Low версии
(+) Максимально быстрое и простое портирование
(-) Не высокое качество продукта
Итого:
Минимизация технических рисков
за счет качества продукта

Часть1. Способы разработки мобильных игр
Одновременная разработка под все платформы
(+) Минимальное время выхода на рынок
(+) Высокое (но не максимальное!) качество всех версией
(+) Не высокие (но не минимальные!) технические риски
(-) Требование к квалификации сотрудников
(-) Необходимость длительного и очень детального pre-production-а
(-) Требование наличия большого количества телефонов и большого и грамотного QA
Итого:
Счастье, при условии что проект не самый сложный и команда в состоянии подход реализовать

Часть1. Сравнение способов разработки

Top 12 Solitaire. 29x413
Incadia. 120x110
Часть2. Art Functional Point
Функциональная единица (Art Functional Point, AFP) для арта это
Область состоящая из 12тыс. пикселей
Примеры
Curling. 72x166

Часть2. Art Functional Point
Зачем?
Оценка трудозатрат на реализацию
Оценка размера арта
Как?
Объем проекта
Сложность арта
Продуктивность команды
Любая количественная оценка лучше чем отсутствие какой-либо оценки (с) Кто-то умный

Часть2. Art Functional Point
Project:
Minigolf 2
Art.FP:
27,41

Часть2. Art Functional Point
Project:
Incadia
Art.FP:
26,77

Часть2. Art Functional Point
Сложность арта определение:
Относительная величина, характеризующая время, необходимое для реализации функциональной единицы необходимого качества
Cложность арта НЕ зависит от
конкретного исполнителя и объема арта.
Сложность арта состоит из
технологические особенности
художественные особенности

Часть2. Art Functional Point
Коэффициент производительности это
Относительная величина, характеризующая скорость освоения функциональных единиц конкретным сотрудником на момент реализации проекта
Коэффициент производительности зависит от
Производительности художников (в определенный момент времени)
Производительность команды (уровень менеджмента проекта)
Поправка на удаленность
Work = Functional Points * Complexity / Productivity Coefficient

Часть2. Art Functional Point
Как можно еще использовать метрику
Еще один способ получить оценку отличную от оценок художников
Убеждение дизайнеров в не реализуемости их надежд из-за ограничений размера
Уровни оценки Art Function Point
Быстрая оценка по базе завершенных проектов (погрешность 30-50%)
Оценка по Fake Art (погрешность до ~10%)
По GDD определить состав графики и количество графики
Определиться с размерами графики
Определиться с количеством фаз анимаций
Упаковать весь fake art в один файл
Перемножить размеры получившегося файла
Разделить на 12тыс
Замечание: метрика не учитывает resize

Часть2. Планирование мобильного проекта сверху
Какой планируем проект
Большой проект со значительными gameplay рисками
Законченный концепт
Что делаем
Выделение резерва (30-50%)
Major Milestones
Alpha (основные фичи, снятие рисков, игру можно пройти)
Beta (feature-complete, законченная игра с багами)
Release (счастье ☺)
Minor Milestones
Alpha. Playable Demo
Alpha. Technical Demo
Планирование задач для каждого Milestone (задачи 0.5-3 дня)
Планирование задач ближайшего Milestone (задачи не больше 1 дня)

Часть2. Планирование мобильного проекта сверху

Часть2. Реализация одновременной разработки
Расчеты по jar
Расчеты по heap
Управление фичами билдов

Часть2. Реализация одновременной разработки
Фича – то что можно выключить и получить выигрыш (jar, heap, performance)
Группировка фич
Heap и/или Performance – Engine Pack
Jar – Art Pack
Sounds – Sound Pack
Network – Code Pack

Часть3. Реализация одновременной разработки

Часть2. Brew and Java Game Frameworks
Основные идеи Game Frameworks
Абстрагирование от платформы (brew only)
Отработка типичных алгоритмов
Накопление опыта
One-click сборка серии билдов на билд-машине
Как результат
Уменьшение времени разработки и портирования
Уменьшение требований к програмистам
Простое портирование на другие платформы (WM, Symbian?)

Часть2. Тактика тестирования в Reaxion
Reaxion QA
Project QA Lead
Максимально ранее тестирование
TestTrack Pro как средство Bug Tracking и Small-Tasks Tracking
Использование TestTrack Pro всеми членами команды
Brew Testing
NSTL Testing
NSTL AppRelay
NSTL Self-Testing
Brew Lab
Тестирование операторов

Часть3. Документы
Project Diary
Недельные цели и результаты сотрудников
Реализация принципов
Прозрачность процесса
Воспроизводимость процесса
Информативность

Часть3. Документы
Project Results
Сбор в одном месте результатов всех проектов, всех портов
Даты старта и окончания проекта
Имена разработчиков
Baseline и actual значения длительности и трудозатрат
Оценка стоимости