Снова привет всем, в этой, третьей, части будет рассказ о том как программировался «Swordbreaker The Game», почему был выбран тот или иной фреймворк, подробности под катом.
Продолжение истории разработки нашей первой игры, начало вот здесь:
Итак, перед тем как перейти к заключительной части и рассказать, что делалось уже после релиза игры, давайте остановимся на главной части разработки, а именно – к программированию.
Как было рассказано ранее проект пережил следующие вехи развития:
- Был создан прототип на бумаге в виде диздока, были определены платформы, и примерный геймплей
- Были созданы прототипы на различных игровых движках с целью определить какой из них подойдёт лучше всего для реализации идей
- Была создана демо-версия для предварительной оценки игры со стороны коммьюнити
- Игра была реализована для основных платформ (Windows, Android OS)
- Игра была реализована для вторичных платформ (Linux, Mac, iOS)
Для начала стоит сказать, что если у вас, читатель, как у нас не было опыта в программировании игровых проектов, то скорее всего вам на начальном этапе стоит определится с главным, а именно — со свободным временем, которое вы будете готовы тратить на разработку вашего проекта. Для разработчика-программиста особенно важно учитывать этот фактор, т.к. освоение нового языка, понимание основ принятого фреймворка, пробы написать тестовый код на нём – это всё отнимает довольного много времени.
Смотрите сами – вы работаете на работе – это 8 часов, вам нужно нормально отдыхать, иначе в голове будет постоянная каша и стресс вас доконает – это как минимум еще 8 часов, еще 8 остаётся вроде как на проекты, но жизнь складывается зачастую так, что из этих 8 на проект получится выделять часа по 4 в лучшем случае. И в эти короткие сроки придётся изучать много и практически «на лету». Поэтому прежде чем начинать что-то делать постарайтесь трезво оценить, готовы ли вы писать код по 12 часов в сутки, чтобы реализовать проект.
К чему это отступление? А к тому, что сейчас оглядываясь назад, я понимаю, что работать в таком режиме – это тот еще адский труд, и будь проект более сложный в механике или больше по объему, мы бы возможно и не дошли бы до финала, либо это бы заняло еще больше времени (а мы делали игру около двух лет).
Лирическое отступление завершено, про денежную сторону этого вопроса я думаю поговорим в следующей части, а теперь собственно к коду. =]
На тот момент когда всё началось (начало 2014) жизнь в интернете происходила под лозунгами а-ля «Флеш умирает, что же делать, а давайте переходить на html5, но он однако какой-то сырой…», также на горизонтах лихо проносились андроиды выпуская всё новые версии системы, охватить хотелось конечно всё и сразу, но для начала были определены две платформы – Android и Windows (в виде Steam Greenlight, если пройдём конечно), соответственно нужен был кроссплатформенный движок. На тот момент были следующие кандидаты на которых я попробовал реализовать базовый уровень – Construct2, Libgdx, Unity3d, ImpactJS, Cocos2d, еще какая-то пара Flash-движков, AndEngine, CoronaSDK. Из всей кучи более-менее адекватными по совместимости, документации и простоте освоения были только два – это LibGDX и CoronaSDK, в Unity3d на тот момент работа с 2д графикой делалась набором костылей (но пару демок я написал и на нём, но по сравнению с теми двумя он не был таким удобным).
Как вообще выбрать движок для начального прототипирования игры? Заметьте, что для прототипа, именно прототипа, когда нужно составить виденье будущей игры, подходит фактический любой движок, который вы сумеете освоить хотя бы за пару недель и начать уже-то что-то на нём писать. LibGDX в этом плане имел хорошую wiki-документацию, отличный форум, с живым коммьюнити, а его авторов Mario Zechner написал даже две книги по программированию игр, с использованием LibGDX, (ищите на packtpub) всё это довольно сильно помогало на начальном этапе, ведь опыта программирования игр у меня не было. Примерно такая же ситуация с CoronaSDK – простая и доступная документация, сравнительно богатый для 2d набор API, язык программирования Lua – простой в освоении, но с большим количеством нюансов.
Сначала я вообще думал писать на CoronaSDK, но постоянная работа со сборщиком на стороне сервера, компиляция, потом загрузка на Android (всё это не быстро), да и довольно “жидкая” структура языка lua, чем то напоминающее javascript, заставили продолжить освоение движка LibGDX.
Собственно LibGDX был хорош всем. Во первых там был хороший туториал который позволял понять основной игровой цикл, были демки (около 100 шт.) с различными функциями API, которые можно было запустить и посмотреть, всё это дело собиралось на Windows и делало это очень быстро, плюс при компиляции на Android проект выглядел 100% также (у Corona бывали глюки, на эмуляторе так, а на телефоне по-другому). К тому же это была Java – мейстримовый ООП язык программирования, надо сказать очень удобный для реализации проектов любого уровня, и практически такой же как C#, на котором я писал (и пишу) на работе. К тому же это было всё управлением Android Studio (создатели Resharper и кучи других инструментов), которая была также крайне удобной IDE для разработки.
Собственно какие выводы я из всего этого сделал – если вы только начинающий в разработке игр, берите тот движок, который наиболее приемлем для вас с точки зрения простоты освоения, да, я понимаю, что выбрав бы допустим Unity3d я бы освоил более мощный инструмент, но в целом для игры, как для программного продукта, важно – сама геймплейная составляющая, на чём она будет реализована – дело вторичное, все движки примерно одинаково работают с 2д и 3д, поэтому выбирайте то, что подходит именно вам (может быть по опыту ЯП, может по удобству), единственный критерий на данном этапе – скорость разработки прототипа.
Описывать сам процесс программирования для игры наверно нет смысла, для LibGDX всё доступно расписано в Wiki, хотя последнее время проект немного подзатих, но думаю для начинающих я бы порекомендовал его для “пробы пера”.
Итак на LibGDX мы доехали до выпуска демо-версии, здесь сыграло важную роль то, что у движка было:
- Лёгкая интеграция с рекламным API, можно было легко и без проблем встроить рекламные модули AdMob в проект с использованием готовых API.
- Это была фактически родная для Android – Java
- Собственно запуск демо прошёл фактически без всяких технических проблем, были пару вопросов почему-то криво формировалось отображение, но в целом – всё нормально.
- Далее начался марафон до релиза основной версии игры.
- На всём этом долгом пути очень полезными были следующие вещи:
- Android Studio – которая ну очень удобная штука со всеми фишками рефакторинга, подсветки синтаксиса, быстрых переходов, отладки и.т.д. JetBrains – one love! Всё это позволяло удобно управлять кодом и быстро находить ошибки экономя время и нервы.
- Структура проектов в LibGDX – так получилось, что данный фреймворк отлично спроектирован под создание 2д игр, почти под всё API были либо Demo либо статьи в Wiki, так что проблем технического характера было мало, также порадовала локализация, которая тоже имела свой API. На финальном этапе интеграции в Steam, также оказалось, что есть свободные компоненты для реализации Steam API в игре, аналогично было и с google play services. В целом LibGDX был этаким фреймворком наподобие стандартной библиотеки .NET с кучей готовых классов из которых ты можешь лепить всё, что тебе требуется, там есть практически всё (в рамках OpenGL ES, наверно =])
- Моральная Санина поддержка, особенно когда мы переписывали диалоги и тестировали всё это дела на баги. =]
В остальном особенно рассказать нечего, если вы прошли этап прототипирования и даже выпуска демо-версии, то, скорее всего, уже выбрали движок, который соответствует вашим требованиям. Если бы на данный момент (28.09.2017), я бы выбирал движок для реализации игры, я бы наверно в первую очередь шагнул в сторону Unity3d, который очень сильно эволюционировал за всё это время.
Постепенно правя последние баги мы подошли к релизу в Steam, запуск Android версии решено было отложить, поскольку там было пара технических моментов и мы всё никак не могли решить делать ли её бесплатной с рекламой или paid-app. Подготовка к запуску в Steam заняла тоже своём время, нужно было заполнит много информации – личные данные, ачивки, подготовить материалы (как оказалось нужны картинки на ачивки, значки, смайлики для чата, обои для профилей пользователей), а также протестировать работу API в игре. Steam вообще в этом плане очень удобная платформа, море документации, которая доступна после регистрации (и которая не подлежит разглашению o_O), делаю процесс довольно простым, к тому же, как я уже говорил, были готовые библиотеки для LibGDX. Вобщем пару раз нас отклоняла модерация из-за несоответствия материалов, но таки мы прошли и стартовали! :D
Тут процесс перетёк из состояния «разработка» в состояние «поддержка», и посыпались первые долгожданные «баги» — у некоторых неправильно отрабатывал FitViewport, у кого-то терялись сохранения, кому-то не давались ачивки, вобщем у кого что болит. Часть багов была оперативно поправлена, а часть… увы, но с некоторыми я так и не смог разобраться до сих пор.
Впрочем у большинства игроков игра шла стабильно, появилась первая статистика, скриншоты, отзывы, и какое-никакое моральное удовлетворение от проделанной работы. Ура мы стали разработчиками! :D
К чему я собственно в начале статьи упомянул про 4 часа… Последнее время перед релизом всё хотелось сделать уже качественно, проверить всё что надо, и выпустить нормальную рабочую версию, вобщем это было довольного много стресса. Кодинг, кропотливая работа по расталкиванию символов по карте, правки диалогов, тестирование, всем кто знает что такое кранч, те в курсе)
Вобщем это были напряженные деньки предфинальной полировки почти готового продукта. Спустя некоторое время была создана версия для Android, и запущена в виде paid-app, трансформация благодаря функционалу LibGDX произошла довольно безболезненно, все функции для if-else условий настройки интерфейса там были, поэтому часть управления была подстроена под пальцевый тач и всё закрутилось-завертелось.
Оставалось еще одно незаконченное дело – это версия для Mac, а именно для iOS, вообще Android для paid-приложения показал себя довольно хорошо, была надежда, что iOS версия будет как минимум не хуже.
Сейчас уже не помню в чём конкретно была причина, по которой я решил версию для iOS писать не на LibGDX, а на CoronaSDK, но вроде это были какие-то нюансы в совместимости. Был также куплен Mac, для того, чтобы пройти регистрацию на портале и для тестирования на виртуалке.
Достаточно быстро, хотя и не без проблем с Lua игра была переписана и запускалась на эмуляторе вполне хорошо, сказались некоторые отличия в компонентах, что-то пришлось оптимизировать, что-то переделать, но в целом движок с возложенной на него задачей справился, плюс CoronaSDK обладает хорошим и шустрым эмулятором. Место Android Studio заменил Sublime Text под который у CoronaSDK существует плагин, получилось что-то наподобие IDE, в котором было тоже довольно удобно. В целом у CoronaSDK плюсом и минусом является язык – это скриптовый Lua с динамической типизацией, к которой не сразу привыкаешь и иногда путаешься в областях видимости, определении переменных, и.т.д., постепенно к этому привыкаешь, всё становится таблицей в которую можно затолкать всё – начиная от данных и заканчивая функциями, в целом тут есть своя логика, но отлаживать всю эту чертовщину – не очень то круто. Коронка тоже имеет богатый API в котором есть много всего для создания 2д игр, очень проста в освоении, содержит много примеров в самой документации, плюс к этому есть плагины для встраивания монетизации, и прочих сервисов (некоторые платные). Для создания простеньких игрушек под телефоны – самое то, для чего-то более крупного, я бы наверно запутался в всём этом балагане, при отсутствии нормальной IDE.
Запуск iOS версии прошёл стабильно, написав и протестировав всё под Windows на эмуляторе, осталось заполнить регистрационную информацию, сделать билд и запустить сборку на iOS. Profit! :D
На этом в принципе всё, основные моменты вроде рассказал, в следующей части мы расскажем про поддержку игры после релиза, какие пиар-акции проводились, и что это всё итоге дало, плюс расскажем про монетизацию.
