Дисклеймер: данная статья написана неспециалистом в данной области. Коррективровки, замечания и развёрнутые комментарии всячески приветствуются.

Суть новости

30 июля на 50th AIAA/ASME/SAE/ASEE Joint Propulsion Conference — пятидесятой совместной конференции Американского Института Аэронавтики и Астронавтики, Американского Сообщества Инженеров-Механиков, Сообщества Автомобильных Инженеров и Американского Сообщества Инженерного Образования, посвященной двигательным системам, если кому интересно значение сокращений, представители лаборатории NASA предоставили отчёт, согласно которому EmDrive, двигатель, создающий тягу без выброса реактивной массы, работает.

Год назад я довел свое первое рельсовое приложение до приемлемого вида. Вопрос использования готового кода в продакшене ранее меня не заинтересовал. С чего вдруг? Несложный язык, лаконичный фреймворк — уж деплой-то явно не сложнее, чем преодоление ментального тормоза после PHP.

Команда разработчиков Rails рекомендует использовать Phusion Passenger, он что-то вроде mod_php — установил, разместил файлы и полетел. На момент изучения вопроса на форумах хватало баталий о производительности решений; Passenger в них фаворитом не значился.

Совета относительно альтернативы я спросил у техдиректора сайта с миллионом уников в сутки — тот отправил меня гуглить на тему Nginx и Unicorn. Инструкция по настройке продакшена, найденная на Хабре, датировалась 2009 годом. Помимо прочего, ее просто переполняли изъяны уроков «Как нарисовать сову».

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

Не прошло и полугода со дня констатации клинической смерти моего первого цифрового детища. Камни Лабиринта поосыпались, графики количества установок сползли до позорных непечатных значений, мизерные центы ежедневных прибылей превратились в пыль. Что в такой ситуации делает отважный и неутомимый инди-разработчик? Правильно: он делает выводы. А после выводов не грех вдохнуть жизнь в новый свежий проект — и стрельнуть им прямо по вершине топа. Главное не промахнуться.

Привет, меня зовут Михаил Куликов, я разработчик игр и в своем нелегком ремесле я использую Unity. Не буду вдаваться в описание того, что представляет из себя Unity или как я дожился до того, что начал использовать его в качестве движка. Скажу лишь, что это отличный инструмент с множеством как плюсов, так и минусов, и основным минусом, на мой взгляд, является отсутствие инструментария для комфортной работы над UI. Тот инструментарий, что разработчики Unity предоставили в версии 4.6 в качестве открытой беты, не в счет. Особо я в него не вдавался, да и особого желания нет, так как я уже давно пользуюсь плагином NGUI. Сегодня я хочу поделиться с вами проблемами, с которыми мне пришлось столкнуться, делая tween-анимации для интерфейса, а также решением этих проблем.

снизу фотографии настоящих жуков, сверху — моя реализация

Продолжение предыдущей статьи, на этот раз пишем шейдер.

Как то я слушал подкаст, в котором вскользь говорилось о написании шейдера для жука (25 минута, 35 секунда), имитирующего радужную поверхность (не знаю как сказать это по-русски, но в английском языке есть термин — iridescence). Я посмотрел этого персонажа и мне захотелось написать свой шейдер, но имитирующий более реальную поверхность хитина, о нем я расскажу в следующей статье.
Однако возникла проблема — у меня не было подходящей модели жука.

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

Доброго времени суток, user.

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

Поиск оптимального маршрута юнита к цели на неизвестной карте — одна из самых сложных задач при разработке игры. К счастью, существует некоторое количество алгоритмов, которые решают эту задачу. Есть и отличная библиотека PathFinding.js с поддержкой 11 таких алгоритмов.

Художник по эффектам — это алхимик. Его задача: за неимением золота это золото добыть. В любом случае это будет фейк, но от опыта художника зависит, насколько он будет правдоподобным. Художник по эффектам — универсал. Если задача не укладывается в стандартный пайплайн художников, значит эта задача для художника по спецэффектам. Нужно уметь как можно больше и не бояться нестандартных решений, но только если они дадут выгоду. В этой статье я постараюсь подробно рассказать, чем руководствуются художники по эффектам на нашем проекте. Расскажу о некоторых хитростях. Затрону сторону оптимизации арта и расскажу о взаимоотношениях в команде.

При разработке игр часто возникает необходимость реализации следования некоторому маршруту. Например, персонажу нужно проложить путь из точки A в точку B. Допустим рассчитали его по какому-нибудь алгоритму поиска пути, идем. И тут оказывается, что из точки C в точку D идет другой юнит и пересекает нам дорогу и надо бы его обойти. Что делать? Постоянно перестраивать путь – накладно, много лишних вычислительных расходов, когда достаточно слегка изменить направление уже во время движения, чтобы избежать столкновения.
Виды изменения направления по ходу движения и есть steering behaviors.

