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

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

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

С Sublime Text я познакомился в августе 2008 года, уже не помню откуда, вроде как с диска Хакер или Софтерры, был этот чудо-редактор установлен. Уже 15+ лет это мой верный спутник для правки всего и вся, я не покупал лицензию, сначала действовал ключик с диска, а потом я нашел там баг: если редактор запускался в 00:00, то он не спрашивал лицензию и просто работал до закрытия. Уж не знаю, был ли это баг или пасхалка, но хак работал. Потом я отправил багрепорт кому-то из разработчиков, где подробно описал саму механику бага, кажется, это был Джон Скиннер, а через неделю получил ответное письмо с ключиком и благодарностью за найденный баг. С тех пор, как появилась возможность оплачивать лицензии на Sublime, я покупаю лицензию на каждую мажорную версию. 99 баксов в эпоху 10к гейминга — не такая уж и большая цена за игру, в которую я играю десяток лет каждый день. Вот таким он был в самой первой версии.

А еще там был и есть офигенный фулскрин режим, который убирал все лишнее и оставался только КОД и ты, можно было даже скролбар убрать.

Sublime не пытается быть IDE, зато открывает 50к строк кода быстрее, чем я успеваю донести руки до клавиатуры, не лагая на регулярках в мегабайтных логах. Да, для полного цикла я использую студию (VS), но когда нужна скорость и фокус, а не глупые подсказки второго пилота — Sublime незаменим, как и семнадцать лет назад — только ты и КОД.

Потому что тулзу писали разработчики, которые ценят свое время, для разработчиков, которые ценят свое время. Что-то подобное я испытывал, когда мне удалось собрать и запустить утекший билд Unreal Engine в 2014 году, вроде (точно не помню). Он тоже стартовал "мгновенно", быстро грузил уровни и летал по ним в 60 фпс, и это всё на железе "2 гига 2 ядра".

Это и сейчас лучший движок на планете, объективно лучший, потому что никто не предоставляет такого количества ассетов, платных и бесплатных, плагинов и готовых решений. Но когда я ставлю какой-то кубик на уровень, я не ожидаю, что движок будет тормозить на топовом железе. Ну ок, может 3080 и 80 ГБ не совсем топовое. Ладно, с кубиком ещё справляется, фриз не так заметен, но что-то посложнее ставлю — и движок начинает подфриживать, шейдеры там пересобирает секунд десять, на диск что-то писать. Я отвлекаюсь на это и теряю нить своих мыслей, я выпал из потока, и теперь мне придется потратить минуту, чтобы "вспомнить" и двинуться дальше.

Хуже только мука с запуском уровней или выходом из симуляции, это больше уже из другого движка (Unity), но и для Unreal тоже верно: нажали кнопку симуляции и "ждем". Чего ждем? Зеленее не будет... Ну вот прогрузилось. Поехали тестировать. А представьте, что вам приходится так сделать 100 раз за день — это не просто слова. Сто раз за день дизайнер (да и программер тоже) жмёт кнопку симуляции и ждет, а потом ещё ждет, и потом ещё немножко ждет. Вот и день закончился.

Или Visual Studio. Вы открывали когда-нибудь процессы для неё?

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

