Javascript разработка для android

Как я разработал мобильную игру на Android с использованием React.js и выложил её в Google Play Store

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

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

Скриншот готовой игры

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

Предыстория

Добрый день, уважаемые читатели. Конечно же мы с Вами не знакомы, однако если бы были, то Вы бы знали, что ещё с раннего детства после приобретения отцом персонального компьютера у меня была мечта стать разработчиком игр, что в дошкольном возрасте выражалось в «создании» платформеров мелом на асфальте для ребят во дворе, а в школьном — отдельными играми в тетрадках, в том числе и во время уроков.

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

Построение и прорисовка мира

Сперва было принято решение создать изометрический мир, который мог бы поддерживать бесконечную прокрутку по горизонтали. После тщательного изучения статей на тему «Как создавать изометрические миры» и им подобных, а также просмотра библиотек для JavaScript и React, которые якобы должны помогать выполнять данную задачу, дело перешло к практике.

Времени на это было потрачено немало и готовых подходящих решений так и не было найдено. Ну что ж, напишем своё. По сути весь наш мир это набор квадратиков-тайлов, которые находятся рядом друг с другом и на соседний квадратик можно перейти в восьми направлениях.

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

Сперва отрисуем ячейки мира построчно. Пускай они будут размером 64×64 пикселя. Далее развернём наш контейнер таким образом, чтобы он выглядел изометрично:

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

Для увеличения производительности нам необходимо перерисовывать только те ячейки карты, которые сейчас являются видимыми на экране. Для этого был использован компонент FixedSizeGrid из модифицированной версии библиотеки react-window с учетом нашего поворота и расположений ячеек, код которого здесь приводить не буду. Из того, что не получилось — это сделать бесконечную прокрутку мира. После изучений исходного различных библиотек для бесконечного скролла / слайдеров и тп. подходящего решения найдено не было. Что ж, значит наш мир будет с границами по всем бокам.

Графика

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

Игра до поиска графических элементов

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

Локализация

Игра поддерживает 4 языка и, если честно, мне непонятно, зачем в несложных приложениях разработчики подключают массивные библиотеки типа react-i18next . Давайте напишем похожее кастомное решение, которое уместится в чуть более чем 100 строк с учетом красивой разметки кода, а также будет поддерживать определение языка девайса пользователя, переключение языков в реальном времени и сохранение последнего выбора пользователя. Здесь используется redux , однако данный код можно адаптировать и под другие реактивные хранилища. Да, здесь нет некоторых фишек больших библиотек типа поддержки переменных в строках, однако в таком проекте нам это и не нужно. И да, эту библиотеку можно использовать как легковесную замену react-i18next (или подобным) в уже существующем проекте.

Мультиплеер

Игра поддерживает мультиплеер в реальном времени для устройств с Android 9 или выше (возможно, будет работать и на 8-м, однако данное предположение не проверялось) с рейтингом и таблицей лидеров.

Сам движок не поддерживает ходы в реальном времени, потому многопользовательский режим построен таким образом, что все события происходят в один и тот же ход, в это же время существуют кулдауны на определенные действия, которые реализованы через requestAnimationFrame . На Android 7 и ранее такой подход почему-то просто-напросто не работает.

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

Стандартная имплементация Lobby из библиотеки движка мне не подходила, так как она открывала ещё одно новое websocket-подключение на каждый инстанс игры, но мне также нужно было передавать данные пользователя и таблицу лидеров по своему уже существующему websocket-подключению, потому, чтобы не плодить подключения, здесь снова было использовано собственное решение на основе библиотеки primus . На стороне клиента подключение хендлится сбилдженной библиотекой от примуса, которое также выложил на npm с именем primus-client . Вы можете сами сбилдить себе подобную клиентскую библиотеку для определенной версии примуса через функцию save на стороне сервера.

Видео геймплея многопользовательского режима можно наблюдать ниже:

Звук и музыка

В игре присутствует несколько звуков — старта игры, атаки и победы. Для проигрывания звука — также кастомная библиотека (для музыки — схожий подход):

Окно настроек игры

Сборка проекта

Сборка web-части осуществляется вебпаком. Однако тут нужно учитывать особенности путей к файлам, ведь в процессе разработке на локалхосте или на сервере в продакшене они являются относительными корня домена, а для приложения в Cordova наши файлы будут размещены по протоколу file:// и потому после сборки нам необходимо провести некоторые преобразования, а именно:

Итоги

Приложение разрабатывалось в течении года, находится в Google Play Store с середины сентября, а значит уже прошло три месяца. Общее количество установок — 46, из которых ещё непонятно, сколько там на самом деле настоящих людей. Если коротко, то это провал. Однако был приобретен первичный опыт как разработки игр, так и мобильных приложений.

Из того, что было задумано, но не получилось:

Более сложный геймплей

Бесконечная прокрутка карты по горизонтали

Продвинутый ИИ компьютера

Поддержка мультиплеера на всех устройствах

Можно потыкать?

P.S. Отдельное спасибо музыканту Anton Zvarych за предоставленную фоновую музыку.

Дальнейшие планы

