Бывшие нефтяники собрали топ-даун шутер: 200 врагов на экране

Что произошло, почему это важно и что взять в работу.

Урок для разработчиков: ускорение не того узкого места не даёт ни одного кадра — сначала профилирование, потом оптимизация.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

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

Они ускорили игровую логику в двадцать раз. И не получили ни одного лишнего кадра.

Логику можно ускорить в 20 раз и не выиграть ни одного лишнего кадра, потому что лаг приходит совсем не оттуда, где его привыкли искать.

Вот это — главный урок сюжета. Не про шутер. Про то, как команды годами оптимизируют не то.

Что вообще произошло

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

К моменту, когда до показа паблишеру оставалось два дня, у них была игра, которая работала. Но потряхивала. И вот тут начинается интересное.

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

И ничего не изменилось. Ноль кадров прироста. Потому что узкое место было не там.

Почему это важнее, чем кажется

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

Почему? Потому что профилирование — это скучно. Оно не даёт ощущения прогресса. Ты сидишь, смотришь на графики, замеряешь, отсекаешь гипотезы. А оптимизация — это действие. Ты что-то меняешь, что-то ускоряешь, чувствуешь, что работаешь. Даже если ускоряешь не то.

Команда бывших нефтяников прошла этот путь в ускоренном режиме. Два дня до дедлайна. Паника. Желание сделать хоть что-то. И они сделали — ускорили логику в двадцать раз. Красивое число. Его можно показать в отчёте. Только вот игроку от этого ни холодно, ни жарко.

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

Что они сделали вместо этого

А вот тут начинается самое интересное. За оставшиеся двое суток команда сделала то, что звучит как капитуляция перед всем, чему учат на конференциях по разработке.

То, что они сделали за эти двое суток, звучит как капитуляция перед всем, чему учат на конференциях по разработке. И это сработало.

Что именно они сделали — в сигнале не раскрывается. Нет ни названий инструментов профилирования, ни конкретных метрик FPS, ни описания архитектурных решений. Мы не знаем, отказались ли они от какой-то абстракции, переписали ли цикл обновления, поменяли ли модель данных. Но сам факт показателен.

Когда дедлайн дышит в затылок, а кадры не растут, люди начинают делать вещи, которые в спокойное время назвали бы кощунством. Убирают слои. Режут красивые паттерны. Отказываются от того, что «правильно», в пользу того, что «работает». И иногда это вытаскивает проект.

Не потому что каноны плохие. А потому что каноны описывают усреднённый случай. А у вас — конкретный. С конкретным профилем, конкретным железом, конкретной игрой.

Что с этим делать в понедельник

Если вы пишете софт — неважно, игру, веб-сервис или мобильное приложение — эта история про вас. Потому что «ускорили не то» — это универсальная болезнь. Вот короткий чек-лист, который стоит пройти до того, как вы начнёте что-то оптимизировать.

1. Замерьте, прежде чем трогать. Не «кажется, что тормозит вот здесь», а конкретный профиль. Без цифр вы гадаете.
2. Найдите настоящий bottleneck. Один. Тот, который держит остальные. Ускорение всего остального не даст ничего.
3. Проверьте гипотезу на минимальном изменении. Не переписывайте модуль целиком. Сделайте одну правку, замерьте, сравните.
4. Отделите «правильно» от «работает». Если архитектурное решение мешает вам попасть в дедлайн — это не архитектура, это якорь.
5. Зафиксируйте результат. Если ускорение в двадцать раз не дало кадров — это тоже результат. Он говорит, что вы копали не там.

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

Вердикт

История бывших нефтяников — не про то, как круто накостылять за двое суток. Она про то, что профилирование — это не этап. Это привычка. И если её нет, вы будете ускорять логику в двадцать раз, пока игра трясётся.

Хорошая новость: bottleneck всегда найдётся. Плохая: он почти никогда не там, где вы думаете. И единственный способ узнать — перестать угадывать и начать мерить.

Двести врагов на экране — это не проблема. Проблема — двести врагов на экране, когда вы оптимизируете не то, что их рисует.