Структуру, о которой ниже пойдёт речь, знали в древней Индии за тысячу лет до самого Фибоначчи и переоткрыли в 1988 году двое математиков, при этом весь граф целиком строится из строк, состоящих только из цифр 1 и 2, или если мы вычтем единицу, то получим 0/1 и бинарный вид.

Берём любую конечную строку из цифр 1 и 2, например такую "11212" и складываем цифры 1 + 1 + 2 + 1 + 2 = 7 и получаем ранг этой строки. Теперь простой вопрос: сколько существует строк заданного ранга? Строку такого же ранга можно получить двумя способами, либо дописав цифру 2 к строке ранга r-2, либо дописав цифру 1 к строке ранга r-1, и других вариантов нет, потому что других цифр в нашем алфавите из единиц и двоек нет.

ранг 0: “” → 1
ранг 1: 1 → 1
ранг 2: 11, 2 → 2
ранг 3: 111, 12, 21 → 3
ранг 4: 1111, 112, 121, 211, 22 → 5
ранг 5: … → 8

Заметили справа подозрительное 1, 1, 2, 3, 5, 8? Да... это последовательность Фибоначчи f® = f(r-1) + f(r-2), с небольшим условием, что f(0) = 1 (пустая строка) и f(1) = 1 (единственная строка “1”), из-за этого вся последовательность сдвинута на одну позицию относительно канонических чисел Фибоначчи, и f® = F(r+1).

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

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

Весь процесс игры, в которую играет мой ребенок, по сути состоит в перестановке мебели и посуды в доме. Я могу разложить по пунктам интересность игры, оценить баланс, подсветить проблемы, но проблема что каждый мой пункт выслушивается, кивается и процесс переставления посуды продолжается. Моё «объективно» оказывается не чутким измерительным прибором, востребованным рынком, а просто чьим‑то раздражением с претензией на экспертизу.

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

В семидесятых Джордж Акерлоф в своей работе про «рынок лимонов» объяснял, что если покупатель не может визуально отличить качественную б/у машину от «хлама» (lemon), то цена на рынке усредняется, качественные машины уходят, и рынок заполняется теми самыми лимонами.

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

C‑level менеджменту и продюсерам продают не хорошую архитектуру UE5, но красивую демо‑сцену на купленных ассетах, громкие фичи и слайды с логотипами других студий, которые «шмагли» выпустить ремейк. И когда презентация в таком движке говорит «наша новая система управления виртуализированной геометрией или автоматическим LOD'ингом решает все проблемы с памятью и арт‑пайплайном», я уже вижу как уволят половину моделеров, потому что менеджмент понял это как возможность сэкономить бюджет на них.

Чего нет в маркетинговых презентациях, так что архитектурный дизайн этой системы предполагает постоянную перезапись GPU‑буферов, вызывая просадки на любых конфигурациях, кроме идеальной тестовой стойки вендора с сотней гигабайт оперативки и четырьмя 5090 в слае.

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

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

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

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

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

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

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

В прошлой статье (Непослушный using ) я разобрал, как using вмешивается в поиск имён и почему его поведение часто расходится с тем, что от него ждет программист, и на этом ветку статей про поиск имен (name lookup) можно временно закрыть.

Using'и попортят вам в проектах еще немало крови, но в целом их проблемы известны и легко ловятся, а теперь давайте поговорим обauto и выводе типов в шаблонах, который регулярно удивляет даже опытных программистов на C++, когда речь идёт о распаде типов (type decay) и неявных ловушках при работе с ним. Представьте, что у нас есть несколько переменных, которые выглядят разными: const int&, просто int, const int и int&&.

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

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

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

Думаю вы узнали COBOL, который по сей день ежедневно эксплуатируется и по разным оценкам стоит за 80% обычных (магазинных) банковских транзакций, а его кодовая база тянет на пару сотен миллиардов строк и до сих пор кормит десятки, если не сотни тысяч разработчиков. Правда, если копнуть эти красивые цифры, почти все они восходят к одному опросу конца девяностых, который потом бесконечно переэкстраполировали на весь мир, так что честнее считать их порядком величины, а не точными данными.

SQL породил особую касту DBA (Database Administrators) и Data Engineers и сегодня человек, который пишет "простые запросы", может легко зарабатывать на уровне мидла, а сам язык стал настолько сложным, что современные диалекты (PostgreSQL, Oracle) - это полноценные языки программирования с процедурной логикой, где можно написать всё что угодно, от генератора фракталов до игрового движка.

Семейство 4GL оказалось "золотой клеткой" и прекрасно работали, пока нужно было сделать типичную форму "ввод-вывод", но как только требовалась нестандартная бизнес-логика или интеграция с внешним сервисом, инструмент упирался в свои границы и программистам приходилось дописывать "костыли" на низкоуровневых языках, что превращало разработку в адский коктейль из визуального дизайна и грязных хаков. И вместо исчезновения программистов, 4GL создали "архитекторов корпоративных систем", которые (например, SAP ABAP), стали невероятно дорогими специалистами, и тоже не устранил программирование, а просто переместил его из зоны "универсальных языков" в зону "дорогих и капризных инструментов", привязывающих компанию к конкретному вендору.

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

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

