От переводчика: Это перевод второй статьи из цикла «Networking for game programmers». Мне очень нравится весь цикл статей, плюс всегда хотелось попробовать себя в качестве переводчика. Возможно, опытным разработчикам статья покажется слишком очевидной, но, как мне кажется, польза от нее в любом случае будет.
Первая статья — http://habrahabr.ru/post/209144/

---

Прием и передача пакетов данных

Введение

Привет, меня зовут Гленн Фидлер и я приветствую вас в своей второй статье из цикла “Сетевое программирование для разработчиков игр”.


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

А сейчас я собираюсь рассказать вам, как на практике использовать UDP для отправки и приема пакетов.

BSD сокеты

В большинстве современных ОС имеется какая-нибудь реализация сокетов, основанная на BSD сокетах (сокетах Беркли).

Сокеты BSD оперируют простыми функциями, такими, как “socket”, “bind”, “sendto” и “recvfrom”. Конечно, вы можете обращаться к этим функциями напрямую, но в таком случае ваш код будет зависим от платформы, так как их реализации в разных ОС могут немного отличаться.

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

Эффект тумана войны из Civilization VI — отличный пример простой структуры вычислительного шейдера (compute shader). Если вы всегда хотели узнать об основах программирования таких шейдеров, то этот туториал для вас. Вы сможете понять его даже без знания шейдеров и программирования на C#; более опытные разработчики могут пропустить введение.

Анализ эффекта

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


Первое, на что нам нужно обратить внимание — граница между видимой и скрытой областями. «Скрытая» область — это напоминающая нарисованную от руки карту область, покрытая туманом войны. Мы чётко можем видеть, что граница не совпадает точно с полями шестиугольников и что присутствует небольшой шум, скорее всего шум Перлина.

Привет, читатель!

Некоторые из вас видели набор букв“qwerty”. Qwerty — это раскладка клавиатуры. Посмотрите на вашу клавиатуру. Вы увидите в верхнем ряду буквы «q»«w»«e»«r»«t»«y». А по какой причине нам интересна раскладка клавиатуры?

Ещё давно, когда люди пользовались печатными машинками, печатали они довольно быстро. Это создавало проблемы: головки печатной машинки, бьющие по бумаге и печатающие на ней буквы, цеплялись друг за друга, что приводило к поломке. Была создана раскладка qwerty, в которой рядом стоящие в словах буквы были размещены на максимально большом расстоянии друг от друга. Таким образом была решена проблема.

Печатными машинками давно никто не пользуется, и проблема соприкосновения печатающих головок исчезла. Факт того, что мы перестали пользоваться неудобной раскладкой клавиатуры логичен. Но, есть загвоздка – такого факта не существует, люди привыкли печатать на раскладке «qwerty» и не хотят переучиваться.

Сейчас, зайдя в настройки, вы можете переключить раскладку клавиатуры на «dvorak». Печать ускорится в разы, в то время как обучение займёт лишь неделю. К сожалению, никому не выгодно быть единственным переучившимся, потому что за любым компьютером, кроме личного, работать будет неудобно. А также, к сожалению или к счастью, людям лень переучиваться. Хотя вместе, приложив усилия и переучившись, мы могли бы увеличить пропускную способность набора текста в разы.

Подводя итоги: при массовом использовании «qwerty», переход отдельного игрока на «dvorak» не эффективен, хотя переход общества на «dvorak» эффективен.

Всем привет. Все кто хоть немного разбирался в теме OpenGL знают, что существует большое количество статей и курсов по этой теме, но многие не затрагивают современный API, а часть из них вообще рассказывают про glBegin и glEnd. Я постараюсь охватить некоторые нюансы нового API начиная с 4-й версии. Ссылка на вторую часть статьи

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

У моего ShaderToy были три основные задачи:

1. Выполнение в реальном времени
2. Простота
3. Физическая корректность (… или типа того)

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

1. Трассировка лучей непрозрачных объектов. Все объекты являются примитивами с простыми пересечениями с лучами (1 плоскость и 3 сферы)
2. Для вычисления освещения используется затенение по Фонгу, а в трёх сферических источниках света применется настраиваемый коэффициент затухания света. Лучи теней не требуются, потому что мы освещаем только плоскость.

Вот как это выглядит:

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

Из этой статьи вы узнаете о картах высот (height maps), также называемых картами параллакса (parallax maps).

Что такое карта высот?

Как обычно, когда я говорю «карта», то имеют в виду текстуру, содержащую информацию о внешнем виде 3D-объекта. Карта высот/параллакса — это карта, которую можно использовать для того, чтобы создать иллюзию того, что одни части объекта выступают сильнее, чем другие, то есть имеют бОльшую высоту.


Без карты высот.


С картой высот.

