Автор этого поста увидел первую 3D-модель, распечатанную на принтере, около 10 лет назад. Шло собрание в огромном российском рекламном агентстве, которое использовало возможности 3D-печати для того, чтобы печатать демонстрации очень дорогой сувенирки — её предстояло сделать из меди, бронзы, серебра и совсем мелкие штучки из золота. Мы с коммерческим директором тогдашней компании крутили в руках будущие статуэтки и значки из буро-серо-синего пластика, с неаккуратными заусенцами, «провалами» и т.д. Нам это казалось восьмым чудом света — и, когда нам отдали макеты насовсем, мы радовались как дети и уже в машине шутили, что круто было бы печатать на принтере блинчики, пирожные и колбасу. Никогда мы ещё не были так близки к предсказанию будущего.


Когда хозяин купил 3D-принтер, а ты понял, как выглядит безысходность

Введение

При разработке своей игры, я дошёл до момента создания первых NPC. И появился вопрос как заставить NPC обойти стену а не "идти в неё".

Полазив по интернету я нашёл такие алгоритмы:

• Поиск в ширину (BFS, Breadth-First Search)
• Алгоритм Дейкстры (Dijkstra)
• А Star "A со звёздочкой"
• Поиск по первому наилучшему совпадению (Best-First Search)
• IDA (A с итеративным углублением)
• Jump Point Search

И решил попробовать реализовать свой A* на воксельной 3д сетке.

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

В первой части этого туториала мы реализуем собственную двухмерную систему крюка-кошки и научимся следующему:

• Создавать систему прицеливания.
• Использовать рендер линии и distance joint для создания верёвки.
• Научим верёвку оборачиваться вокруг игровых объектов.
• Вычислять угол качания на верёвке и добавлять силу в этом направлении.

Примечание: этот туториал предназначен для продвинутых и опытных пользователей, и в нём не рассматриваются такие темы, как добавление компонентов, создание новых скриптов GameObject и синтаксис C#. Если вам нужно повысить навыки владения Unity, то изучите наши туториалы Getting Started with Unity и Introduction to Unity Scripting. Так как в этом туториале используется DistanceJoint2D, то стоит также просмотреть Physics Joints in Unity 2D, и уже потом вернуться к этому туториалу.

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

В этой статье я расскажу как вы можете использовать GraphQL в своих проектах на технологиях InterSystems.

Привет Хабр!

Меня зовут Алексей Солодкий, я PHP-разработчик в компании Badoo. И сегодня я поделюсь текстовой версией моего доклада для первого Badoo PHP Meetup. Видео этого и других докладов с митапа можно найти здесь.

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

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

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

Рассмотрим, что делать, когда сервис падает или тупит, как организовать сбор метрик и что делать, когда всё вышесказанное вас не спасёт.

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

Процедурно генерируемые карты — базовая особенность roguelike. Для жанра, который почти является синонимом понятия «случайность» (и на то есть причины), рандомизированные карты стали простейшим способом демонстрации его ключевого элемента, потому что они влияют на многие аспекты геймплея — от стратегии исследования и тактического позиционирования до расположения предметов и врагов.

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

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

Конечно же, преимущества процедурных карт бессмысленны без большой вариативности механик и контента — однообразный hack-and-slash здесь не подойдёт. Поэтому все roguelike, выдержавшие испытание временем, имеют глубокий геймплей.

Этот пост является результатом моей работы над генерацией карт для Cogmind.

Объяснение

Что же такое hitbox и hurtbox? Разве это не одно и то же?

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

Hitbox — это невидимый прямоугольник (или сфера), определяющий, куда попадает атака.

Hurtbox — это тоже невидимый прямоугольник (или сфера), но определяющий место, в которое игрок или объект может ударить с помощью Hitbox.


На этом изображении из Street Fighter IV красный прямоугольник — это hitbox, а зелёный — hurtbox

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

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