Стандартная библиотека плюсов оказалась почти непригодной для игровой разработки и поняли это практически сразу, как попытались её использовать. Крупнейший на тот момент издатель Electronic Arts стал самым известным примером реализации стандартной библиотеки для разработчиков игр (но конечно же были и другие, менее именитые), и силами команд нескольких студий под руководством Paul Pedriana это было претворено в жизнь.

Корни EASTL уходят в Maxis к 1998-му году, когда Пол работая над SimCity 3000, выступал на GDC с докладом «High Performance Game Programming in C++» про кастомные контейнеры, стоимость вызовов и замеры производительности. Единой EASTL тогда ещё не было, но подход, из которого она потом выросла, виден уже там.

До консолидации, даже внутри одной студии, могли существовать несколько параллельных STL-реализаций, разработанных под разные игры, платформы и инструменты. Рискну предположить, что самой полной была реализация от Maxis, как одной из ведущих студий, а в других командах были поменьше, каждая со своими допущениями.

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

Семнадцать лет назад Брэндон Шеффилд собрал на Gamasutra классическую подборку «Dirty Coding Tricks», перевод на Хабре тут, и «Developers share their most memorable dirty coding tricks» где были камера, повёрнутая на 90 градусов вместо починки рендера, пробел, добавленный в код ради совпадения контрольной суммы, и два мегабайта памяти, спрятанные «на чёрный день», чтобы торжественно достать их за неделю до сдачи.

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

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

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

...или почему игровые движки всегда заканчивают одинаково.

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

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

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

В индустрии разработки игр (а может софта и вообще) живёт очень удобная идея, которой многие оправдывают лишние слои логики и абстракции. Звучит она примерно так: «Я хочу, чтобы сам процесс создания игр был проще, приятнее и продуктивнее и готов пожертвовать 10% производительности ради этого» — Тим Суини.

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

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

Статья родилась после очередного приступа клинокодомании в отдельно взятой студии, когда кто‑то в очередной раз увидел и притащил всем известную книгу Мартина о достоинствах этой самой клинокодии. Но «Clean Code», тот что с заглавной буквы и тысячными тиражами, вовсе не «чистый код» в бытовом смысле, потому что Мартин придумал этот бренд, ярлык, и несколько лет пестовал его на конференциях, связав свое имя и это понятие. Правильнее было бы называть это «стиль мистера Мартина» или «стиль Дядюшки Боба», и тогда половина споров о важности книги отваливается сама собой, потому что спорить приходится уже не про абстрактную «чистоту», а про конкретные наборы приёмов конкретного автора. Та дискуссия с технической стороны так и не получила внятных результатов, потому что на третьем круге обсуждения в ход шла риторика и подмена понятий вроде «clean» (хороший, годный), который начал превращаться в «Clean» (по методичке), и обратно.

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

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

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

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

Есть на ютубе видео на пятьдесят минут с хвостиком, с гордым названием «худший язык программирования всех времён». Не удивлюсь, если вы подумаете, что оно про C++. Оно действительно про плюсы и я его смотрел где-то с полгода назад, ну как смотрел... пробежался на x2 с перемотками, мало ли что обиженный джун там наговорил, но добрый @alyokhin опять про него напомнил, и теперь я его посмотрел полностью. И знаете что самое неприятное? Если убрать интонацию обиженного джуна и оставить только аргументы, то процентов семьдесят там будет правды. Не «спорно», не «зависит от контекста», а буквально правда, которую любой разработчик, проведший с языком пару лет, подтвердит вам не задумываясь.

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

Жанр «почему C++ ужасен» на Хабре выжжен дотла и про Init-зоопарк, перегруженный static, vector названный неправильно, std::move который не move, супер медленный regex, медленный unordered_map вы всё читали раз по двадцать. Сам по себе список этих болей давно не новость, от себя добавлю, что все жалобы и примеры ниже - это следствия одного решения, и я к нему приду. Или открывайте спойлеры, там скрыта история, почему каждая часть языка получалась так, как получалась.

Помните времена, когда трава была зеленее, мобильный интернет помегабайтным, а Apple осваивала непаханые поля смартфоно-игровых ферм? Начало 2010-х было очень интересным временем, когда мобильные студии создавали целые новые жанры, пытались перенести или адаптировать старые концепции и игры, попутно решая задачи, от которой у десктопного разработчика начинал дергаться глаз. Вот и EA решили взять культовые франшизы SimCity и The Sims со всеми их терабайтами ассетов, сложнейшей симуляцией дорог, пробок и отдельных симов, и попробовать затолкнуть это в карман.

