А, ну ненужный элемент можно же убрать с экрана.
Я так понимаю будет какое то меню для выбора игры. Кликнули в кнопку 1 - запустилась игра 1 (меню убрали), нажали выйти из игры - убрали игру, отобразили меню. И так далее.

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

:)
http://flasher.ru/forum/showpost.php...96&postcount=9

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

Спасибо.

В парадигме MVC это вторая буква называется View. Обычно это класс, наследующий DisplayObjectContainer (через Sprite, DOC нельзя наследовать напрямую) и отвечающий за вывод на экран изображения, а также воспроизведение звуков и всю интерактивность (мышиные и тач-события могут получать только дисплейные объекты).
То есть верх цепочки выглядит как Stage > Main > View.
Далее идут компоненты View, то есть какие-то модули, добавляемые в контейнер-View.
Например, ты сейчас смотришь форум в браузере? У браузера есть Окно, которое содержит Панель вкладок, Панель адреса, Панель поиска, Панель инструментов, и собственно окно в котором отображается контент (сайт), со скроллбаром. Все это компоненты. View их не рисует своими средствами. Кнопки сами себя рисуют, View только добавляет их в отображение или удаляет из него: как если бы View было столом, на который выкладываются предметы. Нужно показать Меню? Сделали во Вью addChild(_menu); Подписались на событие SELECT от меню. Получили событие — убрали меню из отображения, выяснили, что в нем выбрал юзер, показали то что он выбрал (или окно "сам дурак такого нет").
Как-то так, если вкратце не касаясь остальных друзей в MVC.

Что ты называешь "рисовальщиком"?За рендеринг экранных объектов отвечает flash runtime.Задача корневого do-контейнера - создавать/уничтожать и управлять всеми дочерними визуальными объектами.Компонент- любой визуальный объект внутри контейнера.
Например проект игры на два экрана(игр. меню и игровой экран).Корневой контейнер не имеет визуального представления, но может содержать внутри себя другие визуальные объекты(DO) и другие контейнеры визуальных объектов(DOC).На старте приложения мы просто создаем объект корневого контейнера и говорим ему "поехали".Корневой DOC создает экран "главное меню" и добавляет его в себя.Для простоты будем считать что в меню всего одна кнопка-"старт".Меню слушает события от своих детей.Например при клике по кнопке,она испускает событие "click".Меню ловит это событие и должно оповестить корневой DOC.Меню шлет событие "start game" которое слушает корневой DOC.Корневой DOC уничтожает экран "меню",создает экран "игра" и помещает его в себя.
Тут важно следить чтоб компоненты общались только со своими родителями т.е. корневой DOC должен реагировать только на события,отправленные его детьми(игр. меню и игровой экран).Т.е. не должно быть такого чтоб родитель родителя реагировал на события детей детей :).В данном примере это значит что корневой DOC не должен слушать событие "click" от кнопки старт.

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

Да, общую логику я понял, здесь все ответившие в теме выше едины. Мне бы получше на уровне реализации понять. Я даже не про код, а про нормальную архитектуру классов и их взаимодействие... Всё по отдельности понимаю, а как воедино собрать - нет :(

Понятно, что корневой DOC создаётся в основном классе приложения. Далее создаём специальный класс (пусть будет GameView) для эксклюзивного выполнения функции управления DO-компонентами, создаём экземпляр этого класса в главном классе, добавляем его там же в корневой DOC через addChild(). Теперь всё, что попадёт в контейнер GameView (что кстати будет этим контейнером, переменная типа Sprite?), будет выведено на экран.

А вот дальше что? Например, у нас есть отдельный класс для меню. Он по логике также должен содержать контейнер. Плюс отдельный класс для кнопки меню, которая содержит загруженное изображение кнопки, либо её рисование программными средствами со всеми параметрами (цвета, линии и т.п.), не важно. Я понял на принципиальном уровне, что при выводе меню нам нужно поместить контейнер из класса "меню" в контейнер GameView, а потом уже в контейнер "меню" добавить какое-то число кнопок, по ситуации.

Как это реализуется? Какие классы к каким обращаются для выполнения того, что я описал выше?

Получается, что механизм реализуется исключительно через систему событий с их грамотной "фильтрацией по этажам"?

this
да не "из", а само меню и есть контейнер. Не "имеет", а "является" (has/is).
Мы же стремимся думать в категориях ООП, верно? Каждый Объект является законченным самостоятельным модулем. Настолько, что он может использоваться в разных проектах, в идеале — вообще без каких-либо изменений. Вчастности, это означает, что GameView не будет добавлять какие-то ОТДЕЛЬНО существующие кнопки в меню, если ты представляешь себе это как _menu.addChild(_blueButton);
Меню, скорее всего, позволяет себя НАСТРАИВАТЬ (для конкретной игры это необязательно, но в идеале да). То есть, при создании или после, Меню предоставляет возможность задать параметры — например список кнопок (всмысле их названий, текстов на кнопках). Получив все необходимые данные, Меню строит себя САМОСТОЯТЕЛЬНО, это его ответственность. Оно создает необходимое количество кнопок, распределяет их в "себе"-контейнере и подписывается на события нажатий. Когда кнопку нажмут, Меню(!) должно послать событие что юзер сделал выбор. На события наведение и увода мыши, нажатия и отпускания Кнопки должны уметь реагировать самостоятельно — это их ответственность. И, наконец, тот кто создал экземпляр Меню, подписывается на событие от Меню "юзер сделал выбор", и получив это событие, разбирается что делать дальше. Надо четко понимать где чья ответственность. Каждый элемент ниже по иерархии является самостоятельным в выполнении своей задачи ИНСТРУМЕНТОМ для того, кто выше: Кнопка должна уметь "нажиматься", Меню должно уметь предоставить выбор, тот кто создал меню — знать что делать с выбором. Это называется иерархия. Тот, кто ниже, обычно извещает того кто выше — своего создателя — о происходящих в нем изменениях, но РЕШЕНИЯ принимает только в своей области ответственности. То есть внутри Кнопки не содержится кода, запускающего игру. И в Меню его не содержится. Меню не запускает игру, это не его ответственность.

Wolsh, спасибо. Исчерпывающе. Даже спросить больше нечего, только идти и пробовать :)

Мини-уточнение. Насколько я понимаю, все утилитарные функции, связанные с выводом (например, полная очистка экрана), делегируются классу View и реализуются через его соответствующие методы, верно?

Еще раз: за рисование отвечает flash runtime никакие очистки/перерисовки экрана не требуются.Если хочется очистить всю сцену- просто отцепляешь от нее все display objects.
золотые слова.

Я это и имею в виду. Функцию по уборке компонентов из DOC нужно реализовывать в том классе, где корневой DOС и находится.