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

• Стоит ли использовать jQuery?

• Стоит ли вообще разрабатывать мобильные игры на JS с нуля?

Итак, прежде чем начать говорить о разработке, следует немного рассказать следующее:

• Как вообще появилась идея разработки мобильной игры?

• Почему были выбраны эти инструменты для разработки?

• Почему не стоит делать так же?

С чего все началось?

Учебный год в университете подходил к концу, студенты закрывали сессии и долги, а также думали о том, как бы пополнить портфолио и подать на стипендию. Я не был исключением и как раз смог устроиться в один международный проект. Работа заключалась в верстке сайта, переносе и настройке его под WordPress.

К сожалению, одного проекта было недостаточно и как раз проводился международный конкурс. Это был шанс получить ценный опыт и возможность занять призовое место. Номинации были в различных сферах: машинное обучение, 1С, мобильная разработка, Big Data и др. Из всех конкурсов был выбран конкурс «веб-дизайн». Необходимо было продумать и разработать два макета по заданным требованиям, один для мобильных устройств и один для десктопа. Мои товарищи и одногруппники выразили желание поучаствовать в конкурсе и вместе мы записались на конкурс «мобильная разработка». Сначала я пытался везде успеть, но, к сожалению, успеть везде было крайне сложно и в итоге было принято решение сделать упор на командном конкурсе по мобильной разработке. Команда была крайне ответственной и поэтому собраться и поработать не составляло проблем, однако возникла другая проблема: все мы работали с разными технологиями. В итоге у нас была команда из Java, Python и JS-разработчиков. Причем каждый из нас только постигал инструменты и был в состоянии поиска себя как программиста. Я бы сказал, что наш уровень был «Junior--» ????.

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

Далее наша команда занялась проектированием и распределила задачи по важности:

Затем дорисовали ресурсы, сделали рамки и поделили их по качеству:

В итоге получилось 70+ зелий и 150+ ресурсов. Мы продумали для зелий схемы смешивания, после чего занялись интерфейсом. Особо опыта ни у кого не было, но мы постарались как могли, и в итоге был получен следующий дизайн:

Выбор инструментов разработки

Итак, пришло время обсудить инструменты для разработки. Изначально было много всяких вариантов – Gdevelop, Construct, PixiJS, PhaserJS и т.п. Оставалось всего две недели, мы посмотрели некоторые из вышеописанных библиотек и пришли к выводу, что разбираться с ними времени нет. Нам нужен был полный контроль и возможность реализовать всё так, как было в разработанном нами дизайне, потому придумывать ничего не стали и решили использовать старый добрый JavaScript. Приложение достаточно простое, поэтому мы решили сделать его в виде сайта, то есть использовать HTML и CSS для верстки, JS для написания логики, а также Apache Cordova для того, чтобы упаковать всё в apk-файл. С продукцией Apple никто особо знаком не был, потому лезть туда даже не стали. Также подключили Firebase для хранения данных пользователей и jQuery, чтобы было удобнее делать всякие всплывашки, переходы и т.п. В итоге стек был следующий:

• HTML, CSS – верстка;

• JavaScript – логика приложения;

• jQuery – придание интерактивности интерфейсу;

• Firebase – БД для хранения данных пользователя;

• Apache Cordova – система сборки итогового APK-файла.

Стоит ли использовать jQuery?

Для некоторых это, возможно, спорный вопрос, но для меня ответ очевиден: нет, не стоит. Конечно, если вы поддерживаете старый проект с jQuery, то, само собой, не стоит все переписывать на JS. Однако если вы разрабатываете проекты с нуля, то стоит задуматься об использовании нативного JS. Во-первых, вы будете больше практиковаться и чувствовать себя комфортнее, если вам нужно будет дорабатывать проекты на нативном JS, во-вторых, если jQuery «умрет», то с JS такое вряд ли случится, поэтому с навыками JS вы сможете при надобности быстро изучить любую библиотеку. Этот ответ может показаться очевидным, однако я до сих пор замечаю, как люди используют данную библиотеку, при этом отказываясь изучать JS. При этом изучать нужно в первую очередь именно JS, потому что все библиотеки написаны на нем, и если знать сам язык, то разобраться в новой для себя библиотеке никогда не составит труда.

