A-tit indd

Битва заклинаниями!
Допустим, мы работаем над магической игрой-боем. 
Два мага сходятся в поединке и бросают друг в друга за-
клинаниями, пока один не побеждает. Мы могли бы про-
писать заклинания в коде, но тогда для внесения правок 
нам каждый раз пришлось бы привлекать программи-
ста. Когда геймдизайнер хочет изменить некоторые зна-
чения и испытать, что выйдет, им с программистом при-
ходится перекомпилировать всю игру, перезагружать ее 
и снова возвращаться в сражение.
Так же как и в большинстве современных игр, у нас 
должна быть возможность модифицировать игру уже 
после релиза, чтобы исправлять ошибки и добавлять но-
вые функции. Если все заклинания будут жестко пропи-
саны в коде, то изменения придется вносить в сам ис-
полняемый файл игры.
Пойдем дальше и скажем, что хотим сделать в на-
шей игре возможность 
моддинга
: 
пользователи
сами 
будут создавать собственные заклятия. Однако если за-
клятия прописаны в коде, значит, каждому моддеру ну-
жен полный набор инструментов для компиляции, а мы 
должны обеспечить свободный доступ к коду. Ну а если 
в коде пользователя окажется ошибка, то она сможет об-
рушить игру на компьютере другого человека.

---

202
Байт-код (Bytecode) — 
Паттерны программирования игр
Данные > Код
Думаю, ясно, что реализация на языке движка — не луч-
шая идея. Нам необходимо изолировать заклятия от ядра 
самой игры. Мы хотим легко вносить в них изменения, 
легко их подгружать; кроме того, они должны быть фи-
зически отделены от основного исполняемого файла.
Мне описанные требования очень напоминают 
обычные 
данные
. Если мы сможем определить поведе-
ние в отдельном файле данных, который игровой дви-
жок загружает и «исполняет», мы достигнем поставлен-
ной цели.
Осталось только выяснить, как «исполнить» дан-
ные — заставить байты из файла выражать поведение. 
Есть несколько способов. Я думаю, вы сможете лучше 
понять сильные и слабые стороны 
этого
паттерна, если 
мы сравним его с другим — паттерном Интерпретатор 
(Interpreter).