Блуждающий монстр: как избавиться от проблем на карте

https://caseymuratori.com/blog_0005
  • Перевод
image

Уже в процессе создания The Witness стала одной из самых любимых моих игр. Я начал играть в неё с того момента, когда Джонатан Блоу начал её разработку, и не мог дождаться её релиза.

В отличие от предыдущей игры Джона Braid, масштаб ресурсов и программирования The Witness был гораздо ближе к AAA-проектам, чем к инди-играм. Всем, кто работает над подобными проектами, известно, что объём работы при выборе такого пути значительно возрастает. Над The Witness работало гораздо больше людей, чем над Braid, но как и в случае с любым проектом такого уровня, в нём есть множество аспектов, которые требуют больше внимания, чем может позволить себе руководство проекта.

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

Walkmonster in Wall


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

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

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

Но как назвать систему для обеспечения качества кода движения игрока? Раньше мне никогда не приходилось писать подобный код. Когда я задумался об этом, то осознал, что лично видел пример такого кода только однажды: при игре в раннюю бету Quake. В ней присутствовали баги с расположением монстров, а в окне консоли можно было видеть сообщения об ошибках, гласящие, что монстры, вместо создания на поверхности земли, создаются, частично пересекаясь с геометрией уровней. Каждое отладочное сообщение начиналось с фразы «walkmonster in wall at…»

Бинго! Сложно подобрать для файла кода лучшее название, чем «walk_monster.cpp». И я был почти уверен, что с этого момента код будет создаваться без проблем.

Движение к точке


Когда вы хотите тестировать систему, то самое важное — это на самом деле тестировать систему. Хотя это правило выглядит простым, пишущим тесты людям часто не удаётся его соблюсти.

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

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

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

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

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

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

Стоит также заметить, что этой функции не передаются физические входные данные; например, для начальной точки не указываются скорости. Так сделано потому, что The Witness — это не экшн-игра, поэтому у игрока есть мало значимых физических свойств. Игроки не могут прыгать, бегать по стенам, включать «bullet time». Поддерживать такие поведения можно с помощью систем, которые я опишу позже, но они добавляют уровни сложности, которые в нашем проекте не требовались.

Как бы то ни было, после реализации DriveTowardPoint я мог приступить к решению первой задачи системы: определению того, куда игрок может двигаться на острове The Witness.

Rapidly Exploring Random Trees


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

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

По каким-то причинам я, ещё не написав ни строки кода, почему-то считал, что лучше всего будет использовать Rapidly Exploring Random Tree. Для тех, кто незнаком с этим алгоритмом, объясню: это очень простой процесс, в котором мы записываем все точки, посещённые нами со ссылкой на точку, из которой мы пришли. Чтобы добавить в дерево точку, мы берём случайную целевую точку в любом месте мира, выбираем наиболее близкую к ней точку, уже находящуюся в дереве, и пытаемся добраться из этой точки к целевой. То место, где мы оказались в итоге, становится следующей точкой выборки.

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

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


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


Если бы я задумался об этом перед началом работы, то понял бы, что преимущество алгоритмов наподобие Rapidly Exploring Random Tree заключается в том, что они эффективно исследуют высокоразмерные пространства. На самом деле, обычно это основная причина их использования. Но в The Witness нет высокоразмерных пространств. У нас есть двухмерное пространство (да, распределённая по сложному многообразию, но это всё-таки двухмерное пространство).

В этом низкоразмерном пространстве преимущества Rapidly Exploring Random Tree проявляются слабо, а его недостаток критически важен для моей задачи: алгоритм предназначен для наиболее эффективного поиска путей к соединённым парам точек в пространстве, а не для эффективного поиска всех достижимых точек этого пространства. Если у вас такая задача, то на самом деле у Rapidly Exploring Random Tree уйдёт на её решение огромное количество времени.

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

3D Flood Filling


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

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

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

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

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

Сразу мне в голову мне не приходило никакого хорошего решения, поэтому я решил начать с простых экспериментов. Воспользовавшись написанным мной кодом Rapidly Exploring Random Tree, я сменил выбор целевых точек со случайного на очень контролируемый. При каждом добавлении новой точки в дерево я указывал, что точки находятся на единичном расстоянии вдоль основных направлений от точки, которая будет считаться будущей целевой точкой, как это бывает в простой двухмерной заливке.

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


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


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

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

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

Локализованное направленное сэмплирование


