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

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

Моя игра Dragons Abound создаёт карты в векторном графическом формате SVG. Векторная графика имеет множество особенностей (например, зум без потерь), что удобно для карт. Также векторная графика хороша для создания чётких линий, например, чернильных контуров:


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


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

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

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

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

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

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

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

_{Дмитрий Пялов — CTO (слева) и Антон Михайлов — сооснователь и креативный директор (справа). Фотограф: Константин Чалабов}

В стартовый набор Apple Arcade попала игра и русских разработчиков — первых и пока единственных. Студия называется Tortuga Team и известна в основном пошаговой серией Bravelands: битвы, подземелья, магия, корабли и вот это все. Новая игра называется Spaceland, ее действие происходит на заброшенной планете. Вы играете за космического рейнджера, и больше всего это похоже на сильно ускоренный X-COM.

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

Пятница, вечер, хороший повод вспомнить детство золотое.

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

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



Я его спросил, что самое трудное в работе художника-постановщика, а он даже не думал, а сразу сказал — придумать образы. Тут ничего тебе не поможет — ни мастерство, ни опыт — ничего. Можно позвать лучших художников — и провалиться, а можно студентов нанять — и в десятку влупить!

Оригинальный, запоминающийся образ — это самое сложное. У меня, говорит, на это уходило больше всего времени и сил. Но, с другой стороны, это и самое благодарное. Если ты угадал с образом — он тебя будет кормить не годами даже — десятилетиями. Я, говорит, в 1954 году, сразу после смерти Сталина, придумал Мойдодыра для мультфильма Иванова-Вано.



И мне, говорит, до сих пор Procter & Gamble за стиральный порошок «Миф» доплачивает — очень, говорит, весомая прибавка к моей невеликой пенсии получилась.

А все почему?

На прошедшем IT-фестивале Tech Train мы встретились с легендарным Джоном Ромеро, который приложил руку к дизайну и разработке культовых Wolfenstein 3D, Doom и Quake. Мы поговорили о том, нужны ли игровым разработчикам софт-скиллы, на какие рабочие инструменты стоит обратить внимание, и какие у сооснователя Id Software любимые игрушки. Вопросы задавал Никита Цаплин — основатель RUVDS.


→ Англоязычная версия текста и видео здесь

В 1985 году Алексей Пажитнов и Вадим Герасимов выпустили в свет Tetris. Эта увлекательная и вызывающая сильное привыкание игра требовала от игроков соединять фигуры, появлявшиеся в случайном порядке. С того времени было выпущено более 150 лицензионных версий «Тетриса». Отличаясь игровыми режимами, правилами и реализацией, все они игрались слегка (или очень) по-разному. Рандомизатор «Тетриса» — это функция, возвращающая случайно выбранную фигуру. На протяжении многих лет правила выбора фигур эволюционировали, оказывая влияние на геймплей и саму случайность. Некоторые из этих алгоритмов были подвергнуты реверс-инжинирингу и задокументированы. Я составил список рандомизаторов, которые считаю важными, и покажу в статье, как с годами менялось внутреннее устройство «Тетриса».

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

Я уже 25 лет зарабатываю на жизнь написанием инди-игр. У нас с женой есть небольшой семейный бизнес. Мы создаём низкобюджетные ролевые игры в ретро-стиле с отличным сюжетом, дизайном и геймплеем.

Но все они выглядят как куча навоза.

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

Благодаря этой репутации мы провели на Kickstarter успешную кампанию по сбору средств на Queen's Wish: The Conqueror — потрясающую RPG, которая тоже будет выглядеть чудовищно. Мы надеемся, что она станет фундаментом для дальнейшего создания ужасно выглядящих игр.

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

Самое главное заключается в том, что я хочу защитить право инди-разработчиков быть странными. Если у инди-разработчика появится безумная, творческая идея, и он испугается её реализовать, но подумает: «Это можно и сделать; по крайней мере, я не настолько сумасшедший, как Джефф Вогель», то я буду считать свою миссию выполненной.

Итак, если вам интересно, почему мы пишем игры, которые выглядят и ВСЕГДА будут выглядеть как куча навоза, то продолжайте чтение.

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

NB! Значительная часть статьи — это копипаста из конфы проекта без особой обработки. Это сделано специально, чтобы показать настоящие воркфлоу и рабочие материалы, а не их вылизанные для публичного доступа версии.

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

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


Буквами E помечены враги-монстры на арене, а буквой P — игрок, изначально находящийся в коридоре.

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


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

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

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

Алгоритм коллапса волновой функции (Wavefunction Collapse Algorithm) учит компьютер импровизировать. На входе он получает архетипичные данные и создаёт процедурно генерируемые данные, похожие на исходные.


