Наконец-то осилил... Нафлудили мама не горюй
С простейшим примером вроде разобрался.
1. Есть главнй класс приложения.
2. Он создает главный контроллер себя отдает этому контроллеру ссылкой в качестве контейнера вьюх
3. Главный контроллер делает главную вьюху и пихает ее в этот контейнер
4. Главный контроллер делает главную модель (главная модель по сути хранит в себе текущий стейт и знает какое сейчас окно открыто + игровая доп-инфа по типу - сколько уровней пройдено, какой уровень следующий и т.п.)
//********************
после этих действий можно считать что мы стартонули.
Далее
0. У главной модели есть какой-то стейт по-умолчанию (майн-меню к примеру)
1. Главный контроллер глядит что у нас там в модели за стейт, в зависимости от этого создает триаду нужного экрана (майн меню, игровой экран, хайскоры, etc). Вьюху от этой триады засовывает в подчинение главной вьюхе, сам же подписывается на контроллер окна.
2. Вьюха этого окна диспатчит события на действия пользователя, события эти получает и обрабатывает контроллер окна.
3. Как только контроллер окна получает от вьюхи событие ченж_стейт - он диспатчит его дальше.
4. Ченж_стейт от контроллера окна получает главный контроллер. В ответ на это событие он зашибает эту триаду окна и создает другие (например были в главном меню и перешли в окно хайскоров, зашибли майнменю, и создали триаду хайскоров)
//*******************
Так, собственно с логикой Главного контроллера вроде разобрались. Он у нас такой типа крутой, по мелочам не разменивается и решает только глобальные вопросы (в данном примере только ченж_стейт)
Если я тут нигде не протупил - то поидее всё понятно, если же протупил то поправьте. А вопросы у меня дальше.
А теперь собственно самое интересное.
Мы заходим в игровой экран. А тут всё интересно. Возьмем по минимуму:
Делаем тавердефенс. Три вида башен. Пять видов врагов. Три уровня. Всё.
1. После того как главный контроллер получает событие смены стейта на игровой экран он убивает текущий экран и создает игровой (он в момент смены стейта уже знает какой уровень надо открыть, заранее запрашивая себе "правильную модель" с сервера или из файла или откуда там надо.)
2. Получает он данные из этого некого места, пихает их в свежесозданную модель. Прикручивает к ней ее персональный контроллер. Создает по этой модели вьюху и пихает эту вьюху в главную вьюху.
(получается с такой структурой задачей основного класса является только стартонуть это всё а потом быть контейнером для главной вьюхи. Главная вьюха является родительской для всех остальных.)
Тут пока вопросов вроде нету. Мы просто взяли и нарисовали уровень по той же схеме что и остальные окна.
Но в определенный момент у нас начинают появляться на уровне враги. Мы начинаем строить башни. Начинается рубилово-мочилово.
А вот здесь я в ступоре (хотя хз, сейчас напишу как я понимаю, а вы поправите, если бред)
1. По клику на "Создать башню №1" - вьюха уровня диспатчит событие "Создать башню"
2. Ее слышит контроллер уровня.
3. В ответ он создает триаду новой инстанции башни. Вьюху кидает внутрь вьюхи уровня. Модель хранит у себя. Контроллеру башни позволяет заниматься логикой башни(ну к примеру в контроллере башни всякие там таймеры и тригеры типа раз в 1 сек перезарядка, а если враг ближе чем 50 пкс - то стрелять)
3.1. ну и дальше башня живет своей жизнью.
3.2. Контроллеру уровня на башню пофигу пока она(либо ее модель, если обнаружит что хп==0; либо вьюха, если юзер тыкнет в кнопку "под снос") не задиспатчит что-то типа "Меня поламали".
3.3. Но на всякий случай контроллер уровня башню слушает, потому что может быть получено какое-то событие типа "на меня навели мышкой" при этом контроллер уровня должен отобразить над башенкой окошко с доп-инфой (или этот функционал висит на контроллере + вью башни? Если так то схема получается следующая - вьюха понимает что на нее навели мышью, никуда ничего не диспатчит и сама на себе выводит окошко инфы.)
4. когда контроллер уровня получает от башни заветное "Меня поламали" - он сносит триаду этой башни. Если надо, вносит в какой-то реестр разбитых башен - т.е. в модель уровня. Ну малоли, хайскоры от этого будут зависеть или еще чего.
Примерно так же дело обстоит и с врагами, с той лишь разницей что создание триады каждого врага делается не по клику "создать башню(врагов)" (хотя и так бывает), а по таймеру.
//**********************
Вот примерно так я себе это вижу.
А теперь вопорсы:
1. Что-то мне подсказывает что я слишком наворотил со вьюхами. В чем роль этого контейнера вьюх? А то у меня получилось что этот контейнер вьюх держит в себе только одну вьюху - главную. Тут короче где-то дублирование. Или я суть главной вьюхи не уловил, или же суть главного класса.
2. Ну и вот это всплывающее окошко - кто его показать должен? Вьюха башни или вьюха уровня? Насколько я понимаю то вьюха башни это какой-то спрайт или Мувик с анимацией самой башни. Стоит себе, привязана к координатам. Ну а чтоб это окошко выглядело так как охота чтоб оно выглядело - то надо его показывать в дисплейОбъекте уровня (ну чтоб за мышкой двигалось и в таком духе).
2.1. Хотя как вариант можно сделать отдельную триаду для хинтов. Триада эта будет на том же уровне что и триады башен с врагами. Т.е. в подчинении контроллера уровня. И тогда получится что контроллер башни получает от вьюхи башни "На_Меня_навели_мышкой", чешет затылок, ибо не знает что с этим делать, и диспатчит дальше. Контроллер уровня получает это событие, дергает контроллер хинтов "слышь чувак, а покажи как мне хинт для вот этой башенки" и все довольны.
//**********************
Короче моск пухнет уже, жду ответов
Спасибо)
Добавлено через 30 минут
Перечитал еще раз.
У меня тут видимо слегка путаница с общением между родительским контроллером и детьми.
Когда я писал то подразумевал что родительский контроллер общается сугубо с контроллером ребенка посредством подписки на его события. И влияет на детей сугубо через контроллер. Ни к вьюхам ни к моделям детей напрямую не вмешивается.