Да это просто пример был, есть приложение, есть объекты, есть объекты в объектах, надо проинформировать приложение о смене состояния.
Но да, я свои танчики делал, лет 8 назад, было такое. На рсдн-е даже есть видео одного забавного бага про останавливающиеся ракеты. Весёлое было времечко :)
А если я недоволен, то как надо сделать?
Код стал удобнее. Приложение пинает только объекты верхнего уровня.
это был пример :) Но, кстати, судя по всему, все любят игры, раз такой интерес сразу.

Меня вообще интересовал паттерн для этой задачи, какой обычно используется?

Ещё раз расскажу:
- Приложение оперирует объектами класса A, класс A содержит объекты класса B, объекты класса B не имеют доступа к Приложению, но должны его информировать о некоторых событиях.
- Вариант 1. Приложение при управлении объектами класса A, само опрашивает дочерние объекты класса B на тему изменения состояния.
- Вариант 2. Объекты класса B в случае изменения состояния, собирают нотификацию и отдают её родительскому объекту класса A, а тот пересылает его Приложению.

Что хорошо, что плохо, как правильно?

Ну оно ответственное за UI, потому и берёт.
Плохо: карта лезет напрямую в UI. Ей надо знать про UI, она привязана к UI.
Хорошо: можно сделать такое архитектурное решение, в котором объекту нижнего уровня можно привязать объект из UI(не напрямую), чтобы он сам им рулил, когда надо. Совсем хорошо подходит, когда 1:1. У меня 1:1. Поэтому я теперь задумался про изменения в архитектуре. Ну и у этого тоже есть плюсы и минусы. Плюс, что "прикрепил и забыл", не надо больше думать об обновлении. Минусы - надо проводить дополнительные шаги при инициализации, заботиться о том, что UI подходит данному элементу, следить за тем, что будет, когда один из этих двух закончится и так далее.
В JS всё хорошо на вид, ну, собственно, это и есть мой второй вариант, когда объект нижнего уровня начинает отправлять наверх сообщение, оно проходит через всю иерархию, до document.

Да, согласен, так получается правильнее. Т.е. мне сейчас надо просто из Приложения вырезать кусок, ответственный за UI и оформить отдельно и правильно. Мне такой вариант нравится, спасибо.
Пока да(их там не сильно много ещё, и они не так сильно разбросаны по смыслу). Но по сути получается, если разделять - это надо завести иерархию классов для нотификаций, каждому типу нотификаций - свой класс. И для каждого класса нотификации будет удобно срабатывать полиморфизм. Ну да, всё красиво и по науке, но топологически у меня получается на строках тоже самое. Плюс, если у меня появится ещё одна нотификация, мне придётся идти писать ещё один класс. Тогда как в моём варианте (мне можно вообще ничего не писать) надо только добавить ещё одно условие в обработчик. К тому же, в нотификации приходит много текстовой информации, которую всё равно придётся парсить. Если делать иерархию классов, то первый слой распарсится за счёт полиморфизма. А дальше всё так и останется.

Да я тоже люблю строгую типизацию, но если классов для нотификации становится слишком много, то отношение смысла к количеству кода начинает стремиться к нулю, и ещё вся эта толпа мельтишит в окне проекта. А это я уже не люблю :)