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

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

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

C и C++ не имеют встроенной сборки мусора, поэтому разработчик сам решает, как и когда выделять и освобождать память. Мы, конечно, можем покивать в сторону STL, сокрытия аллокаций в контейнерах, но от этого они никуда не денутся. Просто если раньше приходилось думать про выделенный кусок памяти, понимать, как он скажется на времени фрейма, помнить, что его надо удалить (а может, не надо и стоит оставить на следующий фрейм), то теперь всё заворачивается в сахарные контейнеры и разработку в стиле STL-blin-vse-sterpit. STL-то может и стерпит, и даже как-то будет ворочаться, однако не стоит полагаться исключительно на системный аллокатор, бездумно вызывая new или malloc для каждого запроса памяти. Вы ведь понимаете, что std::vector посреди цикла или горячей функции — это плохая идея?

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

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

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

Ребята из HFT, Database, Automotive и Embedded-систем наверняка могут рассказать немало интересных историй про оптимизацию new/delete. Давайте я расскажу немного про разные аллокаторы в играх?

В студии Arkane в Лионе на входе в офис есть стена с разными вещами, которые присылают фанаты. Одно время там висела большая борда с цитатами великих разработчиков игр, к сожалению, тогда не подумал её сфотографировать. Это была не просто декорация, часто там стояли люди, даже читавшие её не один раз. Где-то в середине разработки Deathloop этот источник вдохновения, который встречал каждого входящего, убрали на склад. Впрочем там поменяли большинство экспонатов. Среди цитат можно было найти слова Джона Кармака, говорящего о важности технологии, или слова Сида Мейера о том, что игра — это серия выборов, мысли главного "Марио" Шигэру Миямото о том, что плохая игра останется плохой навсегда. Эти цитаты напоминали людям, что они не просто создают игры, а продолжают традиции, заложенные легендами индустрии. Слова мастеров оставались в памяти, напоминая, что каждое решение — от механики до дизайна уровней — должно быть осмысленным и значимым. Цитат было немного, точно не считал, но около тридцати, подумал может кому будут интересны высказывания мэтров. Все на память не помню, пришлось спрашивать у гугла.

...Египет — мир величественных пирамид, бурных вод Нила и одной из самых теплых и ламповых 2D-стратегий из 1999 года! Здесь вы станете архитектором и правителем, строя города, заботясь о благополучии жителей и возводя памятники, достойные фараонов. А вы знали, что у Фараона была полноценная демка? Хотя это нормально для индустрии того периода, вот о различиях с retail версией и пойдет речь.

…но помните, что в 2025-м всё это великолепие может не завестись и потребует доработки напильником, для работы на современных системах. Самый надежный способ насладиться стареньким, но не потерявшим свою магию, ситибилдером без глюков — это установить виртуалку с WinXP, но и это не всегда работает. Виртуалка поможет избавиться от большинства проблем, к сожалению на всех ОС после XP игра работает все хуже и хуже.

После прошлой статьи про «испанских синьор‑программистов» в комментариях и личных сообщениях было много вопросов о том, как выглядит работа в игровой студии изнутри. Некоторые даже в линкед вопросы закидывали. Эта статья про то и начиналась, но быстро стало понятно, что получается скучно — таких уже с десяток точно есть и не только на Хабре. Поэтому решил рассказать не столько о процессах, сколько о людях их творящих, с примерами из жизни, чтобы было поинтереснее. Ведь игры делают именно люди, и очень надеюсь, чатик не скоро отберёт у нас эту работу. А пока, я перечитываю в четвертый, наверное, раз «Мифический человеко‑месяц» Брукса, которой в этом году стукнет 50 лет, только подумайте, книга была написана полвека назад, но она по‑прежнему актуальна.

Люди — это всегда про общение. Это взгляды, жесты, разговоры на кухне, в чатах, в курилке и на террасе. Хочешь работать в команде и делать игры? Прокачивай софт‑скиллы. Кто бы мог подумать, что для программиста это настолько важно. Лет десять назад я бы посмеялся на тем, кто скажет, что половина моего времени будет уходить на обсуждения, убеждения дизайнеров делать «как надо», а не «как хочется», код‑ревью, обучение новичков и решение задач, которые вообще не связаны с программированием.

В разработке игр динамические и статические массивы являются основным инструментом при работе с набором объектов, буду дальше называть их vector. Вы можете подумать про разные map, set, и другие ускоряющие структуры, но их тоже предпочитают делать поверх векторов. Почему так? Вектора просты для понимания, удобны для большого числа задач, особенно там, где объём данных заранее неизвестен или примерно известен. Но как вы понимаете, за все надо платить, и расплачиваться приходится производительностью, которой, как обычно, всегда не хватает. Так что, использование динамических массивов имеет свои ограничения и особенности.

