Pull to refresh
15
0

Software Engineer

Send message

Поля расстояний Raymarching-а: объяснение и реализация в Unity

Reading time24 min
Views28K
image

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


Snail Иниго Килеза была полностью создана при помощи raymarching. Другие примеры подвергнутых raymarching-у сцен можно найти на Shadertoy.

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

Полный код можно найти в этом репозитории Github.
Total votes 21: ↑21 and ↓0+21
Comments5

Терраформинг: как создавался Doom 64

Reading time16 min
Views12K
image

Глаза Джона Ромеро следили за инженером, раскладывавшим свой груз на бильярдном столе. Посетитель прибыл в id Software из Sega, а на стол он положил материнскую плату, пока находящуюся на стадии прототипа. После завершения проекта она должна была стать основой 32X — дополнительного оборудования Sega, которое превратит консоль Genesis из 16-битного динозавра в 32-битного гиганта.

Ромеро и остальные сотрудники id Software собрались вокруг, а инженер установил на сукно монитор, подключил к нему прототип и включил питание. Экран заполнился кодом. Часть его Ромеро узнал. Узнал его и Джон Кармак, вместе с Ромеро основавший id. Это был код того, что должно стать портом Doom. На тот момент работа ещё не завершилась. Чтобы перенести код на свою консоль, Sega нужна была помощь в модифицировании исходников Doom так, чтобы он мог запускаться на 32X.

«Кармак выудил из него максимально подробную информацию о процессоре » — рассказывает Ромеро — «А затем дал инженеру рекомендации, как ускорить работу блиттера. Вот так Sega удалось создать версию для 32X». (Блиттер — это устройство для изменения и быстрого перемещения данных в памяти.)
Total votes 20: ↑20 and ↓0+20
Comments1

C2x: будущий стандарт C

Reading time7 min
Views40K


Я ловлю в далёком отголоске,
Что случится на моём веку.
(«Гамлет», Борис Пастернак)

Признаться, пишу на чистом C я не так уж и часто и за развитием языка уже давно не слежу. Но тут произошло два неожиданных события: С вернул себе звание популярнейшего языка программирования по версии TIOBE и случился анонс первой за долгие годы действительно интересной книги, посвящённой этому языку. Поэтому я провёл несколько вечеров за изучением материалов о C2x — следующей версии C.


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

Читать дальше →
Total votes 107: ↑107 and ↓0+107
Comments155

Что нужно для создания хорошего подземелья в RPG?

Reading time12 min
Views14K
image

Для начала нужно ответить на вопрос что же такое подземелье?

Не буду углубляться в эту тему, а просто использую определение из третьего издания руководства мастера подземелий (ДМ) D&D:

Понятие «подземелье» очень расплывчато. Подземелье обычно находится под землёй, но могут существовать и надземные «подземелья». Некоторые ДМ называют подземельями любые места, где происходит приключение. Здесь мы будем называть подземельем замкнутое, чётко заданное пространство, состоящее из соединённых определённым образом мест встреч с врагами.

Такое определение мне нравится, оно очень хорошо подходит как для настольных, так и для компьютерных RPG (которые я в дальнейшем буду называть CRPG). Но что же такое хорошее подземелье?

Это может показаться очевидным, но хорошее подземелье в CRPG должно соответствовать игре. Например, мне нравятся огромные переплетённые спагетти-подземелья из Daggerfall:


Они соответствуют игре, потому что в Daggerfall игрок движется быстро, есть такие способы перемещения, как полёты, взбирание, плавание и телепортация (слава богу, что есть телепорты), а встречи с врагами редки и скоро заканчиваются. Благодаря камере с видом от первого лица движение кажется очень удобным, в классическом стиле Doom.

Если бы такой дизайн использовали в Final Fantasy IX с её медленным движением, медленными пошаговыми боями, постоянными случайными врагами и фиксированной камерой, то это было бы невыносимо. То же самое относится к играм, где движение привязано к сетке карты, например, к Legend of Grimrock, или где перемещается большая группа персонажей, например, к Baldur’s Gate.
Читать дальше →
Total votes 15: ↑13 and ↓2+18
Comments8

Библиотека ttf2mesh — преобразование TrueType шрифтов в сетку

Reading time11 min
Views6.9K

Многим известна проблема трёхмерной графики — отсутствие легковесных кроссплатформенных решений в вопросе вывода текста.


Большинство реализаций позволяет использовать выбранный шрифт в виде текстуры. Публикуемая библиотека ttf2mesh реализует другой способ — она преобразует векторные символы TrueType шрифта в сеточные объекты. Это позволяет выводить текст в виде набора треугольников.


