Давно хотелось составить список навыков и инструментов, которыми, по моему мнению, должны входить в «джентльменский набор» любого программиста под Unreal Engine 4. Буквально на днях, в чатике по UE4 я встретил такое:

> blueprints, animation dev, tech art, ai, multiplayer, editor extensions. первое, что пришло в голову

> Что приходит на ум: blueprints, animations, AI, material editor, widgets, slate, editor extensions, ue4 plugins, physics, lighting, rendering, c++
+ Сколько времени работал(а) с движком и страна, всё :)

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

Сколько уже было мануалов "Как сделать игру на Unity за 3 часа", "Делаем Counter-Strike за вечер" и т.п.? Низкий порог входа — это, несомненно, главный плюс и минус Unity. Действительно, можно накидать “ассетов”, дописать несколько простых “скриптов”, обмотать синей изолентой и это даже будет как-то работать. Но когда проект обрастает игровыми механиками, сложной логикой поведения, то проблемы при подобном подходе нарастают как снежный ком. Для внедрения новых механик требуется переписывание кода во многих местах, постоянная проверка и переделывание префабов из-за побившихся ссылок на компоненты логики, не говоря уже об оптимизации и тестировании всего этого. Разумеется, архитектуру можно продумать изначально, но на практике это всегда недостижимая цель — дизайн-документ довольно часто меняется, какие-то части выкидываются, добавляются абсолютно новые и никак не связанные со старой логикой поведения. Компоненты в Unity — это шаг в правильном направлении в виде декомпозиции кода на изолированные блоки, но особенности реализации не позволяют достичь необходимой гибкости, а самое главное, производительности. Разработчики придумывают свои фреймворки и велосипеды, но чаще всего останавливаются на ECS (Entity Component System). ECS – одно из решений, продолжающее идею компонентной модели Unity, но придающее ей ещё больше гибкости и сильно упрощающее рефакторинг и дальнейшее расширение приложения новым функционалом без кардинальных изменений в текущем коде.

Привет, Хабр!

При ознакомлении с разработкой под Unity3D, для меня, пришедшего из мира Java и PHP, довольно необычным стал подход к внедрению зависимостей на данной платформе. В основном, конечно, это связано с недоступностью конструкторов MonoBehaviour и ScriptableObject, создание объектов вне доступа разработчика, а также наличие редактора, в котором можно конфигурировать каждый объект индивидуально или целыми префабами (при этом оставляя возможность один из экземпляров префаба изменить на своё усмотрение в процессе создания сцены).

Если вы знакомы с C#, то, скорее всего, знаете, что необходимо всегда переопределять Equals, а также GetHashCode, чтобы избежать снижения производительности. Но что будет, если этого не сделать? Сегодня сравним производительность при двух вариантах настройки и рассмотрим инструменты, помогающие избегать ошибок.

Очередная статистика от hh.ru под катом. Вкратце — очень хотелось посчитать, на каких языках чаще всего пишут отечественные разработчики и какие языки чаще других ищут работодатели. Итого — посчитал, что указывали в вакансиях и в резюме в первом полугодии 2018 и 2017 годов. Получилось что получилось.

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

Мой путь оказался непростым и витиеватым. Но в результате получилось устройство, передающее показания воды по Wi-Fi на телефон. Простое и понятное в использовании и настройке хоть школьнику, хоть гуманитарию пенсионеру. А знакомым со словом «Ардуино» — ещё и несложное для изготовления. Девайс способен работать от батареек четыре года (дольше, чем длились отношения с вашей бывшей). Это ещё и первый открытый проект с такими характеристиками. Заводские аналоги я выписал, их мало, да и ладно с ними.

Итак, у нас есть немного денег и большое, но честное желание упростить себе жизнь, не нарушая Уголовный Кодекс. И чтобы никаких этих ваших 220В, серверов и кучи кнопок! Показания смотрим на смартфоне в приложении Blynk или аналогичном сервисе.

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

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

Однако, в зависимости от вида, каждые 7, 11, 13 или 17 лет периодические цикады одновременно массово вылезают на свет и превращаются в шумных летающих тварей, спариваются и вскоре умирают.

Хотя наши странные цикады весело уходят в иной мир, возникает очевидный вопрос: это просто случайность, или числа 7, 11, 13 и 17 какие-то особенные?