«String interning», иногда это называют «пулом строк» — это оптимизация (https://en.wikipedia.org/wiki/String_interning), при которой хранится только одна копия строки, независимо от того, сколько раз программа ссылается на нее. Среди других оптимизаций по работе со строками (SWAR, SIMD-cтроки, immutable strings, StrHash, Rope string, и немного других), часть которых была описана тут, она считается одной из самых полезных оптимизаций в игровых движках, есть правда небольшие недостатки у этого подхода, но экономия памяти и скорость работы при правильной подготовке ресурсов и работе с лихвой их перекрывают.

Вы 100% когда-нибудь писали одну и ту же строку несколько раз в одной программе. Например:pcstr color = "black"; А позже в коде пришлось написать: strcmp(color, "black");Как видите, строковый литерал "black" встречается несколько раз. Означает ли это, что программа содержит две копии строки "black"? Более того, означает ли это, что в оперативную память загружаются две копии этой строки? На оба вопроса ответ — зависит от компилятора и вендора. Благодаря некоторым оптимизациям в сlang (Sony) и GCC, каждая строка-литерал хранится в программе только в одном экземпляре, и, следовательно, только одна копия загружается в оперативную память, поэтому иногда cтановятся возможными разные фокусы.

Моя текущая позиция и аутсорсы последних пяти лет на 90% были в западных gamedev студиях, соответственно и общение было преимущественно с не‑ру коллегами. А когда надолго отрываешься от славянских коллективов разработки, то отличия начинают проявляться очень четко, начиная от модели управления командой и заканчивая культурой разработки. Хотя вот культурой я бы это не назвал, скорее плясками варваров‑полуиндусов на останках штатовской империи софтостроения. Индийцы тут ни при чем, а вот практики и сам процесс написания кода очень попахивает этими жителями полумифической страны Индустана. Есть немало книг по истории развития игровой индустрии и истории успехов и провалов разных студий, в основном западных, оставлю в статье список самых интересных и захватывающих, если решите углубиться в историю (кому интересно, будет под спойлером).

Одна из последних — «Not All Fairy Tales Have Happy Endings» (Ken Williams), мемуары одного из основателей Sierra On‑Line, прочитана была около года назад и понравилась больше других, наверное потому, что читая книгу — я, наконец, понимал большинство решений и причин которые привели к тому или иному результату. Этого понимания точно не было десять лет назад, это сложно объяснить, если не работал непосредственно сам долгое время с людьми с иным образом мыслей, культурным кодом, как сейчас принято говорить. Нынешняя команда на 95% франко‑испано‑английская — австралийцы, немного европейцев и американцы. В студии по‑русски говорят трое, включая меня. До этого в карьере были по большей части все же ру‑студии с привычным менталитетом, пускай и под управлением все тех же американцев, но менеджмент скрадывал все огрехи и брал «разговоры как надо» на себя, а нам доставались только технические задачи, грамоты и иногда премии. Десять лет назад, придя в индустрию создания игр, я не задавался вопросом — чем отличаются мои таски, мой код, мои идеи от тасок, кода и идей Джона из Кемпбеловки под Сан‑Хосе, потому что вокруг были все «свои». Сейчас уже тоже все «свои», но те «свои», от этих «своих» отличаются примерно — всем.

Меня всегда удивляло как разработчики умудряются размещать большой объем вычислений на относительно слабом железе, к каким трюкам и решениям прибегают, чтобы приложение работало быстро, это относится не только к игровым движкам, но и базам данных, системам управления и т.д., но так как моя область это все же игры и игровые движки, то рассказывать я буду про них. Особенно заметна эта разница была при портировании относительно свежих игр (поколение ps3+) на всякие портативные консоли вроде Nintendo Switch, Apple TV (это девайс тоже считается неплохой платформой, в плане что там есть платящая аудитория) и мобилки. И свитч и appletv по производительности не сильно далеко ушли от третьей плойки, и попытки перенести требовательные игры, рассчитанные как минимум на следующее (ps4) поколение консолей, приводят к значительным проблемам, которые непросто решаются. Игры - это достаточно требовательный софт, зачастую с мягким реалтаймом, надо же выдавать приемлимый фпс - иначе играть будет больно, некомфортно и её никто не купит. Небольшим подспорьем при переносе на портативки и мобилки является их стабильное железо, хотя вот для мобилок я бы так не сказал, там целый зоопарк процов, видях и окружения. На консолях с этим все получше и спеки меняются раз в пару лет. Когда речь заходит о портировании игры - оптимизации можно разделить на несколько уровней: архитектура, алгоритмы и код.

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

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

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

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

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

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

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

После статьи о книгах для саморазвития gamedev программиста, меня просили больше написать про аишную часть и том, что стоит почитать по этой теме. Для программиста ИИ в игрострое ситуация с книгами схожа, но с несколькими интересными особенностями. Здесь важна не только глубина знаний, сколько наработанность с инструментами, библиотеками и технологиями в целом, а с учетом что новые подходы развиваются с поразительной скоростью, поразительной для игростроя конечно. Казалось только лет 10 назад стали использоваться BT (behavior tree), но и они уже имеют редакцию 4.x (https://www.behaviortree.dev/). Но важно не зацикливаться на затаскивании в проект модных примочек, базовые знания остаются самым важным что можно получить. Это как в притче о удочке — дай человеку рыбу, и он накормит себя сегодня; дай ему удочку, и он будет кормить себя всю жизнь. Удочкой в этом случае выступает знание, как оно работает, а не как можно его использовать.

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

Всегда хотел написать о чем-нибудь легком и воздушном, как пишет например @antoshkkaпро userver или о том, как легко и непринужденно обернуть какую-нибудь хрень алгоритм в десяток шаблонов, полить это все std::optional и попивая кофе ждать, когда компилятор соизволит это всё пережевать. Но судьба (а не тимлид, нет, как вы могли такое подумать) постоянно подкидывает задачки, где суровые объятия отладчика не отпускают мечтательную душу программера до поздней ночи, да вечная борьба с компилятором рушит все попытки обернуть результат хрени алгоритма в другой десяток шаблонов. На этот раз судьба ясным июньским утром подкинула забавную задачу - время полной сборки бандла подбиралось к двум часам, да собирать бандлы нынче удовольствие не из быстрых, но посмотрев статистику стало понятно, что ~55% процентов времени тратится на сборку ресурсов: текстур, моделей, локализацию, и тд. Там есть что чинить, но это царство билд-инженеров. Еще 30% или сорок минут тратится на тесты, теперь все что мы насобирали и переконвертили надо проверить, загрузить, пострелять, побегать, монстров поубивать, BT-шки погонять, с этим пусть QA разбираются. А вот оставшиеся 15% или около 15 минут мы занимались настоящей работой, собирали сердце проекта - бинарь. Да норм, у нас всегда так, даже на пустом проекте UE - сказали наши мобильщики и ушли пить кофе на терассу . Но мы же не мобильщики, мы серьезные AAA ребята, у нас свой движок и кастомный пайплайн на билдферме. И потом 15 минут это очень много, даже если у тебя 27к файлов в проекте, айда смотреть куда время потратили.

В конце технического интервью, если кандидат ответил на вопросы и справился с задачами, у нас есть время для свободных вопросов, которые можно задать команде или кому-то из интервьюеров. Эту практику я переносил из компании в компанию, и она всегда помогала разрядить обстановку или вывести человека на разговор, если он был напряжен во время общения. Вопросы могут быть любые, кроме личных или тех, что под NDA. Обычно кандидаты задают технические вопросы по стеку, пайплайнам, иногда пытаются задать каверзные вопросы, особенно по плюсам, чтобы проверить нас. Иногда мы не можем ответить на них. Вопросы в стиле Google — например, «почему таблетки круглые?» — тоже встречаются, но недавно на одном из интервью прозвучал вопрос, на который вроде все и знали ответ, но никто сразу не смог его дать. Вопрос звучал так: «Какие общие технологии и решения появились в процессорах с времён 486, которыми мы часто пользуемся?»

Вопрос действительно интересный — что нового появилось, чем мы пользуемся каждый день? Что умеют современные процессоры, чего не могли процессоры год или два назад, пять или десять лет назад, сорок лет назад? Мы просто используем миллиарды транзисторов, даже не зная, как они работают. Покопавшись в Википедии, на сайте Агнера Фога и в документации Intel, я составил список того, что появилось и используется в современных процессорах. Всё, что указано ниже, относится в основном к x86 и консолям, если не указано иное. Поскольку консоли после третьего поколения PlayStation — фактически ПК с минимальными отличиями, речь дальше пойдёт в основном о ПК. История имеет склонность повторяться, и многое из того, что мы сейчас имеем, вводилось не один раз, просто под разными названиями.

В 2014 году в движке Unity набралось столько критических изменений и новинок, что «пятерка» фактически была другим движком. И хотя многие за одинаковым фасадом не особо этого и заметили, но изменения коснулись всех компонентов движка, начиная от файловой системы и заканчивая рендером. Питерский офис EA имел свою ветку основного репозитария, отставая от мастера максимум на месяц. Я уже писал про различные реализации и типы строк в игровых движках, но в Unity была своя реализация, имевшая как положительные так и отрицательные стороны, которая использовалась практически во всех подсистемах. К ней привыкли, знали слабые стороны и плохие «use cases» и хорошие «best practices». Поэтому когда эту систему стали выпиливать из движка много чего поломалось, и если у обычных пользователей был сразу переход на новую версию и наблюдались только отголоски шторма, то допущенные до «тела» наловили много прикольных багов.

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

В бытность мою лидом в Gaijin, получилось поработать со многими отличными людьми и профессионалами своего дела, в том числе Женей К. и Давыдом Ф., и даже после перехода в другую студию мы продолжаем поддерживать связь, кидая друг другу интересные новости и поздравляя с днем рождения. Собственно несколько месяцев назад так мне и прилетел очередной хохмотред про джунов (не ходите туда, дабы не создавать хабрэффект) интересные цитаты я выложу ниже. Но на тот момент было совсем туго со временем, очередной майлстоун, поиск работы, собеседования новых ребят, перетряски в компании, вообщем не до тредов и статей было особо, доползти бы до кровати не уснув по дороге. Тогда глянул мельком, отметил странную подачу материала и забыл.

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

void в плюсах довольно забавная штука. Мы можем привести к void почти любой тип, завести указатель с типомvoid*, который может адресовать что угодно. Еще можем сделать функцию с возвращаемым типом void , которая ничего не возвращает. Объявление функции типа void f(void) будет просто функцией без аргументов. Но вот иметь объекты типа void или написать что-то вроде void& не можем. Это немного странно, но не настолько, чтобы вызывать у вас бессонные ночи, пока вы не начинаете ловить странные баги, когда void вообще не void.

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

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

В конце 90-х годов историческая серия градостроев от Sierra была на вершине популярности, получала отличные отзывы и породила немало последователей и подражателей, начиная от Сhildren of Nile и не заканчиваясь в Banished (2014), Pharaoh: A New Era(2023), Nebuchadnezzar (2021), Builders of Egypt(к сожалению закрытая) став фактически дедушкой жанра. Фараон появился в 1999 году после двух лет разработки, вслед за любимой многими Caesar III. Это была первая игра серии, которая перенесла сеттинг из Древнего Рима в Древний же Египет и предложила (хотя на самом деле фактически повторила, реальным шагом по механикам стал Зевс) сложный игровой процесс, не завязанный однако на микроменеджменте зданий и жителей. Собственно многие и помнят эти игры, благодаря сотням проваленных миссий, когда император в гневе присылал войска или королевство отзывало титул изза долгов. До первой игры от "пароходов" еще целый год, да и жанры и сеттинги достаточно далекие, так что 1999 и 2000 Фараон собирает лавры и сливки с продаж, а Simon Bradbury, главный технический гений студии и душа проекта, покидает команду и основывает свою Firefly Studios, чтобы подарить нам Stronghold.

В процессе кодоархеологических раскопок бинарника, что Цезаря, что Фараона было найдено немало интересных окаменелостей легаси технических решений, многие из которых я видел в других проектах и не только игровых. Возможно это дремучее легаси (хотя и не такое дремучее как AoE1/2) может показаться топорным, но красота решений определенно есть, и учтите что игры запускались и выдавали неплохие фпс (15-30), работая на разных первых пеньках, 586, атлонах с 32 мб памяти всего, а не только кеша. И работали быстро, красиво и на одном ядре.

Ошибки программистов C++ — это отдельный вид искусства, вроде бы простой язык, но стоит отвлечься на чашечку кофе, как компилятор начинает вываливать простыню ворнингов пополам с ошибками, и иногда это больше похоже на древнеегипетские письмена, чем на нормальный выхлоп. Вы наверное и сами не раз сталкивались с разыменованием nullptr или перепутали (= и ==) по недосмотру. Часто причиной ошибкой является лень или невнимательность, или усталость - не зря появились суеверия "не комитить в пятницу вечером", "не кодить в состоянии изменного сознания" или "избегать кода под кофейным угаром", ну это когда три-четыре кружечки кофе навернул и пошел нести добрый код направо и налево.

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

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

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

- bool LoadAnimation(str::string filename);
- void DrawLines(std::vector path);
- Matrix RotateObject(Matrix m, Angle angle);
- int DrawSprite(Sprite sprite);

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