Всем привет! Меня зовут Александр, я уже более 5 лет работаю с Unreal Engine, и почти все это время — с сетевыми проектами.

Поскольку сетевые проекты отличаются своими требованиями к разработке и производительности, нередко необходимо работать с более простыми объектами, такими как классы UObject, но их функциональность изначально урезана, что может создать сильные рамки. В этой статье я расскажу о том, как активировать различные функции в базовом классе UObject в Unreal Engine 4.

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

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

Но когда вы пишете игровой код на Unreal Engine, вы не имеете дело с игровым циклом напрямую. Вы не начинаете работать сразу с основной функцией — сначала вы определяете подкласс GameMode и переопределяете функцию под названием InitGame. Или пишете одноразовые классы Actor и Component и переопределяете их функции BeginPlay или Tick для добавления собственной логики. Это самый минимум того, что вам нужно сделать: обо всем остальном движок позаботится за вас.

Unreal Engine также предлагает вам как программисту мощный и гибкий инструментарий: конечно, он имеет открытый исходный код, но также возможно и расширение несколькими другими способами. Даже если вы только начинаете работать с этим движком, было бы не лишним получить представление о его GameFramework: о таких классах, как GameMode, GameState, PlayerController, Pawn и PlayerState.

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

В стандартной сетевой архитектуре Unreal Engine, сервер проверяет, изменение значения у реплицированной переменной Actor класса, и в случае отличия, значение синхронизируется между сервером и клиентом. Когда объем данных для синхронизации не больших размеров, особых проблем с производительностью нет.

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

UE уже предоставляет такие функции как: NetUpdateFrequency, NetCullDistanceSquared и т.д. Основная задача которых состоит в том, что бы устранить из общей картины репликации, как можно больше актеров не нуждающихся в постоянно синхронизации данных.

PushModel, пока что экспериментальная фича, которая может позволить разработчикам активно отмечать необходимость синхронизации свойства, для этого предоставляется несколько макросов:

Работники не понимают, чего хочет от них глава компании.

Я пообщался с несколькими бывшими (в том числе, теми, кто работал в компании более 5 лет назад) и текущими сотрудниками, чтобы понять, были ли недавние увольнения единичным случаем или у компании системные проблемы.

В первых 2х статьях (раз и два) мы с вами уже взглянули на виды тестирования, применяемые в геймдеве и примеры багов, часто (и не очень) встречаемых в играх. Но в воздухе остался неозвученный вопрос: "Каким образом всё это тестировать?" В этой главе поделюсь подходами и инструментами, которые я использую для тестирования тех или иных игр, включая игры с большими картами (к примеру в жанре Battle Royal) или же что-то более локальное, такое как спортивный симулятор.

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

Сравнить точность алгоритмов можно прямо сейчас на этой странице.

В конце будет краткая памятка по тому, где и когда лучше применять какой из методов. При правильном выборе можно добиться увеличения скорости вычислений в 5 раз при погрешности ~1%, а иногда и вовсе без неё.

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

Если вы пишете на C++, то скорее всего сталкивались с тем, что компиляция, кодогенерация и компоновка проектов, написанных на нём, занимают время и с развитием проекта начинают мешать как CI конвейеру так и итерации разработки на рабочем месте. Наша команда не понаслышке знает об этих проблемах, и в этой статье мы хотим поделиться опытом внедрения широко известного в узких кругах инструмента - сборочной системы FASTBuild.

Введение

Помимо увеличения количества диагностик с каждым новым релизом анализатор PVS-Studio развивается и в инфраструктурном плане. В данном случае это плагин для среды разработки JetBrains CLion, межмодульный анализ С++ проектов, ускорение работы ядра C# анализатора.

Локализация видеоигр (как и любой другой аспект разработки) хорошо описывается волшебным треугольником тройственной ограниченности: цена — время — качество.

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

А если хотите получить высокое качество, то это будет либо дорого, либо очень долго.

Чтобы локализация была выполнена быстро, придется жертвовать качеством либо платить больше. (В зависимости от того, насколько сжатые сроки и сколько людей задействовано, может получиться, что вы и заплатите намного больше, и потеряете в качестве!)

В общем, смысл понятен.

Мне слишком часто приходится видеть, как разработчики привлекают к работе над локализацией игры волонтеров из «сообщества»: они хотят, чтобы локализация была дешевой и быстрой и думают, что если исходный английский текст написан хорошо, то и качество перевода будет высоким. Так же?

Ну… вообще-то нет.

Добрый день, коллеги! Доказывать, что нужно использовать систему контроля версий, уже давно не нужно. И Git занял тут лидирующую позицию, стремительно вытеснив SVN. Но это инструмент, а инструментом нужно уметь пользоваться, чтобы добиться лучших результатов. Как топором, один человек сможет просто срубить дерево а другой из этого дерева сможет сделать великолепную скульптуру. Так и с помощью Git, один человек сможет просто не потерять результаты своего труда за день, а другие смогут организовать совместную работу над проектом нескольких сотен человек. Да так, что о любой строчке кода можно будет и через пять лет сказать, откуда она взялась и для чего нужна.

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

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

Хотя, подобные решения, не всегда хороши. В отличие от обыкновенных цифровых значений, которые легко кешировать и сортировать, UUID не так гибки в использовании. UUID версии 7 предназначен как раз для того, чтобы разобраться с подобными проблемами.

Современные AAA-тайтлы уже давно стали весить больше 100 ГБ, а их апдейт еще на 20 ГБ считается обычным делом. Тот же тренд разрастания билда постепенно просачивается в мидкорные и хардкорные мобильные игры. Впрочем, к тому, что уже не удивляет ПК- и консольных юзеров, мобильные геймеры все еще довольно чувствительны.

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