A-tit indd

 Разбиение кода на кадры усложняет его
Если вы сравните два первых примера кода, то заметите: 
второй немного сложнее. Оба просто заставляют скеле-
тов ходить вправо и влево, но второй делает это, каждый 
кадр передавая контроль в игровой цикл.
Такое изменение практически (см. сноску) всегда 
необходимо, чтобы игровой цикл имел возможность 
обрабатывать пользовательский ввод или изображе-
ние. Первый пример получается не очень практичным. 
Но имейте в виду: его реализация всегда подразумевает 
значительное усложнение кода.
Необходимо сохранять состояние, откуда вы 
вышли, чтобы обновить кадр
В первом примере кода у нас не было переменных, что-
бы определить, куда двигался охранник — вправо или 
Я говорю «практиче-
ски», потому что есть 
ситуации, когда вы мо-
жете совместить несо-
вместимое. Например, 
напишете простой при-
митивный код, не име-
ющий отношения к по-
ведению ваших 
объектов, но при этом 
несколько ваших объек-
тов будут действовать 
параллельно, даже со-
гласуясь с игровым ци-
клом.
Вам понадобится 
только система, позво-
ляющая иметь не-
сколько «потоков» ис-
полнения, которые 
выполняются син-
хронно. Если код объ-
екта предусматривает 
возможность приоста-
новиться, а затем возоб-
новить работу с того же 
места, то вместо необ-
ходимости полностью 
выходить
можно писать 
код в более императив-
ной форме.
Настоящие потоки 
слишком тяжеловесны 
и мешают системе рабо-
тать должным образом, 
но если ваш язык под-
держивает более легкие 
параллельные конструк-
ции, такие как генера-
торы, сопрограммы или 
волокна (fi bers), то вы 
можете их использовать.
Паттерн Байт-код 
(Bytecode) (с. 200) — еще 
один способ создать по-
токи исполнения 
на уровне приложений.

---