В кармане у пользователя тогда лежал условный iPhone 4 или 5 с уже тогда куцым бюджетом оперативной памяти в районе 100–300 МБ на всё про всё, но айфоновладельцы были "платящей" аудиторией, поэтому игровое подразделение метило в основном в них. Как не превратить смартфон в обогреватель и словить ООМ в первые минуты игры? Выкинуть честную симуляцию на помойку, превратить симов в конечные автоматы, а город сделать хитрой иллюзией из текстурных атласов и таймеров. Раскажу немного как устроены SimCity BuildIt и The Sims Mobile с инженерной изнанки, кода почти не будет, да он и не нужен тут для понимания, а еще будет немного грустинки по российскому подразделению EA, и фотки с закрытия офиса в 2016.

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

EA, Facebook, Google, Adobe, LLVM и рядок компаний поменьше тратят человеко-десятилетия в поисках ответа на главый вопрос жизни, Вселенной и всего такого «почему std:: это медленно, непредсказуемо и жрёт память». По аналогии с прошлой статьей вам не потребуется знать стандарт наизусть, а будет достаточно понимать, что такое указатель, чем вектор отличается от дерева и почему промах в кеше это дорого, а дальше я пройдусь по разным стандартным библиотекам и про каждую немного расскажу, что это, зачем оно появилось и где об него можно больно удариться, потому что про вот этот последний пункт обычно забывают "продаваны" и прочие студийные еванглелисты, когда расказывают какое там всё красивое, легкое и с++двадцатое.

Есть такая забавная категория людей в разработке, давайте назовём их IT-волки. Это те самые ребята, у которых в 26 лет уже 12 лет опыта, в 27 два проекта и архитектура уровня «я тут всё с нуля поднял», а в 28 управление двумя командами под миллион MAU.

Иногда смотришь такое CV и думаешь - ну всё, сейчас придёт человек, который видел боль, огонь и сломаный прод, а потом начинается интервью. И очень быстро становится понятно, что дело вообще не в синтаксисе или знаниях фреймворков, иногда это могут быть идеальные знания, что тоже пугает. Знания конкретных фреймворков, это вообще не проблема и можно забыть название паттерна, потому что этих самых паттернов овердофига и можно перепутать детали. Это нормально, у всех бывает, интереснее другое. Когда начинаешь спрашивать про реальные решения, про ошибки, про “что вы делали”, про “почему вы это сделали именно так”... вот тут часто начинается тишина.

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

Навыки есть? А если найду?

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

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

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

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

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

Большинство этих примеров родилось в эпоху до C++11, когда у языка ещё не было ни умных указателей в стандарте, ни move-семантики, ни constexpr, ни концептов, и приходилось руками собирать из шаблонов и перегрузок некоторые конструкции, которые в более поздних стандартах язык даёт почти бесплатно. Многие идиомы, примеры и идеи стоит читать в двух смыслах сразу, как исторический артефакт, объясняющий «почему старый код выглядит вот так», и как живой приём, который всё ещё применяется в движках и играх.

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

Когда я собирал оглавление Game++, раздел про идиомы, идеи, паттерны и механизмы C++ планировался шестым и завершающим, и должен был занять страниц сто, по одной на каждый пункт, но чем дальше я собирал материал, тем яснее становилось, что каждая секция тянет за собой историю, а каждая история требует контекста, а каждый контекст в игрострое никогда не бывает простым. В итоге текст разросся до размеров, при которых он просто сломал бы структуру книги, и мне пришлось выбирать между «урезать до неузнаваемости» и «отпустить жить отдельно». Пришлось выбрать второе.

Перед вами то, что могло бы стать половиной Game++, но стало самостоятельным материалом. Здесь собраны идиомы, идеи, паттерны и механизмы C++, которые сложились в сообществе за несколько десятилетий и продолжают жить в кодовых базах игровых движков, иногда под своими именами, иногда под другими, иногда вообще без имён, потому что их давно перестали объяснять. У большинства имена все же есть, есть и история с ответом почему именно так, а не иначе.

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

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

Теперь попробую разложить архитектуру UI по нескольким осям, именно осям, потому что один и тот же UI может быть diegetic по расположению, immediate mode по хранению, reactive по потоку данных, flexbox по лейауту и векторным по рендеру одновременно, а проблемы начинается там, где люди пытаются совместить несовместимое.

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

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

Под конец приходит локализатор, который превратил «1 enemy / 2 enemies» в «1 враг / 2 врага / 5 врагов» и зависимость от рода. Иногда заскакивает инженер по портированию, которому надо то же самое окно крутить на PC, консолях или мобилках с разными разрешениями и соотношениями сторон, ну на него пофиг, он сам себе программист и если что, допишет код. И всё эти требования должны как-то жить вместе.

Большая часть студий начинала с написания системы GUI «по месту», т.е. для конкретной игры, под конкретный рендер, с захардкоженной раскладкой, а когда выходила следующая игра, выяснялось, что вытащить старый GUI почти невозможно. Такой UI насквозь срастается с рендером, инпутом, звуком и игровой логикой и каждый следующий проект начинается с фразы «давайте сделаем нормально один раз», и каждая следующая итерация показывала, что «нормально» это не одна задача, а много и одновременно.

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