A-tit indd

24
Архитектура, производительность и игры — 
Паттерны программирования игр
Производительность и скорость
Существует еще одно мнение против проектирования 
архитектуры программ и абстракций, особенно в отно-
шении создания игр: якобы они оказывают негативное 
влияние на производительность. Многие паттерны, де-
лающие ваш код более гибким, основаны на виртуальном 
управлении, интерфейсах, указателях, сообщениях и дру-
гих механизмах, каждый из которых как минимум имеет 
накладные расходы во время выполнения программы.
И тому есть причина. Основной смысл проектиро-
вания архитектуры программного обеспечения заклю-
чается в стремлении сделать вашу программу более 
гибкой. Мы стараемся приложить как можно меньше 
усилий для ее изменения. Следовательно, в программе 
должен присутствовать минимум допущений. То есть, 
если вы используете интерфейсы, они должны рабо-
тать с любыми классами, где бы они ни применялись, 
а не только с теми, которые существуют на данный мо-
мент. Вы используете наблюдателей (с. 59) и сообще-
ния (с. 315) для взаимодействия двух частей програм-
мы друг с другом, но используете таким образом, чтобы 
иметь возможность при желании легко увеличить коли-
чество частей до трех или четырех.
Однако производительность — это про предполо-
жения. Практика оптимизации основывается на кон-
кретных ограничениях. Можно ли предположить, что 
у нас никогда не будет более 256 врагов? Отлично, то-
гда уместим идентификатор в один байт. Будем ли мы 
всегда вызывать только метод конкретного типа? Хоро-
шо, мы можем вызывать его статически или использо-
вать встраивание (inlining). Все ли сущности будут при-
надлежать одному классу? Отлично, мы организуем их 
в хороший непрерывный массив (с. 351).
Все перечисленное не означает, что гибкость — это 
плохо! Она позволяет нам быстро изменять нашу игру, 
а скорость разработки, несомненно, важна, если вы хоти-
те получать удовольствие от процесса. Никто, даже Уилл 
Один интересный при-
мер, опровергающий 
это мнение, — шаблоны 
в C++. Шаблонное мета-
программирование ино-
гда позволяет создать 
абстракцию с помощью 
интерфейсов без каких-
либо временных издер-
жек.
Создается простран-
ство для гибкости. Когда 
вы пишете код, вызы-
вающий конкретный ме-
тод в некоем конкрет-
ном классе, вы 
фиксируете использова-
ние этого класса уже на 
момент написания — вы 
жестко прописали 
в коде, какой именно 
класс вызываете. Когда 
вы используете вирту-
альный метод или интер-
фейс, класс, который вы-
зывается, неизвестен 
до момента выполнения 
кода. Это намного более 
гибкий вариант, но под-
разумевает определен-
ные накладные расходы.
Шаблонное метапро-
граммирование нахо-
дится где-то между двумя 
названными вариантами. 
Вы принимаете решение 
о том, какой класс вы-
звать, уже на этапе ком-
пиляции, когда инстанци-
руется шаблон.

---