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

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

Начиная с Ultima Underworld и System Shock, Looking Glass Studios всегда стремилась создавать глубоко иммерсивные игры. Ее основатель Пол Нейрат с детства любил обследовать всякие здания, в том числе и те, где его быть не должно — но тяга к исследованиям была сильнее. 

Как-то раз после урока плавания не то в 10, не то в 12 лет Нейрат заглянул в подвал оздоровительного клуба, дверь в который по счастливой случайности оказалась открыта. Оттуда можно было спуститься еще ниже — судя по количеству пыли, в помещение, где никто не бывал годами. Конечно, его это заинтриговало, но вскоре он услышал звук чужих шагов и перепутался, что его поймают. Он прятался в темном углу до тех пор, пока охранник не войдет и не осмотрится, а поняв, что никого здесь не найдет — не уйдет обратно.

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

Оригинальный Xbox известен тем, что имел всего 64 мегабайта оперативной памяти, чего даже в то время не всегда хватало играм. В недавнем подкасте о слиянии Bethesda и Xbox директор Bethesda Game Studios Тодд Говард рассказал о том, что именно из-за нехватки памяти и для ее освобождения Morrowind иногда перезагружала Xbox незаметно для пользователя. Долгие внутриигровые загрузки — это как раз то, о чем идет речь. 

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

Любой проект начинается с идеи. Когда эта идея преобразуется в цель со своими дедлайнами и выделенными ресурсами, следующий этап к ее реализации ― предпродакшн. На нем мы еще не приступили к разработке продукта, но оцениваем, сколько времени нам на нее понадобится, какого размера нужна команда, как правильно организовать процессы. А также стараемся учесть все, что может пойти не так, и выработать на это меры.

Эта статья ― начало нашего большого цикла о том, как делаются ремастеры. В ней мы расскажем, как правильно оценить объем работы, которую никто раньше не делал, о риск-менеджменте и управлении неопределенностью.

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

Сегодня мы расскажем, как в геймдеве делаются тени — в реальном времени и статичные. В своих проектах War Robots и Dino Squad мы используем сразу несколько техник — им и уделим особое внимание.

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

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

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

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

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

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

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

Примечание: Эта статья ни в коем случае не является полным руководством/объяснением трассировки лучей, поскольку эта тема слишком обширна, а скорее просто введением для любопытствующих.

Спустя два года после запуска Turing в сентябре 2020 года NVIDIA сменила архитектуру своих видеокарт на Ampere. AMD не осталась в стороне и вскоре после этого тоже обновила архитектуру RDNA до второй версии.  

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

Но что насчет чипов, лежащих в их основе? Какой из них лучше?

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

В этой статье я систематизировал собственный опыт работы с таблицами и их дополнительными функциями, которые могут оказаться полезными как для начинающих, так и опытных геймдизайнеров. Примеры приведены в Google Sheets, поскольку они чаще используются командами разработки, но большая часть из них применима и к MS Excel.

«Игра всегда называлась именно так», — вспоминает Дэвид Бревик, ведущий программист оригинальной Diablo 1997 года. — «Diablo — это название горы в районе залива Сан-Франциско, у подножия которой я тогда жил. Когда я об этом узнал, помнится, я сказал: «Да, когда-нибудь это станет отличным названием для видеоигры».

Своеобразная анти-RPG того времени, Diablo многие заложенные в нее решения получила не благодаря, а вопреки. «Посмотри, как делают другие, и сделай ровно наоборот», — примерно по такому принципу и разрабатывалась ее философия.

Но одна из знаковых для игры механик все-таки не была заложена в нее изначально.

Чип Apple M1, доступный в новых MacBook Air, MacBook Pro и Mac Mini, уже стал предметом множества обсуждений, статей о бенчмарках и публикаций в блогах. И производительность его действительно впечатляет, особенно если говорить о производительности на ватт.

Но конкретно сейчас мы остановимся подробнее на трассировке лучей — в частности, на трассировке лучей через API Metal, анонсированный на WWDC-2020.

Для тестов в данной статье использовались Mac Mini и интерактивный трассировщик пути ChameleonRT, а сравнение проводилось с DirectX, Vulkan, OptiX и Embree.

Представьте себе: вот вы ждете новую часть вашей любимой игры и, наконец, она выходит. Специально под это дело вы обновили свой ПК: установили новейшие ЦП и ГП, увеличили объем оперативки и даже заменили жесткий диск на SSD. Теперь игра должна запускаться у вас гладко, как шелк, с первого же экрана загрузки и до самого конца.

Вот вы скачиваете себе ранее оплаченный предзаказ. Завершается установка, вы запускаете игру. Все идет хорошо: игра «летает» с частотой кадров 60 FPS. Или, во всяком случае, так говорит вам счетчик кадров в оверлее вашего ГП. Но что-то идет не так. Вы водите мышкой туда-сюда и замечаете, что игра… фризится.