Процесс разработки

Вот и добрались до разработки, в этом разделе будет показан программный код и почему (с точки зрения автора) он был написан именно так. На верстке и стилях останавливаться не будем и перейдем сразу к главному и единственному файлу с логикой игры. Прежде чем запускать весь код, необходимо было проверить, что устройство готово и Cordova полностью загрузилась. Для этого Apache Cordova предоставляет событие «deviceready»:

document.addEventListener("deviceready", function () { /* остальной код */ });

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

document.addEventListener("pause", saveGame, false);

var storage = window.localStorage;

var firebaseConfig = {
	// подключение к firebase
}
firebase.initializeApp(firebaseConfig);

Как видно, при событии «pause» вызывается функция «saveGame». Данная функция отвечает за сохранение данных в Local Storage. Событие «pause» предоставляет Cordova, и срабатывает оно в момент сворачивания приложения, а точнее, когда приложения переходит в фоновый режим. Далее рассмотрим главный объект «gameState» со всеми параметрами:

let gameState = {
      crystal: 0, // донатная валюта
      money: 0, // основная валюта
      currentStamina: 10, // текущая выносливость
      maxStamina: 10, // максимальная выносливость
      rechargeStaminaTime: 60, // время восстановления ед. выносливости
      exitGameTime: Math.round(Date.now() / 1000), // время выхода из игры
      inventorySize: 0, // текущая заполненность инвентаря
      maxInventorySize: 20, // максимальное количество ячеек в инвентаре
      inventory: [], // инвентарь
      recipes: [], // открытиые рецепты зелий
      recipesMax: 0, // максимальное количество рецептов
      storeItems: [], // предметы в магазине
      books: {
        common: true, // книга зелий (обычная)
        rare: false, // книга зелий (редкая)
        mythical: false, // книга зелий (мифическая)
        legendary: false, // книга зелий (легендарная)
      },
      booksDesc: [
        // Описание и параметры книг
        {
          id: "rare-scroll",
          name: "Редкий свиток",
          cost: 2500,
          category: ["rare", "редкое"],
          isBuy: false,
        },
        {
          id: "mythical-scroll",
          name: "Превосходный свиток",
          cost: 5000,
          category: ["mythical", "превосходное"],
          isBuy: false,
        },
        {
          id: "legendary-scroll",
          name: "Легендарный свиток",
          cost: 7500,
          category: ["legendary", "легендарное"],
          isBuy: false,
        },
      ],
      search_area: [
        // зоны поиска ресурсов и параметры затрат энергии и времени
        {
          id: "forest_area",
          stamina: 1,
          time: 15,
        },
        {
          id: "grot_area",
          stamina: 2,
          time: 15,
        },
        {
          id: "ruin_area",
          stamina: 3,
          time: 15,
        },
      ],
      chestPrice: {
        // сундуки и стоимость
        chestGold: 15,
        chestCrystall: 1,
      },
      donat: [
        // донатные предметы
        {
          id: "plus_item",
          name: "Зелье выпадения вещей",
          desc: "Увеличивает на 1 количество выпадаемых предметов (макс 3).",
          count: 1, // бонус предмета
          cost: 2, // стоимость
          buyCount: 0, // количество купленных
        },
        {
          id: "plus_percent",
          name: "Зелье увеличения шанса",
          desc: "Увеличивает шанс выпадения более редких предметов на 10% (макс 5)",
          count: 0.1,
          cost: 2,
          buyCount: 0,
        },
        {
          id: "plus_stamina",
          name: "Зелье восстановления",
          desc: "Восстанавливает 10 ед энергии",
          count: 10,
          cost: 2,
          buyCount: 0,
        },
        {
          id: "plus_inventory",
          name: "Увеличение рюкзака",
          desc: "Увеличивает вместимость инвентаря на 5 (макс увеличений 10)",
          count: 5,
          cost: 2,
          costGold: 400,
          buyCount: 0,
        },
      ],
      maxItemDrop: 2, // количество стака выпадаемых предметов
      maxItemStack: 5, // количество максимальных стаков в инвентаре
      itemDropCount: 2, // количество выпадаемых вещей
      chestItemDrop: 1, // количество выпадаемых вещей из сундука
      percentItemDrop: [
        // параметры для рассчеты шансов выпадения вещей
        {
          name: "common",
          dropChance: 0.65,
        },
        {
          name: "rare",
          dropChance: 0.15,
        },
        {
          name: "mythical",
          dropChance: 0.07,
        },
        {
          name: "legendary",
          dropChance: 0.005,
        },
      ],
      percentItemDropMulti: [
        // множитель шанса для локации и сундуков
        {
          id: "forest_area",
          multi: 1,
        },
        {
          id: "grot_area",
          multi: 1.3,
        },
        {
          id: "ruin_area",
          multi: 1.7,
        },
        {
          id: "chestGold",
          multi: 1.25,
        },
        {
          id: "chestCrystall",
          multi: 2,
        },
      ]
}