По описанию это может показаться очень похожим на карту нормалей (normal map), благодаря которой 3D-объект кажется более рельефным, но действует она немного иначе. Карта нормалей использует освещение, чтобы объект казался более рельефным, чем на самом деле. Карта высот использует параллакс, чтобы сделать объект выше, чем на самом деле.

Что такое октодеревья? Если вам совершенно неизвестно это понятие, то рекомендую прочитать статью в Википедии (это займёт около пяти минут). Она даёт достаточное представление, но едва ли её будет достаточно, чтобы понять, для чего они используются и как их реализовать.

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

Предисловие

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

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

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

Первые шаги

На поиск среды, способной работать с этой игрой, у меня ушло несколько дней. Протестировав несколько версий RenderDoc и PIX, я остановился на изучении результатов трассировки лучей с помощью Nvidia NSight. Я хотел изучать рендеринг без функций raytracing, но NSight позволял исследовать подробности и этой функции, поэтому я решил оставить её включённой. Для всего остального рендеринга вполне подошёл PIX. Скриншоты сделаны с помощью обоих приложений.

Для того, чтобы получить реалистичный мир внутри игры, необходимо учитывать взаимодействие различных форм рельефа между собой и с другими моделями. И если видимые линии пересечения между 3D-моделями портят органичность изображения, стоит задуматься над тем, как их устранить. Самый распространенный случай таких линий, который может быть знаком многим, — пересечение билбордов частиц с непрозрачной геометрией.



Другой пример — нарушающие естественность композиции пересечения скал и растительности с поверхностью ландшафта в сценах «на открытом воздухе».



Помимо разнообразных методов сглаживания (SSAA, MSAA, CSAA, FXAA, NFAA, CMAA, DLAA, TAA и др.), которые пусть и смягчают вызывающий внешний вид таких линий пересечений, но не исправляют ситуацию в полной мере, существуют и более действенные приемы. Их мы и рассмотрим.

Разработчикам при создании игры приходится искать баланс не только в механиках, но и в физике. Реализм или аркада? В общем-то, кому что нравится. Главное — фан и удовольствие. Нужно создать фундаментальные законы своего мира, и объяснить, что возможность ходить по потолку — механика, а не баг.

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

В последнее время я играл в несколько roguelike, поэтому решил попробовать написать собственный процедурный генератор подземелий. Существует множество способов решения этой задачи, и я выбрал алгоритм автора TinyKeep, описанный здесь. Я расширил этот алгоритм, чтобы он работал в 3D и мог создавать многоэтажные подземелья.

Код примера выложен в репозитории Github. Для демонстрации я использую Unity3D, но эти концепции, разумеется, применимы к любому другому движку.

Два измерения

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

Сцена для этого примера называется Dungeon2D. Код для него находится в папке Scripts2D.

Алгоритм

Мир разделён в виде прямоугольной сетки. Я предполагаю, что 1 единицы будет достаточно для обозначения коридора. В полной игре 1 единица измерения Unity может соответствовать например 5 метрам. Для сетки я выбрал размер 30×30.

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

Статья рассчитана на начинающих разработчиков игр.

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

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

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

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

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

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

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

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

//обновления данных, полученных с устройств ввода
cotrols->Update()
...
void Player::Move()
{
  if (controls->MouseButonPressed(0))
  {
     ...
  }

  if (controls->KeyPressed(KEY_SPACE))
  {
     ... 
  }

  if (controls->JoystickButtonPressed(0))
  {
     ...
  }
}

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

Что можно предложить для решения проблемы?

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

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

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

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

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

Немного о контексте (GPU)

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

При заполнении области объектами (например, комнатами в подземелье) в случайном порядке вы рискуете тем, что всё будет слишком случайным. Результат может оказаться абсолютно бесполезным хаосом. В этом туториале я покажу, как использовать для решения этой проблемы двоичное разбиение пространства (Binary Space Partitioning, BSP).

Я подробно и по этапам расскажу об использовании BSP для создания простой двухмерной карты, к примеру, схемы подземелья. Я покажу, как создать простой объект Leaf, который мы используем для разделения области на маленькие сегменты. Затем мы займёмся генерированием в каждом Leaf случайной комнаты. И, наконец, узнаем, как соединить все комнаты коридорами.

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

Перевод статьи Джеффа Прешинга (Jeff Preshing) How to Write Your Own C++ Game Engine.

Как написать собственный игровой движок на C++

В последнее время я занят тем, что пишу игровой движок на C++. Я пользуюсь им для создания небольшой мобильной игры Hop Out. Вот ролик, записанный с моего iPhone 6. (Можете включить звук!)

Hop Out — та игра, в которую мне хочется играть самому: ретро-аркада с мультяшной 3D-графикой. Цель игры — перекрасить каждую из платформ, как в Q*Bert.

Hop Out всё ещё в разработке, но движок, который приводит её в действие, начинает принимать зрелые очертания, так что я решил поделиться здесь несколькими советами о разработке движка.

С чего бы кому-то хотеть написать игровой движок? Возможных причин много: