[Dev Story] История создания игры Cipher Fall

Нам пишет Константин Новик

Мобильные игры сегодня занимают существенную долю рынка: по статистике, более 20% приложений App Store и Google Play составляют игры. Пользователям доступны приложения разнообразных жанров, сложности и качества (от казуальных головоломок с минималистичной графикой до аркад и шутеров со сложными трехмерными сценами и физическими моделями). Ценовая политика разработчиков также весьма разнообразна: это и целиком платные проекты, и free-to-play-приложения с внутриигровыми покупками, и использование встроенной рекламы. В некоторых программах используются комбинации вышеописанных подходов монетизации. Учитывая, что количество загрузок игровых приложений огромно, данный сегмент рынка является очень привлекательным для разработчиков, несмотря на высокую конкуренцию.

Учитывая все вышесказанное, было очень интересно попробовать свои силы в сегменте мобильных игр. Как верно отметил Нассим Талеб в своей книге «Черный лебедь» (глава 3), разработка собственных приложений, особенно для широкого круга пользователей, сопряжена с высоким риском и относится к так называемой «вероятностной вселенной». Можно долго и кропотливо создавать идеальный продукт с гениальными идеями, учитывать все пожелания рынка, отшлифовать качество, потратив существенную часть времени и средств, но рынок холодно воспримет итоговый результат. В то время как сделанная «на коленке» программа, эксплуатирующая простейшую идею или являющаяся клоном уже существующего продукта, наберет огромную популярность. В этом нет ничего удивительного, поскольку предугадать реакцию рынка практически невозможно. Грамотный маркетинг может улучшить ситуацию, но никогда не станет гарантией успеха. Рынок жесток, беспощаден и безжалостен, но при определенном везении результат может превзойти все мыслимые ожидания. Любой, в особенности независимый, разработчик должен это понимать и уметь вовремя расставаться со своим творением, чтобы двигаться дальше. Ориентироваться на успех, но соизмерять затраты времени, сил и средств, не бояться ошибок и неудач.

Планирование и первые шаги

После такой преамбулы попробую рассказать о собственном опыте разработки первой мобильной игры: как выбирался жанр, каким планировалось и каким получилось приложение, что использовалось в качестве инструментария разработчика. Естественно, будет описан мой личный опыт, который может существенно отличаться от опыта других программистов и команд.

Итак, начну с выбора жанра: сейчас в магазинах приложений можно встретить игры с различным уровнем геймплея и графики. Структура игрового процесса важна для последующей монетизации. Графическая составляющая существенно меньше влияет на данный аспект, но однозначно определяет сложность и срок разработки. Наиболее универсальным вариантом, который позволяет реализовывать разные сценарии монетизации и при этом дает большую свободу в графике, является класс казуальных игр-головоломок. Для таких игр можно добиться разумного срока разработки при интересном геймплее.

Идея цифровой игры-головоломки давно крутилась в голове. Такой жанр можно дополнить элементами аркады и игры с поиском предметов. Итогом стала концепция арифметической головоломки: пользователю необходимо путем выполнения простых математических операций получить заданный результат, что позволит перейти к следующему уровню.

Общая концепция геймплея была вдохновлена фильмом «Матрица»: движущийся поток символов, где будут присутствовать числа и математические знаки, дает аркадную составляющую и требует внимательности от игрока. Окончательная идея: числовая игра-головоломка с дизайном в стиле «Матрицы».