image


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

Читать дальше →
Total votes 34: ↑34 and ↓0+34
Comments15

Маленькие секреты геймдизайнеров, заставляющие игрока ненавидеть вашу игру чуточку меньше

Reading time8 min
Views43K
Три года назад ведущий геймдизайнер ArenaNet Дженнифер Шойрле завела в Твиттере очень интересный тред на тему «отличных игровых механик, скрытых от глаз игрока с целью достижения определенного эмоционального эффекта, реакции или поведения», где любой геймдизайнер мог поделиться своими внутриигровыми «фишками».

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

  • В Hellblade предупреждение перед игрой было тщательно продумано, чтобы заставить игроков поверить, будто в игре срабатывает система permadeath в случае, если игрок умирает слишком часто, хотя на самом деле ее там нет.
  • Pacman может огибать углы более резко, чем это делают призраки, тем самым наделяя игрока небольшим преимуществом.
  • Во многих шутерах последние очки здоровья стоят больше всей остальной шкалы, чтобы усилить чувство «выживания на грани». С той же целью в System Shock последняя пуля нанесет урон в 4 раза более сильный, чем остальные.
  • И, напротив, Shadow of Mordor слегка увеличивает здоровье некоторых врагов, чтобы бои длились дольше.
  • В Bioshock и Devil May Cry, находясь за спиной игрока, противники замедляют свою атаку.
  • В Xcom, если промахнуться много раз подряд, игрок получит скрытый бонус для последующих выстрелов. Кроме того, если игроки остаются пассивными слишком долго, враги усиливают свою агрессивность.
  • Похоже, что в Heartstone есть pity timers ― таймеры жалости. Многие другие игры позорно использовали их в более ранние годы.
  • В Resident Evil 4 после слишком большого количества смертей заспавнится меньше врагов, чтобы дать игроку больше шансов пройти трудный для него эпизод.
  • В любой гоночной игре реализован адаптивный ИИ, чтобы сделать соревнование более жестким.

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

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


Читать дальше →
Total votes 67: ↑63 and ↓4+78
Comments117

Собственные игровые движки: небольшое исследование

Reading time12 min
Views41K

Пару недель назад я играл в A Plague Tale студии Asobo Studio (и прошёл её). Меня очень захватила эта игра, благодаря не только красивой графике, но и сюжету с локациями. Я решил немного изучить технологии, использовавшиеся при её разработке, и был удивлён, обнаружив, что игра создавалась на собственном движке относительно небольшой студии. Я знаю, что некоторые компании используют собственные движки, но очень сложно найти подробное маркетинговое исследование с подобной информацией. Поэтому я написал эту статью.

Сегодня многие компании выбирают для разработки игр такие движки, как Unreal или Unity (или, по крайней мере, так думают многие люди), потому что для разработки собственного движка AAA-уровня требуется множество ресурсов. Поэтому я решил составить список некоторых из самых популярных самописных движков с указанием размеров студий и значимых игр, выпущенных на этих движках.

Большинство представленных здесь движков разрабатывалось на протяжении многих лет, множества итераций и для множества видеоигр, эти движки имели несколько версий или даже полностью (частично) переписывались с нуля с последующей сменой названия. Кроме того, важно заметить, что большинство этих движков для реализации определённой функциональности (совместимость с платформами, физика, сеть, растительность, UI, рендеринг, звук...) использует всевозможное промежуточное ПО.
Читать дальше →
Total votes 30: ↑30 and ↓0+30
Comments46

Pixockets: как мы написали собственную сетевую библиотеку для игрового сервера

Reading time7 min
Views8.1K


Привет! На связи Станислав Яблонский, Lead Server Developer из Pixonic.

Когда я только пришел в Pixonic, наши игровые сервера представляли собой приложения на основе Photon Realtime SDK: многофункционального, но весьма тяжелого фреймворка. Решение это, казалось бы, должно было упростить работу с сервером. Так оно и было ― до определенного момента.

Photon Realtime привязывал нас к себе тем, что приходилось использовать его для обмена данными между игроками и сервером, ― а также привязывал к ОС Windows, поскольку может работать только на ней. Это накладывало на нас ограничения как с точки зрения runtime (среды исполнения): нельзя было изменить многие важные настройки виртуальной машины .NET, ― так и операционной системы. Мы привыкли работать с Linux-серверами, а не Windows. Кроме того, они нам обходились дешевле.

Также использование Photon било по производительности как на сервере, так и на клиенте, а при профилировании образовывалась приличная нагрузка на сборщик мусора и большое количество boxing/unboxing.

