Тестирование – очень важный этап разработки мобильных приложений.

Стоимость ошибки в релизе мобильного приложения высока. Приложения попадают в Google Play в течении нескольких часов, в Appstore несколько недель. Неизвестно сколько времени будут обновляться пользователи. Ошибки вызывают бурную негативную реакцию, пользователи оставляют низкие оценки и истерические отзывы. Новые пользователи, видя это, не устанавливают приложение.

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

Поэтому в отделе тестирования у нас работает 8 человек (0,5 тестировщика на программиста), за его развитием и процессами следит выделенный тест-лид.

Под катом я расскажу как мы тестируем мобильные приложения.

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

Меня зовут Светлана, я занимаюсь разработкой в компании Бука. Хочу поделиться с вами историей о том, как мы портировали игру.

Как всё начиналось

Многие наверняка помнят золотую эру квестов, которая пришлась на 90-е годы прошлого века. А некоторые из тех, кто постарше, даже застали лучших представителей жанра: King’s Quest, Space Quest, Myst, Broken Sword, Grim Fandango, Monkey Island.

Российский геймдев тоже не сидел сложа руки: коробки с играми серий «Братья Пилоты» и «Петька и Василий Иванович» расхватывали с прилавков магазинов как горячие пирожки!

Старые игры с возрастом не становятся хуже, но запустить их с каждым годом всё сложнее. Поэтому, как и многие другие издательства, мы решили портировать одну из своих лучших игр на современные устройства. И в качестве пробы пера выбрали классический квест «Петька и Василий Иванович: Спасают Галактику».

«Галоп пикселя», часть I — базовые понятия, этапы взросления, прикладные упражнения (линк)
«Галоп пикселя», часть II — перспектива, цвет, анатомия и прикладные упражнения (линк)
«Галоп пикселя», часть III — Анимация (линк)
«Галоп пикселя», часть IV — Анимация света и тени (линк)
«Галоп пикселя», часть V — Анимация персонажей. Ходьба (линк)
«Галоп пикселя», часть VI — Анимация персонажей. Бег (линк)

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

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

Материал разделен на несколько публикаций в виду объема текста и изображений. Каждая статья имеет свою степень сложности, однако, все из них наглядны и могут быть использованы как руководство к действию.

Добрый день, Хабр!

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

Только что вышла книга «Multiplayer Game Programming: Architecting Networked Games (Game Design)».



Насколько актуален ее перевод на русский язык? Подробности под катом. Ждем ваши комментарии.

Картинка для привлечения внимания

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

Так как небольшой опыт создания игры у меня уже был, я вооружился не клавиатурой, как в прошлый раз, а карандашом и бумагой, и принялся «придумывать» игру. На разных листах А4 я записывал свои мысли по разным направлениям: игровые механики, сеттинг, интерфейс, правила, интересные мысли, запомнившиеся игры из детства и т. п.; при этом я параллельно шерстил Google Play Market в поисках вдохновения. В итоге, спустя несколько дней, было принято решение, что игра станет головоломкой, а именно — пазлом. За это время мой мозг и пальцы заскучали по программированию, в результате чего захотелось сделать хоть какой-нибудь прототип игры. Это сподвигло меня на более интенсивную проработку идеи пазла, и в итоге в качестве рабочего был принят вариант со следующими правилами: игровое поле состоит из квадратных кусочков пазла (далее они будут называться тайлами), на которых располагаются разноцветные линии; тайлы можно менять местами; цель игры: собрать пазл единственным образом, в котором линии одного цвета замкнуты в некий узор.

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

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


*Подробно опишу правила еще раз в разделе про ИИ.

Читателей статьи условно разделяю на три группы.

1. Начали программировать несколько часов назад.
   Вам будет сложно, лучше предварительно пройдите какой-нибудь небольшой курс по введению в Android-разработку, разберитесь с двумерными массивами и интерфейсами. А потом загрузите проект с гитхаба. Комментарии и эта статья помогут вам разобраться, что и как работает.
2. Уже умеете программировать, но еще не можете назвать себя опытными.
   Вам будет интересно, потому что вы очень быстро сможете сделать свою игру. Я взял на себя грязную работенку по построению логики игры и ui-составляющей, вам же оставляю творческую часть. Вы можете сделать другой режим игры (2 на 2, онлайн и т.п.), изменить алгоритмы бота, создать уровни и т.д.
3. Опытные.
   Вам может быть интересно подумать над ИИ — написать его не так легко, как кажется на первый взгляд. Так же я был бы очень рад получить от вас замечания по коду — уверен, далеко не все я сделал оптимально.

Нерешенные задачи

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

