FlatArt

Если ты начинающий инди-разработчик, или хочешь узнать о тестировании игр, то эта статья тебе понравится!

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

ТЕСТ-ДИЗАЙН

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

QA-ШАОЛИНЬ

Классы эквивалентности и граничные условия. Это наиболее популярные техники, которые могут применяться одновременно.
Перед тем, как начну подробнее рассказывать про техники, хочу подчеркнуть один очень важный момент. Полностью проверить каждый чих в игре - невозможно. Точнее возможно, но это может занять не один год, а нам ведь нужно уже "вчера" выпустить игру в стор. Правильно? Вот тут нам и приходит на помощь классы эквивалентности и граничные. Они помогают тестеру и инди-разработчику минимизировать количество тестов, чтобы уложиться в адекватные сроки и не пропустить серьезных багов.
Я думаю, что с граничными условиями всё понятно, их я затрагивал в предудщих статьях. А вот, как пользоваться техникой классов эквивалентности, сейчас расскажу:
* определи объект, который хочешь протестировать;
* подумай или посмотри (если тесты у тебя уже есть), какие тесты применимы к этому объекту;
* посмотри, какие из этой массы тестов эквивалентны, т.е. проверяют одно и тоже и скомпонуй их;

* после  разделение на классы, нужно выбрать по одному представителю, от каждого класса, и протестировать его.
Записал? Теперь давай разберем пример, чтобы понять, что это только что было. 

Пример. Допустим, мы тестим шутер от первого лица. Нам нужно протестировать взаимодействие пули с врагами. Обычно в шутерах тело врага разделено на зоны (голова, туловище, ноги) при попадании в которые наносится разный урон. Это тоже нужно учесть при тесте и желательно уточнить у разработки где находятся эти зоны.
Итак, врагов у нас целая орда. Какие наши действия? Нет, шмалять во всех мы не будем, хоть это и весело.
1) Для начала поделим врагов на классы, как это сделал гейм-дизайнер. Например: Бандит, Мародер, Джаггернаут, Снайпер.
2) Затем найдем одного представителя из каждого класса, и вот теперь уже шмальнем по нему.
2.1) Выстрелим сперва в самый низ ботинка (нижняя граница зоны ног);
2.2) Затем, выстрелим ему прям в ладошку. Можно еще в пряжку ремня (Стык зон туловища и ног);
2.3) Еще дышит? Выстрелим наглецу в шею (Стык зон туловища и головы);
2.4) Ну и контрольный, в самую макушку (Верхняя граница головы);
3) Записать результаты тестирования.

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

Следующая техника - это предугадывание ошибок или тестирование на основе опыта.

Тут всё строится на выявлении особенностей игры и составлении списка потенциальных багов. Например:
1) Многие тестировщики знают, что при подборе аптечек есть вероятность столкнутся с ошибками в игровой логике. Т.е. мы подобрали аптечку, у нас фактически увеличились очки жизни, но на панели здоровья количество очков осталось прежним, или на панели изменилось, а в информации о персонаже нет (если мы тестируем РПГ, к примеру).
2) Анализ спецификации (требований). Т.е. тестировщик, читая требования и основываясь на своем опыте, может предположить, в каких местах разработка вероятнее всего допустит ошибку.
3) Чтение исходного кода. Если комментарии написаны невнятно, или код написан кривовато, то с большой вероятностью, в этом месте вылезут баги. (Этот пункт инди-разработчики делают на автомате. Написал строчку / цикл - проверил).
4) Наблюдение "симптомов" ошибки. Т.е. если моб респаунится в тексутре, то это уже сам по себе баг, т.к. игрок не сможет его убить, но если он респнется в текстуре много раз, то это может привести к снижению производительности игры (к примеру если у нас ММО)

Итак! Предугадывать ошибки можно двумя способами:

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