Вероятно, потому, что я начал с Rapidly Exploring Random Tree, мой мозг вытеснил все остальные идеи, кроме идеи близости. Все предыдущие алгоритмы для выполнения своей задачи использовали близость, например, для того, чтобы определить новую точку, которую нужно рассмотреть следующей, или для того, чтобы выбрать точку, с которой нужно начать, чтобы добраться до новой целевой точки.

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

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

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

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


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


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

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

Рудиментарная проверка рёбер


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

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

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


А вот та же область с проверкой рёбер:


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

Быстрые победы


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


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


The Witness должна была стать созерцательной игрой, но задаваться вопросом, почему кажется, что камень есть, хотя его нет, не было одним из её коанов. Как можно догадаться, эта проблема возникла, потому что кто-то оставил в игре объём коллизии после удаления обозначающей его геометрии. Такое может запросто случиться, и очень хорошо, что у нас есть инструмент, способный быстро распознавать такие ошибки, чтобы этого не пришлось делать людям.



Эти объекты должны были стать непроходимыми скалами, но Walk Monster обнаружил, что этого не произошло. Хуже того — Walk Monster обнаружил, что путь почему-то проходим только в одном направлении (на скриншоте — слева направо), а такого быть не должно. Я убедился, что игрок действительно может это сделать (мне удалось). Очень интересно наблюдать за возникновением таких ошибок!

Открытые вопросы


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

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

Во-вторых, как можно улучшить паттерны сэмплирования вокруг границ, чтобы гарантировать нахождение максимального количества «дыр»? Существуют ли хорошие способы характеризации сведения фигур в решётку, и есть ли качественные схемы тесселяции, максимально увеличивающие вероятность пересечения и прохождения через эти фигуры?

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

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

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

Похожие публикации