Тут должно быть все более-менее понятно, а вот дальше уже пойдут страшные вещи.

Рассмотрим методы объекта «gameState». Честно говоря, я не помню логическую последовательность созданных методов ????, поэтому пойдем сверху вниз.

Первый метод реализует продажу предметов:

sellItem(itemID, count) {
  let elem = this.inventory.find((el) => el.id == itemID);

  if (elem.count >= count) {
    elem.count -= count;
    this.money += elem.sell * count;
    $(".money").find("span").text(this.money);
    this.updateInventory();
  }
}

Данный метод получает id предмета и его количество (подразумевается, что можно продать как 1 ед., так и всё сразу). В игре это выглядело следующим образом:

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

Если с методом по «продаже» все понятно, то вот о методе «покупки» такого не скажешь:

buyItem(itemID, num) {
  let fItem = itemPack[itemID];
  let item = { ...fItem, count: num };
  let elem = this.inventory.find((i) => i.id == item.id);
  if (gameState.money >= item.buy) {
    if (elem && this.inventorySize <= this.maxInventorySize) {
      elem.count += item.count;
      this.updateInventory();
      if (this.inventorySize > this.maxInventorySize) {
        elem.count -= item.count;
        gameState.showMsg("Инвентарь полон!", "warning");
      } else {
        this.money -= item.buy * num;
        $(".money").find("span").text(this.money);
        gameState.showMsg("Товар добавлен в рюкзак!", "success");
        if (elem.count % 5 == 0) {
          $("#bag").append(`
                      <div>
                          <span class="count">${item.count}</span>
                          <img src="./img/source/${item.category[0]}/${item.id}.png"
                          alt="${item.name}">
                      </div>
                      `);
        } else {
          $("#bag")
            .find("img")
            .each(function (i, e) {
              let key = e.src.split("/");
              let k = key[key.length - 1].split(".")[0];
              if (k == elem.id) {
                $(this)
                  .parent()
                  .find("span")
                  .removeClass("hidden")
                  .text(elem.count);
              }
            });
        }
      }
    } else if (this.inventorySize < this.maxInventorySize) {
      this.inventory.push(item);
      this.money -= item.buy * num;
      $(".money").find("span").text(this.money);
      $("#bag").append(`
              <div>
                  <span class="count">${item.count}</span>
                  <img src="./img/source/${item.category[0]}/${item.id}.png" 
                  alt="${item.name}">
              </div>
          `);
      gameState.showMsg("Товар добавлен в рюкзак!", "suссess");
    } else {
      gameState.showMsg("Инвентарь полон!", "warning");
    }
  } else {
    gameState.showMsg("Недостаточно средств!", "warning");
  }

  this.updateInventory();
}

Первое, что бросается в глаза внимательному читателю – а что за itemPack? На самом деле я тоже сначала не мог понять ????. Как оказалось, на 934 строке была загрузка предметов из базы:

let itemPack = "";
let recMax = 0;