* Предугадывание ошибок методом "туров". Когда проверки ошибок выстраиваются определенным образом в виде "тура". Под туром понимается упорядоченный список объектов или их состояний, который нужно проверить, исходя из имеющейся информации. Для аналогии можно привести незнакомый город, в который вы прибыли туристом и хотите посетить только достопримечательности, а не блуждать по всем закоулкам.
Спроектировать набор хороших туров не просто. Нужно уметь анализировать игру и требования к ней. Однако в совокупности с опытом тестера, этот метод становится очень эффективным оружием в борьбе с багами. 

Эй, если ты поехал в Москву и посетил только Кремль, это не значит, что в городе нет больше ничего интересного! Туры бывают разные, вот их классификация. Подробнее о ней можно прочитать в книге Джеймса Витаккера "Exploratory Software Testing" (если ты тоже читаешь книжки про тестирование, можешь написать их название в комментариях):

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

1.2) Денежный тур. В данном методе тестируются основные фичи и внутриигровые объекты, которые активно рекламируются и за которые игрок готов выложить деньги.
1.3) Внеурочный тур. Если игрок свернул/закрыл игру, это еще не означает, что оно прекратило свою работу. Игра может сохранять данные, получать обновление. Суть тура в том, чтобы проверить эти операции.
2) Туры по историческим районам. Исторические районы игры - это старый функционал, унаследованный код или исправление старых багов. Разделяются на:
2.1) Тур по нерекомендуемым местам. Это как зайти в гоп-стоп райончик. Нерекомендуемые места в игре - это места, где часто скапливаются баги. После того, как баги были исправлены, необходимо еще раз пройтись по этому месту.
  2.2) Музейный тур. Это проверка "музейного" кода. Т.е. кода, который давно не менялся. При переносе игры на новую среду, этот участок кода может не работать и ронять нашу игру.  2.3) Тур предыдущей версии. Применяется, когда вырезается какой-то функционал, меняется интерфейс или устраняется баг, который игроки использовали, как фичу.
3) Туры по развлекательным районам. Обычно туристы приходят в развлекательный район, чтобы отдохнуть, а не ради достопримечательностей. В большинстве игр имеются функции, не представляющие значения для бизнеса, но являющиеся приятным дополнением к основному функционалу. Например, функции, позволяющие настроить игру «под себя» или позволяющие «навести красоту»: персонализация, изменение стиля персонажа, иконок и пр. Таким образом, развлекательные туры проверяют второстепенные функции, и то, насколько они правильно и гармонично сочетаются с основными. Разделяются на:
3.1) Тур по тёмным переулкам. Это тур по фичас, которые не востребованы/мало востребованы игроками, т.к. приносят меньшую пользу или вызывают меньший интерес.  3.2) Тур любителя ночной жизни. В данном метода проверяются возможности работы игры без перезагрузки. А ты о чем подумал?
4) Туры по туристическим районам. Быстрый осмотр игры или основных фич. Разделяются на:
4.1) Тур супермодели. Этот тур о внешнем интерфейсе игры. На сколько он красив и привлекателен, насколько правильно используются цвета, нет ли лишних элементов интерфейса, насколько быстрая анимация, соответствует ли интерфейс стандартам и ожиданиям пользователя. Цель тура - сделать так, чтобы игра смотрелось великолепно, как супермодель на подиуме.  4.2.) Тур по шотландским пабам. Не всегда можно узнать об интересных местах из путеводителя. Иногда, для этого нужно заглянуть в паб. Форумы и блоги, в ним узнать много нового об игре. (В основном это касается крупных игр или игр с большой фан базой). Задача тура заключается не только в проверке игры, но и в том, чтобы получше с ней познакомиться, в идеале, путём общения с игроками.
5) Туры по району отелей. Проверяют второстепенный функционал игры. Разделяются на:
5.1) Тур, отмененный из-за дождя. В этом туре проверяется возможность отмены действия игрока всеми способами: кнопкой "отмена", Esc, Alt + F4, отмена каста заклинания движением персонажа вперед/назад/в стороны/прыжком, закрытием игры через диспетчер задач и т.д. При этом важно отметить, возвращается ли игра в начальное состояние, сохраняются ли данные, возможно ли повторить отмененное действие.  5.2) Тур домоседа. Проверка по принципу наименьшего сопротивления, т.е. выполнять в игре только обязательные задания, качать только обязательные характеристики и т.д.
6) Туры по неблагополучным районам (самый веселый). Проверка уязвимых мест в игре, которые часто используют недобросовестные игроки. Разделяются на:
6.1) Тур диверсанта. Тестировщик должен подорвать работу игры всеми возможными способами. Для этого нужно начать выполнить какое-то действие, определить ресурсы, необходимые игре для выполнения этого действия, удалить или ограничить доступ к этим ресурсам, повторить действие. Например, отключить интернет, ограничить размер оперативной памяти, удалить файл, который считывает игра, ограничить права на выполнение операции, запустить игру на проблемном окружении и т.д. Ограничивайся только своей фантазией!  6.2) Антисоциальный тур. В этом туре нужно делать с игрой то, что обычный пользователь не стал бы делать. Т.е. делай все то, что противоречит логике игры.  6.3) Тур невротика. Повторяй одни и те же действия в игре много и часто.

