A-tit indd

Паттерны программирования игр
— Паттерны уменьшения связанности
301
воспроизводить ограниченное количество звуков. Осталь-
ные игнорируются или обрезаются.
Чтобы решить эту проблему, нам придется просмо-
треть весь 
набор
вызовов звукового движка, агрегиро-
вать их в единое целое и расставить приоритеты. К не-
счастью, наш аудио API обрабатывает каждый вызов 
playSound()
независимо. Он видит запросы словно 
через замочную скважину, по одному в каждый момент 
времени.
• Проблема 2: запросы не получится обрабатывать 
в агрегированной форме.
Но упомянутые проблемы — всего лишь небольшое не-
удобство по сравнению с тем, с чем мы столкнемся даль-
ше. На данный момент вызовы метода 
playSound()
разбросаны по всему коду, по всем игровым системам. 
А наша игра работает на современном многоядерном 
аппаратном обеспечении. И чтобы воспользоваться пре-
имуществом многоядерности, мы распределим наши си-
стемы по разным потокам: рендеринг в один, ИИ в дру-
гой и так далее.
Поскольку наш API синхронный, он будет работать 
в потоке 
вызовов
. И когда мы вызываем его различными 
системами игры, мы сталкиваемся с конкуренцией за наш 
API со стороны нескольких потоков. Посмотрите на пример 
кода выше. Видите синхронизацию потоков? Вот и я нет.
Это неудивительно, ведь мы планировали вынес-
ти нашу аудиосистему в 
отдельный
поток. А она сидит 
тут, прохлаждается, пока другие потоки работают в поте 
лица, мешая друг другу и ломая друг друга.
• Проблема 3: запросы обрабатываются не в том 
 потоке.
Обычно эта проблема связана с тем, что наш аудиодви-
жок интерпретирует вызов метода 
playSound()
как 
«Брось все и немедленно воспроизведи звук!». Пробле-
ма в 
срочности
. Другие системы игры вызывают метод 
playSound()
, когда удобно 
им
, а не когда аудиодвижку 

---