Недавно, благодаря удачному стечению обстоятельств, меня пригласили на один из крупнейших немецких игровых подкастов, Stay Forever, где мы обсуждали метод разработки RollerCoaster Tycoon (1999). Это было увлекательное интервью, которое можно целиком послушать здесь — конечно, если вы понимаете немецкий. Если нет, то ничего страшного — в этой статье я перескажу его основное содержание и затрону другие интересные моменты.

RollerCoaster Tycoon, как и её сиквел, практически полностью написанные Крисом Сойером на ассемблере, считаются одними из самых оптимизированных игровых проектов за всю историю. Автор каким-то чудесным образом смог добиться плавной симуляции полноценных тематических парков с тысячами агентов на железе 1999 года. Невероятно впечатляющий результат с учётом того, что сегодня многие похожие симуляторы строительства едва обеспечивают стабильный фреймрейт.

Как же Крису Сойеру это удалось?

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

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

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

Но помимо использования ассемблера, код RCT изначально писался с жёстким упором на оптимизацию. Откуда нам это известно, если его исходники никогда не разглашались? А у нас есть весьма удачный образец для анализа: полностью аутентичный ремейк игры под названием OpenRCT2.

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

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

Градация денежных ресурсов

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

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

Замена математических операций битовым сдвигом

Если заглянуть в исходники OpenRCT2, то мы увидим, что в нём часто используется синтаксис, который в современном коде встречается редко. Например:

NewValue = OldValue << 2;

В C++ за счёт использования перегрузки оператор << может иметь разное значение. Действие этой строки соответствует тому, что большинство программистов записали бы так:

NewValue = OldValue * 4;

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

Поначалу это звучит как странная техническая муть, но при умножении чисел в десятичной системе мы, по сути, делаем то же самое. К примеру, когда вы умножаете 57 на 10, то реально «вычисляете» эту операцию? Или же просто добавляете 0 к 57? И здесь тот же принцип, только применяется он в другой числовой системе.

Аналогичный приём можно использовать и в обратном направлении при делении:

NewValue = OldValue >> 3;

По сути, это:

NewValue = OldValue / 8;

В RCT это проделывается постоянно, и даже в версии OpenRCT2, так как компиляторы не будут безусловно выполнять эту оптимизацию за вас.

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

Но ещё более интересное в этих вычислениях то, как часто их удаётся проделывать в коде. Очевидно, что битовый сдвиг можно выполнять только для операций умножения и деления, кратных двум — например, 2, 4, 8, 16 и так далее. Получается, что во внутриигровые формулы специально закладывалось использование именно этих чисел. В большинстве же современных проектов разработки такое просто невозможно. Представьте себе, что программист просит гейм-дизайнера изменить формулу так, чтобы в ней использовалось число 8, а не 9,5, потому что так процессору будет проще считать. И здесь есть веский аргумент, мол, гейм-дизайнеру вообще не пристало беспокоиться о влиянии характеристик бинарной арифметики на игровую производительность, ибо это удел программистов. Но, к счастью, в случае RCT гейм-дизайнером и программистом был один человек, что также подводит нас к третьей мощной оптимизации.

Гейм-дизайн с упором на производительность

RCT никогда не был проектом исключительно одного человека. Хотя нередко его преподносят именно так. К примеру, всю графику и дополнения создавал Саймон Фостер, а за звуковое оформление отвечал Алистер Бримбл.

Но, пожалуй, будет справедливо назвать RCT игрой Криса Сойера, который был её главным программистом и единственным гейм-дизайнером.

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

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

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

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

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

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

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

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

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

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

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

Отсутствие заторов даже при толпах людей

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

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

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

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