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

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

В стратегиях у ботов обычно есть обычно очень простая задача пройти через какие-нибудь ворота-узкое место, обойти стену и оказаться во дворе, и пока у нас один солдат, который идёт по пустой карте, никакой особой проблемы не возникает. А стоит вам добавить на карту десять, пятьдесят, сто, двести солдат и одни ворота, через которые физически способны одновременно протиснуться всего несколько юнитов, как выясняется они этого не делают, хотя алгоритме поиска пути (вроде A*) прекрасно отработал. Отработал, то отработал, а солдатики на месте тупят, и выясняется что мы пытаемся заставить его решать задачу, на которую он не рассчитан.

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

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

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

Расскажу, как я получил свою первую работу программиста 25 лет назад. Потому что мне кажется, именно в этой истории ответ на вопрос, почему сейчас такой трэш на рынке труда в IT. Компания “HBM”, известная тогда игровая контора набирала людей для нового проекта под “Буку”, в качестве тестового задания надо было за месяц сделать простую РТС на чем угодно, но с работой по сети. Я тогда студент второго курса, без портфолио, без опыта, без вот этого всего. Взял задание и вечерами на кафедре, потому что своего компа еще не было, а папин был за 200 км и особо не наездишься, наклепал стратежку с видом сверху про пакманов и призраков, которые собирают точки и стреляют друг в друга. Я не знаю как она работала, потому что там было столько косяков, что работать он в принципе не могла, а если слишком быстро перемещать курсор, то крашилась, и поэтому некоторые пакманы начинали стрелять в курсор и стопать его, если скорость была выше положеной.

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

В сетевой игрe происходит примерно то же самое, но приходится немножечко врать уже не о положении персонажа, а о времени и если coyote time был маленькой ложью о том, где заканчивается платформа, то lag compensation, будет маленькой ложью о том, когда именно существовал игровой мир.

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

Есть довольно интересная категория багов в играх, которые формально багами являются, но игрокам они нравятся, и они, наоборот, называют багом “нормальное поведение” и строчат про него репорты про криворуких погромистов. Там, где программист хорошо и физически корректно сделал свою работу, игрок видит ошибку своего восприятия игры, не физики, а именно восприятия.

Представьте самый обычный платформер, в котором персонаж бежит по платформе, приближается к краю и должен прыгнуть на следующую. Если вы сделаете правильную обработку прыжка в этом месте в стиле “персонаж стоит на земле - можно прыгать, персонаж на земле не стоит - прыгать нельзя”: if (IsGrounded() && JumpPressed()) then Jump(), то c точки зрения “корректной” физики здесь будет не к чему придраться, потому что если под ногами уже нет платформы и было бы довольно странно сообщать персонажу, что он всё ещё находится на земле.

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

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

В литературе по оптимизации, работа с памятью стоит не на первом месте, и даже если вы добрались до этих глав там, с большой вероятностью будут рассказывать про пропускную способность, чтобы система могла перемалывать условные пять ГБ/с вместо трех. И в целом это правильная метрика, когда у вас потоковая обработка, или батчи данных вродя запекания освещения, сборки навмеша, или компиляция шейдеров. Там имеет значение сколько данных прошло через процессор за отведённое время, и все стандартные приёмы (SoA, плотные массивы, линейный обход, векторизация) работают на эту метрику.

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

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

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

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

Число... например, 16 мс или 33 мс или 8 гигабайт, из которых 5 доступны, или «игра должна показать первый интерактивный кадр не позже чем через десять секунд после запуска, иначе сертификацию не пройдем». Как только у свойства системы появляется измеримая цель, простота перестаёт быть бесплатной и превращается в то, чем вы платите.

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

Попросили меня по старой дружбе, где‑то с полгода назад, помочь с разработкой и выводом игры в Steam. Ребята до этого занимались нефтью, и накопив деньжат, решили, что называется оставить след в индустрии. Если честно, я несколько отвык от такого «детского» кода и простых решений, что меня несколько удивило, хотя и вернуло на грешную землю из объятий ентрепрайза. Но я сразу оговорюсь, что простая архитектура это не оправдание плохого кода, а способ выбрать, где именно вы позволяете себе быть сложным. Бюджет сложности конечен... прежде всего размером вашей натуральной оперативкой, и тратить его надо туда, где игрок это увидит.

На одном из проектов (4Х историческая стратегия) появилась задача убрать часть логики в потоки, отдав им снапшот игрового состояния, чтобы пока основной поток считает свой тик, остальные (AI, поиск пути, UI и др) могли крутить свою логику, вроде "кто стоит в этой локации" и делать это без блокировок или риска увидеть половину чужой записи. Чтобы реализовать такую систему, надо придумать как получить обратный индекс полка по локации, причем сделать поиск дешевым для потоков, т.е. у потока должен быть свой снапшот состояния некоторой части игрового мира на момент старта апдейта (кадра, тика логики, дня, месяца и т.д)

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

std::vector<std::vector<unsigned int>> regiments(location_count);

Такая структура называется jagged array, массив массивов (зачем она и как с ней работать я показывал в книге Game++), или, если вам ближе академическая терминология, CSR (compressed sparse row) немного другая форма записи таких массивов, либо разреженные матрицы. И такие структуры довольно частое явление в играх, если у вас много локаций и вам надо узнать какой лут разложен в каждой локации, какие армии принадлежат каждой области, или какие монстры живут в локации, какие локации входят в область, какие области в регион, или почекать соседей локации на карте, adjacency region, на чем строится весь поиск путей и вся заливка областей в глобальных стратегих;

В 2016 году EA закрывает свой последний оплот разработки в Питере, и народ начал разбредаться по разным студиям и командам. Тогда мировой игрострой ещё благосклонно смотрел на обладателей красных паспортов, и несколько моих бывших коллег "со связями" организовали мини-галеру и умудрились получить контракт на поддержку движка для прототипа новой игры Arkane. Причем схема взаимодействия была достаточно мутная, из-за нежелания Остинцев работать напрямую с пост-СНГ конторами, поэтому основной контракт у них был через каких-то корейцев за три рубля, которые делегировали часть работы французкой конторе за рубль, а те наняли каких-то ребят за десять копеек из восточной Европы, ну вы поняли каких:)

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

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

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

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

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

Структуру, о которой ниже пойдёт речь, знали в древней Индии за тысячу лет до самого Фибоначчи и переоткрыли в 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, лекций про паттерны, и общение с коллегами из больших студий. Отсылка к словам и блогам двадцатилетней давности тут не для ностальгии, а для дела, потому что в интернете информация живёт недолго, блоги нулевых уже наполовину выпилены, а выводы пятнадцатилетней давности до сих пор актуальны до неприличия.