Вспомните, какие самые болезненные проблемы разработки дизайна? Их, как минимум, три:

• Нет контента.
• НЕТ КОНТЕНТА!
• Резкая замена лица, принимающего решение (ЛПР). И, как вероятное следствие, смена общей концепции сайта.

Итого, имеем: ЛПР никак не выражает свое мнение ровно до того момента, как дизайнер демонстрирует ему готовый, с любовью сделанный, результат. А как только это произошло — предъявляет список правок.

Классические компьютерные игры начались ещё, собственно, до появления компьютеров в виде интерактивных книг. Скорее всего, в детстве у вас была одна такая либо Браславского, либо вообще из цикла про Стальную Крысу Гаррисона.



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

Базовый сюжет строился в виде системы узлов и переходов. За один проход вы задействовали примерно 25-35% страниц книги.



То есть техническая вариативность сводилась к тому, что вы всё равно получали 80% основного сюжета, но просто не всегда линейно и не всегда с одной и той же точки зрения. И автоматизации там не было почти никакой, кроме того, что вы листали страницы.

Вас интересуют игры? Хотите создать игру но не знаете с чего начать? Тогда вам сюда. В этой статье я рассмотрю простейший физический движок, с построения которого можно начать свой путь в GameDev'e. И да, движок будем писать с нуля.

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

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

Итак,
Часть 1 — открытия в области управления временем и проектом.
Часть 2 — полезные сервисы и ресурсы, пригодившиеся в процессе разработки и релиза.

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

Этот урок описывает метод планирования течения игры и навигации юнитов, который использует многоагентные потенциальные поля. Он основан на работах под номерами [1, 2, 3]. (Смотри в конце статьи ссылки на используемые материалы)

Итак, подошло время рассказать и показать как это все управляется. Как я уже говорил во второй части, после нескольких итераций — все остановилось на HTML + JS. Писать отдельное приложение под Android я не планировал, но жизнь, как обычно, внесла некоторые коррективы.

Ссылки на первые две части:

• Первая часть, железная
• Вторая часть, серверная

Многие из тех, кто печатает на 3D-принтере сталкиваются или с необходимостью получить партию моделей в короткие сроки, или скопировать удачно получившуюся деталь, или получить изделия с прочностными характеристиками, превосходящими таковые у пластиков для домашней 3d-печати.

3D-принтер далеко не всегда способен выполнить такие задачи, но отлично подойдет для создания единственного образца, или мастер-модели. А дальше на помощь нам приходят материалы производства компании Smooth-On, наверное, самого популярного производителя материалов холодного отверждения.



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

Посмотрите на это фото.



Это совершенно обычная фотография, найденная в Гугле по запросу «железная дорога». И сама дорога тоже ничем особенным не отличается.

Что будет, если убрать это фото и попросить вас нарисовать железную дорогу по памяти?

Если вы ребенок лет семи, и никогда раньше не учились рисовать, то очень может быть, что у вас получится что-то такое:

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

В современном мире «интернет вещей» (IoT) стремительно набирает популярность. Он в будущем поможет человечеству автоматизировать многие аспекты жизни, упростить рутинные операции, да и просто сделать жизнь комфортнее и приятнее. Современная элементная база только способствует этому. Еще несколько лет назад задача управления устройством из сети порождала необходимость использовать высокопроизводительные процессоры, что увеличивало стоимость конечного исполнительного устройства в разы. Сейчас же есть возможность построить простые и эффективные IoT-решения за копейки.

Сделать свой дом поистине «умным» можно и без использования модных Raspberry Pi или Arduino. Большинство IoT-задач сводится к подключению типовых датчиков и исполнительных механизмов со стандартными интерфейсами: I2C, SPI, UART. А иногда даже с элементарным аналоговым выводом, с которого нужно считать наличие напряжения или подать его, или просто замкнуть.

В статье будет описан нестандартный способ поиска данных об уровнях в NES-играх — с помощью последовательного изменения всех данных в образе и исследования последствий («коррапт» в терминах ромхакеров). Для примера я покажу, как найти данные об уровнях в игре «Jackal» для NES и добавить один из её уровней в редактор CadEditor. Данный способ позволяет исследовать любую игру с блочной структурой уровней (почти любую игру на NES), без знания ассемблера X8502, требуются только начальные навыки работы со скриптовыми языками (Lua и Python).

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

В этом выпуске серии «5 вещей …», я представлю некоторые из тонких аспектов многопоточного программирования, в том числе synchronized-методы, volatile переменные и атомарные классы. Речь пойдет в особенности о том, как некоторые из этих конструкций взаимодействуют с JVM и Java-компилятором, и как различные взаимодействия могут повлиять на производительность приложений.

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