Как это возможно? Какие еще фризы при 60 FPS?

Это может казаться смешным до тех пор, пока не столкнешься с этим сам. Если вы встречались с такими фризами, то наверняка уже успели их возненавидеть.

Это не лаги. Не низкий фреймрейт. Это статтеринг. При высоких FPS и идеальной сверхбыстрой конфигурации.

Что это такое, откуда взялось и есть ли способ от него избавиться? Сейчас разберемся.

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

В этой статье я расскажу, как на проекте War Robots при создании карт мы учитываем основные механики, усиливаем их положительные стороны и сглаживаем недостатки.

Для начала немного об игре. War Robots — это мобильный сессионный PvP-шутер про огромных роботов. Игроки здесь делятся на две команды и сражаются в одном из режимов: захват маяков или дезматч. Кор-геймплей формируют следующие механики:

После того, как Walt Disney Animation Studios выложила в сеть описание сцены острова из «Моаны», много кто пытался его отрендерить своими силами, исключающими оригинальный Hyperion. Это лишь малая часть списка таких движков:

Hyperion (естественно);

Renderman;

PBRT;

Embree/OSPRay;

A hobby renderer от Джо Шютте (с использованием Embree);

Moana на RTX (с использованием Optix);

GPU-Mononui (с использованием Optix).

Андреас Вендледер из Бабельсбергского киноуниверситета представил другой, написанный им рендерер Gonzales. Он в значительной степени вдохновлен PBRT, написан на Swift (с несколькими строками кода на C ++ для вызова OpenEXR и Ptex) и оптимизирован для проведения рендеринга в (сравнительно) разумные сроки на бесплатном хранилище Google Cloud (8 виртуальных ЦП, 64 ГБ RAM). Насколько автору известно, это единственный рендерер, написанный не на C/C++, способный на рендеринг этой сцены. Написан он с помощью vi и командной строки Swift в Ubuntu Linux и Xcode на macOS, так что скомпилировать его на этих платформах не должно составить труда.

MoonGun — игра в жанре экшен/стратегия о защите лунной базы от астероидов. Игра была создана Ивенсом Серпой — автором множества статей о геймдизайне — в рамках Github Game Off Game Jam в ноябре 2020 года. Занимался он ей в одиночку в свободное от работы время. Игра получила немало положительных отзывов, так что ее создатель решил поделиться опытом ее разработки: описать весь процесс создания и поделиться методами, которые он использовал, включая этапы концепции, планирования, непосредственно разработки и релиза.

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

Стоит заметить, что термин «честность» здесь более уместен, чем «баланс», ведь последний чаще можно истолковать неверно. Честность подразумевается в том смысле, что опыт игроков должен быть выдержанным и правдоподобным. Честный геймплей должен быть приятным и увлекательным, даже если он не совсем четко сбалансирован. Идеальный баланс, в свою очередь, может сделать игру более скучной. По словам ведущего дизайнера Overwatch Джеффа Каплана:

Восприятие баланса гораздо важнее, чем сам баланс.

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

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

Во всех описанных случаях могут быть разные стратегии и отправные точки, которые можно использовать для достижения этой самой честности. Одна из них, на которой мы и сфокусируемся в данной статье, — мощность (Power).

Привет! Меня зовут Владимир Попов, и я клиентский разработчик на проекте War Robots.

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

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

Любая система, которая часто используется в проекте, со временем обречена на эволюцию. Так случилось и с нашей системой реактивного связывания reactive bindings.

Что это за система? Она позволяет нам связывать данные на префабе с данными в коде. У нас есть ViewModel, лежащая на префабе. В ней есть некие ключи с разными типами. Соответственно, вся остальная логика, которая у нас привязана к UI, привязана к этим ключам и их изменениям. То есть, если у нас есть некая логическая переменная, меняя ее в коде, мы можем менять любые состояния UI автоматически.



Использование reactive bindings принесло нам как множество новых возможностей, так и ряд зависимостей. Для связи переменных кода и ViewModel, лежащей на префабе, нам необходимо было соответствие строковых имен. Это приводило к тому, что в результате неосторожной правки префаба или ошибки мерджа могли быть утеряны какие-то из этих связей, а ошибка замечалась уже на этапе поздних тестов в виде отвалившегося UI-функционала.

Росла частота использования системы — росло число подобных сложностей.

Два основных неудобства, с которыми мы столкнулись:

• Строковые ключи в коде;
• Нет проверки соответствия ключей в коде и ключей в модели.

Эта статья — о том, как мы дополнили систему и тем самым закрыли эти потребности.

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

Эта статья — как раз о том, как минимальными усилиями управлять зависимостями между несколькими мобильными сервисами Android и Huawei в одной кодовой базе.