Зачем писать игры руками?

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

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

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

Так вот, здесь это упоминается в совершенно другом ключе. Не в смысле открыть документацию по OpenGL/Vulkan и следующие пять лет писать свой Unreal (с преферансом и куртизанками). А в смысле попробовать собрать игру (не движок!) из значительно более простых компонентов: SDL, raylib, отдельных "легковесных" библиотек, а может, вообще напрямую используя API операционной системы.

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

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

Что ещё за Handmade?

История возникновения этого движения однозначна и неразрывно связана с проектом "Handmade Hero" Кейси Муратори (Casey Muratori). В 2014 году он решил сделать игру "с нуля", показывая весь процесс разработки "в прямом эфире". Это следует понимать довольно буквально: никакая модификация кода и даже служебных скриптов не происходила вне экрана трансляций. То есть прям всамделишное программирование: с ошибками, отладкой, профилированием, изменением решений.

Но даже не это главное. А то, какой именно код и как его писал Кейси. Работа с Win32, графикой, звуком, памятью и всем остальным на низком уровне. Ручная сборка из исходников без использования билд-системы. Использование Emacs вместо Visual Studio. Всё это не было чем-то новым для Кейси: с его слов, именно так и пишутся (хоть теперь уже, возможно, писались) все серьёзные игры. Но всё это было на тот момент по большей части скрытым знанием для абсолютного большинства любителей, да и для многих профессионалов тоже. На меня лично всё это произвело неизгладимое впечатление.

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

И дело не в том, что все библиотеки плохие и хороший handmade-программист обязан сам написать компилятор (как Джонатан Блоу) до того, как сможет со спокойной совестью вывести треугольник на экран. Скорее одна из центральных идей -- владение своим кодом. Каждая большая зависимость даёт вам какое-то удобство, но одновременно забирает часть контроля. Вы уже не полностью знаете, что происходит внутри программы. Начинаете подстраивать свою архитектуру под архитектуру чужой системы. Зависите от её ошибок, обновлений и дальнейшего существования.

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

И всё-таки, зачем?

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

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

Мне кажется, именно это ощущение сильнее всего и объединяет очень разных людей вокруг Handmade. Сделать не "как положено", а попробовать понять, как оно вообще работает. Не бояться залезть на уровень ниже. Не считать, что всё интересное уже написали какие-то другие, более умные программисты.

Хотя Handmade во многом про низкоуровневое программирование, это, на мой личный взгляд, не является каким-то обязательным атрибутом. Можно написать игру на Unity и при этом разделять эти принципы, а можно писать на Си++ и иметь горы зависимостей и ООП (я уже говорил, что Кейси не жалует ООП?).

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

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