Здравствуйте. Несколько недель назад я начинал серию переводов статей по изучению OpenGL. Но на 4 статье один хабровчанин заметил, что мои переводы могут нарушать лицензию, по которой распространяются учебные материалы, предоставленные в исходной статье. И действительно, мои переводы нарушали лицензию. Для разрешения этой проблемы я обратился к авторам того набора уроков, но так и не смог добиться нормального ответа. По этой причине я связался с автором другого, не менее (а возможно даже и более) крутого, набора уроков по OpenGL: Joey de Vries. И он дал полное разрешение на перевод его набора уроков. Его уроки гораздо более обширные, чем прошлый набор, поэтому эти переводы растянутся на долго. И я обещаю, будет интересно. Заинтересовавшихся прошу под кат.

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

На счет уроков по Vulkan: к сожалению мне тяжело сейчас написать уроки по данному API по причине скудной видеокарты на данный момент, которая просто не поддерживает Vulkan API, поэтому уроки по данному API будут только после обновления видеокарты.

В процессе движения к долгожданному титулу Lead Senior C++ Over-Engineer, в прошлом году я решил переписать игру, которую разрабатываю в рабочее время (Candy Crush Saga), с помощью квинтэссенции современного C++ (C++17). И так родилась Meta Crush Saga: игра, которая выполняется на этапе компиляции. Меня очень сильно вдохновила игра Nibbler Мэтта Бирнера, в которой для воссоздания знаменитой «Змейки» с Nokia 3310 использовалось чистое метапрограммирование на шаблонах.

«Что ещё за игра, выполняемая на этапе компиляции?», «Как это выглядит?», «Какой функционал C++17 ты использовал в этом проекте?», «Чему ты научился?» — подобные вопросы могут прийти к вам в голову. Чтобы ответить на них, вам придётся или прочитать весь пост, или смириться со своей внутренней ленью и посмотреть видеоверсию поста — мой доклад с Meetup event в Стокгольме:


Примечание: ради вашего психического здоровья и из-за того, что errare humanum est, в этой статье приведены некоторые альтернативные факты.

Если вы играете в современные AAA-игры, то могли заметить тенденцию использования покрытых снегом ландшафтов. Например, они есть в Horizon Zero Dawn, Rise of the Tomb Raider и God of War. Во всех этих играх у снега есть важная особенность: на нём можно оставлять следы!

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

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

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

В одной из предыдущих статей мы провели обзор технологий, которые используются на нашем новом проекте — fast paced шутере для мобильных устройств. Теперь хочу поделиться, как устроена клиентская часть сетевого кода будущей игры, с какими трудностями мы столкнулись и как их решали.

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

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

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

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

Можно сказать, что девиз почти всех инди-разработчиков — это «Большие мечты при ограниченных ресурсах». Когда я начал работать над первой игрой Motion Twin для Steam Dead Cells, эта фраза стала и моим девизом.

Меня зовут Тома Вассёр, в течение целого года я был единственным художником Dead Cells. Я занимался дизайном и анимациями каждого аспекта игры. В одиночку мне пришлось создавать графический стиль, персонажей, монстров, анимации, спецэффекты (FX) и большинство фонов Dead Cells… Пока, к счастью, мне на помощь не пришёл мой злой брат-близнец Генель Массе. Количество художников Dead Cells удвоилось.

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

Несколько лет назад мне казалось, что Олег Чумаков (тогда еще из Nival) был самым известным программистом геймдева. Постоянно выступал, проводил Gamesjam, был частым гостем подкаста Как делают игры.

С появлением на рынке VR, Олег возглавил в компании новое подразделение — NivalVR. Но вы все знаете, с виртуальной реальностью что-то пошло не так, как хотелось.

Я на долгое время отвлекся от геймдева, а взглянув снова, увидел — у команды Олега дела стали только интереснее. Теперь она называется Luden.io и их симулятор специалиста по машинному обучению while True: learn() стал хитом в своей нише, вокруг него творится куча крутых историй.

Мы поговорили с Олегом, но я не смог выбрать только одну тему — слишком уж насыщен и разнообразен был его путь. А чтобы программист говорил о программировании не боясь быть непонятым, беседу поддержал мой друг, коллега и опытный разработчик fillpackart.

Введение

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

Но сначала я хотел бы пояснить, что понимаю, зачем вы разрабатываете крутые или сексуальные наряды с характерными силуэтами – конечно же, продолжайте. Не всей броне нужно быть реалистичной. Также отмечу, что многие из упомянутых далее игр мне очень нравятся. Если какие-то аспекты персонажей нуждаются в доработке, это вовсе не значит, что игры становятся от этого хуже.

Зачем нужна броня

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

Свойства металлов

Вес

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

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

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