Если ты дочитал до этого моменты, то я тебя поздравляю! Теперь ты знаешь техники тест-дизайна: умеешь разбивать тесты на классы эквивалентности, проверять граничные условия и понял, как можно эффективно предугадывать ошибки. Надеюсь это поможет тебе в создании тестов, лично мне эти значения хорошо помогают в работе. В заключении, хочу перечислить характеристики, которыми должен обладать хороший, эффективный тест:
* Тест должен выявлять ошибки;
* Набор тестов не должен быть избыточным;

* Тест должен быть наилучшим в своей категории;
* Тест не должен быть слишком простым или сложным;

* Между тестами не должно быть зависимостей (серьезно, не надо).

Ну вот и все на сегодня. Спасибо что уделил мне свое время! Надеюсь тебе понравилась статья. В следующий раз мы начнем рассматривать виды тестирования. Возможно первым станет регрессионное тестирование.

До встречи! 

Если ты начинающий инди-разработчик, или хочешь узнать о тестировании игр, то эта статья тебе понравится!

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

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

ЦИКЛ ТЕСТИРОВАНИЯ ИГРЫ

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

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

АНАЛИЗ ТРЕБОВАНИЙ. На этом этапе выполняется тестирование требований и уточнение требований. "Как можно тестировать требования?" - спросишь ты. Да очень просто, нужно лишь смотреть, чтобы они отвечали следующим пунктам:

* Завершенность (чтобы не было фраз по типу: "и т.д.", "смотри выше");
* Атомарность (требование должно описывать только одну ситуацию, никаких: "когда игрок лутает врага и судук, или босса, должно открываться окно инвентаря"); 

* Непротиворечивость;

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

* Выполнимость;

* Обязательность (если требование не обязательно, так зачем оно вообще нужно? Явный признак необязательности, наличие пометок "на всякий случай" или же устаревшие требования); 

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

ПЛАНИРОВАНИЕ ТЕСТИРОВАНИЯ. На данном этапе определяются цели тестирования. Составляется тест-план (за частую он есть лишь в голове тестера). Определяется трудоемкость тестирования и составляется расписание, если это необходимо.

РАЗРАБОТКА ТЕСТОВ. Вот тут тебе и пригодятся навыки тест-дизайна и знания тестовых артефактов.

ВЫПОЛНЕНИЕ ТЕСТОВ. Ну тут всё понятно из названия. Плюсом будет лишь заведение баг-репортов в баг-трекер. Если ты инди, то тебе повезло, т.к. баг-репорты заводятся прямиком тебе в голову!

ОЦЕНКА РЕЗУЛЬТАТОВ. Составляется отчет и определяется состояние игры: "готово к релизу", "надо подправить", "что это было???".