Сейчас понятно, что подобные игры мало кому интересны, так что в прогрессе изучение Unity, и возможно через некоторое время появится ещё одна игра в жанре tactical rts.

Update: игра на Unity под названием Special Tactics RTS появилась и находится в стадии alpha.

Источник

JavaScript to APK. Подводные камни разработки под Android для тех, кого задолбал PhoneGap. Построение мостов из Java в JavaScript

Я люблю игры на JavaScript и стараюсь сделать их код пуленепробиваемыми для портирования на все платформы. Полгода назад я уже писал о сборке Android приложений и сегодня хотел бы раскрыть тему более подробно.

Сразу предупрежу, что мне пришлось отказаться от PhoneGap, т.к. опыт использования его в двух проектах меня огорчил. Он отлично справляется с «Hello World» приложениями, но при конвейерной сборке всего подряд всплывают нюансы.

Почему PhoneGap не пошел:
1. Он изначально пустой. Постоянно приходится подключать все новые и новые модули.
2. Многие модули написаны криво. Они либо берут много лишнего, либо ведут себя неожиданно. Например, из двух модулей под Android для отправки SMS, один не работал, второй — отправлял true при любых условиях.
3. Не решены элементарные вещи, вроде получения EMEI телефона. Нужно постоянно допиливать.

Я так и не понял сути PhoneGap. Изначально ожидал одну кнопку «сделать хорошо», а не деле он ничего не делает. Под каждую платформу мне все равно надо ставить SDK. Под каждую задачу — искать и ставить модуль. Сами модули тоже ограничены. Они могут делать что-то только под часть платформ, а если нужно под другие — то приходится снова искать модули, которые смогу сделать это на других девайсах. Много мусора и ненужных вещей, а ведь хочется собирать билды с минимумом затрат. Все эти факторы заставляют писать нативно. И вот тут начинают вылезать подводные камни.

Почему CocoonJS не пошел:
С CocoonJS работал мало, поэтому никаких особых вопросов не возникло. Билды с canvas действительно работают быстрее. Но в общем — смысла работать с CocoonJS не увидел, т.к. он платный.

Что касается сборки под другие платформы и прочие нюансы — про это будет отдельная статья, и дальнейшее обсуждение по этой теме или теме PhoneGap выходит за рамки этой.

Перейдем к сути

Для начала начнем с основы — WebView с запущенной HTML страничкой на весь экран. В onCreate MainActivity пишем:

Все спорные ситуации будем решать в Java. Помните, пишите вы для Bada или SmartTV — всегда есть какой-то стандартный функционал, который позволяет кидать мосты в JavaScript. В нашем случае для Android`а мы кинули экземпляр класса WebAppInterface, а сам класс будет выглядеть так:

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

Если у вас возникла необходимость из Java сообщить JavaScript`у какое-либо событие на ровном месте, самый простой способ достучаться до него — это стучать в URL:

Подводный камень: В Android`ах > 4 от Samsung`а при тач-событии DOM элементы могут подсвечиваться синим цветом.

Обратите внимание на этот нюанс. Типичная «защита» вам не поможет:

Чтобы обойти багу, надо добавить:

Но это не всегда решает проблему. Возможно, на проблему влияет сама верстка. Например, возьмем два приложения: Судоку и Тест. В судоку доска сверстана таблицей, и для таблицы такое решение помогло. В Тесте же кнопки это. Вроде бы все по стандартам семантики HTML5, и все должно быть более чем прекрасно, но на деле приходиться добивать таким CSS комбо:

Так же заметил, что синее выделение не появляется, если тач-событие пришлось точно на текст кнопки (текст при этом должен быть очень большим).

Источник

12 часов в шкуре Android разработчика глазами JS разработчика

Все началось с Kotlin. Случайно попалась статья про новый язык, что на нем можно писать под Android. Соприкоснувшись с темой, узнал что изначально приложения под Android пишутся на JAVA. Решил узнать на сколько трудоемко писать приложения под Android, в чем преимущества платформы на практике. Ведь по сути приложения JS и приложения Android выполняют одну и туже функцию. Заодно решил провести эксперимент. Что можно сделать за 12 часов, не зная что такое JAVA и тонкости разработки под Android, используя как помощник только Google. Пришла идея, которую развил в постановку задачи.

Постановка задачи

Взять из внешнего сервиса список всех Аэропортов мира и по коду Аэропорта получить от внешнего сервиса он-лайн табло с информацией о статусах рейсов. В 100% приложений, которые лежат в google play и реализуют такую функцию, нужно проходить цепочку действий, искать внутри приложения. Я лично, не нашел агрегатор, который позволял бы на первой странице ввести любой Аэропорт и получить его он-лайн табло. Идея и приложение само по себе простое, но это функция которой пользуется любой кто совершает перелет. Доступ к такой информации должен быть мгновенным.

Нашел потрясающий сервис, который открывает много возможности в части разработки под Авиацию. developer.flightstats.com Зарегистрировался получил на месяц бесплатный аккаунт.

Действовал интуитивно, полагаясь на свой опыт разработки в JavaScript. Набросал скетчи экранов в Photoshop. Составил требования к приложению.

Форма «Поиск»

Форма «Результат»