В этой статье я подробно расскажу и покажу, как правильно и быстро прикрутить распознавание русской речи на движке Pocketsphinx (для iOS порт OpenEars) на реальном Hello World примере управления домашней техникой.
Почему именно домашней техникой? Да потому что благодаря такому примеру можно оценить ту скорость и точность, которой можно добиться при использовании полностью локального распознавания речи без серверов типа Google ASR или Яндекс SpeechKit.
К статье я также прилагаю все исходники программы и саму сборку под Android.

В этой статье я кратко расскажу, как именно преобразуются координаты точек при повороте камеры в 3D играх, css-преобразованиях и вообще везде, где есть какие-то вращения камеры или предметов в пространстве. По совместительству это будет кратким введением в линейную алгебру: читатель узнает, что такое (на самом деле) вектор, скалярное произведение и, наконец, матрица поворота.

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

На последней конференции I/O Google показал свою версию очков виртуальной реальности из картона. В принципе, схемы подобных очков уже давно ходят по интернетам (например, FOV2GO). Однако схема ребят из Google получилась проще аналогов, а также они добавили фишку с магнитом, который работает как внешняя аналоговая кнопка. В этом посте я поделюсь своим опытом сборки очков виртуальной реальности на базе смартфона: Google Cardboard из картона, OpenDive из пластика и очков, вырезанных на лазерном резаке из акрила.

В первой части был написан лексер. Далее будет рассмотрена разработка парсера.

Парсер

Парсер будет реализован по алгоритму сортировочной станции, так как он достаточно прост и не нуждается в рекурсии. Сам алгоритм таков:

В начале даются пустой выходной поток и пустой стек. Начнём читать токены из входного потока по очереди.

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

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

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

• При получении пустого списка, возвращается пустой список.
• При получении списка с одним числом, возвращается список с этим числом.
• При получении [1 + 2], возвращается [1 2 +].
• При получении [1 + 2 + 3], возвращается [1 2 + 3 +], так как оператор + является лево ассоциативным.
• При получении [1 * 2 + 3], возвращается [1 2 * 3 +].
• При получении [1 + 2 * 3], возвращается [1 2 3 * +], так как оператор * имеет больший приоритет.

Со скобками и ошибками разберёмся позднее. Итак, напишем первый тест из списка.

TEST_CLASS(ParserTests) {
public:
    TEST_METHOD(Should_return_empty_list_when_put_empty_list) {
        Tokens tokens = Parser::Parse({});
        Assert::IsTrue(tokens.empty());
    }
};

Введение

Многие C++ программисты слышали про разработку через тестирование. Но почти все материалы по данной теме касаются более высокоуровневых языков и сосредоточены больше на общей теории, чем на практике. Итак, в данной статье я попробую привести пример пошаговой разработки через тестирование небольшого проекта на C++. А именно, как можно предположить из названия, простого интерпретатора математических выражений. Такой проект также является неплохой code kata, так как на его выполнение затрачивается не более часа (если не писать параллельно статью об этом).

Архитектура

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

Существует множество библиотек и инструментов, которые могут облегчить разработку интерпретаторов и компиляторов. Начиная от Boost.Spirit и заканчивая ANTLR и Bison. Можно даже запустить канал интерпретатора командной строки через popen и вычислить выражение через него. Целью данной статье является пошаговая разработка достаточно сложной системы с помощью TDD, поэтому будет использоваться только стандартная библиотека C++ и встроенный в IDE тестовый фреймворк.

Привет, читатель хабра.

Наверное, ты сразу спросишь меня: «Да кто ты такой, чтобы давать мне советы?». Итак, немного обо мне.

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

Я не хочу рассказывать как надо делать, эта статья результат моего опыта и попытка написать рекомендации тем, кто только начинает, хотя и для матерых верстальщиков (слово режущие слух) здесь могут найтись интересные идеи.
Если ты заинтересовался прошу под кат…

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

По крайней мере, таков план.

Но как же именно вам, как разработчику игры, отрендерить такой эффект?

Сегментация изображений и выделение границ объектов (edge detection) играют важную роль в системах Computer Vision и применяются для задач распознавания сцен и выделения (определения) объектов. По большому счету, это такой же инструмент, как, например, сортировка, предназначенный для решения более высокоуровневых задач. И поэтому понимание устройства данного класса алгоритмов не будет лишним при построении подобных систем с учетом предъявляемых требований (в плане качество/производительность) и специфики поставленных задач.

В данной статье кратко описан алгоритм «Efficient Graph-Based Image Segmentation» авторов Pedro F. Felzenszwalb (MIT) и Daniel P. Huttenlocher (Cornell University), опубликованный в 2004 году. Да, алгоритм относительно старенький, но, несмотря на это, он до сих пор остается весьма популярным, демонстрируя неплохие результаты в плане производительности.

Под катом – большая смесь картинок и текста, не требовательная к текущему уровню знаний тематики. Любопытство приветствуется.