Следующим шагом стала разработка дизайна (как графической составляющей, так и конкретики игрового процесса). Также необходимо было выбрать инструментарий разработки. У меня был достаточно небольшой опыт создания мобильных приложений с использованием среды XCode и языка Objective-C. При всей сложности и некоторой громоздкости, Objective-С имел достаточно элегантную концепцию. Однако всегда хочется попробовать что-то новенькое. Сначала мой взгляд обратился к универсальным средам разработки игры, которые позволяли создавать мультиплатформенные приложения. При более внимательном изучении оказалось, что, помимо дополнительных финансовых затрат, потребуется изучение новых API и особенностей такой среды разработки. Кроме того, подобные среды остаются надстройками над стандартным API, поэтому возникают опасения относительно стабильности работы получаемых приложений и их скорости. Конечно, это всего лишь гипотетический риск, но не хотелось бы иметь проблем в простейшей казуалке. Для этого можно пожертвовать и мультиплатформенностью, тем более что беглое изучение API таких сред показало, что потребуется модификация кода для каждой отдельной платформы. Что касается сред, базирующихся на движке JavaScript, то они являются упаковкой кода с отображением в стандартном WebView/HTMLView компоненте, что накладывает ряд ограничений на доступ к функциям базовой платформы. Поскольку ранее я обратил внимание на анонсированный компанией Apple язык Swift, то решено было остановиться на стандартном XCode. Наличие пакета SpriteKit позволяло надеяться на умеренную сложность и хорошую наглядность при работе над проектом.

По своему опыту могу сказать, что наиболее качественными материалами для изучения языка являются стандартные руководства компании Apple: «The Swift Programming Language» и «Using Swift with Cocoa and Objective-C». С моей точки зрения, они дают необходимый и достаточный объем информации для дальнейшей работы, позволяют получать быструю справку в процессе написания кода. Что касается работы с конкретными библиотеками, то в данном случае я бы рекомендовал источники Apple в качестве справочника, но содержательное описание и примеры лучше представлены на независимых ресурсах. Наиболее активно я использовал www.raywenderlich.com и stackoverflow.com. Следует отметить, что подобные ресурсы позволяют быстро отыскать примеры работающего кода и задать общее направление движения, однако для получения финального результата потребуется актуализация по reference guides с портала developer.apple.com.

Выбор SpriteKit и Swift оказался весьма удачным: неперегруженный синтаксис языка сочетался с достаточно широкими возможностями SpriteKit при высоком уровне абстракции. Кроме того, не возникало препятствий по использованию других стандартных API (CoreData, Social и т. д.). Поскольку я давний сторонник agile-подхода к разработке (причем в самом безалаберном варианте), то на бумаге был сделан набросок плана и функций приложения, который выглядел следующим образом:

• Числовая игра-головоломка
• Разрабатывается только для телефона (портретная ориентация)
• Похожа на «Матрицу»
• В центре экрана отображается число-ключ
• По экрану «падают» цифры, математические знаки, иероглифы
• Игровое поле снизу заполняется водой (ограничение по времени + физика при наклонах телефона)
• Интеграция с Twitter и Facebook (возможность делиться результатами)
• Минималистичный дизайн

Такой план задавал общее направление разработки. По мере продвижения данный план уточнялся и редактировался. Я старался придерживаться следующего принципа: в каждый момент времени должен быть работающий прототип, который в дальнейшем дополнялся необходимыми функциями. Помимо морального комфорта (на руках всегда имеется действующая программа) это позволяло оперативно тестировать те или иные идеи, вносить изменения в план работ.

Конечно, не обошлось без периода прокрастинации, который оказался весьма полезен: детально был продуман базовый дизайн и общий принцип игровой механики.

Реализация

Первым делом был реализован модуль, отвечающий за логику игры. Он был выделен из интерфейсной части, что позволило в дальнейшем достаточно легко вносить доработки и изменения. Вообще, сбалансированный подход к реализации принципа MVC (Model-View-Controller) и модуляризация кода, которая сегодня базируется на принципах ООП (объектно-ориентированное программирование), позволяют существенно упростить и ускорить процесс разработке. Важным в данном случае является взвешенный подход: излишняя академичность и перфекционизм могут значительно затормозить процесс и усложнить внесение последующих изменений.

Первоначально физику модели также предполагалось реализовать в логическом модуле, но дальнейшая работа со SpriteKit показала, что лучше уйти от такой идеи. В результате данный модуль отвечал за контроль окончания раунда и всей игры, генерацию чисел-ключей, обработку операций, изменение скорости игры и вычисление счета. Это дало комфортный уровень абстракции при достаточной независимости от интерфейсной части.

