Как сочинить музыку для игры в монгольском сеттинге, если ты не монгол? С таким вопросом я начинал работу над новым проектом. В этой статье я расскажу, что это за проект, как я в него попал и что в итоге получилось.
Пользователь
Как я зарабатывал $10,000 в месяц на серверах ARK: Survival Evolved
Простой
16 мин
Я — ведущий гейм дизайнер с опытом разработки крупных, хардкорных проектов в жанрах от MMORPG и CRPG до мобильной MOBA. Почти три года мы с лучшим другом продюсировали, дизайнили, разрабатывали и занимались живым оперированием своих серверов по игре ARK: Survival Evolved. За это время мы неплохо заработали (в среднем проект приносил $6000-12000 gross ежемесячно). Конечно же, мы столкнулись с тонной сложностей и челленджей, и выучили много уроков. В этой статье я хочу не только рассказать о нашем приключении, но и поделиться выученными уроками. Оперирование кастомных серверов огромных франшиз типа Roblox, Fortnite или Minecraft и других игр похожа на разработку игр в классическом понимании, но имеет под собой свою специфику. Этот опыт будет полезен не только моддерам, но и разработчикам и продюсерам игр.
ARK: Survival Evolved — ММО экшен от 1 и 3-го лица с крафтом, строительством и динозаврами. На динозаврах в игре можно охотиться, можно приручать, ездить на них, разводить и воевать с другими племенами в игре, и это основная фишка, привлекающая игроков. Но настоящая основная особенность игры в том, что карты — собственно, ковчеги, объединены в кластеры, внутри которых игроки могут беспрепятственно путешествовать между карт, превращая мир игры в настоящее ММО — в отличие от большинства остальных подобных игр. Это гениальная игра, о которой невозможно рассказать в двух словах, и она доводит своих игроков до настоящей аддикции, и те проводят в ней тысячи и десятки тысяч часов.
Трёхмерная графика с нуля. Часть 2: растеризация
47 мин
Перевод
Первая часть статьи может быть доказательством того, что трассировщики лучей — это изящный пример программного обеспечения, позволяющий создавать потрясающе красивые изображения исключительно с помощью простых и интуитивно понятных алгоритмов.
К сожалению, эта простота имеет свою цену: низкую производительность. Несмотря на то, что существует множество способов оптимизации и параллелизации трассировщиков лучей, они всё равно остаются слишком затратными с точки зрения вычислений для выполнения в реальном времени; и хотя оборудование продолжает развиваться и становится быстрее с каждым годом, в некоторых областях применения необходимы красивые, но в сотни раз быстрее создаваемые изображения уже сегодня. Из всех этих областей применения самыми требовательными являются игры: мы ожидаем рендеринга отличной картинки с частотой не менее 60 кадров в секунду. Трассировщики лучей просто с этим не справятся.
Тогда как это удаётся играм?
Ответ заключается в использовании совершенно иного семейства алгоритмов, которое мы исследуем во второй части статьи. В отличие от трассировки лучей, которая получалась из простых геометрических моделей формирования изображений в человеческом глазе или в камере, сейчас мы будем начинать с другого конца — зададимся вопросом, что мы можем отрисовать на экране, и как отрисовать это как можно быстрее. В результате мы получим совершенно другие алгоритмы, которые создают примерно похожие результаты.
Хакинг классического Sonic the Hedgehog для Sega
13 мин
В этой статье я хочу разобрать внутреннее устройство легендарной игры Sonic the Hedgehog для приставки Sega Mega Drive, а также способы ее модификации или, как еще говорят, хакинга. Эта игра насчитывает порядка сотни хаков, включающих как действительно достойные работы (такие как Pana Der Hejhog или Sonic Remastered), так и странные и даже жутковатые (вроде An Ordinary Sonic ROM Hack). Чтобы понять, как их создавать, нужно разобраться, как писать на языке ассемеблера Motorola 68K (обычно игры для приставок тех времен писались именно на ассемблере), откуда взять дизассемблированный вариант игры и какую архитектуру имеет ее движок.
Дизассемблирование ROM-файлов для Sega осуществляется при помощи коммерческого дизассемблера и дебаггера IDA Pro. Затем происходит кропотливый процесс разметки, структурирования и причесывания сырого ассемблерного кода с использованием дебаггера (и смекалки). Этот процесс требует хорошего понимания технических особенностей платформы Sega Mega Drive и игр для нее.
К счастью, на GitHub уже есть дизассемблированные и размеченные версии всех игр серии Sonic the Hedgehog, созданные энтузиастами при поддержке сайта Sonic Retro. Лучше всего размечен и структурирован исходный код именно первой игры серии. Эта версия кода находится в репозитории sonicretro / s1disasm и именно она будет разобрана в статье.
Погружение в внутреннее устройство игрушки начнем с теории.
Создание псевдотрёхмерной гоночной игры
17 мин
Перевод
В детстве я редко ходил в залы аркадных автоматов, потому что особо в них не нуждался, ведь дома у меня были потрясающие игры для C64… но есть три аркадные игры, на которые у меня всегда находились деньги — Donkey Kong, Dragons Lair и Outrun…
… и я очень любил Outrun — скорость, холмы, пальмы и музыка, даже на слабой версии для C64.
Поэтому я решил попробовать написать олдскульную псевдотрёхмерную гоночную игру в стиле Outrun, Pitstop или Pole position. Я не планирую собрать полную и завершённую игру, но мне кажется, будет интересно заново изучить механики, при помощи которых эти игры реализовывали свои трюки. Кривые, холмы, спрайты и ощущение скорости…
Итак, вот мой «проект на выходные», который в итоге занял пять или шесть недель по выходным
- Сыграть в игру
- Посмотреть исходный код
Играбельная версия больше напоминает техническое демо, чем реальную игру. На самом деле, если вы хотите создать настоящую псевдотрёхмерную гонку, то это будет самый минимальная основа, которую нужно постепенно превратить в игру.
Она не отшлифована, немного уродлива, но полностью функциональна. Я покажу, как реализовать её самостоятельно за четыре простых шага.
Можно также поиграть
Создание псевдотрёхмерной гоночной игры: реализация холмов и готовая игра
14 мин
Перевод
Часть 3. Холмы
В предыдущей части мы создали простую псевдотрёхмерную гоночную игру, реализовав в ней прямые дороги и кривые.
На этот раз мы займёмся холмами; к счастью, это будет намного проще, чем создание искривлённых дорог.
В первой части мы использовали закон подобных треугольников для создания трёхмерной перспективной проекции:
… что привело нас к получению уравнений проецирования координаты 3d-мира в координату 2d-экрана.
… но так как тогда мы работали только с прямыми дорогами, мировым координатам нужна была только компонента z, потому что и x, и y были равны нулю.
Это хорошо нам подходит, потому что для добавления холмов нам достаточно дать сегментам дороги соответствующую ненулевую координату y, после чего уже имеющаяся функция
render() волшебным образом заработает.Как работает рендеринг 3D-игр: обработка вершин
13 мин
Перевод
В этом посте мы рассмотрим этап работы с вершинами. То есть нам придётся снова достать учебники по математике и вспомнить линейную алгебру, матрицы и тригонометрию. Ура!
Мы выясним, как преобразуются 3D-модели и учитываются источники освещения. Также мы подробно объясним разницу между вершинными и геометрическими шейдерами, и вы узнаете, на каком этапе находится место для тесселяции. Чтобы облегчить понимание, мы используем схемы и примеры кода, демонстрирующие, как в игре выполняются вычисления и обрабатываются значения.
На скриншоте в начале поста показана игра GTA V в каркасном (wireframe) режиме отображения. Сравните её с намного менее сложным каркасным отображением Half-Life 2. Изображения созданы thalixte при помощи ReShade.
Пиксель-арт для начинающих: инструкция по применению
11 мин
Перевод
Инди-разработчикам нередко приходится совмещать сразу несколько ролей: геймдизайнера, программиста, композитора, художника. И, когда дело доходит до визуала, многие выбирают пиксель-арт — на первый взгляд он кажется простым. Но чтобы сделать красиво, нужно много опыта и определенные навыки. Нашел туториал для тех, кто только начал постигать основы этого стиля: с описанием специального софта и техник рисования на примере двух спрайтов.
Действительно ли использование BSP в Doom стало гениальным ходом?
16 мин
Перевод
Вершина технологий того времени.
В 1993 году id Software выпустила шутер от первого лица Doom, который быстро превратился в феномен. Сегодня считается, что это одна из игр, оказавших самое большое влияние за всю историю.
Десять лет спустя после выпуска Doom, в 2003 году, журналист Дэвид Кушнер опубликовал книгу об id Software под названием Masters of Doom, которая с тех пор стала каноническим описанием процесса создания Doom. Я прочитал Masters of Doom несколько лет назад и почти ничего уже не помню, но одна история из книги о ведущем программисте Джоне Кармаке сохранилась в моей памяти. Моё описание будет не совсем точным (подробнее см. ниже), но если вкратце, то на раннем этапе разработки Doom Кармак осознал, что написанный им для игры 3D-рендерер при рендеринге отдельных уровней начинал тормозить. Это было неприемлемо, потому что Doom должен был стать активной и даже бешеной игрой. Осознав, что проблема рендерера была настолько фундаментальной, что ему придётся искать более оптимальный алгоритм рендеринга, Кармак начал читать исследовательские статьи. В результате он реализовал технику под названием «двоичное разбиение пространства» (binary space partitioning, BSP), которая раньше никогда не применялась в видеоиграх, и значительно ускорил таким образом движок Doom.
Эта история о том, как Кармак применил передовые научные исследования к видеоиграм, всегда впечатляла меня. По-моему, именно благодаря этому Кармак стал такой легендарной фигурой. Он заслуживает быть известным в качестве архетипичного гениального программиста видеоигр по множеству причин, но в качестве главной мне всегда вспоминается эпизод с чтением научных статей и двоичным разбиением пространства.
Unity, ECS, Actors: как поднять FPS в своей игре в десять раз, когда оптимизировать уже нечего [с правками]
7 мин
→ Что такое ECS
→ Что такое Actors
Не раз слышал, как хорош шаблон ECS, и что Jobs и Burst из библиотеки Unity — решение всех проблем с быстродействием. Чтобы не добавлять каждый раз слово «наверное» и «может», рассуждая о быстродействии кода, решил проверить всё лично.
Моей целью было непредвзято разобраться, насколько это быстрый инструмент разработки, и стоит ли использовать распараллеливание для вычислений. И если стоит, то лучше использовать Unity.Jobs или System.Threading? Заодно выяснил, какова польза от ECS в реальных задачах.
→ Что такое Actors
Не раз слышал, как хорош шаблон ECS, и что Jobs и Burst из библиотеки Unity — решение всех проблем с быстродействием. Чтобы не добавлять каждый раз слово «наверное» и «может», рассуждая о быстродействии кода, решил проверить всё лично.
Моей целью было непредвзято разобраться, насколько это быстрый инструмент разработки, и стоит ли использовать распараллеливание для вычислений. И если стоит, то лучше использовать Unity.Jobs или System.Threading? Заодно выяснил, какова польза от ECS в реальных задачах.
Моддеры потратили 15 лет на исправление Knights of the Old Republic 2
7 мин
Перевод
Star Wars Knights of the Old Republic 2: The Sith Lords (KOTOR2), выпущенная 6 декабря 2004 года, стала первой игрой новорождённой Obsidian Entertainment. В то время новая студия состояла всего из семи разработчиков-ветеранов, ушедших из закрытой Black Isle Studios и окопавшихся на чердаке CEO компании Фергуса Уркхарта. Но издатель LucasArts, желающий снять сливки с успеха первой KOTOR, выпущенной в предыдущем году, дал этой потрёпанной новой команде на создание сиквела всего 14-16 месяцев.
Неудивительно, что у готового продукта возникали проблемы.
Самой заметной из таких проблем, выявленных на момент выпуска игры, стало завершение побочного квеста с фабрикой HK-50. Если конкретнее, то в готовой игре это завершение квеста отсутствовало.
Это означало, что игроки никогда не узнают причины возникновения самой часто встречающейся в KOTOR2 угрозы. В файлах, погребённых в коде игры, обнаружился контент, который Obsidian создала для последней планеты KOTOR2, в том числе диалоги и декорации, которые разработчики попросту не успели заставить работать до выпуска продукта.
И благодаря этому возникла коллективная моддерская одержимость, длившаяся 15 лет…
Воссоздание в новой игре того, за что мы любили старые
12 мин
В процессе работы над своей игрой, которая повторяет некоторые элементы старых игр, я задумался, а так ли необходимо намеренно придерживаться ретро-стиля. И за что мы, собственно, любим старые игры? Не воспринимаем ли мы понятие ретро-игр слишком буквально и стереотипно?
Вообще, что такое ретро-игра? Скорее всего, первое, что придет на ум большинству — это модный нынче пиксель-арт. Если это 2D, то нарисуйте множество пиксельных спрайтов, сделайте слегка угловатые движения персонажей — и готово. Если это 3D, то… Ну, наверно, нужно понизить разрешение текстур, реализовать движение игрока в стиле «бульдозер», как это было в первом Doom, стрелочками вперед-назад-влево-вправо, добавить слегка мультяшных персонажей и… Я уж не знаю, как еще сделать современный клон старого Doom или Quake. Но в этом ли, в действительности, заключается дух старых игр? Уверяю вас, нет.
Это норма: что такое карты нормалей и как они работают
6 мин
Перевод
На протяжении нескольких лет я пытался разобраться в картах нормалей и в проблемах, которые обычно возникают при работе с ними.
Большинство найденных объяснений было слишком техническим, неполным или чересчур сложным для моего понимания, поэтому я решил попробовать объяснить собранную мной информацию. Я понимаю, что эти объяснения могут быть неполными или не совсем точными, но всё равно попробую.
Первые созданные человеком 3D-модели выглядели примерно так:
Это замечательно, но у такой модели есть очевидное ограничение: она выглядит слишком полигональной.
Наиболее очевидное решение: добавить больше полигонов, сделав поверхность более равномерной и гладкой, вплоть до того, чтобы полигоны казались единой гладкой поверхностью. Но оказывается, для того, чтобы сделать поверхности наподобие сфер гладкими, нужно огромное количество полигонов (особенно сегодня).
Большинство найденных объяснений было слишком техническим, неполным или чересчур сложным для моего понимания, поэтому я решил попробовать объяснить собранную мной информацию. Я понимаю, что эти объяснения могут быть неполными или не совсем точными, но всё равно попробую.
Первые созданные человеком 3D-модели выглядели примерно так:
Это замечательно, но у такой модели есть очевидное ограничение: она выглядит слишком полигональной.
Наиболее очевидное решение: добавить больше полигонов, сделав поверхность более равномерной и гладкой, вплоть до того, чтобы полигоны казались единой гладкой поверхностью. Но оказывается, для того, чтобы сделать поверхности наподобие сфер гладкими, нужно огромное количество полигонов (особенно сегодня).
Процедурная генерация многоэтажных 3D-подземелий
6 мин
Перевод
В последнее время я играл в несколько roguelike, поэтому решил попробовать написать собственный процедурный генератор подземелий. Существует множество способов решения этой задачи, и я выбрал алгоритм автора TinyKeep, описанный здесь. Я расширил этот алгоритм, чтобы он работал в 3D и мог создавать многоэтажные подземелья.
Код примера выложен в репозитории Github. Для демонстрации я использую Unity3D, но эти концепции, разумеется, применимы к любому другому движку.
Два измерения
Сначала мне нужно написать алгоритм для двух измерений. В целом он работает так же, как алгоритм TinyKeep, но имеет отличия для создания более интересных уровней.
Сцена для этого примера называется Dungeon2D. Код для него находится в папке Scripts2D.
Алгоритм
Мир разделён в виде прямоугольной сетки. Я предполагаю, что 1 единицы будет достаточно для обозначения коридора. В полной игре 1 единица измерения Unity может соответствовать например 5 метрам. Для сетки я выбрал размер 30×30.
Как работает рендеринг 3D-игр: растеризация и трассировка лучей
18 мин
Перевод
Часть 1: обработка вершин
В этой статье мы подробнее рассмотрим то, что происходит с 3D-миром после завершения обработки всех его вершин. Нам снова придётся стряхнуть пыль с учебников по математике, освоиться в геометрии пирамид усечения и решить загадку перспектив. Также мы ненадолго погрузимся в физику трассировки лучей, освещения и материалов.
Главная тема этой статьи — важный этап рендеринга, на котором трёхмерный мир точек, отрезков и треугольников становится двухмерной сеткой разноцветных блоков. Очень часто этот процесс кажется незаметным, потому что преобразование из 3D в 2D оказывается невидимым, в отличие от процесса, описанного в предыдущей статье, где мы сразу же могли увидеть влияние вершинных шейдеров и тесселяции. Если вы пока не готовы к этому, то можете начать с нашей статьи 3D Game Rendering 101.
Подготовка к двум измерениям
Подавляющее большинство читателей читают этот веб-сайт на совершенно плоском мониторе или экране смартфона; но даже если у вас есть современная техника — изогнутый монитор, то отображаемая им картинка тоже состоит из плоской сетки разноцветных пикселей. Тем не менее, когда вы играете в новую Call of Mario: Deathduty Battleyard, изображения кажутся трёхмерными. Объекты движутся по сцене, становятся больше или меньше, приближаясь и отдаляясь от камеры.
Как работают пули в видеоиграх?
6 мин
Перевод
Игры FPS (first-person shooter, шутер от первого лица) стали неотъемлемой частью видеоигровой индустрии ещё с момента появления в 1992 году популярнейшей Wolfenstein 3D. С тех пор жанр эволюционировал: улучшалась графика, увеличивались бюджеты на разработку, развивалась экосистема киберспорта. Но что насчёт их фундамента — механики стрельбы? Как проходило развитие на этом фронте? Почему в некоторых играх оружие кажется реальными, а в других похоже на игрушки?
В предыдущую эпоху многие игры для рендеринга 3D-сцен в 2D-изображения использовали технику под названием raycasting («бросание лучей»). Raycasting позволяет движку определять первый объект, с которым пересечётся луч. Но потом разработчики задались вопросом: «Что, если выпустить луч из ствола оружия, чтобы имитировать пулю?» Благодаря этой идее родился hitscan («сканирование попадания»).
Пример raycasting
В большинстве реализаций оружия с hitscan при выстреле игрока физический движок выполняет следующие операции:
Если движок определил, что объект находится на линии огня, то он сообщит ему об этом, сказав, что в него «попала» пуля. Затем цель может выполнить все вычисления, необходимые для регистрации повреждений.
Hitscan
В предыдущую эпоху многие игры для рендеринга 3D-сцен в 2D-изображения использовали технику под названием raycasting («бросание лучей»). Raycasting позволяет движку определять первый объект, с которым пересечётся луч. Но потом разработчики задались вопросом: «Что, если выпустить луч из ствола оружия, чтобы имитировать пулю?» Благодаря этой идее родился hitscan («сканирование попадания»).
Пример raycasting
В большинстве реализаций оружия с hitscan при выстреле игрока физический движок выполняет следующие операции:
- Определяет направление, в котором указывает оружие.
- Выпускает из ствола оружия луч на заданное расстояние.
- Использует raycasting для определения того, попал ли луч в объект.
Если движок определил, что объект находится на линии огня, то он сообщит ему об этом, сказав, что в него «попала» пуля. Затем цель может выполнить все вычисления, необходимые для регистрации повреждений.
Как была устроена графика NES
14 мин
Перевод
Выпущенная в 1983 году домашняя консоль Nintendo Entertainment System (NES) была дешёвой, но мощной машиной, достигшей феноменального успеха. При помощи блока обработки изображений (Picture Processing Unit, PPU) система могла создавать достаточно впечатляющую по тем временам графику, которая и сегодня в нужном контексте выглядит вполне неплохо. Самым важным аспектом была эффективность памяти — при создании графики приходилось обходиться как можно меньшим количеством байтов. Однако вместе с этим NES предоставила разработчикам мощные и простые в использовании функции, позволившие ей выделиться на фоне более старых домашних консолей. Поняв принципы создания графики NES, можно проникнуться техническим совершенством системы и осознать, насколько проще работать современным разработчикам игр.
Фоновая графика NES собиралась из четырёх отдельных компонентов, комбинация которых образовывала изображение, которое мы видим на экране. Каждый компонент отвечал за отдельный аспект; цвет, расположение, «сырая» пиксельная графика и т.д. Такая система может показаться излишне сложной и громоздкой, но в конечном итоге она намного эффективнее использовала память и позволяла создавать простые эффекты в малом объёме кода. Если вы хотите понимать графику NES, то ключевой информацией будут эти четыре компонента.
В этой статье подразумевается, что вы знакомы с компьютерной математикой, и в частности с тем, что 8 бит = 1 байт, а 8 бит могут обозначать 256 значений. Также необходимо понимание того, как работает шестнадцатеричная запись. Но даже без этих технических знаний статья может показаться интересной.
Создаём свою Minecraft: генерация 3D-уровней из кубов
24 мин
Перевод
Частично из-за популярности Minecraft, в последнее время наблюдается рост интереса к идее игры, действие которой происходит в состоящем из кубов мире, построенном из 3D-рельефа и заполненного такими элементами, как пещеры, обрывы и так далее. Такой мир — идеальное применение для шума, сгенерированного в стиле моей библиотеки ANL. Данная статья возникла из обсуждений моих предыдущих попыток реализации этой техники. С тех пор в структуре библиотеки появились незначительные изменения.
В предыдущих постах я рассказывал об использовании функций 3D-шума для реализации рельефа в стиле Minecraft. После этого библиотека немного эволюционировала, поэтому я решил вернуться к этой теме. Так как мне пришлось отвечать на множество вопросов по этой системе, я попытаюсь более подробно рассказать о задействованных концепциях. Чтобы базовые концепции были понятнее, я начну с идеи генерации 2D-рельефа, используемого в таких играх, как Terraria и King Arthur's Gold, а затем расширю систему до 3D-примеров наподобие Minecraft. Это позволит мне эффективнее демонстрировать концепции на примере изображений.
Эта система разрабатывалась с учётом следующей абстрактной цели: мы должны иметь возможность передать системе координату определённой точки или ячейки, и определить, какой тип блока должен находиться в этой локации. Мы хотим, чтобы система представляла собой «чёрный ящик»: передаём ей точку, возвращаем тип блока. Разумеется, это относится только к изначальной генерации мира. Блоки в подобных играх могут изменяться действиями игрока, и будет неудобно пытаться описать такие изменения при помощи такой же системы. Подобные изменения должны отслеживаться каким-то иным образом. Эта система генерирует изначальный мир, первозданный и нетронутый руками игрока и других персонажей.
LeanChess — самые маленькие компьютерные шахматы в мире
2 мин
Меня зовут Дмитрий Шехтман, и я автор самых маленьких компьютерных шахмат в мире.
Началось всё с того, что моя (ныне бывшая) девушка предложила написать компьютерные шахматы. Идея меня заинтересовала, и я решил этим заняться. Правда, почитав интернет, я понял, что опоздал лет на сорок. Особенно впечатляли шахматные разработки Оскара Толедо — на Си размером в 1257 байт, на JavaScript в 1023 байта и, наконец, Atomchess на ассемблере x86, компилирующийся в 392 байта.
Прежде, чем я вернулся к теме, прошло несколько месяцев. Как оказалось, за это время был установлен новый рекорд размера — ChesSkelet для ZX Spectrum занимал всего 352 байта. Правда, он не знал всех правил и играл весьма слабо, но всё же! А не замахнуться ли мне на шахматы на ассемблере? — подумал я.
Как работал графический чип Super Nintendo: руководство по Super PPU
5 мин
Перевод
Описание концепций PPU
Super PPU
Super "Picture Processing Unit" — чип видеоконтроллера, обрабатывающий тайловую графику, плоскости скроллинга и спрайты SNES. По функциям схож с PPU консоли NES.
VRAM
VideoRAM — ОЗУ, используемое Super PPU. Содержит тайлы. В каждом режиме экрана используется собственный размер тайлов. Обычно это 8x8 или 16x16 пикселей на тайл. VRAM имеет объём 64 КБ.
OAM
«Object Attribute Memory» — содержит данные определений спрайтов. Может содержать данные не более чем 128 спрайтов. Схожа с OAM в NES, но более совершенная.