КСТАТИ. Если ты хочешь быть настоящим львом в тестировании, то у тебя всегда должен быть особый настрой. Берясь за тестирование, ты должен внушить себе, что перед тобой настолько хреновая игра, что играть в нее просто невозможно. Ведь все мы ищем только то, что хотим. Если ты настроишь себя иначе, мол "Игра просто супер! Надо это лишь доказать", то ты нихрена не найдешь. Инди-разработчикам это бывает очень сложно сделать.

ТЕСТОВЫЕ АРТЕФАКТЫ

Итак, что же нужно, чтобы ловить и уничтожать баги?

(Я использую Excel для создания артефактов, если ты пользуешься другим софтом, то можешь написать об этом в комментариях)

Чек-листы. Это, по сути, список всех объектов и их состояний в игре, которые нужно проверить. Чек-лист нужно иметь даже идни-разработчику (хотя бы упрощенную версию). Зачем? Чтобы было понятнее, приведу аналогию с походом в магазин за покупками. Когда ты / твоя жена / мама предварительно пишет тебе список покупок, то зайдя в магазин, ты купишь всё что нужно. Если у тебя списка не будет, то ты купишь только то, о чем вспомнишь или что понравится.

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

Что должно включаться в тест-кейс (рекомендуемое):

* Номер теста (Нумерация должна быть уникальной, чтобы можно было потом сослаться на этот тест);

* Название (краткое описание);

* Предварительные условия (начальное состояние объекта);

* Шаги тестирования;

* Ожидаемый результат;

* Фактический результат;

* Постусловие (событие, которое возвращает игру в начальное состояние).

Вот пример. Предположим, что по логике игры можно иметь только одну казарму:

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

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

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

Если ты начинающий инди-разработчик, или хочешь узнать о тестировании игр, то эта статья тебе понравится!

Привет, дружище!
Не так давно, я поймал себя на мысли, что тематика тестирования игр, в т.ч. и инди-игр практически нигде не затрагивается. А ведь это очень важный аспект разработки любого проекта, даже самого простого. Что же, присаживайся поудобнее, сейчас мы с тобой немного поговорим о теории тестирования, и о ее применении в инди-проекте, чтобы твои крутые игры были еще круче!

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

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

Фантастические Баги и где они обитают

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

Ошибки пользовательского интерфейса. Где их можно встретить, понятно из названия, вот примеры характерные особенности:
* Имеются кнопки или игровые элементы (постройки, ресурсы, валюта), которые выполняют не те функции, которые от них требуются или же вообще не выполняют никаких функций (пустышки);

* Имеются кнопки или игровые элементы, которых вообще не должно быть;

* Синтаксические ошибки (Не все это любят, но писать нужно правильно); 

* Плохое расположение кнопок, диалоговых окон, информационных панелей (К примеру, когда работаешь с Unity и накосячил с иерархией объектов в Канвосе);

* Пропущенные команды. Игрок должен иметь возможность отменить действие или вернуться к предыдущему (К примеру отменить выбор здания для постройки);

* Низкая производительность. Интерфейс и картинки долго прогружаются. (Конечно, можно обвинить во всем железо игрока, но сперва нужно проверить код и по возможности его оптимизировать).

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

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

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

* Ввод логина длинной 51 символ, при допустимом количестве - 50 (в идеале, ничего не произойдет, а не в идеале, будет переполнение памяти, и возникновение новых "багов" в абсолютно разных местах);

* Откат способности происходит на 10 секунде. Что будет если активировать способность на 9, 10 и 11 секунде?

* 2D враг может двигаться по Y в диапозоне от -2 до 2, по X от -4 до 4. Что произойдет, если врага поместить в координату (Y:-2, X:-4) или за допустимый диапозон?

Уловили логику? Едем дальше!

Ошибки вычислений. Эти ошибки возникают там, где происходят расчеты, а именно - атака, лечение, таймеры / секундомеры, использование ресурсов:

* Выполнение умножения вместо деления;

* Неверные округления (например, когда при создании таймера использована неправильная формула округления);

* Возникновение отрицательных значений (например при получении урона, количество ОЖ получается отрицательным).

