'

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

Понравилась презентация – покажи это...





Слайд 0

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


Слайд 1

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


Слайд 2

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


Слайд 3

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


Слайд 4

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


Слайд 5

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


Слайд 6

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


Слайд 7

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


Слайд 8

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


Слайд 9

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


Слайд 10

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


Слайд 11

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


Слайд 12

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


Слайд 13

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


Слайд 14

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


Слайд 15

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


Слайд 16

Часть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 дня)


Слайд 17

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


Слайд 18

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


Слайд 19

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


Слайд 20

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


Слайд 21

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


Слайд 22

Часть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 Тестирование операторов


Слайд 23

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


Слайд 24

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


Слайд 25

Вопросы? Пишите: dva@reaxion.com Звоните: dva_reaxion


×

HTML:





Ссылка: