Имелся в виду простейший пример который не ограничивается какой-то парой тройкой триад, а уже что-то более похожее на полноценное приложение.

Ну для меня модель - это сугубо база данных.
Контроллер - AI, калькулятор. Вью - морда, а модель - БД. Для того чтобы узнать в каком месте рисоваться - вьюха спрашивает координаты у модели. Для того чтобы получить операнды для расчетов логики - контроллер спрашивает данные у модели.
Исходя из этого модель не имеет публичных методов (в том числе и протектед) а имеет только пачку геттеров-сеттеров. Контроллер видит и то и то, а вью только геттеры. Плюс в каждом сеттере висит dispathEvent("changed param #xxx") - который слышат все желающие, и все кто от этого зависят - подстраиваются. Например контролер поменял координаты башни, модель отмаячилась, а вьюха услышала об этом и перерисовалась.

Принципиальной разницы не вижу. Ссылка на модель все-равно имеется. Если я помещу модель в модель уровня, то будет дублирование в некоторых моментах привносящее удобство, возможно.

Я просто упустил эту ссылку дабы не усложнять схему. Но да, ссылка есть, как минимум вью должна слушать события модели, а так же иметь доступ к геттерам модели.

А вот это уже интересно, хотя как по мне - вносит некую путаницу в четкую систему, в которой контроллер решает всё. Хотя в пользу производительности наверное стоит на это идти в некоторых случаях.

Просто копипаста из первого варианта схемы. На параметры не обращайте внимания. Всё что там нужно было увидеть, это квадратики и наследование между класса "Mxx", "Vxx", "Cxx".

Видимо да. А когда она будет нужна, в таком случае? Можно пример?

Хм. наверное таки да. Я упустил триаду окна.
будет наверное так в итоге:
- Триада окна
-- триада уровня
-- триада интерфейса
-- триада доп-элементов(возможно и без нее)

Это кстати да. Я так же упустил что можно клонировать нужные модели, или же вообще передавать существующие ссылки.

Спасибо за ответы.

Добавлено через 49 минут
помедитировал на "типовую схемку из википедии".

- Контролер содержит в себе модель и вью.
- вью содержит в себе модель.
- контроллер слушает вью.
- вью слушает модель.

т.е. касательно башни это будет выглядеть примерно так:
- V: "контроллер, Враг на горизонте"
- C: "вьюха, взять на прицел, заряжааай!!!"
- V: "Заряжаю"
- V: "Контроллер, Заряжено!"
- C: "Вьха, Огонь! Модель, у нас минус снаряд."

Вторая ситуация:
- V: "Ахренеть, нас враги атакуют"
- C: "Модель, делай минус 10 хп
- M: "Сделано, осталось 90%
- V: "Поняла, рисую анимацию потерпания от ударов".
......
- V: "Контроллер, они до сих пор атакауют"
- C: "Модель, делай минус 10 хп
- M: "Сделано, осталось 60%
- V: "Поняла, рисую анимацию пожара".
......
- V: "Контроллер, а они еще атакауют"
- C: "Модель, делай минус 10 хп
- M: "А хрен вам, овердамадж получили. Нету у нас больше хп"
- V: "Поняла, взрываемся. Контроллер, слышь, чувак, взорвались мы".
- C: "Товарищ Майор, мы взорвались"
- ParentC: "МодельУровня, делай минус башню. ВьюУровня - убери мусор"

//****************
Пральна я понимаю? Просто охота уже разобраться чтоб сразу и навсегда. Потому могу флудить глупыми вопросами.

А почему у вас вьюха определяет что ее бъют?

Добавлено через 10 минут
Применительно к вашему примеру игры жанра TD, я бы построил архитектуру так:
Есть модель (не один класс, а пакет), в которой все происходит, что должно происходить на экране,
только виртуально. То есть обновляются координаты врагов и наносится урон башням.
А вьюха (тоже не один класс =)) просто обновляет визуальное представление соответственно текущему состоянию модели.

Контроллеры вижу тут примерно такие:
- Юзер, что-то кликнул (строим башню, выходим в меню, пауза и тд)
- Обновление всей модели на единицу времени

И еще,
Не совсем верно говорить "содержит", тк это подразумевает агрегацию,
а у тут более общий случай - композиция.

Видимо я зря писал статьи про эмвэцэ. :(

Psycho Tiger, нет не зря. Стиль подхвачен верно =)

Стиль не подхвачен, стиль в оригинале, так что попрошу;)

Ок тогда вопрос. Кто это определяет?

Хотя вьюха жеж не понимает что ее бьют, она просто видит что враг близко, она ж тупая. Сиськи большие, а размер моска обратно пропорционален размеру сисек.

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

//**********************
Путаница опять:) Получается в таком случае лучше не плодить кучу контролеров на каждую башню и каждого врага, а попытаться обойтись одним контролером уровня. А там он уже будет глядеть: "враг1 на расстоянии выстрела башни1. Отдать башне1 команду стрелять". А башни и враги будут просто суб-вьюхами одной большой вьюхи уровня. Модели же башен и врагов будут просто суб-моделями модели уровня(ну типа в модели уровня где-то массив башен, и массив врагов.)

Контроллер вертит моделями и определяет, были ли столкновения или нет. Заносит в модели инфу, если было столкновение.

Походу вкурил.

У меня были шоры на тему того что триада должна быть триадой.
Ну а теперь Вывод таков: надо не бояться делать к примеру один контроллер на пачку вьюх и пачку моделей.
И в то же время одна вьюха может быть целой триадой.

Как-то так. Вроде теперь всё ясно. Спасибо. (ну если я со своими выводами ошибся, то готов продолжить дискуссию)

Ага, верно. Ровно как и вьюха может сосать 3-4 модели, так и один контроллер может отдавать приказы 3-4 вьюхам, так и контроллер может слушать 3-4 вьюхи, так и контроллер может менять 3-4 вьюхи.
Триадой я бы её не назвал. Просто "компонент" для триады.

Хз. Попытался возразить да передумал. Тут чтоб дальше продолжать предметный разговор нужно уже конкретно архитектуру приложения рисовать. А это не один час работы.

Например тот же пример тавердефа.
Башня может быть просто вьюхой. а контроллер уровня уже будет всем рулить.
А можно этой вьюхе прикрутить контроллер минимальный какой-то. К примеру в его задачи будет входить оценивать расстояние до врагов, формировать массив врагов до которых может дострелить. Если какой-то враг попадает в область на расстоянии выстрела - внести в список. Если выходит из этого круга - удалить из списка. Ну и диспатчить выше моменты изменения списка.

Оценка расстояния это ведь логика, потому этому действию место в контроллере. Башне ведь проще прошерстить 9 клеток (3х3) и сделать свой маленький массив из, к примеру, 3-х мобов в области своей видимости, нежели контролеру уровня каждый кадр шерстить всё поле и делать перерасстановку сил из 10-и башен и 40-а врагов.
//********************

Короче суть ясна. А дальше уже под каждое конкретное приложение своя архитектура нужна.
//********************
А если так глобально, то мне импонирует данная система:)) Куда удобнее работать с 10-ю классами по 50 строк каждый чем с одним классом на 500 строк ;)

Привет всем, тему не осилил(прочитал все, но в башке - каша), поэтому спрашиваю, контроллер(предположим игры) создает контроллер игрока, уровня и врага. Контроллер игрока в свою очередь создает модель игрока и вьюшку игрока, с уровнем и врагом - также, дальше что? модели ни про свои ни про чужие вьюшки не знают, расчет движения игрока/врага происходит в контроллере игры? Как устроить проверку столкновений? Или я путаю теплое с мягким?
ЗЫ. Код приводить не надо, тезисно.

Да, в контроллере.

Контроллер игрока модель игрока не создает.

Размер топика уже превосходит здравые границы. В топике повторяются вопросы и ответы. Потому, что каждому вновь спрашивающему не осилить уже всё написанное ранее, проще еще раз спросить.

Как будет выглядеть MVC для проекта на Papervision3D?

Я не большой мастак, но подозреваю, что MVC в Papervision3D и ему подобных самое последнее, о чем стоит заботиться. Там приоритет №1 — скорость, а не элегантность.

ясно, тогда другой вопрос - насколько сильно упадет скорость приложения, при использовании MVC?
Возьмем например гамес уровня TD и ТаймЗэро.

Ну это разговор ни о чем. Игры уровня TD никак не пострадают от использования MVC. Как вообще в данном случае можно сравнивать 3d движок и казуальную игру?

