DOC - display object container. Он может быть как корневым, так и не корневым.
В любом случае добавлять/отцеплять display object'ы от дисплей-листа должен родительский для этих объектов контейнер.

Ты бы на пару дней отбросил амбиции сходу написать игру, которая покорит весь мир, и попробовал силы в написании банальной кнопки, а затем менюшки с тремя-четырьмя этими кнопками.
У меня ученики начинают с CheckBox и RadioButton, затем RadioBar — о каком бы Варкрафте ни мечтали)). И на таких простейших компонентах прекрасно осознают львиную долю концепций ООП.
Скучно, стыдно, но начинать надо с малого — оно в мозгу целиком помещается.

Это ошибочное суждение. Не знаю почему многим так вбилось это в голову. Объекты могут и сами себя удалять из дисплей листа. Ничего плохого в этом нет, если на них нет каких-то дополнительных внешних ссылок. Часто вот такие "правильные" подходы приводят к дико нечитаемому и трудноподдерживаемому коду.
Взять какого-нибудь персонажа в игре. Врага. Игрок убивает этого врага, и вот тут возникает вопрос, а как его удалить? Если пользоваться подходом, что только родитель должен удалять дочерние объекты, то этот враг должен (согласно парадигме флеша) послать событие о том, что он дожен удалиться. Это событие должен слушать родитель. По событию родитель находит целевой объект, отписывается от его событий и удаляет объект.
Хотя все можно было сделать гораздо проще. Не оставлять никаких внешних ссылок на врага, а просто создать в нем метод destroy / dispose, в котором он может сам удалиться из дисплей листа. Никаких ненужных событий и лишних зависимостей.

Ну не знаю. Мне кажется дикой идея, когда мой мусорный пакет сам выбрасывает себя в мусорный бак.

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

Я с ходу догадался, что ты преподаёшь :) Чувствуется стиль языка и манера изложения: последовательно, доходчиво и метафорично. У тебя книжек или туториалов нет?

Wolsh,
Мне бы такого учителя в своё время.. Знания моего преподавателя ограничивались кодом на кнопке для перехода в нужный кадр.

Предприниматель, сумевший реализовать эту идею станет миллионером!

Всё-таки я тоже малась поддержу caseyryan, ну не всегда на практике получается строго придерживаться концепции Родитель -> Ребёнок. Это как с оператором goto в c++, его нужно стараться избегать всегда. Но где-то, единичное и умелое его применение может облегчить, упростить или ускорить выполнение кода.

Правило не строгое.Главное чтоб исключение не стало доминирующим паттерном в проекте.Сам часто для хинтов создаю MC с анимацией появления/исчезновения и в последнем кадре:
и в любом месте:

А лучше через статический метод из пула их брать ;) (знаю, что я сейчас сКЭПил))
Я даже в этом ничего страшного не вижу. Если это удобнее, чем использовать классический подход, то почему бы и нет.
А мне она кажется великолепной :D
Всё верно. Идея нужна, иначе не будет стимула. Я когда начинал изучение, я тоже сразу начал с большой онлайновой игры. И я, таки, сделал её и даже запустил в ВК. Там только с монетизацией получилась беда, в силу недостаточного опыта. Но игра, сама по себе, получилась довольно неплохо. Вот с неё некоторые скрины. А главное, я на ней очень многому научился, как по клиентской части, так и по серверной. Я по ней не только AS3 но и Java изучал. Так что поддержу, наличие такой цели - это очень хорошо. Главное, чтобы руки не опустились после множества неудач, которые обязательно будут на этом нелегком пути ;)

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

Симпатично. На Desert/Jungle Strike чем-то похоже. :) А ссылку в студию?