в контроллере достаточно повесить слушатель на всю большую вью, а из юнитов диспатчить события с bubbles=true - тогда они будут насквозь пролетать аж до контроллера, и контроллер сможет их поймать и обработать. В большой вью делать ничего не нужно для этого.

Короче говоря - надо все переписывать. Я как-бы понимаю что такое MVC, и понимаю что моя стратегия написания неправильна. Но в то же время не понимаю как мне полностью абстрагировать вьюшку от всего происходящего, как организовать работу их троих... Конечно, каждый случай уникальный, правила игры уникальные, поэтому мне самому нужно думать. Но может, если кто-то делал хотя бы похожее, подскажите, пожалуйста, как вы строили эту структуру.
PS: все делается без сервера.

Ну переписывать это кардинальное решение)
Как сделать я тебе уже ответил, чуть выше. Если хочешь можешь в личку/скайп стучаться.

Модель не должны интересовать координаты объекта, для неё объект - некая статистическая единица, с набором соотв. информации (кол-во жизни, патронов и пр.), ИМХО, конечно (на классика пока не тяну )).
Думаю, что контроллер должен трансформировать данные из вью-типа в данные модель-типа, что собсно
и является его прямой обязанностью.

Если говорить не о "хорошем" MVC, а о классической реализации, то контроллер интерпретирует данные
и при необходимости изменяет вьюер (не знаю конкретики, но звено "контроллер", почти всегда лишнее, если события порождают информацию касающуюся только вьюера).

В данном случае координаты это часть модели карты, поэтому они в модели быть должны.

Вообще задача модели хранить всю информацию, которая позволит воссоздать картину происходящего с какой-нибудь другой вьюхой например. Если речь идет о карте то координаты с ней неразрывно связаны.

Если же это будут координаты какой-то там звездочки которая выпадает откуда-то как некий эффект, то конечно ее координаты никому кроме вью не понадобятся.

Значит, я так понял, что: классы юнитов это всего лишь каркасы, которые не должны нести графического представления? Они должны лишь иметь ссылку на класс графического обьекта который они представляют (король, солдат, дом...). А вьюха должна создавать не новые юниты и добавлять их на сцену, которыми оперирует контроллер, а новые анимашки (король, солдат...). Ой-ой-ой сколько же работы предстоит!!!

Нет.
Каждый юнит это тоже моделька МВЦ, маленькая.
У каждого юнита есть модель
Есть вью
И возможно есть отдельный контроллер, а может и нет. Скорее всего контроллером всех юнитов будет этот главный контроллер.

Массив моделей юнитов хранится в модели, ни о каких ссылках на спрайты или мувики там речи быть не может.
Массив вьюх в свою очередь хранится в главной вьюхе.
Вьха когда рендерится она смотрит в массив моделек, и создает у себя аналогичный массив визуальных штук, пользуясь данными из этих самых моделек.

Но это одна из частных реализаций, может быть и иначе.

Не знал, что классические принципы MVC уже изменились.

Задача модели, вообще-то, хранить логику независимо от вьюера, то есть ваше приложение должно одинаково работать и с вьюером, и с двумя (выполненными в разных масштабах, например) и вообще без него, напр. в консольном режиме...

Комент ради комента.

Я не то же самое сказал?

нет


нет

/всё - 6 знаков, хотя оно того не стоило/