A-tit indd

Паттерны программирования игр
— Паттерны поведения
233
Допустим, мы даем нашим разработчикам команду 
к старту, и они начинают писать подклассы для супер-
сил. Что произойдет?
• Будет очень много избыточного кода
. Несмотря 
на разнообразие, наверняка встретятся повторы. 
Разные суперсилы будут сопровождаться похожими 
визуальными и звуковыми эффектами. Заморажи-
вающий, испепеляющий лучи и луч из дижонской 
горчицы окажутся чуть ли не идентичными, когда 
вы дойдете до реализации. И если не скоординиро-
вать работу людей, который пишут код, то получит-
ся очень много дублирования.
• Каждая часть игрового движка будет сильно свя-
зана с классами
. Не зная других способов, разра-
ботчики будут писать код, вызывающий методы 
подсистем, которые изначально не должны иметь 
никаких связей с классами суперсил. Даже если 
мы организуем рендеринг на нескольких уровнях 
и только одному из них поручим взаимодействие 
с кодом за пределами графического движка, я го-
тов поклясться, что в итоге у нас будут суперсилы, 
пытающиеся взаимодействовать со всеми слоями.
• Внесение изменений во внешние системы с большой 
вероятностью вызовет кучу ошибок в случайных 
местах кода суперсил
. Так как множество классов 
суперсил связаны с самыми разнообразными частя-
ми игрового движка, внесение изменений в эти си-
стемы неизбежно отразится на классах сил. Но раз-
работчики графики, аудио и ИИ точно не хотят 
участвовать 
еще и 
в разработке игрового процесса…
• Сложно определить постоянные, которым подчи-
нялись бы все суперсилы
. Допустим, мы хотим убе-
диться, что все аудиоэффекты, сопровождающие 
суперсилу, всегда соблюдают очередь и получают 
правильный приоритет. Но простого способа это 
сделать нет, ведь сотни классов напрямую взаимо-
действуют со звуковым движком, когда им нужно.

---