A-tit indd

разделяемых всеми объектами определенного типа.
Назовите меня сумасшедшим, но это очень похо-
же на мое описание классов. Вы 
можете
написать код 
в прототипном стиле на JavaScript (
без
клонирования), 
но синтаксис и идиомы языка призывают именно к под-
ходу на основе классов.
Лично мне нравится такой подход. Как я уже сказал, 
по моему мнению, слишком большой упор на использо-
вание прототипов усложняет работу с кодом, поэтому 
я радуюсь, когда JavaScript оборачивает основную се-
мантику в нечто более «классное».
 Прототипы для моделирования данных
Ладно, я продолжаю говорить о вещах, которые мне 
не
нравятся в прототипах, а это делает главу немного 
печальной. Но вообще-то изначально я собирался сде-
лать книгу больше похожей на комедию, чем на траге-
дию, и потому давайте закончим главу примерами, где, 
на мой взгляд, прототипы, или, точнее, 
делегирование
, 
могут быть полезными.
Если бы вы подсчитали в игре все байты, кото-
рые составляют код, и сравнили получившееся чис-
ло с байтами данных, то увидели бы, что доля данных 
неуклонно растет с самого рассвета программирова-
ния. В старых играх почти все данные генерировались 
в процессе выполнения — их же требовалось уместить 
на дискеты и старые игровые картриджи. Во многих 
играх сегодня код — всего лишь «движок», который 
управляет игрой, а та в свою очередь полностью опре-
деляется данными.
Это здорово, но помещение содержимого в файлы 
данных не решает волшебным образом задачи органи-
зации большого проекта. А в некоторых случаях даже 

---

Паттерны программирования игр
— Другой взгляд на паттерны проектирования
93
усложняет ситуацию. Причина, по которой мы исполь-
зуем языки программирования, состоит в том, что у них 
есть инструменты для снижения сложности.
Вместо копирования и вставки фрагмента кода в де-
сяти местах мы перемещаем его в функцию, которую 
можем вызвать по имени. Вместо копирования метода 
в кучу классов мы помещаем его в отдельный класс, от-
куда другие классы наследуют или заимствуют.
Когда объем данных вашей игры достигает опреде-
ленного размера, вам действительно уже хочется иметь 
похожую функциональность. Моделирование данных —
широкая область, я даже не надеюсь осветить ее здесь 
полностью, но хочу указать на одну особенность, кото-
рую вы можете учесть при разработке собственных игр: 
использование прототипов и делегирование для со-
вместного использования данных.
Предположим, мы определяем модель данных для 
бесстыжего клона Gauntlet, о котором я упоминал ра-
нее. Разработчики игр должны указать атрибуты для 
монстров и предметов в некоем подобии файлов.
Распространенный подход — использовать JSON. Это 
объекты данных, в основном 
карты
, или 
сумки с предме-
тами,
или дюжина любых других терминов, потому что 
программиста хлебом не корми, дай придумать новое 
название для того, для чего оно уже есть.
Следовательно, гоблин в игре может быть определен 
примерно так:
{
"name":"goblin grunt",
"minHealth":20,
"maxHealth":30,
"resists":["cold", "poison"],
"weaknesses":[" re", "light"]
}
Это настолько просто, что даже дизайнер, который 
ненавидит писать код, справится. Таким образом, вы 
можете создать пару ветвей в семейном древе Велико-
го Гоблина:
Я использую полностью 
оригинальное название, 
никоим образом 
не вдохновленное ника-
кими ранее существо-
вавшими аркадными иг-
рами с подземельями 
и видом сверху. Пожа-
луйста, не подавайте 
в суд на меня.
Мы изобретали их за-
ново столько раз, что 
Стив Йегге назвал это 
«Универсальным шабло-
ном проектирования».

---