Имхо, флекс и прочие системы с использованием лейаутов и кучей компонентов слишком избыточен для игры; да и универсальности здесь особой не требуется, как в какой-нибудь библиотеке GUI-компонентов для разработки разных приложений. У игр обычно.. весьма специфический дизайн, далекий от графических примитивов, часто на 100% отрисованый в битмапах.

А где им еще храниться, есть варианты? В самих себе?)
"Как она узнает".. ей не надо узнавать, это ты пишешь её и её компоненты. Не доводи до абсурда. Если же вдруг понадобится неизвестная заранее ЗАМЕНА одного компонента другим с неизвестной высотой/шириной, или просто не хочется хардкодить (забивать точные значения вместо "реальных" свойств), то всегда можно спросить именно свойство после ресайза. Если компонент не может изменять высоту, он ее и не изменит при ресайзе. То есть, в моем примере ты задавал бы координату Y центральному модулю как _topPane.height, а не тупо "24". И если в какой-то момент тебе пришлось бы вставить туда другую панель, высотой 30, центральному модулю пришлось бы слегка сжаться.
Сначала в конструктор, текущие на момент создания, а потом в метод ресайз(w, h). Понятно, что код в конструкторе не дублирует код в ресайз(), а просто вызывает его с этими начальными параметрами.

ZergMaster, Вы меня пугаете. То есть, НЕ абсурд для Вас — когда никто понятия не имеет, какого размера штуки вываливаются на экран, и в каких местах?

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

а никто не подскажет чего-нибудь легковесного для оформления ui с помощью лейаутов(можно на js раз уж флэш похоронили)?Флекс и в самом деле сильно монструозен.

Wolsh ну, тут, конечно, все зависит от задачи. Мне, как правило, хватает пропорций. Главной вьюхе не надо знать, где находятся дочерние, достаточно передать им свой размер. А они, исходя из этого размера, располагаются на сцене. Например произошел ресайз и по событию обновились глобальные width и height. Какая-нибудь дочерняя вьюшка, например аватарка пользователя, по событию приняла глобальные width и height и делает свой ресайз, в котором может быть наворочено куча всего. Например, она располагается на 10 пикселей от правого края и 10 пикселей сверху, принимает ширину 1/10 от сцены (но не меньше и не больше от крайних). А другая вьюха, какой-нибудь прогрессбар здоровья, висит на 10 пикселей от верхнего края и располагается в точке width/2 и так далее.
Нет, конечно, дисплей обжект контейнер все равно будет знать, где находятся его дети, я, конечно, имею ввиду то, что он их не располагает, а весь лэйаут происходит внутри компонента. Зачастую это удобно. Да, конечно, что касается кнопок меню, или каких-либо иконок в ряд или любых других списков - они просчитываются в зависимости друг от друга. Но главная сцена, как правило, все равно не располагает их. Она передает своим размеры в компонент "меню", который уже внутри себя располагает взаимозависимо кноки.
Или, вы хотите сказать, что главная сцена (вьюха) у вас содержит в себе большой-пребольшой метод resize, который занимает всеми этими расчетами и располагает всех детей в зависимости друг от друга? У меня этот метод в этом случае так разрастался, что я довольно быстро стал всю эту логику прятать в детей.

Добавлено через 5 минут
undefined для флеша - feathers на старлинге предназначена для построения интерфейсов.

Ну, у меня никогда "аватарка пользователя" или кнопка меню не окажется в главной Вью. Возможно, дело в этом. Вью имеет дело с тремя-пятью детьми, а те расставляют по местам своих детей, те — своих, и т.д. Положением и размером картинки-стейта кнопки занимается класс Кнопка, положением и размером Кнопки занимается класс Меню, положением и размером Меню занимается класс PopupLayer, а вот им управляет Вью. И даже игровое окно Вью не будет сама собирать по кусочкам, это будет какой-нибудь ГеймВью, который в свою очередь будет создавать три-четыре модуля и управлять ими (звучало хорошее слово "разметка"). А те уже тусовать внутри себя другие модули с иконками, аватарками и тп. То есть всегда, когда я пишу визуальный модуль, я закладываю в него возможность такого "умного" масштабирования без растягивания, искажения элементов. Поэтому и слово использую ресайз, а иногда и более точное rebuild. Потому что это не scale. Но инициировать этот ребилд может только хозяин компонента, потому что только он знает, что там творится вокруг. И даже если в результате какой-то внутренней жизни ребенка его вдруг раздуло (пришел новый текст например, или дизайнер заложил в него такую анимацию), ребенок должен сообщить об этом родителю, а не тупо занять под себя весь экран (что неизбежно в предлагаемой тобой парадигме "я сам!").

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

Представь. Написал ты игру по этой своей системе. Классная игра, и тебе удалось ее впарить какому-то гейм-порталу. И приходит от них ответ: Дружище, такое дело. Все эти ваши игрульки у нас на сайте загружаются в ротатор (проектор?). И поскольку игрулек много, там в проекторе слева есть такая панель со списком. А внизу — так уж повелось — у нас крутятся банеры. Вопрос: ты с чего вообще решил, что стейдж принадлежит тебе? Теперь пожалуйста возьми и перепиши свою игру так, чтобы она подстраивалась не под стейдж, а под Мейн, которому мы задаем размеры в своем проекторе-загрузчике.
Как думаешь, легко будет переписать ВСЮ игру так, чтобы каждый ее элемент подстраивался не под стейдж, на который у него автоматически есть ссылка, а под Мейн, который, строго говоря, и размеров то собственных на самом деле не имеет (в отличии от стейджа), а полностью зависит от добавленного в него контента. Представь, как ты будешь протаскивать в КАЖДУЮ фигулину ссылку на Мейн?

В чем мораль то. Стейдж не является частью вашего приложения. Он полностью независим и никак вашим кодом не управляется. Вы даже размер ему задать не можете. Даже те настройки, которые вы можете сделать из своего кода — stageAlign, scaleMode — относятся не к стейдж, а к тому как стейдж будет вертеть вашим Мейном. Стейдж всегда один для всего, что загружено в флэш-плеер, а загружено в него может быть далеко не только ваше приложение. Короче, размер вашего приложения может быть совсем не таким же, как у стейджа, и координаты вашего приложения на стейдже могут быть вовсе не (0, 0).

Wolsh про пример - понятно. Главный ресайз от стеджа то никак не зависит - он может сработать как от события .RESIZE, так и от ExternalInterface, приняв в себя ширину и высоту.
Ну, про аватарку это ж я примеру ради. Речь о том, что в моем случае, ГеймВью, создав три-четыре модуля, не расставляет и не управляет ими, они просто сами знают, какую часть экрана занимают и в какой относительной точке находятся. Ведь пропорционально приложение то все равно должно быть постоянным. Если нам при каждом ресайзе надо полностью перестраивать их расположение, составляя разные узоры или что-то в этом духе - тогда конечно, без логики в родителе не обойтись. Просто, как правило, этого не требуется.
Я думая, что мой подход очень похож на то, о чем вы говорите, просто я стараюсь все, что возможно - спрятать в ресайзы детей. Пусть сами занимаются своим расположением, чай не маленькие.