A-tit indd

360
Локальность данных (Data Locality) — 
Паттерны программирования игр
numActive_
. Это позволит сделать объекты частиц 
меньше, а значит, большее их количество поместится 
в строку кэш-памяти, и выполнение программы уско-
рится.
Однако не все так прекрасно. Как вы можете заметить 
из API, мы потеряли частицу ориентированности на объ-
екты. Класс 
Particle
больше не контролирует свое соб-
ственное состояние активности. Вы не можете вызвать 
метод 
activate()
для него, поскольку не знаете его ин-
декс. На самом деле любому коду, который захочет акти-
вировать частицу, понадобится доступ к 
системе
частиц.
В общем, нормально, если классы 
ParticleSystem
и 
Particle
будут тесно связаны. Мне нравится думать, 
что передо мной 
единая
идея, разбитая на два разных 
класса
. То есть частицы имеют значения только в кон-
тексте некоторой системы частиц. И если система ча-
стиц будет порождать новые и убивать старые части-
цы — это тоже нормально.
Горячее/холодное разбиение
Ладно, даю последний пример простой техники, кото-
рая облегчит использование кэша. Допустим, у нас есть 
компонент ИИ для некой игровой сущности. В нем со-
держится состояние — проигрываемая в данный мо-
мент анимация, уровень энергии и так далее — все, что 
проверяется и обрабатывается каждый кадр:
class AIComponent
{
public:
void update() {/* … */}
private:
Animation* animation_;
double energy_;
Vector goalPos_;
};
Но есть и другое состояние, оно используется реже. 
В нем хранится информация о том, какой предмет 

---

Паттерны программирования игр
— Паттерны оптимизации
361
выпадает в качестве награды, когда сущность случайно 
сталкивается с патроном нашего шумного ружья. Эти 
данные используются только один раз за весь жизнен-
ный цикл сущности, а конкретно в момент ее смерти:
class AIComponent
{
public:
void update() {/* … */}
private:
// 9 …
LootType drop_;
int minDrops_;
int maxDrops_;
double chanceOfDrop_;
};
Если мы применяем ранние паттерны и обновляем 
компонент ИИ, то мы проходим через хорошо скомпо-
нованный цельный массив данных, включающих в себя 
в том числе информацию о выпадающем предмете. Это 
делает каждый компонент больше, а значит, уменьша-
ет количество компонентов, которые могут поместить-
ся в кэш. Следовательно, мы получим больше пропусков 
кэша, ведь общий объем памяти становится боль-
ше. Данные о выпадающем предмете попадают в кэш 
на каждом кадре для каждого компонента, даже если 
они нам не нужны.
В качестве решения проблемы предлагаю «горячее/
холодное разбиение». Разобьем нашу структуру данных 
на две самостоятельные части. Первая будет содержать 
«горячие» данные — состояние, нужное нам на каждом 
кадре. Другая часть — «холодные» данные — все осталь-
ное, что используется реже.
Горячая часть —
главный
компонент ИИ. Ее данные мы 
используем часто, поэтому не хотим следовать за ними 
по указателю. Холодный компонент мы отложим в сторо-
ну, хотя он нам все равно может понадобиться, так что 
мы дадим горячему компоненту указатель на холодный:

---