Следующим шагом стала работа над игровым полем. Первоначально для символов (включая иероглифы и значки) была идея использовать графические изображения. Однако необходимость создавать картинки для разных разрешений и увеличение конечного размера приложения на мысль воспользоваться стандартными символами. Отображение таких символов на экране эквивалентно по качеству векторной графике, что не создаст проблем при масштабировании: качество изображения будет сохраняться. Оказалось, что таблица Unicode содержит огромное количество самых разнообразных знаков и иероглифов. Хорошим помощником в подборе таких символов оказался сайт https://unicode-table.com/. Число-ключ, которое необходимо получить, отображалось в центре экрана.

По результатам первого этапа разработки получился достаточно симпатичный прототип, который уже достаточно близко соответствовал первоначальной задумке. Пришло время проанализировать результаты и внести изменения в план работ:

• От «водяной» составляющей (заполнение игрового поля водой для демонстрации временного ограничения раунда) пришлось отказаться: поджимали сроки, да и игровое поле становилось чересчур перегруженным объектами.
• В модуль игровой логики необходимо было ввести проверку ограничений при совершении арифметических операций (от банального деления на ноль до максимальных и минимальных значений, комфортно отображаемых на экране).
• Отсутствовала наглядность: только число-ключ не позволяло понимать, в какой точке находится игрок. В результате область отображения ключа была разделена на две части: верхняя часть показывала ключ, нижняя – текущее значение. Также необходимо ввести звуковой сигнал при нажатии цифры или знака математического действия, чтобы игрок мог идентифицировать факт их выбора.
• Также необходимо было реализовать таблицу рекордов. От первоначальной идеи с GameCenter решено было отказаться и сделать локальную базу достижений. Возможность поделиться достигнутым результатом реализуется с применением соцсетей.

Доработка заняла незначительный промежуток времени. Подходящий звук нашелся в стандартном наборе GarageBand, потребовалась лишь незначительная его доработка. В процессе разработки очередной раз убедился в удобстве, простоте и гибкости библиотеки SpriteKit. Получившийся результат вполне устраивал. Некоторая сложность возникла с реализацией локального хранилища: все-таки интерфейс CoreData остается перегруженным отдельными второстепенными деталями. Также потребовалось несколько экспериментов с количеством символов в наборе: чрезмерно большое количество вариантов приводило к тому, что цифры и знаки математических операций появлялись слишком редко. С другой стороны, недостаточное разнообразие снижало красочность игры и значительно упрощало геймплей.

После реализации базовой функциональности осталось внести последние штрихи:

• Сделать экраны помощи и таблицы рекордов, организовать переходы между экранами.
• Интегрировать приложение с Twitter и Facebook (возможность отправки результатов игры в соцсети со ссылкой на страницу в App Store).
• Сделать иконку приложения и стартовый экран. Это является одним из самых важных моментов разработки: значок приложения – это первое, что видят пользователи App Store. Он должен быть не только эффектным, но и информативным.
• Подготовить описание игры для App Store, отдельную страницу в сети а также ссылку для перехода к приложению в магазине.

Для работы с графикой я давно предпочитаю использовать Pixelmator: цена умеренная, иногда раздается бесплатно, поддерживает слои, работу в растровом и векторном режиме. Последнее особенно важно при создании иконок для приложения: требуется несколько вариантов в разных разрешениях, использование векторного режиме позволяет легко масштабировать рисунок, сохраняя качество элементов. Первоначально для создания значка предполагалось взять часть снимка экрана приложения, но проблемы с последующим изменением размера растрового изображения заставили отказаться от такого варианта. Учитывая, что в игре используются стандартные Unicode-символы, в графическом редакторе также решено было использовать текстовые элементы. В дальнейшем средствами Pixelmator этот текст преобразовывался в векторные фигуры, что позволило в дальнейшем легко менять размер картинки.

