Окончание перевода статьи «путеводитель по реализации 2Д платформеров».
Начало

Тип №3: Битовые маски

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

Worms World Party с разрушаемой топографией
Примеры: Worms, Talbot’s Odyssey

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

Поскольку данные для анализа формируются в php и мне этот язык сейчас ближе всего, то искалась библиотека с интерфейсом для php. В связи с этим мне порекомендовали FANN (Fast Artificial Neural Network) — открытое программное обеспечение для построения сетей. У этого решения есть апи для 15 языков, так что почти каждый сможет выбрать что-то для себя.

Пример. Распознавание языка текста на странице

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

Данная статья продемонстрирует возможность легко написать свою нейронную сеть на языке Javа. Дабы не изобретать велосипед, возьмем уже хорошо проработанную библиотеку Fast Artificial Neural Network. Использование нейронных сетей в своих Java-проектах — реально. Часто можно услышать упреки в адрес Java касательно скорости выполнения. Хотя разница не так велика — подробно об этом можно узнать в публикации «Производительность C++ vs. Java vs. PHP vs. Python. Тест «в лоб»». Мы будем использовать обертку вокруг библиотеки FANN.

Так как ранее я был разочарован количеством информации по этому вопросу, я решил восполнить этот пробел, собрав разные виды реализации 2Д платформеров, описав их сильные и слабые стороны и порассуждав над деталями реализации.

Моей целью было создать исчерпывающий и понятный путеводитель по реализации 2Д платформеров.



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

Четыре решения

Мне приходит на ум четыре основных варианта решений при создании платформера. В рамках этой статьи будут рассмотрены все четыре, но из-за большого объема статья поделена на 2 части (прим. пер).

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

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



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

Здравствуй, Хабр! Ух! Давно же я не писал здесь. Итак, начну пожалуй с небольшой предыстории и заодно приведу скриншот получившейся игры.


Скриншот игрового процесса

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

Начало тут
Продолжение тут

Ричард А. Бартл (Richard Allan Bartle)
Дипломированный специалист по искусственному интеллекту. Один из создателей самого первого MUDа (1978 год), который дал начало всей индустрии массивно-многопользовательских игр, за бумом которой мы сейчас наблюдаем. В дальнейшем Ричард плотно занялся исследованиями виртуальных миров и их обитателей. В качестве независимого консультанта он участвовал практически в каждом таком проекте за последние 20 лет.

(Кто хочет помочь с переводом фундаментальной книги по разработке игр, пишите в личку или на почту magisterludi2016<собака>yandex.ru)

Основы

(за перевод огромное спасибо Владиславу Задумову (zadumov.v<собака>gmail.com), который профессионально занимается переводами с английского и японского)

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

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

• Внешний вид
• Жанр
• Кодовая база
• Срок жизни
• База игроков
• Степень изменяемости
• Степень неизменности

Давайте рассмотрим их по порядку.

В своей статье я бы хотел поделиться технической частью игры, которую сделали два человека. Будут рассмотрены основные архитектурные шаблоны (design patterns) и приёмы, дополнительные библиотеки, особенности портирования при работе с движком cocos2dx. Исходный код здесь.

Интро

Цель — создать велосипед скрипт, который пробежится по сайту и проверит каждую страницу сайта на валидность html.
Я слышал, что если нападает перфекционизм, то надо полежать, отдохнуть и это пройдет.
Подумаешь, в валидаторе ошибка…
Но если все же не проходит, то

Если вы еще не знакомы с ReactJS или React Native, то очень рекомендуем ознакомиться, эти фреймворки уже сейчас оказывают значительное влияние на то, куда движется мир разработки мобильных и веб-приложений. Наша же статья о том, как дать возможность веб-разработчику делать приложения для iOS с аудио/видео звонками и другими прелестями платформы voximplant. Создание нативных модулей для React Native — это настолько обширная тема, что про нее можно писать бесконечно и материалов про нее в сети пока еще катастрофически мало. Мы при создании модуля опирались на ряд готовых примеров с github, которые очень помогли не закопаться с этим на века.

Авторы статьи: Данила Перепечин DanilaPerepechin, Дмитрий Чеклов dcheklov.

Здравствуйте.
Data management platform (DMP) — это наша любимая тема во всей истории про онлайн рекламу. RTB is all about the data.
В продолжение цикла рассказов о технологическом стеке Targetix (SSP, DSP), сегодня я опишу один из инструментов, входящих
в DMP — Keyword Builder.

Цены на жильё формируются из многочисленных факторов, основные из которых — это близость к центру города и наличие рядом различной инфраструктуры. Но реальные цены только в бумажных газетах и риэлторских сайтах. Мы будем строить свою карту с ценами на недвижимость в Москве при помощи python, яндекс API и matplotlib, специальный репортаж с места событий под катом.

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

Чем выгодно отличается шум Перлина, легко можно заметить, если сравнить картинки.

Обычный шум (из той самой статьи):


Шум Перлина:


И увеличением количества октав первую картинку ко второй никак не приблизишь. Я не буду описывать достоинства шума Перлина и область его применения (потому что статья о программировании, а не о применении), а постараюсь объяснить как он реализован. Думаю, это будет полезно многим программистам, ведь хакерские исходники Кена Перлина мало объясняют даже при наличии комментариев.

Предлагаем вашему вниманию подборку с ссылками на полезные ресурсы, интересные материалы и IT-новости

* — в трёх измерениях.


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

«Что может быть проще самолёта? Подъёмная сила пропорциональна квадрату скорости, двигатель тянет вперёд, всё просто» — такая мысль пришла в мою голову летом, и я сел писать игру. Лето прошло, было собрано несколько граблей, а списочек того, что я планировал добавить в проект, очень сильно вырос.

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

Сложные системы подвержены сбоям многих компонентов, поэтому вполне целесообразно разделить сбои на два класса. К первому можно отнести повторяющиеся сбои, которые возможно предупреждать (например, отказ жесткого диска) и выявлять с помощью непосредственных проверок. Ко второму классу относятся непредвиденные сбои.

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

Что это за зверь?

Не будет преувеличением сказать, что Urho3D по возможностям сопоставим с Unity3D и работать с ним так же легко. При этом он бесплатен без каких-либо оговорок (лицензия MIT), доступен для многих платформ (Windows, Linux, Mac OS X, Android, iOS, Raspberry Pi, HTML5), невероятно быстр и легковесен. Позволяет писать игры на AngelScript (синтаксис похож на C#), LUA и C++. Если вы заинтересовались, то добро пожаловать под кат.

Я работаю в игровой индустрии уже более 8 лет. В Wargaming решаю весьма широкий круг вопросов: от анализа патчей до решения различных внутренних проблем. Так вышло, что проблема комфорта и производительности попала в поле моего зрения. После общения с разработчиками World of Tanks, тестировщиками и исследователями поведения игроков у меня сложилось видение вопроса, которое я оформил в виде этой статьи. Я не специалист в области компьютерной графики или разработчик графического движка, не провожу UX-тесты на людях. Но надеюсь, собранная информация и мой непредвзятый взгляд на вопрос натолкнут вас на прогрессивные мысли и стимулируют к творческому поиску решения проблемы производительности в игре.