Это и была одна из игр, на которую мы ровнялись, когда делали (говорю мы, потому что графику делал не я). Второй игрой-рефом была сеговская Cannon Fodder.
Игра отключена уже несколько лет.

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

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

Пример конечно странный, но тем не менее он отражает потерю контроля владельца
Дерево DisplayObject это лишь частный случай родитель-потомок, это может быть и список Enemy в родителе с методами addEnemy, removeEnemy

Да. Этим все сказано.
Я бы лучше сделал статический аниматор, который принимает объекты применяющие интерфейс IUpdatable из которого объект тоже сам удаляется.
Ну тут то получается, что архитектура приложения заточена на то, чтобы именно родитель удалял детей. В этом случае, конечно не нужно делать "самоудаление"

я один не понимаю что страшного произойдет?Когда Enemy самоуничтожится,numChildren автоматически станет на 1 меньше и цикл либо продолжится дальше,либо остановится.

Добавлено через 24 минуты
Гараздо неприятнее что такое самоудаление сдвигает весь dl

Покойник сам на кладбище не ходит, его хоронят, так заведено.
Развели тут =)

при этом один ребенок проскочит без апдейта, так как встанет на текущий i вместо удалившегося, а цикл перейдет к следующему. Распространенная ошибка при чистке массивов.

Друзья!

Дошёл я до ввода-вывода, по заветам мэтров начал с программирования кнопочек и менюшек. Возник идиотский вопрос, даже группа вопросов.

Во-первых, файлы с растровыми изображениями можно загружать с помощью Loader-ов и с помощью тега метаданных [embed]. Разбирался, в чём их отличие. Пока единственное, что твёрдо усвоил и осознал, это тот факт, что Loader загружает изображение на этапе выполнения, а [embed] - на этапе компиляции. Делаю вывод, что если я планирую игру на flash, работающую в т.ч. оффлайн, то мой выбор, по всей видимости, - это "встраивание" графики на этапе компиляции, т.е. вариант [embed]. Верно?

Во-вторых, с этим самым [embed] какой-то стрёмный синтаксис. Вот из нашего отца родного Колина Мука:

Что это за тип данных Class? Почему приватная переменная Photo записана с большой буквы в нарушение всех конвенций? Каким образом происходит связь загруженного через мета тег графического файла и переменной внутри программы?

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

Синтаксис стремный, потому что это не язык AS3, а команда компилятору.
Photo c заглавной буквы, потому что все классы именуют с заглавной.
Компилятор создает автоматически класс-наследник Bitmap с "предустановленной" битмапдатой — Photo. Поэтому в дальнейшем ты можешь создавать сколько угодно экземпляров этого класса и обращаться с ними как с обычным Bitmap.
Все классы являются объектами типа Class. Их можно передавать между функциями, хранить в переменных и получать на них ссылки, зная только название класса (строку). Для удобства этих операций существует тип Class.
Думаю, понятно почему нельзя написать Потому что на этапе компиляции такого типа "A" не существует, это всего-лишь имя переменной.

а при загрузке в рантайме — не будет простыни и переменных?
Многие по возможности собирают много маленьких в одну большую — спрайтшит или атлас — и в рантайме "нарезают" ее на маленькие. Это особенно удобно, когда картинки являются кадрами какой-то секвенции или например иконками графического интерфейса; удобно, когда не нужен КЛАСС для каждой картинки, и даже отдельная переменная — когда можно хранить их в массиве.