• Вывод данных в виде таблицы
• Сортировка по времени Прилет\Вылет

Разработка

Дальше был Я, Google и Android Studio.

Из опыта понимаю что код нужно организовывать. Интуитивно определил структуру проекта. Выделил следующие группы(Models, Stores, Views, Fields, API, Adapters) Двигало мной в этот момент бессознательное, вернее опыт. Дальше начал развлекаться с Layouts. Android Studio очень интуитивный редактор, это одна из причин которая подвигла попробовать написать Android приложение. Если kind of intellij idea – значит все комфортно. Плюс редактор лежит в бесплатном доступе, никаких ограничений, развивается и обновляется регулярно. Layouts сложились на раз два. Ни одного глюка за весь период работы, все на своих местах.

Момент который меня насторожил в самом начале, в 90% источниках, поиск и работа ведется по ID компонента. Обще принято, работа с ID это bad practice, в Android оказалось нормальной практикой. Погуглил, одно из лекарств DataBinding, отличная вещь, позволяет уйти от findViewById. Но, принцип в начальной стадии и еще год назад связь работала в одну сторону. Звучит странно, DataBinding но в одну сторону. Нужно было писать свою реализацию чтобы DataBinding был полноценный. Опираясь на реализации в JS, удивил концепт, который на текущий момент предлагает Data Binding Library(можно увидеть в большинстве случаев в сети), в ViewModel размещается логика по обработке handlers от визуальных компонент, которые в свою очередь могут иметь прямой доступ к данным которые лежат в ViewModel. С виду какой то гибрид контроллера и ViewModel.

Далее пошли вопросы коммуникации, то что нагуглилось с первого раза повергло в шок. Чтобы сделать обычный AJAX запрос нужно было тянуть строк 70 кода. Создавать фоновый процесс и там уже творить магию соединения, а потом через буфер собирать ответ. «Не может быть, чтобы было так сложно!» и продолжил поиск. В одном из результатов попалась статья про Retrofit2. С Retrofit стало все веселее и в целом жить можно в части коммуникаций. Определился с интерфейсами взаимодействия с сервером и начал сопрягать данные с визуальными компонентами.

С фильтром spinner(он же combobox) пришлось повозиться, возможно из-за неопытности. По ходу возникала куча вопросов от конвертации одного типа в другой до как реализован ООП в JAVA, но все элементарно находилось в stack overflow с ответами и примерами, плюс интуиция. В целом все шло как по маслу, кроме некоторых моментов. Чего не ожидал, что получу головную боль с датой. Почему то JAVA(или может быть это у меня так вышло) по defaul выдавала все в UTC.

В целом каких то совсем непреодолимых моментов не было из-за которых возникал полный стопор. Что не понял(зачем это сделали как dafault поведение?!) При изменении ориентации экрана(или конфигурации), ваша View которая присутствует на экране уничтожается и в новом повернутом экране заново пересоздается(фоном идет масштабная работа). Что порождает головную боль если у Вас в классе View(она же «Активность») есть динамические данные, они просто теряются при уничтожении View и с этим что-то надо делать. Дайте эту возможность, но опционально, для тех кто хочет подменять экраны при повороте. Интересно услышать мнение Android разработчика по этому поводу, возможно я не вижу всей картинки в целом.

Awesome

Потрясла производительность интерфейсов при большой нагрузке. Для теста сделал 8 spinner, в каждый забросил 4000 записей(в каждой записи еще набор свойств) и приложение даже не крякнуло. При такой ситуации, JS приложение напряглось бы, и если бы еще нужно было отображать все записи сразу, и иметь доступ работы с ними, то большая вероятность поймать зависание экрана или вообще «Опаньки». Пришлось бы тащить буферизацию вывода или решать как то алгоритмически. Но есть задачи когда нужен весь объем и сразу.

Многопоточность и фоновые процессы, на лету. Что в JS нужно можно делать с помощью webworkers, но там свои трудности, которые при разработке под Android решаются на раз, два. Причем фоном можно тягать действительно весомые объемы. Это огромное value для разработки off line приложений с сложными инженерными расчетами.

Приложение под браузер имеет свой потолок по производительности, если речь идет о высоко нагруженных интерфейсах(вывод одновременно большого объема данных) или когда фоном нужно делать объемные вычисления. Здесь перед Android приложениями снимаю шляпу. Но если Вам нужно делать что-то средне статистическое, то javascript возьмет свое скоростью разработки.

Резюме

Признаю, трудоемко писать под Android и требует в разы больше времени чем написание приложений на JS, но google интенсивно развивает и наращивает платформу. Неделя сидения за книгами и теорией Android разработки скорее всего убило бы идею попробовать сделать Android приложение и не дала бы навыков и опыта полученного за эти 12 часов. Реально столкнуться с проблемами и увидеть мир изнутри, получить первую оценку возможностей Android приложений и в будущем, столкнувшись с задачами трудно реализуемыми в JS, иметь в запасе знания куда можно еще бросить свой взгляд. Практика — быстрый путь к достижению навыков и опыта.

Что получилось: Android-приложение для просмотра он-лайн табло любого аэропорта мира.

Источник