Комментарии 22

    0
    Удивительно как с таким кодером игра работает.
    Либо это крутой QA-щник.
      –1
      А какой он собственно «кодер»? В статье он свой код не показывает.
        –3
        Сложно подобрать для файла кода лучшее название, чем «walk_monster.cpp»
        — это уже о много говорит.
        Ну и додуматься использовать такой алгоритм, когда есть множество стандартных Navigation Mesh алгоритмов.
          0
          Сложно подобрать для файла кода лучшее название, чем «walk_monster.cpp»

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

          Стандартных, это каких? И на какой черт тут нужен Navigation Mesh, когда задача протестировать проблемные места в пространстве, где игрок может находиться фактически, а не потенциально?
      +5
      Если кому интересно, то Кейси уже два года ведёт онлайн-трансляции разработки зельда-подобной игры без фреймворков и библиотек на голом C/C++. То есть абсолютно с нуля, ни единой библиотеки, прямая работа с буферами (даже вывод аудио guide.handmadehero.org/code/day140). Целью этого проекта является обучение грамотных программистов в эпоху хипстеров тормозных текстовых редакторов на платформе Electron и игровых фреймворков, которые слишком тяжеловесны, неоптимизарованы и не позволяют узнать, как вещи работают на самом деле.

      Уже вышло примерно 500 эпизодов (полтора-два часа в среднем), где код пишется, параллельно объясняется диаграммами guide.handmadehero.org/code/day079/#385 (в данном примере подход к генерации уровней из девяностых в играх Quake и Unreal, спойлер: в квейке берётся кирпич, и в нём вырезаются дыры, создающие пространоство уровня, тогда как в анриле комната изначально пустая, и генерируются блоки, создающие геометрию уровня, так что в квейке нельзя «выпасть» за пределы уровня, а в анриле можно), обсуждаются подходы ООП vs структуры и функции (спойлер: ООП для игр — неэффективно по многим причинам). Спектр тем огромен: эффективное программирование как таковое, компиляция, живая перезагрузка кода программы, отладка, игровая геометрия, камера, fps-независимость, коллизии, текстуры, аудио, анимация и так далее: словом, всё, что нужно для полноценной игры.

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

      Архив ютуба (нагляднее): www.youtube.com/user/handmadeheroarchive/videos
      Архив с темами и метками (структурированнее) handmadehero.org/watch — пролистать ниже до списка эпизодов
        +2
        Тот самый момент, когда комментарий полезней и информативнее статьи.
        Спасибо.
          0
          без фреймворков и библиотек на голом C/C++
          Это не по хардкору. Вот если бы он сначала свой язык написал с компилятором, да на собственноручно собранном компьютере запустил…

          Заголовок спойлера
          Сидит себе бог в раю, тут перед ним появляется ученый и говорит: — Поздравь нас, Господи, ты нам больше не нужен. Мы, ученые, наконец изобрели способ создать жизнь из ничего. Иначе говоря, мы теперь можем сделать то, что ты сделал вначале. — О, вот как? Это интересно… — Да, мы можем взять грязь и слепить из нее подобие тебя, а потом вдохнуть в нее жизнь, и таким образом создать человека. — Здорово, а ну-ка, покажите! — Смотри! — Ученый нагнулся и начал сгребать землю под ногами в кучку. — Эй, минуточку! — прервал его бог. — Ты сначала сам свою землю создай!
            0
            Прекрасный анекдот.

            А по теме: фреймворки написаны людьми. Фреймворк не даёт вам полного понимания, как игра работает под капотом. Когда вы учитесь создавать игры с помощью Unity, вы учитесь создавать игры на Unity. Если завтра Unity сгорит, включит анальный DRM, запросит с вас 90% прибыли или не сможет портироваться на нужную вам платформу из-за религиозных соображений, вы окажетесь в луже. Потому что вы не владеете своей игрой. Вы владеете набором инструкций для Unity. А если вам нужно будет портировать игру на Windows 11 через десять лет, Unity может вовсе не существовать к тому моменту: в таком случае удачи. Когда вы работаете с библиотеками, вы не можете обойти их ограничения. Если библиотека не умеет что-то делать, вам придётся либо лезть в её исходники, изучать, править и пересобирать самому, либо дышать в лапу, если она закрытая, и менять свой стэк.

            Во-вторых, вы будете смеяться, но есть такой парень Jonathan Blow, создатель Braid и The Witness. Он не доволен текущими средствами разработки, и пишет свой язык программирования с компилятором (если не ошибаюсь, с помощью LLVM), заточенный под геймдев. Называется Jai. Посмотрите стрим, например www.youtube.com/watch?v=K2rvoCQksG8 Достаточно хардкорно? Ну или можете ему написать, что он лопух и заблуждается =)
              0
              А разве я где-то утверждал, что сабж лопух и заблуждается? Я вообще о другом. Уметь в низкоуровневое программирование и знать все тонкости — это полезно. В том слысле, что если ты уже их знаешь, то очень круто. Но по соотношению «усилия/результат» изучение этих вещей с нуля может быть субоптимально. 90% (цифра честно взята с потолка) гейм девелоперов вполне достаточно фреймворков. Им никогда не понадобится «портировать игру на Windows 11 через 10 лет». В частности потому, что они никогда не напишут игру, про которую будут помнить через 10 лет.

              Это как веб-дизайн и аналитическая геометрия. Круто, что я математик и могу изобразить какую-нибудь прикольную CSS-анимацию благодаря своему глубокому пониманию замен координат и прочего. Но нельзя сказать, что человек, который этого не понимает так же глубоко, как и я — никудышный фронтендер.
                –1
                Ловко вы переобулись. Насмешливый тон про хардкор, компилятор и собственноручный компьютер звучал отнюдь не двусмысленно =) Наверное, вы просто шутили, а я воспринял всерьёз. Но раз уж начался диалог, отвечу по существу.

                Никто и не говорит, что Handmade Hero нужен всем. Этот проект как раз для тех 10%, которые хотят знать все тонкости и разрабатывать максимально эффективные и оптимизированные игры, а в будущем, возможно, разрабатывать новые технологии, фреймворки и языки. Он возник как реакция компетентного инженера на повальную безграмотность, оказуаливание и конвеерность индустрии разработки игр. Такие дела.
                  0
                  Я шутил о том, что неочевидна грань между абстракциями, потроха которых программист должен знать, и абстракциями более низкого уровня, о которых ему лучше не задумываться.
                +1
                Вообще то вы очень сильно утрируете. В разработке игр достаточно сложностей за пределами движков и умение делать игры прокачивается в отрыве от навыка использования конретного движка.

                Пример того, что у господина из вашей ссылки идет уже 400+ день, а у него ничего по факту ещё нет (кода много, но оно пока ещё ничего не показывает толком), говорит насколько неразумно начинать всё с нуля, если цель сделать игру. Если цель сделать обучающий проект или продвинуть общий уровень технологий в геймдеве то другой вопрос, конечно. Но эти цели надо разделять.
                  0
                  Но ведь это и есть обучающий проект!

                  Смысл каждого эпизода в том, что любое действие разжёвывается. Есть десятки эпизодов, где целый час идёт чисто рисование на доске (вот произведение матриц, например guide.handmadehero.org/code/day362/#354) Потому это и продолжается так долго. Если убрать объяснения (-50% времени), Q&A (-20% времени), на чистый кодинг останется 140 эпизодов средней длиной 1,5 часа (до 350-го эпизоды были короче), то есть 210 часов чистой работы, грубо говоря. Округлим до 240 часов. 240 часов это 3 месяца интенсивной работы. Это крайне мало для того результата, который есть на экране (с учётом разработки с нуля, 100% понимания и полной ответственности за каждую строчку кода, и соответствующей производительности). И не стоит забывать, что значительная часть кода будет использоваться повторно в последующих проектах (аппаратный уровень, алогритмы работы с векторами/матрицами/массивами, камера, управление, инструменты отладки, движок анимации и тд).
                    +1
                    Я ничего не имею против обучающего проекта (как для самообучения так и для других), но нужно понимать, что если цель сделать игру, то нет никакого смысла проделывать кучу работы, которую люди уже многократно проделал. Вот по вашим же собственным словам он сам и делает движок, только свой. А в этом деле невероятное количество подводных камней от платформоспецифичных багов и фичей (по своему типо сжатия текстур на каждый гпу) до архитектурных проблем, которые становятся видны, когда приходит в голову сделать очередную крутую фичу.
                    Если кратко — движки благо, люди, которые могут написать свой движок молодцы, но и люди способные сделать игру на готовом движке тоже молодцы.

                      0
                      Современные небольшие движки хороши для прототипирования. Как было с Dustforce, к примеру. На GameMaker за пару месяцев набросали концепт, а потом пару лет сидели и кодили на C++, потому что игра по сути frame-perfect и не имеет права даже на микрофризы. Эти движки также хорошо могут справиться с простыми и нетребовательными играми (логические, квесты, метроидвании, простые платформеры).

                      В целом же современные движки — палка о двух концах.

                      С одной стороны это благо, потому что уменьшают порог вхождения в индустрию. С другой стороны, это бич, потому что меньшают порог вхождения в индустрию, снижают уровень компетентности и требований (засилие инди-хлама на Steam), используют неоптимальные языки и инструменты (фризы из-за GC, или например любая игра, даже пустой экран, на Godot содержит в себе 30Мб движок, который интерпретирует код, то есть виртуальная машина типа Java), либо вовсе являются монструозными комбайнами (типа Unity, Unreal Engine и CryEngine в гигабайты величиной).

                      Ну и да, приведите примеры AAA-проектов на этих движках? Кроме приснопамятного Star Citizen, разумеется, который никогда не выйдет. В том-то и дело, что такой движок используется либо небольшой студией, либо самой студией-автором движка. Большинство крупных и высокобюджетных тайтлов (Quake/Rage/DOOM 2016/Wolfenstein, Battlefield, Anthem, Dragon Age, GTA, Red Dead Redemption, Call of Duty, Witcher, Uncharted, новые Tomb Raider, Assassin's Creed, Horizon Zero Dawn, Diablo III, Starcraft 2, Overwatch и т.д.) работают на собственных разработках студий. Да, этим движкам дают названия, типа RedEngine, idTech, RAGE, Decima, Frostbite — но они не становятся достоянием общественности, а либо оседают в студии, либо лицензируются за большие деньги. Почему? Наверное, потому что отполированы и заточены под свой внутренний пайплайн. В отличие от конструкторов, которые должны угодить всем, но средненько.

                      Возвращаясь к Handmade Hero. Цель — не просто сделать игру. Цель — научиться делать качественную игру и понимать механизмы, которые лежат у движков под капотом (в определённых пределах).

                      Мне непонятен ваш мотив. Почему вы защищаете людей, которые плодят низкокачественные решения? Соседний пост Моё разочарование в софте за два дня собрал 340 плюсов и 900 комментариев. Люди устали от тормозного, раздутого, неэффективного ПО, которое пишется некомпетентными людьми ради сомнительных целей. Почему вы воспринимаете в штыки проект, который ставит своей целью обучение грамотных программистов?
                        +2
                        Делая handmade hero, Diablo 3 не сделаешь, по нему можно понять и сформулировать базовые принципы и собрать первые шишки. То что в хендмейд хиро сделано это такой минимум, над которым ещё работать и работать, тогда как готовом движке такую игру можно сделать за месяц. Ещё раз повторюсь я понимаю смысл в обучающем проекте, но нельзя тыкать в него и говорить смотрите как человек делает, а все кто делает не так просто хреновые программисты.

                        Вы серьезно спрашиваете есть ли примеры AAA-игр на Unreal? На Unity нет AAA-игр, но есть огромное количество отличных игр с меньшими бюджетами, которые не были бы сделаны или стоили в разы дороже в разработке (а значит не смогли бы окупиться), такие как: Pillars of Eternity, Endless Space/Empires/Dungeons, Wasteland 2, 3, Battlerite и огромное количество других достойных игр, разработчики которых посчитали, что им важнее разрабатывать игру, чем разрабатывать технологию.

                        Мне непонятен ваш мотив. Почему вы защищаете людей, которые плодят низкокачественные решения? Соседний пост Моё разочарование в софте за два дня собрал 340 плюсов и 900 комментариев. Люди устали от тормозного, раздутого, неэффективного ПО, которое пишется некомпетентными людьми ради сомнительных целей. Почему вы воспринимаете в штыки проект, который ставит своей целью обучение грамотных программистов?


                        Я не воспринимаю в штыки проект, я воспринимаю в штыки апломб, с которым вы его преподносите. Предположение что программисты в целом это сборище некомпетентных идиотов, которые без надобности увеличивают сложность кода не верно. Уровни абстракции это то что позволяет разрабатывать в большом количестве и с приемлемой столь ПО той сложности, которая сейчас стала стандартом, да, во многих случаях ценой производительности. А лайки легко объяснимы: на хабре очень много людей около АйТи, а профессиональных программистов не так уж и много, да и меня самого как программиста, конечно, бесит медленное и неэффективное ПО и так и подмывает плюсануть такой благой манифест, однако, я стараюсь удерживаться от мысли что все вокруг идиоты, а я один тут стою красивый.

            0
            спойлер: в квейке берётся кирпич, и в нём вырезаются дыры, создающие пространоство уровня, тогда как в анриле комната изначально пустая, и генерируются блоки, создающие геометрию уровня, так что в квейке нельзя «выпасть» за пределы уровня, а в анриле можно)
            А вы ничего не напутали? Вроде как с точностью до наоборот. Когда начинал делать мапу для Unreal после Quake бы несколько удивлён тем, что изначально уровень заполнен, а не пуст, и комнаты не добавляются, а вырезаются.
              0
              Коротко: вы правы, всё с точностью до наоборот.

              Видимо, Кейси на старости лет стал забываться. В подтверждение, кому интересно, есть наглядная иллюстрация компиляции карты из набора объёмных «кистей»-примитивов в первом Quake.

              image

              Полная статья здесь wikivividly.com/wiki/Quake_engine#Reducing_3D_complexity_to_increase_speed

              Причём в статье не говорится о Constructive Solid Geometry. В квейке реализация пространства идёт через алгоритм BSP-деревьев. Насколько я понимаю, в скомпилированном виде карта квейка выглядит именно как полость, вырезанная внутри бесконечного сплошного материала, и поэтому нельзя провалиться за пределы карты. Отсюда наверное и возникло заблуждение. А вот в Unreal реализована полноценная CSG, позволявшая редактировать геометрию уровня в редакторе на лету. wikivividly.com/wiki/Unreal_Engine#Unreal_Engine_1 Ну и ссылка на статью по конструктивной сплошной геометрии до кучи wikivividly.com/wiki/Constructive_solid_geometry

              Замечу, мы говорим про первые игры Quake и Unreal из девяностых годов. С тех пор многое изменилось.
                0
                Видимо, Кейси на старости лет стал забываться

                Возможно, что он просто сделал неверный вывод про редактор на основе их движков:
                — в Quake — bsp-trees
                image
                — в Unreal — quad-trees, делящие плоскость на квадранты, каждый из которых опять делят
                image
                image
                и потому было бы вполне логично ожидать, что в редакторе будет изначально пустое место.

                DrZlodberg, а можно скриншоты того, чем изначально всё заполнено в Unreal? (сходу не нагугливается)
                  0
                  Тем более странно, потому как с помощью BSP представить «вырезанный» мир сложно. Там просто нет для этого средств. А вот для q-tree это вполне естественно, т.к. он оперирует замкнутыми объёмами.

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

                  Кстати и вывалиться с уровня в кваке вполне можно, если геометрия уровня это позволяет. А вот анрил ввиду вышеупомянутой особенности это позволить не может по определению. Даже при желании.
                    0
                    В Unreal можно через noclip покинуть уровень и увидеть ДВА (!!) скайбокса! И оба скайобокса — в виде коробочек с небом, звёздами, облаками, лунами, светилами и горами. И оба находятся за пределами основного уровня в виде меньших коробочек.
                      0
                      На самом деле не только в Unreal (вроде). Хотя рендерить небо как отдельный объект придумали (опять таки вроде) именно они. По сути небо — это портал в ту коробочку с изменением масштаба.

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

            Самое читаемое