(Источник)

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


(Источник)

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

Большинство реализаций и объяснений коллапса волновой функции — это полная, оптимизированная по скорости версия алгоритма. Разумеется, все они важны и необходимы, но в них сложно разобраться с нуля. В этом посте я буду объяснять всё понятным я простым языком, сосредоточившись на версии Wavefunction с ограничениями, которую я назвал Even Simpler Tiled Model. Кроме того, я выложил пример реализации ESTM на Github. Код в нём неэффективный и медленный, но очень хорошо читаемый и подробно прокомментирован. Как только вы разберётесь в технологии, лежащей в основе ESTM, то станете ближе к пониманию более сложных версий алгоритма. Если хотите понять алгоритм коллапса волновой функции, то эта статья будет хорошим началом.

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

Разбиение пространства

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

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

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


Такого поведения можно избежать несколькими способами. Один из них — ограничить позицию разделения двумя соотношениями длин сторон, например, в интервале от 30% до 70% или от 40% до 60%. Другой способ — использовать вместо равномерного распределения нормальное или биномиальное, благодаря этому повысится вероятность разделения по центру стороны, а не по краям. Эти способы устраняют проблему, но сложно понять, как конкретно параметры влияют на окончательный результат.

Ave!

Дело в том, что я довольно долгое время провела в больнице, и во время лечения начала играть в Star Wars: Knights of the Old Republic на планшете, чтобы хоть как-то отвлечься.

Немного позже наткнулась на статью с несколькими идеями Криса Авеллона о сюжете 3-й части (перевод полной версии статьи). Идеи мне понравились (особенно на фоне того, что сделали в SWTOR), и захотелось узнать ещё что-нибудь про планы Obsidian, и почему 2-ую часть KotOR многие считают провалом, а 3-ю и вовсе отменили.

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

Для эффекта вертикального скроллинга в первой части «The Legend of Zelda» используются манипуляции графическим «железом» NES, скорее всего не предусмотренные разработчиками консоли.


У меня нет доступа к официальной документации Picture Processing Unit (PPU — графический чип) консоли NES, поэтому мои заявления о «неопределённом поведении» скорее ближе к догадкам. Спецификацию работы графического оборудования я взял из NesDev Wiki. PPU управляется записью в регистры с отображением в память. Если использовать эти регистры так, как это было (похоже) задумано проектировщиками, то добиться этого эффекта было бы невозможно:


При скроллинге экрана по вертикали весь экран должен скроллиться разом. В предыдущем GIF показан пример частичного вертикального скроллинга. Часть экрана остаётся стационарной (элементы интерфейса), а другая часть (игровая область) прокручивается по вертикали. Частичный вертикальный скроллинг невозможно реализовать при «стандартной» работе с PPU.

В отличие от него, частичный горизонтальный скроллинг полностью определён и возможен.


Запись в отдельный регистр PPU в момент отрисовки кадра может привести к графическим артефактам. The Legend of Zelda намеренно вызывает артефакт, который проявляется как частичный вертикальный скроллинг. В этом посте я немного расскажу о графическом оборудовании NES и объясню, как работает трюк с вертикальным скроллингом.

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

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

Cities: Skylines — это игра-симулятор города, обладающий достаточной сложностью, чтобы создавать в нём универсальные логические элементы. При помощи универсальных логических элементов можно построить любую схему, в том числе и Тьюринг-полные машины. То есть как и в Minecraft, мы можем создать внутри Cities: Skylines компьютер. Однако было бы очень трудно создавать на основе этих элементов полнофункциональный компьютер, поэтому я продемонстрирую вместо него 4-битный сумматор. Всё выполняется в ванильной версии игры, не требуется ни модов, ни дополнений.

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


Основные участники, слева направо: электростанция на жидком топливе, водонапорная башня, канализационная труба. Сзади стоит ветровая турбина.

Diablo 1 — это классический roguelike 1996 года в жанре hack and slash. Это была одна из первых успешных попыток познакомить широкие массы с roguelike, которые до этого имели нишевую графику в виде ASCII-арта. Игра породила несколько сиквелов и множество имитаций. Она известна своей тёмной, мрачной атмосферой, сгущающейся по мере спуска игрока в подземелья, располагающиеся под городом Тристрам. Это была одна из первых для меня игр с процедурной генерацией карт, и возможность генерации столь правдоподобных уровней просто потрясла меня.

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

Благодарю Дэвида Бревика и команду Blizard North за создание такой потрясающей игры, а также galaxyhaxz и команду Devilution за их удивительную работу по восстановлению читаемого исходного кода проекта.

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

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

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