Короче говоря, решение с Photon Realtime было далеко от оптимального для нас, и давно надо было что-то с этим делать ― но всегда находились более срочные задачи, и до решения проблем с сервером руки банально не доходили.

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

Что из этого вышло ― читайте дальше.
Читать дальше →
Total votes 24: ↑24 and ↓0+24
Comments6

3 бесплатных инструмента, которые сделают прототипирование игр еще проще

Reading time5 min
Views16K


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

Ведущий геймдизайнер Ustwo Games, создателей Monument Valley и недавней Assemble with Care для Apple Arcade, рассказал, как студия использует бесплатные инструменты для креативного прототипирования. Перевод под катом.
Читать дальше →
Total votes 32: ↑32 and ↓0+32
Comments0

Хорошо, что создатель вашего любимого инструмента не слушал ослов, когда изобретал велосипед

Reading time5 min
Views35K


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

Ну конечно. Нас буквально смыло волной критики. Там было много людей, которым не нравится мое самомнение и я лично — это ок, с ними у меня нет проблем. Меня взбесили вроде бы умные люди, которые даже не захотели смотреть в код и вникать в контекст, потому что с порога заявили: «Вы, парни, сделали велосипед». И все подхватили — изобретать велосипеды плохо, ужасно, кошмарно, недопустимо, позор, казнить их, линчевать. Ведь, только идиот будет разрабатывать новый инструмент для задачи, которую кто-то уже решил.

Меня поражает насколько быстро разрабы ведутся на эту уловку. Я спрашивал даже самых критичных и глубоко думающих людей — “изобретать велосипеды плохо?”. Они отвечают “да” меньше чем через секунду.

Ну нет, мужики, так не пойдет. Давайте-ка остановимся здесь, посмотрим вокруг и обстоятельно порассуждаем.
Читать дальше →
Total votes 128: ↑95 and ↓33+83
Comments103

Правила дизайна иконок, которые стоит запомнить

Reading time2 min
Views16K


Изображение стоит тысячи слов. Хорошо продуманное стоит еще больше. Мы видим их на дорожных знаках, в ресторанах, аэропортах и приложениях. Они могут сэкономить время, а могут создать путаницу.

Иконки считываются быстрее текста, их легче заметить, они занимают меньше места и требуют меньше усилий при переводе. Стена из текста сливается в кучу, а иконки различаются по форме и хорошо выглядят даже в группах. Несколько рекомендация по созданию эффективных иконок — в переводе под катом.
Читать дальше →
Total votes 27: ↑25 and ↓2+35
Comments25

Законы программирования

Reading time20 min
Views57K

Законы, теории, принципы и закономерности, полезные для разработчиков


Введение


Перевод репозитория github.com/dwmkerr/hacker-laws

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

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

Законы


Закон Амдала


Закон Амдала — это формула, демонстрирующая потенциал ускорения вычислительной задачи, которого можно достичь при увеличении количества ресурсов системы. Обычно он используется в параллельных вычислениях, и может предсказать наличие реальных преимуществ от увеличения количества процессоров с учётом ограничений параллелизуемости программы.
Читать дальше →
Total votes 67: ↑65 and ↓2+80
Comments21

5 инструментов геймдизайнера, которые помогут вашей игре

Reading time5 min
Views23K


Видеоигры существуют более 50 лет. За это время технологии скакнули от текстовой The Oregon Trail до фотореалистичной Red Dead Redemption 2. Не говоря уже о VR-тайтлах вроде Half-Life: Alyx, которая выходит в конце марта.

И все же, игровая индустрии еще очень молодая. Постоянно появляются новые способы и инструменты, которые помогают изучать и улучшать геймдизайн. О пяти из таких — в переводе под катом.
Total votes 34: ↑34 and ↓0+34
Comments5

Когда фильтр Блума не подходит

Reading time9 min
Views15K


Я ещё с университета знал о фильтре Блума — вероятностной структуре данных, названной в честь Бёртона Блума. Но у меня не было возможности её использовать. В прошлом месяце такая возможность появилась — и эта структура буквально очаровала меня. Впрочем, вскоре я нашёл у неё некоторые недостатки. В этой статье — рассказ о моей краткой любовной связи с фильтром Блума.
Читать дальше →
Total votes 37: ↑36 and ↓1+48
Comments15

Шесть советов, как сделать правильный игровой туториал

Reading time4 min
Views8.1K


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

