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

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

А прежде чем я расскажу всё, попробуйте этот генератор в действии. Мы выложили его web версию тут: galaxypassstation.com/character-creator (для ПК и Планшетов)

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

Чтобы решить эту проблему, можно использовать встроенные в Godot ноды Navigation2D или AStar (вот туториал GDQuest, посвящённый обоим нодам). Но в Helms of Fury мы использовали другой способ, который отлично подошёл нашей игре, и мы хотим поделиться им в этом туториале. Вот как это выглядит:

Приступаем к работе

Будем считать, что вы создаёте врагов как объекты KinematicBody2D и используете для управления их состояниями конечный автомат. Не знаете, что такое конечный автомат? Мне нравится эта статья с объяснением конечных автоматов, а также способов их использования. Вот ещё одна статья о реализации простых конечных автоматов в Godot.

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

Если у вас возникало отвращение при копировании одного и того же кода по проектам и желание как то это исправить, добро пожаловать под кат.

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

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

В публикации рассматриваются следующие темы:

• Наследование VS компоненты
• Сложные иерархии классов юнитов, предметов и прочего
• Машины состояний, деревья поведений
• Абстракции игровых объектов
• Упрощение доступа к другим компонентам в объекте, сцене
• Сложные составные игровые объекты
• Характеристики объектов в игре
• Модификаторы (баффы/дебаффы)
• Сериализация данных

Здравствуйте. Хочу представить свой проект – компилятор .NET/Mono в Java. Целью проекта является создание компилятора, и набора стандартных библиотек позволяющих переносить написанные приложения и библиотеки на платформу Java, версии 1.6 и выше. Из аналогичных проектов мне известен лишь проект dot42. Но он заточен под Android и имеет собственную стандартную библиотеку не совсем совместимую с .NET/Mono.

Пока есть только альфа версия, и поэтому для реального использования компилятор пока не годится, однако уже частично работоспособен, генерирует валидный код Java и поддерживает часть стандарта ECMA-335.

Исходные коды на github.com: https://github.com/zebraxxl/CIL2Java

Уважаемые читатели! Хочу поделиться с вами своим open-source проектом, над которым я работаю в своё свободное время уже достаточно давно, TeaVM. TeaVM представляет собой транслятор из байткода Java в JavaScript. Существует несколько попыток создать JVM на JavaScript, одна из самых удачных — Doppio. Однако, кроме академической, никакой ценности они не представляют, так как скорость интерпретации байт-кода оставляет желать лучшего. Более того, для интерпретации байткода необходимо как минимум загрузить этот байткод в браузер, а это вырождается в загрузку десятков мегабайт class-файлов.

В отличие от них, TeaVM не интерпретирует байткод, а генерирует JavaScript, который выполняет ровно то, что делал бы байткод, будь он запущен в реальной JVM. Проще говоря, TeaVM декомпилирует байткод Java, но не обратно в Java, а в JavaScript. Разумеется, всё это верно до определённых пределов. Во-первых, в JavaScript попросту отсутствуют некоторые вещи, привычные Java-разработчикам, такие как потоки, полноценная поддержка Юникода (например, поддержка классов символов, регулярные выражения), блокирующий ввод-вывод. Во-вторых, это обусловлено требованиями, которые я предъявлял к компилятору. Например, в TeaVM очень ограничена поддержка reflection. Это следствие одного из преимуществ TeaVM — сравнительно небольшой размер генерируемого файла. Нет, TeaVM не генерирует минимально возможный JavaScript, однако и не станет генерировать огромные многомегабайтные скрипты на каждый чих. Reflection делает невозможным какой-либо статический анализ, поэтому было принято решение от него отказаться.

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

Так сложилось, что за последние пару лет я успел поучаствовать в разработке нескольких социальных сетей. Главная задача, которую приходилось решать в каждом из этих проектов, заключалась в формировании новостной ленты пользователя. При чём важным условием была возможность масштабирования этой ленты в условиях роста числа пользователей (точнее, числа связей между ними) и, как следствие, — количества контента, который они деливерят друг другу.

Мой рассказ будет о том, как я, превозмогая трудности, решал задачу формирования новостной ленты. А также я расскажу о подходах, которые наработали ребята из проекта Socialite, и которыми они поделились на MongoDB World.

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

Разработчики HHVM составили первоначальный черновик, который полностью передали в общественное достояние. Спецификации опубликованы на Github и доступны для обсуждения и правки.

Наверное многие слышали или сталкивались с таким параметром JVM как -javaagent, увидеть этот параметр вы могли используя Jrebel или Plumbr это могло выглядеть например так JAVA_OPTS=-javaagent:[path/to/]jrebel.jar или так -javaagent:/path-to/plumbr.jar
Хотя javaagent появился еще в версии java 1.5, многие разработчики так никогда и не использовали возможности агентов и имеют смутное представление что это такое.
Что же это за агент? Зачем он может нам понадобиться и как написать свой?