Комментарии 23
Удивительно как с таким кодером игра работает.
Либо это крутой QA-щник.
Либо это крутой QA-щник.
А какой он собственно «кодер»? В статье он свой код не показывает.
Сложно подобрать для файла кода лучшее название, чем «walk_monster.cpp»— это уже о много говорит.
Ну и додуматься использовать такой алгоритм, когда есть множество стандартных Navigation Mesh алгоритмов.
Сложно подобрать для файла кода лучшее название, чем «walk_monster.cpp»
Это был кодерский юмор.
Ну и додуматься использовать такой алгоритм, когда есть множество стандартных Navigation Mesh алгоритмов.
Стандартных, это каких? И на какой черт тут нужен Navigation Mesh, когда задача протестировать проблемные места в пространстве, где игрок может находиться фактически, а не потенциально?
Самое забавное, что при этом они всё-таки умудрились пропустить как минимум одно место. И попутно раскрыли другую любопытную информацю о карте.
Подробно рассказано в этом видео. Вкратце: при путешествии на лодке из неё минимум в одном месте можно выпасть. Судя по отладочной сетке — граница была проверена этим самым алгоритмом (очень похожая визуализация). А ещё видео наводит на мысль, что у лодки нет коллайдера двери, а его роль в движении выполняет невидимый тоннель(!?) в котором движется лодка. Решение довольно странное, но любопытное.
Подробно рассказано в этом видео. Вкратце: при путешествии на лодке из неё минимум в одном месте можно выпасть. Судя по отладочной сетке — граница была проверена этим самым алгоритмом (очень похожая визуализация). А ещё видео наводит на мысль, что у лодки нет коллайдера двери, а его роль в движении выполняет невидимый тоннель(!?) в котором движется лодка. Решение довольно странное, но любопытное.
Если кому интересно, то Кейси уже два года ведёт онлайн-трансляции разработки зельда-подобной игры без фреймворков и библиотек на голом 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 — пролистать ниже до списка эпизодов
Уже вышло примерно 500 эпизодов (полтора-два часа в среднем), где код пишется, параллельно объясняется диаграммами guide.handmadehero.org/code/day079/#385 (в данном примере подход к генерации уровней из девяностых в играх Quake и Unreal, спойлер: в квейке берётся кирпич, и в нём вырезаются дыры, создающие пространоство уровня, тогда как в анриле комната изначально пустая, и генерируются блоки, создающие геометрию уровня, так что в квейке нельзя «выпасть» за пределы уровня, а в анриле можно), обсуждаются подходы ООП vs структуры и функции (спойлер: ООП для игр — неэффективно по многим причинам). Спектр тем огромен: эффективное программирование как таковое, компиляция, живая перезагрузка кода программы, отладка, игровая геометрия, камера, fps-независимость, коллизии, текстуры, аудио, анимация и так далее: словом, всё, что нужно для полноценной игры.
Следует оговориться, что на данный момент проект всё ещё далёк от завершения, наполнение как таковой игры отсутствует, и потребуется ещё не один год, чтобы довести это проект до состояния игры. Однако такое количество информации, представленное настолько наглядно, не найти ни в одной книге или обучающем курсе.
Архив ютуба (нагляднее): www.youtube.com/user/handmadeheroarchive/videos
Архив с темами и метками (структурированнее) handmadehero.org/watch — пролистать ниже до списка эпизодов
Тот самый момент, когда комментарий полезней и информативнее статьи.
Спасибо.
Спасибо.
без фреймворков и библиотек на голом C/C++Это не по хардкору. Вот если бы он сначала свой язык написал с компилятором, да на собственноручно собранном компьютере запустил…
Заголовок спойлера
Сидит себе бог в раю, тут перед ним появляется ученый и говорит: — Поздравь нас, Господи, ты нам больше не нужен. Мы, ученые, наконец изобрели способ создать жизнь из ничего. Иначе говоря, мы теперь можем сделать то, что ты сделал вначале. — О, вот как? Это интересно… — Да, мы можем взять грязь и слепить из нее подобие тебя, а потом вдохнуть в нее жизнь, и таким образом создать человека. — Здорово, а ну-ка, покажите! — Смотри! — Ученый нагнулся и начал сгребать землю под ногами в кучку. — Эй, минуточку! — прервал его бог. — Ты сначала сам свою землю создай!
Прекрасный анекдот.
А по теме: фреймворки написаны людьми. Фреймворк не даёт вам полного понимания, как игра работает под капотом. Когда вы учитесь создавать игры с помощью Unity, вы учитесь создавать игры на Unity. Если завтра Unity сгорит, включит анальный DRM, запросит с вас 90% прибыли или не сможет портироваться на нужную вам платформу из-за религиозных соображений, вы окажетесь в луже. Потому что вы не владеете своей игрой. Вы владеете набором инструкций для Unity. А если вам нужно будет портировать игру на Windows 11 через десять лет, Unity может вовсе не существовать к тому моменту: в таком случае удачи. Когда вы работаете с библиотеками, вы не можете обойти их ограничения. Если библиотека не умеет что-то делать, вам придётся либо лезть в её исходники, изучать, править и пересобирать самому, либо дышать в лапу, если она закрытая, и менять свой стэк.
Во-вторых, вы будете смеяться, но есть такой парень Jonathan Blow, создатель Braid и The Witness. Он не доволен текущими средствами разработки, и пишет свой язык программирования с компилятором (если не ошибаюсь, с помощью LLVM), заточенный под геймдев. Называется Jai. Посмотрите стрим, например www.youtube.com/watch?v=K2rvoCQksG8 Достаточно хардкорно? Ну или можете ему написать, что он лопух и заблуждается =)
А по теме: фреймворки написаны людьми. Фреймворк не даёт вам полного понимания, как игра работает под капотом. Когда вы учитесь создавать игры с помощью Unity, вы учитесь создавать игры на Unity. Если завтра Unity сгорит, включит анальный DRM, запросит с вас 90% прибыли или не сможет портироваться на нужную вам платформу из-за религиозных соображений, вы окажетесь в луже. Потому что вы не владеете своей игрой. Вы владеете набором инструкций для Unity. А если вам нужно будет портировать игру на Windows 11 через десять лет, Unity может вовсе не существовать к тому моменту: в таком случае удачи. Когда вы работаете с библиотеками, вы не можете обойти их ограничения. Если библиотека не умеет что-то делать, вам придётся либо лезть в её исходники, изучать, править и пересобирать самому, либо дышать в лапу, если она закрытая, и менять свой стэк.
Во-вторых, вы будете смеяться, но есть такой парень Jonathan Blow, создатель Braid и The Witness. Он не доволен текущими средствами разработки, и пишет свой язык программирования с компилятором (если не ошибаюсь, с помощью LLVM), заточенный под геймдев. Называется Jai. Посмотрите стрим, например www.youtube.com/watch?v=K2rvoCQksG8 Достаточно хардкорно? Ну или можете ему написать, что он лопух и заблуждается =)
А разве я где-то утверждал, что сабж лопух и заблуждается? Я вообще о другом. Уметь в низкоуровневое программирование и знать все тонкости — это полезно. В том слысле, что если ты уже их знаешь, то очень круто. Но по соотношению «усилия/результат» изучение этих вещей с нуля может быть субоптимально. 90% (цифра честно взята с потолка) гейм девелоперов вполне достаточно фреймворков. Им никогда не понадобится «портировать игру на Windows 11 через 10 лет». В частности потому, что они никогда не напишут игру, про которую будут помнить через 10 лет.
Это как веб-дизайн и аналитическая геометрия. Круто, что я математик и могу изобразить какую-нибудь прикольную CSS-анимацию благодаря своему глубокому пониманию замен координат и прочего. Но нельзя сказать, что человек, который этого не понимает так же глубоко, как и я — никудышный фронтендер.
Это как веб-дизайн и аналитическая геометрия. Круто, что я математик и могу изобразить какую-нибудь прикольную CSS-анимацию благодаря своему глубокому пониманию замен координат и прочего. Но нельзя сказать, что человек, который этого не понимает так же глубоко, как и я — никудышный фронтендер.
Ловко вы переобулись. Насмешливый тон про хардкор, компилятор и собственноручный компьютер звучал отнюдь не двусмысленно =) Наверное, вы просто шутили, а я воспринял всерьёз. Но раз уж начался диалог, отвечу по существу.
Никто и не говорит, что Handmade Hero нужен всем. Этот проект как раз для тех 10%, которые хотят знать все тонкости и разрабатывать максимально эффективные и оптимизированные игры, а в будущем, возможно, разрабатывать новые технологии, фреймворки и языки. Он возник как реакция компетентного инженера на повальную безграмотность, оказуаливание и конвеерность индустрии разработки игр. Такие дела.
Никто и не говорит, что Handmade Hero нужен всем. Этот проект как раз для тех 10%, которые хотят знать все тонкости и разрабатывать максимально эффективные и оптимизированные игры, а в будущем, возможно, разрабатывать новые технологии, фреймворки и языки. Он возник как реакция компетентного инженера на повальную безграмотность, оказуаливание и конвеерность индустрии разработки игр. Такие дела.
Вообще то вы очень сильно утрируете. В разработке игр достаточно сложностей за пределами движков и умение делать игры прокачивается в отрыве от навыка использования конретного движка.
Пример того, что у господина из вашей ссылки идет уже 400+ день, а у него ничего по факту ещё нет (кода много, но оно пока ещё ничего не показывает толком), говорит насколько неразумно начинать всё с нуля, если цель сделать игру. Если цель сделать обучающий проект или продвинуть общий уровень технологий в геймдеве то другой вопрос, конечно. Но эти цели надо разделять.
Пример того, что у господина из вашей ссылки идет уже 400+ день, а у него ничего по факту ещё нет (кода много, но оно пока ещё ничего не показывает толком), говорит насколько неразумно начинать всё с нуля, если цель сделать игру. Если цель сделать обучающий проект или продвинуть общий уровень технологий в геймдеве то другой вопрос, конечно. Но эти цели надо разделять.
Но ведь это и есть обучающий проект!
Смысл каждого эпизода в том, что любое действие разжёвывается. Есть десятки эпизодов, где целый час идёт чисто рисование на доске (вот произведение матриц, например guide.handmadehero.org/code/day362/#354) Потому это и продолжается так долго. Если убрать объяснения (-50% времени), Q&A (-20% времени), на чистый кодинг останется 140 эпизодов средней длиной 1,5 часа (до 350-го эпизоды были короче), то есть 210 часов чистой работы, грубо говоря. Округлим до 240 часов. 240 часов это 3 месяца интенсивной работы. Это крайне мало для того результата, который есть на экране (с учётом разработки с нуля, 100% понимания и полной ответственности за каждую строчку кода, и соответствующей производительности). И не стоит забывать, что значительная часть кода будет использоваться повторно в последующих проектах (аппаратный уровень, алогритмы работы с векторами/матрицами/массивами, камера, управление, инструменты отладки, движок анимации и тд).
Смысл каждого эпизода в том, что любое действие разжёвывается. Есть десятки эпизодов, где целый час идёт чисто рисование на доске (вот произведение матриц, например guide.handmadehero.org/code/day362/#354) Потому это и продолжается так долго. Если убрать объяснения (-50% времени), Q&A (-20% времени), на чистый кодинг останется 140 эпизодов средней длиной 1,5 часа (до 350-го эпизоды были короче), то есть 210 часов чистой работы, грубо говоря. Округлим до 240 часов. 240 часов это 3 месяца интенсивной работы. Это крайне мало для того результата, который есть на экране (с учётом разработки с нуля, 100% понимания и полной ответственности за каждую строчку кода, и соответствующей производительности). И не стоит забывать, что значительная часть кода будет использоваться повторно в последующих проектах (аппаратный уровень, алогритмы работы с векторами/матрицами/массивами, камера, управление, инструменты отладки, движок анимации и тд).
Я ничего не имею против обучающего проекта (как для самообучения так и для других), но нужно понимать, что если цель сделать игру, то нет никакого смысла проделывать кучу работы, которую люди уже многократно проделал. Вот по вашим же собственным словам он сам и делает движок, только свой. А в этом деле невероятное количество подводных камней от платформоспецифичных багов и фичей (по своему типо сжатия текстур на каждый гпу) до архитектурных проблем, которые становятся видны, когда приходит в голову сделать очередную крутую фичу.
Если кратко — движки благо, люди, которые могут написать свой движок молодцы, но и люди способные сделать игру на готовом движке тоже молодцы.
Если кратко — движки благо, люди, которые могут написать свой движок молодцы, но и люди способные сделать игру на готовом движке тоже молодцы.
Современные небольшие движки хороши для прототипирования. Как было с 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 комментариев. Люди устали от тормозного, раздутого, неэффективного ПО, которое пишется некомпетентными людьми ради сомнительных целей. Почему вы воспринимаете в штыки проект, который ставит своей целью обучение грамотных программистов?
В целом же современные движки — палка о двух концах.
С одной стороны это благо, потому что уменьшают порог вхождения в индустрию. С другой стороны, это бич, потому что меньшают порог вхождения в индустрию, снижают уровень компетентности и требований (засилие инди-хлама на 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 комментариев. Люди устали от тормозного, раздутого, неэффективного ПО, которое пишется некомпетентными людьми ради сомнительных целей. Почему вы воспринимаете в штыки проект, который ставит своей целью обучение грамотных программистов?
Делая handmade hero, Diablo 3 не сделаешь, по нему можно понять и сформулировать базовые принципы и собрать первые шишки. То что в хендмейд хиро сделано это такой минимум, над которым ещё работать и работать, тогда как готовом движке такую игру можно сделать за месяц. Ещё раз повторюсь я понимаю смысл в обучающем проекте, но нельзя тыкать в него и говорить смотрите как человек делает, а все кто делает не так просто хреновые программисты.
Вы серьезно спрашиваете есть ли примеры AAA-игр на Unreal? На Unity нет AAA-игр, но есть огромное количество отличных игр с меньшими бюджетами, которые не были бы сделаны или стоили в разы дороже в разработке (а значит не смогли бы окупиться), такие как: Pillars of Eternity, Endless Space/Empires/Dungeons, Wasteland 2, 3, Battlerite и огромное количество других достойных игр, разработчики которых посчитали, что им важнее разрабатывать игру, чем разрабатывать технологию.
Я не воспринимаю в штыки проект, я воспринимаю в штыки апломб, с которым вы его преподносите. Предположение что программисты в целом это сборище некомпетентных идиотов, которые без надобности увеличивают сложность кода не верно. Уровни абстракции это то что позволяет разрабатывать в большом количестве и с приемлемой столь ПО той сложности, которая сейчас стала стандартом, да, во многих случаях ценой производительности. А лайки легко объяснимы: на хабре очень много людей около АйТи, а профессиональных программистов не так уж и много, да и меня самого как программиста, конечно, бесит медленное и неэффективное ПО и так и подмывает плюсануть такой благой манифест, однако, я стараюсь удерживаться от мысли что все вокруг идиоты, а я один тут стою красивый.
Вы серьезно спрашиваете есть ли примеры AAA-игр на Unreal? На Unity нет AAA-игр, но есть огромное количество отличных игр с меньшими бюджетами, которые не были бы сделаны или стоили в разы дороже в разработке (а значит не смогли бы окупиться), такие как: Pillars of Eternity, Endless Space/Empires/Dungeons, Wasteland 2, 3, Battlerite и огромное количество других достойных игр, разработчики которых посчитали, что им важнее разрабатывать игру, чем разрабатывать технологию.
Мне непонятен ваш мотив. Почему вы защищаете людей, которые плодят низкокачественные решения? Соседний пост Моё разочарование в софте за два дня собрал 340 плюсов и 900 комментариев. Люди устали от тормозного, раздутого, неэффективного ПО, которое пишется некомпетентными людьми ради сомнительных целей. Почему вы воспринимаете в штыки проект, который ставит своей целью обучение грамотных программистов?
Я не воспринимаю в штыки проект, я воспринимаю в штыки апломб, с которым вы его преподносите. Предположение что программисты в целом это сборище некомпетентных идиотов, которые без надобности увеличивают сложность кода не верно. Уровни абстракции это то что позволяет разрабатывать в большом количестве и с приемлемой столь ПО той сложности, которая сейчас стала стандартом, да, во многих случаях ценой производительности. А лайки легко объяснимы: на хабре очень много людей около АйТи, а профессиональных программистов не так уж и много, да и меня самого как программиста, конечно, бесит медленное и неэффективное ПО и так и подмывает плюсануть такой благой манифест, однако, я стараюсь удерживаться от мысли что все вокруг идиоты, а я один тут стою красивый.
спойлер: в квейке берётся кирпич, и в нём вырезаются дыры, создающие пространоство уровня, тогда как в анриле комната изначально пустая, и генерируются блоки, создающие геометрию уровня, так что в квейке нельзя «выпасть» за пределы уровня, а в анриле можно)А вы ничего не напутали? Вроде как с точностью до наоборот. Когда начинал делать мапу для Unreal после Quake бы несколько удивлён тем, что изначально уровень заполнен, а не пуст, и комнаты не добавляются, а вырезаются.
Коротко: вы правы, всё с точностью до наоборот.
Видимо, Кейси на старости лет стал забываться. В подтверждение, кому интересно, есть наглядная иллюстрация компиляции карты из набора объёмных «кистей»-примитивов в первом Quake.
Полная статья здесь 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 из девяностых годов. С тех пор многое изменилось.
Видимо, Кейси на старости лет стал забываться. В подтверждение, кому интересно, есть наглядная иллюстрация компиляции карты из набора объёмных «кистей»-примитивов в первом Quake.
Полная статья здесь 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 из девяностых годов. С тех пор многое изменилось.
Видимо, Кейси на старости лет стал забываться
Возможно, что он просто сделал неверный вывод про редактор на основе их движков:
— в Quake — bsp-trees
— в Unreal — quad-trees, делящие плоскость на квадранты, каждый из которых опять делят
и потому было бы вполне логично ожидать, что в редакторе будет изначально пустое место.
DrZlodberg, а можно скриншоты того, чем изначально всё заполнено в Unreal? (сходу не нагугливается)
Тем более странно, потому как с помощью BSP представить «вырезанный» мир сложно. Там просто нет для этого средств. А вот для q-tree это вполне естественно, т.к. он оперирует замкнутыми объёмами.
Скриншот пустоты? Редактора под рукой сейчас нет, но ничего интересного на на картинке видно и не будет. Просто там у геометрии нет внешней стороны. Совсем. И никаких окон в пустоту тоже по определению сделать невозможно. В кваке-же дыры в геометрии создавали занятные артефакты рендера. Впрочем как и во всех других движках, основанных на обычных полигонах.
Кстати и вывалиться с уровня в кваке вполне можно, если геометрия уровня это позволяет. А вот анрил ввиду вышеупомянутой особенности это позволить не может по определению. Даже при желании.
Скриншот пустоты? Редактора под рукой сейчас нет, но ничего интересного на на картинке видно и не будет. Просто там у геометрии нет внешней стороны. Совсем. И никаких окон в пустоту тоже по определению сделать невозможно. В кваке-же дыры в геометрии создавали занятные артефакты рендера. Впрочем как и во всех других движках, основанных на обычных полигонах.
Кстати и вывалиться с уровня в кваке вполне можно, если геометрия уровня это позволяет. А вот анрил ввиду вышеупомянутой особенности это позволить не может по определению. Даже при желании.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Блуждающий монстр: как избавиться от проблем на карте