Вот тут небольшое приключение, о том, как чинить 15 минут сборки проекта (https://habr.com/ru/articles/856916/)

У sublime один процесс в системе, изредка там запускается что-то еще.

Есть еще один пример софта, о котором я до сих пор не знаю, что сказать. Это Oodle от RAD Tools, очень известные в игрострое ребята, почти все CGI-ролики в играх конца девяностых — начала нулевых использовали их для сжатия видеороликов. Их библиотеки — образец оптимизации под железо, реализация под плойку рвет всякие lzma и иже с ними алгоритмы сжатия на этой платформе, и немного отстает от хардварной реализации. Вы представляете, что кто-то сделал софтовый алгоритм, который работает наравне с реализацией в железе?

Есть правда один минус — дорого, очень дорого для обычного использования, лицензия начинается от 50к за игру, но думаю, для больших игр это не очень-то и проблема. Если ты начал задумываться о том, чтобы использовать Oodle для своего 100Gb билда, то наверное не проблема найти полтинник для этих ребят. Проблема, когда время загрузки ассетов из архивов занимает 30 секунд на lzma против 5 на Oodle — это не код, это искусство (Kraken — это реализация Oodle под плойку с учетом специфики консоли и доступного железа).

Разработка вообще, и разработка на плюсах в частности – это сложный процесс, в котором каждая мелочь может привести к UB или крашу. Отладка является неотъемлемой частью этого процесса, позволяя выявлять ошибки, оптимизировать производительность и гарантировать стабильную работу. Мой лид часто шутит, что отладка — это «темная магия», потому что те баги, которые приносит в клювике QA team, они в принципе не могут существовать, и они их наколдовали. И в открытую говорит на созвоне: «Опять эти шаманы из куа нам багов наколдовали». Шутка, конечно же, я очень ценю их работу и наколдованные баги.

Инструменты для отладки и профилирования — это вообще отдельная религия. RenderDoc открывает GPU-снимок за 2 секунды. Отлично! Значит, вы будете делать их чаще, чаще смотреть артефакты, быстрее находить ошибки. Tracy с его мгновенной выборкой данных по статистике, времени выполнения функций, потреблению памяти и кучей других плюшек, уже где-то лет пять у нас в проекте используются оба профайлера Pix/Tracy, и я вижу, что всё чаще именно Tracy запущен у коллег, надо только нажать шорткат в игре, и откроется профайлер с фреймами за последние 2 секунды.

А теперь сравните это с PIXом, когда мне надо запустить игру, собрать данные, остановить игру, дождаться сбора дампа с консоли, подождать обновления внутренней БД, попить кофе, пока идет анализ этих данных.

И вот теперь я могу посмотреть и исследовать, где просаживается перфоманс. Вот блин... только я забыл, какой это был фрейм, сейчас поищем. Знакомо? Это разница между пиксовским «кажется, тут просадка FPS» и точным знанием, где цикл съедает миллисекунды, который мне дает Tracy.

У вас могло сложиться впечатление, что я тут несколько негативно отозвался о PIX, это не верно, это очень мощный инструмент, который умеет ВСЁ, но почему он такой медленный? Что сотня звездно-полосатых индусов не могут сделать то, что делает один парень из Кракова?

Photoshop для текстур? Он безбожно тормозит при работе с 8/16K PSD, а переключиться не на что, потому что весь пайплайн сборки завязан на него. Вы скажете, есть GIMP/Substance Painter, которые летают относительно фотошопа, но мы даже не поднимаем вопрос о переходе, потому что придется переделывать все скрипты. Или Maya с её вечными зависаниями при скиннинге и случайными крашами. Упала майка на экспорте модели — да пофиг, моделер перезапустит ещё раз, у него же куча времени до майлстоуна. Скорость и стабильность здесь точно не были фичей при разработке.

Сколько раз я слышал: «Да это же мелочь — окно сейва в нашем редакторе грузится всего 3 секунды». Да, всего три секунды, но когда ты сохраняешься 100 раз за день, это 5 минут жизни. А теперь умножьте на 100 человек в команде. Мелочи — это термин для тех, кто не считает время разработчика. Три секунды — это много? Нет, просто окно в редакторе грузится в сто раз дольше, чем должно.

Наш прошлый редактор был на WPF, и это были вечные тормоза. Потом стали переводить его на ImGui, это вообще-то библиотека для дебаг-интерфейсов, но она нереально быстрая. Она рендерит элементы напрямую в DirectX, без тяжеловесных обвесов, предварительных сборок окон, мегабайтных форм. В результате UI не проседает даже на 1000 кнопок. Ага, была такая жесть в каком-то из меню, там было 0 (ноль!) фпс на WPF, его открывали только QA, когда их били палками — это был список тестов :)

Потом на ImGui переехал весь редактор, и это было щаСтье с большой буквы С — скорость.

Почему скорость критична в разработке игр? Потому что игра — это симуляция реальности в 16ms на кадр. Если редактор уровней не успевает за мыслью дизайнера и плетется на 15-20 фпс, дизайнер сделает только треть своей работы и растянет сроки сдачи фичи в три раза, попутно сделав кучу ошибок. Он их и так бы сделал, просто скорость текущей работы не дает ему их исправить. Потому что быстрые инструменты приучают к быстрым итерациям, которые позволяют делать меньше ошибок, потому что вы быстрее их исправляете, вы чините ошибку до того, как она станет проблемой у других.

Мне некуда деться от Visual Studio, Photoshop, Maya, Symplygon и зоопарка SDK, ибо больше никто не умеет собирать проект сразу под все консоли. Скорость ПО в разработке — это не про «успевать к дедлайну». Это про уважение ко времени разработчика: когда билд-сервер, редактор или компилятор не заставляют ждать, когда можно потратить время и силы на создание, а не на борьбу с лагами и ожидание. И да, иногда ради этого стоит написать свой кастомный инструмент вместо того, чтобы мириться с «общепринятым, но медленным». Как говорил один хороший человек: «Если что-то лагает — найди это в профайлере, а потом аккуратно удали этот код».

P.S. Sublime Text, вопреки всем модным VS Code, до сих пор открывается быстрее, чем я успеваю убрать руку с мышки. И это бесценно. Это магия, за которой — годы оптимизаций.