Для стартового экрана и экрана помощи использовался снимок экрана игры с небольшой доработкой:

 

Как и в значке приложения, необходимо было создать эффект движения символов, что сразу давало представление об игровом процессе.

Наиболее затратным по времени оказалось создание стартового экрана приложения: новый подход с использованием Storyboard с одной стороны расширил возможности разработчика, но ряд моментов оказался неочевидным. Потребовался ряд экспериментов, чтобы понять, как отцентрировать надпись и картинку на стартовом экране. Оказалось, что для этого необходимо явно задать ограничения-отступы (constraints).

Работа с соцсетями была реализована с использованием библиотеки Social: все оказалось очень просто и интуитивно, всего несколько строк кода дало возможность отправлять сообщения в Twitter и Facebook. Вот пример для работы с Twitter:

if SLComposeViewController.isAvailableForServiceType(SLServiceTypeTwitter) {
let share: SLComposeViewController = SLComposeViewController(forServiceType: SLServiceTypeTwitter)
share.addImage(UIImage(named:"social-icon"))
share.setInitialText("My score is \(score). Play the Cipher Fall: https://bit.ly/1VgNpXh")
self.viewController?.presentViewController(share, animated: true, completion: nil)
} else {
let alert = UIAlertController(title: "Accounts", message: "Please, login to a Twitter account to share.", preferredStyle: UIAlertControllerStyle.Alert)
alert.addAction(UIAlertAction(title: "OK", style: UIAlertActionStyle.Default, handler: nil))
self.viewController?.presentViewController(alert, animated: true, completion: nil)
}

Доработка потребовалась для стандартных значков соцсетей, чтобы они соответствовали цветовой схеме приложения.

По результатам внутреннего тестирования также была скорректирована скорость игрового процесса и алгоритм начисления очков. Также было принято решение расположить на экране дополнительный информационный элемент, показывающий текущую выбранную математическую операцию, а сами элементы расположить на игровом поле асимметрично (первоначально число-ключ располагалось в центре экрана).

Наконец, приложение было отправлено в App Store на проверку. Момент публикации решено было выбирать вручную: в случае, если приложение будет допущено к публикации и автоматически появится в магазине в выходные дни, эффект от размещения может оказаться существенно смазанным.

Итоги

Через неделю после размещения игры появилась идея с дополнительным повышением наглядности геймплея и обнаружилась досадная ошибка с сохранением результатов в локальном хранилище (причем данная ошибка была исключительно логической). Конечно, было несколько неприятно, но процесс доработки и улучшений бесконечен. Необходимо уметь сделать промежуточную остановку и принять риск выпуска «неидеального» с точки зрения программиста продукта. Конечно, совсем «сырая» программа может отпугнуть покупателей. В данном случае каждый должен самостоятельно определять готовность продукта. Учитывая, что везение играет немаловажную роль в мире мобильных разработок, важна разумная доля решительности и авантюризма.

Конечно, выпуск приложения – это только первый шаг. В дальнейшем требуются значительные усилия по маркетинговому продвижению. Грамотный маркетинг не является волшебным эликсиром, который поднимет ваше приложение в топ продаж и гарантирует создателю многомиллионные прибыли, но он является важным составляющим успеха. Остальное сделают рынок и везение.

Надеюсь, мне удалось просто и интересно рассказать о всех основных этапах работы над игрой. Я хотел сделать акцент не на технических аспектах (тем более что в Сети достаточно ресурсов для разработчиков), а сосредоточиться больше на процессе и философии. Мне кажется, что они являются не менее важными элементами.

Название: Cipher Fall
Издатель/разработчик: Konstantin Novik
Цена: 29 руб.
Встроенные покупки: Нет
Совместимость: Для iPhone
Ссылка: Установить

Если вам есть, чем поделиться с другими читателями нашего сайта, пишите на advert@appleinsider.ru и не забудьте указать свое имя или ник. Мы внимательно читаем входящие письма и публикуем ваши самые интересные истории.