Без MVC TimeZero валила бы Core i7 на раз-два.

Я бы сказал по другому: без mvc, чтобы TimeZero не валила бы Core i7 на раз-два, пришлось бы приложить гораздо больше усилий, и не факт что получилось бы так же хорошо.

MVC для скорости? Всегда видел в нём небольшой упадок в ней в угоду сильно возрастающему удобству разработки.
Расскажи пожалуйста за счет чего, по твоему мнению, из за MVC появляется megaboost в скорости?

Как по мне - внятная архитектура и есть залогом производительности. А как ты сам несколько раз повторял в своих постах - МВЦ у всех разный;)

Поменять текущее имя игрока:
1) Кривоархитектура с логикой и отображение в одном классе:
1.1) Поменять поле класса
2.2) Обновить новое значение визуально

2) MVC:
2.1) Диспатч события об изменении
2.2) Поймали событие, меняем модель
2.3) Поменяли модель, рассылаем событие
2.4) Ловим событие, обновляем отображение

На фоне общей картины это микроны, но отчего MVC даёт производительность я не понимаю. Только удобство, имхо.

скорее не так:)) Твой пример на подгонку фактов похож уж слишком)

Поменять текущее имя игрока:

1) MVC:
1.1) Диспатч события об изменении
1.2) Поймали событие, меняем модель
1.3) Поменяли модель, рассылаем событие
1.4) Ловим событие, обновляем отображение

2) Кривоархитектура с логикой и отображение в одном классе:
2.1) Диспатч события об изменении (ввели в поле, нажали ок)
2.2) Поймали событие
2.3) Выполнили с десяток непонятных действий, объяняемых тем что архитектура писалась кучей программистов
2.4) И еще десяток действий
2.4.хх) Не забываем что в процессе написания поправили я пяток-другой классов чтоб предыдущие пункты выполнялись.
2.5) теперь у нас есть переменная с именем новым (и старым)
2.6) для верности продублировали в десяток переменных
2.7) послали в базу данных
2.8) оно до базы не дошло (почему-то О_о)
2.9) поправили еще с пяток классов
....................
Ну и в таком духе. Так и блуждет наше нажатие на кнопку "Ок" при смене Никнейма по всей системе, плодя за собой еще целые кучи событий и кучи переменных....

Ещё до начала пользования MVC код у меня был более-менее, так что не разделяю :)

Вот я кретин - у Мука зоопарк был построен на MVC - пойду перечитаю...

В централизации событий. Не нужно бегать по всем контролам и обновлять данные. Нет посредников в операции обновления.

Спасиб.

если в контроллере происходит расчет коллизий, а мы вдруг трах тибидох и 3d, контроллер тоже надо будет менять, так как в расчете столкновений появляется z координата, и модель наверно тоже надо будет дополнить?
если я туплю не пинайте сильно, модель может состоять из 5-7 классов?

Столкновения визуальных объектов должен рассчитывать View, и результат(столкнулся/не столкнулся) отдавать контроллеру.

Очень спорное утверждение

у меня 10 вьюшек которые ничего друг о друге не знают. у них есть модели, а у контроллера есть и модели и вьюхи

Минус. Столкновение — это логика.

И где оно тогда будет рассчитываться?

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

Если используется hitTest (уже про 2D), то можно и во вьюхе. Но, имхо, лучше тоже в контроллере.

vHuman расширяет DisplayObject3D - это papervision3d.

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

По таймерам и enterFrame-ам?

А с чего вьюха то начала управлять логикой?
Получается, что вьюха сама двигает объекты, не читая данные из модели (т.к. писать в модель она не может по определению).

Вьюха только сообщает, что произошёл хиттест вот этого и вот этого. Что с этим делать — решает контроллер.
Но оперировать с display-объектами контроллер не должен.

Спорно. Может действительно удобней. Удаляюсь думать.

@etc, bgg, спасибо.

ок, возьмем 2d, передвигается мувик, допустим автомобиль, на пути следования автомобиля стоит столб(другой мувик). Контроллер получает событие от клавы, что машинка должна двигаться вперед, и меняет модельАвто.х и модельАвто.у, вьюхаАвто, услышав изменение модели - передвигается в новые координаты. как вьюхаАвто узнает, что влупилась в столб?