Приветствую, читатели!
Сегодня хочу поделиться с вами историей о том, как я делал много всяких правильных вещей, чтобы довести проект по созданию небольшой игрушки от начала и до конца. Такими вещами были: анализ, планирование, дизайн, TDD разработка и тестирование. И все это шло по scrum'у. Да-да, именно в таком составе и порядке. Вообще все это должно быть правилом, идеальным маршрутом ведения проекта, но не все и не всегда это понимают. Ну как минимум я часто ленюсь и бросаюсь в код, забывая про остальное. Не сложно догадаться что из этого выходит. Но не в этот раз, — сказал я себе, и отложив клавиатуру, взял листок и ручку.
Disclaimer: данная статья носит чисто мотивационный характер. Технические детали будут изложены отдельно.
Мотивы
Основной причиной, которая подстегнула меня к этому проекту, было желание пройти весь путь разработки игр, пусть даже в контексте столь маленького проекта и пусть даже в вакууме. Но в итоге хотелось все же проникнуться каждым аспектом game dev'а. Для себя я решил, что в прошлом уже достаточно наошибался с домашними проектами, и на этот раз все должно быть как у взрослых.
Идея
Тип предстоящего ПО уже был заранее определен — игра (тут как-то и думать не о чем было, подсознательно все было решено уже давно). Целевая платформа первой версии предполагала собой Android, но лишь из-за того что она ближе по духу и не требует дополнительных знаний. Далее я задумался над жанром. Не смотря на всплывающие в моей фантазии шутеры и стратегии реального времени, я, пессимистично оценив свои силы, решил следовать принципу quick win и нацелился на несложный пазл. Среди обилия пазлов первым в памяти возник филлер, поле из ромбиков разных цветов и единственная цель: захватить больше половины всех ячеек. На этом и остановился. Конечно, как и ожидалось, поиск дал схожие результаты, но тем не менее не так и много, и выбор был утвержден.
Разбиение на задачи и их планирование
Прежде чем считать трудозатраты и распределять задачи по календарю, нужно было рассмотреть конечный продукт со всех сторон, декомпозировать его до уровня элементарных задач, подобрать инструменты, библиотеки, прикинуть процесс тестирования и продакшен.
Первым делом на листке бумаги (а точнее пара десятков А4) были созданы предварительные мокапы. Затем их же было решено в полной мере изобразить в фотошопе, таким образом появлялся шанс предотвратить визуальные неточности еще при проектировании. Художник из меня никакой, так что в итоге пришлось искать уроки на просторах интернета (на сколько успешно все получилось судить вам). Зато эскизы было решено строить из финальных версий ресурсов, таким образом я старался убить сразу двух зайцев, и уже по завершении проекта могу сказать, что это решение было удачным.
Далее я продумал бизнес логику от А до Я (важно понимать, что если даже мелкие алгоритмы не будут продуманы на этом этапе, их придется городить впопыхах уже на этапе разработки, поэтому настоятельно рекомендую этим не пренебрегать) и составил функциональные требования. Отталкиваясь от этой информации, я перешел к выбору фреймворка.
Дух экспериментатора подсказывал, что нужно опробовать что-то новенькое. Так я и познакомился с cocos2d-x. Перечислять преимущества я не буду. Пытливые пользователи уже ушли в гугл, а те, кто знаком с данной платформой, поймут меня в моем выборе. От себя лишь замечу — и функциональные возможности и производительность, и лицензия подходили под мои требования отлично. Теперь, когда был известен фреймворк, стало легче с оценкой трудозатрат.
А код то писать все еще рано, но опираясь на имеющуюся информацию, можно заняться UML'ем. Настоятельно рекомендую обложиться всеми материалами, собранными на данный момент и строить-строить-строить диаграммы классов. Я целый вечер потратил на эту активность. Первый вариант был как и ранее, тяп-ляп, и справился. Но ведь диаграмма классов должна избавить разработчика от проектирования архитектуры на ходу. Поэтому все квадратики ушли в мусор и начался второй виток. Где-то на его середине я повторно допустил ошибку излишнего упрощения и лишь с третьего раза получилось составить весьма приличный документ. Забегая вперед скажу, что он более чем на 80% соответствует реальному коду.
Подрезюмировав и пробежавшись по всей писанине, я с запасом определил 10 часов на работу с ресурсами (музыку кстати брал готовую, уж чего не умеют того не умею), 20 часов чистого программирования, и 10 часов на тестирование и багофиксинг.
Приступаем!
Итак, список задач составлен, переходим к выполнению. На календаре было начало отпуска, а руки, не отвыкшие от клавиатуры на работе, уже чесались и рвались в бой. Но дабы продолжать соблюдать best practices, я засел за фотошоп. И, о чудо, мне не требовалось выдумывать себе работу. У меня все было четко декомпозировано и расписано:
— Всего, 5 экранов.
— 1-й день, экран меню, и выбора режима игры. На них изображены ...,… кнопки,… элементы и тд.
— 2-й день, игровое поле, на котором изображены ...,… и тд.
— 3-й день, экран паузы и завершения игры.
Орудуя scrum'ом, я выделял себе задачи, приоритизировал их, устанавливал лимиты и управлял беклогом, короче был царь и бог. Все вкуче очень неплохо систематизировало мою работу. Для себя я вынес небольшое правило — не брать в разработку более 2-х взаимозаменяемых задач. Застопорился на одной, перехожу к другой, а позже вернусь к первой.
Подготовка ресурсов отобрала три вечера, суммарно 7 часов. Такое опережение графика грело душу.
Переходим к разработке. У нас 20 часов. Как же следить за прогрессом и хоть косвенно понимать успеваю ли? А вот как: 20 часов это округленное число, состоящее из суммы трудозатрат на реализацию каждого элемента диаграммы классов. Теперь, чтобы понять какие части программы готовы, и какой общий прогресс выполнен, был придуман следующий способ:
— реализовываем все-все классы/методы, но внутрь кладем пустышки, нам нужна лишь успешная компиляция;
— для каждого метода набрасываем Unit тесты (3-5 штук для каждого);
— теперь при сборке видно сколько тестов прошло, и это % завершенности проекта, и сколько тестов упало, а это та часть, которая еще не реализована.
Таким образом у нас есть индикатор продвижения проекта.
Отдельного абзаца заслуживает информация про монетизацию. Конечно же за потраченные время и усилия хочется вознаграждения. Поэтому было решено прикрутить немного рекламы. У Google AdMob есть разные виды рекламных сообщений. Я же выбрал вот такую стратегию: во время игры — никакой рекламы, а лишь полностраничный баннер после выхода из игры. Тут так же хочу рассказать про небольшой архитектурный финт (это из 20% кода несоответствующего диаграмме классов). Cocos2dx при завершении игры, не идет нормальным путем финализации работы приложения, он не вызывает onDestroy и т.д., он просто kill'яет текущий поток с приложением. В то же время впихать рекламу в native библиотеку — задача тоже нетривиальная.
Решение вот такое:
1) после того как пользователь закрывает игру (нажав Exit), основное поле игры скрывается и на помощь приходит JNI который дергает отображение новой Activity с рекламой;
2) когда реклама то-ли закрывается пользователем, то-ли сворачивается, то-ли еще какой вариант (Back/Home/Menu кнопки и т.п.), опять таки JNI, но уже в обратную сторону отправляет вызов финализации игры и все закрывается.
Тестирование
Для тестирования я применил две стратегии (опять таки, даже на этом этапе у меня все было расписано и шло по плану):
1) ручное тестирование. Благо жена — QA инженер. Отдельная благодарность за помощь.
2) автоматизированное тестирование. Сейчас в интернете активно развиваются сервисы, предоставляющие удаленный доступ к реальным телефонам/планшетам с целью тестирования разрабатываемых приложений (ниже приведу ссылки). Так же положительной чертой таких сервисов является наличие trial периода использования. Для себя я выделил три таких сервиса. Первый — для того что бы иметь возможность запустить итоговое приложение на разных устройствах. Второй — для замеров производительности и нагрузки. И третий — для массового поверхностного тестирования на большом количестве устройств.
Обе стратегии в сумме дали с десяток явных проблем и опять заложенный объем трудозатрат был использован не до конца.
Продакшен
Лучше один раз увидеть нежели семь раз услышать.
Итог
— Бесценный опыт!
— 18 часов разработки + 7 часов подготовки ресурсов + 5 часов тестирования = 30 часов реальной работы, за которую не стыдно.
— Гордость за проект который доведен до конца! И дикое желание поделиться достижением (именно поэтому, не выспавшись, я наяриваю эту статью).
— Надежда на то, что из этого что-то да получится (может пустая, так как опыта мини-коммерческого game dev'а ранее у меня не было).
— Мотивация/советы для читающих.
Что еще предстоит сделать (если проект начнет подавать признаки популярности):
1) Зарелизить игру для iOS и Windows Phone 8, ну и скорее всего десктопную версию для Windows.
2) Прикрутить google-аналитику для анализа поведения игроков.
3) Расширить функционал: уровни сложности, размеры поля/ячеек, общий top (где-то в облаке).
Если я не осветил каких либо интересующих деталей, пишите в комментарии, обязательно отвечу.
Полезные ссылки:
play.google.com/store/apps/details?id=com.xlab.ice.HexFiller — собственно мой «шедевр»
appthwack.com — сервис массового тестирования
cloud.testdroid.com/web/home — сервис тестирования производительности приложения
testobject.com — возможность запуска приложения на множестве устройств с последующим взаимодействием
developers.google.com/mobile-ads-sdk/docs/admob/advanced — межстраничные объявления
За кулисами остались нюансы подготовки графики, работа с разными дисплеями, сборка, запуск на эмуляторе, алгоритм стратегии игры AI и еще всякие мелочи. Но данная статья носит более мотивационный характер. И все же, если кому будет интересно услышать недосказанное — голосуйте, я напишу вторую часть статьи.
Спасибо за прочтение!
Как видите, серьезный подход даже к мелким проектам дает свои плоды. И экономия времени, и финальный результат, все это указывает на негативные стороны наплевательского отношения к pre-coding/post-coding этапам, которые must have везде. Уж теперь-то я это усвоил.
P.S. Спасибо reenboog за советы по графике и ресурсам и coder1cv8 за советы по монетизации.
Автор: icepro