Основа геймплея для Unreal Engine 4 предоставляет разработчику мощный набор классов для создания игры. Ваш проект может быть шутером, симулятором фермы, глубокой RPG — это неважно, основа очень универсальна, делает за вас часть тяжёлой работы и задаёт некоторые стандарты. Она довольно сильно интегрирована в движок, поэтому рекомендую вам придерживаться этих классов, а не пытаться изобретать собственную основу игры, как это часто бывает в движках наподобие Unity3D. Понимание этой основы очень важно для успешной и эффективной работы над проектами.

Для кого эта статья?

Для всех, кого интересует создание игр в UE4, а конкретно на C++, и кто хочет больше узнать о основе геймплея Unreal. В этом посте рассматриваются базовые классы, которые вы будете использовать в основе геймплея, и объясняется их применение, процесс создания их экземпляров движком и способ получения доступа к этим классам из других частей кода игры. Бо́льшая часть информации справедлива также и для блюпринтов.

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

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

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

В этой статье вас ждёт продолжение описания устройства спецэффектов для игр под NES (первая часть здесь). На этот раз будет меньше теории и больше картинок-примеров.


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

Недавно я выпустил свою первую игру BYTEPATH и мне показалось, что будет полезно записать свои мысли о том, чему я научился в процессе её создания. Я разделю эти уроки на «мягкие» и «жёсткие»: под мягкими я подразумеваю идеи, связанные с разработкой ПО, жёсткие — это более технические аспекты программирования. Кроме того, я расскажу о том, почему хочу написать собственный движок.

Мягкие уроки

Сообщу ради контекста, что начал делать собственные игры примерно 5-6 лет назад и у меня есть 3 «серьёзных» проекта, над которыми я работал до выпуска первой игры. Два из эти проектов мертвы и полностью провалились, а последний я временно приостановил, чтобы поработать над BYTEPATH.


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

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

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

Введение

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

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

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

Это рассказ о том, как написать свою игру на Corona.
Уровень вхождения — минимальный (и ботаник с кафедры алгебры поймет).

Я напомню, что Corona — это движок для создания 2D игр на все платформы и, touch-touch, сегодня День космонавтики. Сюжет для игры выбран соответсвующий и, разумеется, мы повторяем за первым космонавтом

-Поехали!

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

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

В этом туториале вы научитесь следующему:

• Процедурно генерировать уровни на примере создания игры про бег в лабиринте.
• Генерировать данные лабиринтов.
• Использовать данные лабиринтов для построения меша.

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

В большинстве алгоритмов (таких, например, как этот и этот) создаются «идеальные» плотные лабиринты, то есть такие, у которых есть только один верный путь и нет петель. Они похожи на лабиринты, публикуемые в газетных разделах «Головоломки».


Однако в большинство игр приятнее играть, когда лабиринты неидеальны и в них есть петли. Они должны быть обширными и состоящими их открытых пространств, а не из узких извилистых коридоров. Это особенно справедливо для жанра rogue-like, в котором процедурные уровни являются не столько «лабиринтами», а скорее подземельями.


В этом туториале мы реализуем один из простейших алгоритмов лабиринтов, описанный здесь. Я выбрал его для того, чтобы реализовать лабиринты в игре с минимальным количеством усилий. Такой простой подход хорошо работает в классических играх, перечисленных по ссылке, поэтому мы можем использовать его для создания лабиринтов в игре под названием Speedy Treasure Thief.

Распространение света в реальном мире это чрезвычайно сложное явление, зависящее от слишком многих факторов, и, располагая ограниченными вычислительными ресурсами, мы не можем себе позволить учитывать в расчетах все нюансы. Поэтому освещение в OpenGL основано на использовании приближенных к реальности упрощенных математических моделей, которые выглядят достаточно похожими, но рассчитываются гораздо проще. Эти модели освещения описывают физику света исходя из нашего понимания его природы. Одна из этих моделей называется моделью освещения по Фонгу (Phong). Модель Фонга состоит из трех главных компонентов: фонового (ambient), рассеянного/диффузного (diffuse) и бликового (specular). Ниже вы можете видеть, что они из себя представляют:

Продвинутое освещение

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