Почти все мои прошлые туториалы — провал. Они часто откладывались на самый конец разработки. Когда до запуска оставалось считанные дни, всегда находился человек, который спрашивал: «А не должны ли мы сделать туториал?». Мы были слишком заняты реальной разработкой, чтобы думать об этом. «Я знаю игру, как свои пять пальцев. Ее не так сложно понять, ей не нужно обучение», — часто я себе говорил.
Читать дальше →
Total votes 17: ↑17 and ↓0+17
Comments12

Монады как паттерн переиспользования кода

Reading time24 min
Views69K


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


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


Но ведь в интернете буквально сотни статей про ФП и монады, зачем писать еще одну?


Дело в том, что все их (по крайней мере те что я читал) можно поделить условно на две категории: с одной стороны это статьи где вам объяснят что монада это моноид в категории эндофункторов, и что если монада T над неким топосом имеет правый сопряжённый, то категория T-алгебр над этой монадой — топос. На другой стороне располагаются статьи, где вам рассказывают, что монады — это коробки, в которых живут собачки, кошечки, и вот они из одних коробок перепрыгивают в другие, размножаются, исчезают… В итоге за горой аналогий понять что-то содержательное решительно невозможно.


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


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

Читать дальше →
Total votes 89: ↑85 and ↓4+100
Comments256

Мотор! или Что такое игровая физика

Reading time9 min
Views26K


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

Насколько сложной должна быть игровая физика, какие виды бывают и на какие хитрости идут разработчики при ее реализации — в переводе под катом.
Total votes 24: ↑23 and ↓1+30
Comments22

Как я забросил игру спустя четыре года разработки

Reading time8 min
Views64K


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

Под катом ожидания, реальность и выгорание инди-разработки. А в конце — ссылка на демо, можно прочувствовать, как близко автор был к успеху.
Total votes 93: ↑92 and ↓1+120
Comments104

Пять важных уроков о балансе в играх

Reading time6 min
Views16K

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

1. Слишком сильный намного хуже слишком слабого


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

Причина заключается в том, что игроки стремятся к тому, что самое сильное, и используют только это. Например, в Awesomenauts есть 34 персонажа. Если трое из них будут слишком слабыми, то большинство игроков не будет ими играть, и у них на выбор останется 31 персонаж. То есть у них по-прежнему большой выбор и присутствует разнообразие. С другой стороны, если бы три персонажа были слишком сильными, то игроки играли бы только этими персонажами и не обращали внимания на остальных. Это бы сделало игру очень однообразной и она бы быстро наскучила.

Это знание можно использовать как грубый инструмент в ситуация, когда нет возможности использовать решение лучше. Например, если что-то слишком сильное, но только при определённых условиях, то вы можете решить ослабить (понерфить) этот элемент, пока его сила в этих условиях не окажется допустимой, а во всех остальных ситуациях он будет слабым. По крайней мере, он перестанет доминировать в игре.
Читать дальше →
Total votes 25: ↑25 and ↓0+25
Comments8

Сверхсовременные иммутабельные структуры данных

Reading time22 min
Views30K
Годами эксперты в С++ рассуждают о семантике значений, иммутабельности и разделении ресурсов за счет коммуникации. О новом мире без мьютексов и гонок, без паттернов Command и Observer. На деле все не так просто. Главная проблема по-прежнему в наших структурах данных.



Иммутабельные структуры данных не меняют своих значений. Чтобы что-то с ними сделать, нужно создавать новые значения. Старые же значения остаются на прежнем месте, поэтому их можно без проблем и блокировок читать из разных потоков. В итоге ресурсы можно совместно использовать более рационально и упорядоченно, ведь старые и новые значения могут использовать общие данные. Благодаря этому их куда быстрей сравнить между собой и компактно хранить историю операций с возможностью отмены. Все это отлично ложится на многопоточные и интерактивные системы: такие структуры данных упрощают архитектуру десктопных приложений и позволяют сервисам лучше масштабироваться. Иммутабельные структуры — секрет успеха Clojure и Scala, и даже сообщество JavaScript теперь пользуется их преимуществами, ведь у них есть библиотека Immutable.js, написанная в недрах компании Facebook.

Под катом — видео и перевод доклада Juan Puente с конференции C++ Russia 2019 Moscow. Хуан рассказывает про Immer — библиотеку иммутабельных структур для C++. В посте:

  • архитектурные преимущества иммутабельности;
  • создание эффективного персистентного векторного типа на основе RRB-деревьев;
  • разбор архитектуры на примере простого текстового редактора.

Total votes 84: ↑84 and ↓0+84
Comments57

Information

Rating
Does not participate
Location
Беларусь
Date of birth
Registered
Activity

Specialization

Game Developer