function loadItems() {
  firebase
    .database()
    .ref("ingridients")
    .once("value")
    .then((snapshot) => {
      itemPack = snapshot.val();
      for (key in itemPack) {
        itemPack[key].components ? recMax++ : "";
      }
      gameState.recipesMax = recMax;
    });
}
loadItems();

Догадаться разделить зелья и ингредиенты по отдельным таблицам было невероятно сложно (сарказм ????), и потому есть странный цикл, который подсчитывает, что из всего лежащего является зельем (если есть свойство components у элемента, то это зелье) Странно, никто даже не додумался ввести поле «тип» и дальше по нему определять тип предмета (ингредиент/зелье). Количество рецептов («recMax») мы подсчитывали для того, чтобы отобразить сколько всего зелий можно открыть:

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

Вернемся к методу «buyItem», с «fItem» все понятно: достаем элемент из общего массива предметов, далее создаем новый объект item с дополнительным свойством count для того, чтобы туда можно было записать количество предмета (они могут объединяться в пачку). Далее нужно найти элемент в инвентаре, чтобы объединить предметы в одну пачку, если предмет уже есть. Ух, перейдем к условиям:

1. В первом условии проверяем, хватает ли денег, и если не хватает, то показываем сообщение с ошибкой.

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

3. Далее проверяем, кратно ли количество элементов в пачке пяти, если да, то закидываем сгенерированный HTML в инвентарь, если нет, то ищем все изображения внутри инвентаря, а затем берем номер изображения и сравниваем с id элемента, после чего у span удаляем класс hidden, который скрывал количество предметов:

Не спрашивайте, почему всё так плохо, я и сам сейчас не понимаю ????. Ну, и заключительное условие уже просто проверяет есть ли место в инвентаре и если есть, то добавляет предмет.

Чтобы вы понимали масштабы, мы рассмотрели только 200 строк кода, а дальше еще чуть больше 1000 строк кода такого же формата, где-то лучше, где-то даже хуже.

В итоге за 2 недели мы достигли следующего результата:

Заключение

В данной статье я постарался показать вам, насколько все плохо внутри и якобы хорошо снаружи можно сделать. Если вы помните, то проект создавался для конкурса, в котором участвовало 140 команд. Чтобы пройти отборочный этап, нужно было попасть в топ-30 команд. И как вы думаете, смогли мы попасть в топ-50 или хотя бы в топ-100? Конечно ????, смогли, и, более того, мы были на 27 месте по результатам отборочных испытаний. К сожалению, доработать проект было уже нельзя, поэтому мы сосредоточили свои силы на презентации и выступлении. По итогам финала мы были на 9 месте, и это с учетом того, что все, кто был выше нас, либо уже зарабатывали на своих приложениях, либо имели хорошие возможности для заработка. Конечно же, на это повлияло множество факторов: выступление, презентация, внешний вид конечного продукта. Если оценивать только код, то, конечно, мы и не поднялись бы дальше 100го места.

Ну, и в заключение отвечу на вопрос: стоит ли вообще разрабатывать мобильные игры с нуля?

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

1. Определите размер и сложность своей игры. Если вы хотите сделать 2D/3D RPG с большим количеством динамики, анимации и т.п., при этом вы знаете, скажем, только один язык программирования, то следует поискать и изучить инструменты для создания игр, анимации на этом языке.

2. Продумайте структуру проекта. Если вы решили использовать JS, то сразу продумайте структуру, разделите все на компоненты, вынесите логику и отрисовку в отдельные файлы. Не жалейте на это времени, в дальнейшем вы будете себе благодарны, и, вернувшись к проекту через какое-то время, вы не будете тратить недели, чтобы понять, что и как там происходит.

3. Займитесь планированием. Потратьте время на планирование проекта, в противном случае вам придется додумывать на ходу, а это всегда плохо. И настанет момент, когда это «додумывание» превратится в «ладно, пусть будет пока так, а потом додумаю» (знакомо, да?! ????).

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

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

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

Разрабатывайте, господа, разрабатывайте чаще!