Ошибка управления потоком. Во сути это нарушение очередности выполнения функций.

* К примеру, главный герой получил урон и скопытился, а затем враг проиграл анимацию удара;

* Отображение изменений внутриигровой валюты при повторном заходе в игру или в меню магазина (частый баг, но не критичный. На Unity случается, когда забываешь воткнуть в функцию Update отображение валюты);

* Зависание игры, бесконечное получение или нанесение урона (случается, когда забываешь поставить условия выхода в бесконечных циклах. Например - получение урона при входе в огонь);

* Условия проверок пересекаются и противоречат друг другу.

Перегрузки. Название говорит само за себя:

* Перегрузка игровых серверов;

* Переполнение памяти (Явный признак - потеря выполненных действий);

Начальное и последующее состояние. Очень противные "Баги". За частую, они случаются только один раз, при запуске игры, и при последующих запусках выскакивать не будет. Особенность этой ошибки в том, что ее сложно воспроизвести, для этого требуется либо переустановка, либо регистрация нового пользователя. Таким страдают RTS и различные фермы. Вот пример "Бага", обнаруженного на одной из ферм:
* При активации нового производственного здания, появляется окно с обучением, после чего можно продолжать игру. Но если просто закрыть обучение не проходя его, и активировать это здание у друга, то получаешь ERROR'ом в лицо.

Ошибки тестирования. Не только разработка допускает ошибки, но и тестировщик. За частую, ошибки тестера указывают на несовершенство пользовательского интерфейса, но есть и такие, которые возникают из-за неверных тестовых данных.

А вот как их избежать, я расскажу в следующей статье. Которая будет посвящена тестовым артефактам и тест-дизайну!

 Любишь векторную графику, ретро-игры и космос? Тогда ты по адресу!

Just Don’t Die – это хардкорная аркада, в которой вы – космический рейнджер, вернувшийся в родную систему, после долгой экспедиции. Как оказалось, людей в ней больше нет. Их уничтожили Демонийцы – агрессивная и безбашенная цивилизация, жаждущая абсолютного господства.
Осознав, что являетесь последним человеком во Вселенной, вы были уже готовы направить свой корабль в сторону Солнца, но ваше возвращение не осталось незамеченным. Радары зафиксировали приближение огромной вражеской флотилии. Смерть неизбежна. Вы уже чувствуете её тяжелое дыхание за спиной. Так заберите с собой как можно больше врагов! В этом вам поможет ваш надежный корабль с полным боекомплектом и остатки человеческих технологий. В бой!

Об игре:

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

Теперь подробнее…

Рядовая авиация: На их плечи ложится ответственность за вашу ликвидацию. Чем больше вы их уничтожите, тем больше и злее они будут.

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

Мины: Мины в Just Don’t Die заставят подгорать даже самую крепкую нервную систему. Они имеют разный цвет, и в зависимости от этого по-разному влияют на ваш корабль. Не удивляйтесь, если после столкновения с очередной миной у вас откажет двигатель или орудия…

Бонусы: Конечно же, не всё в мире Just Don’t Die хочет вас убить. В игре присутствуют остатки человеческих технологий - бафы, которые могут починить ваш корабль, пополнить запас смертоносных ракет, активировать силовое поле или же усилить ваши орудия. Получить их можно очень просто, достаточно разбивать астероиды. Поверьте, вы их не пропустите! Но будьте осторожны, кто знает, что еще может скрываться внутри.

В заключении, хочу добавить. Я не являюсь крутым разработчиком, а только начинаю свой путь в геймдеве и Just Don’t Die является моим дебютом. Но я люблю хорошие, красивые и ненапряженные игры (без лютого доната и надоедливой рекламы за каждый чих), которые помогают расслабиться в наших тяжелых буднях. Если тебе понравилось описание игры, и

хочется, чтобы их было больше, то поддержи студию своим вниманием, подписавшись на страничку в ВКонтакте, или просто скачай игру с Google Play и оставь свой отзыв там! Нам важно каждое мнение!

Спасибо за уделенное время!