Вопрос про структуру игровых классов.
 

Я зеленый в ООП, можно уточнить...
Как сделать оптимальную структуру игры, не используя кадры.
Например, у нас есть главный класс Game.as, который привязывается к Game.fla. В этом классе создаем экземпляр следующего класса Menu.as, который экспортирует нужные кнопки и размещает их на сцене.
Например, после события Клика по кнопке GoGame_btn вызывается некая функция создающая экземпляр GameWorld.as
Что делать дальше? Удалить все кнопки? Или скрыть со сцены .visible?
Если GameWorld.as отвечает за концепцию игры, то после выигрыша или проигрыша, снова удалять все компоненты прошедшей игры? :o

Нет универсальной структуры классов, как и нет универсального способа создать игру.
Есть разные шаблоны проектирования (design patterns), вот о них и нужно читать, чтобы понять как лучше организовывать проекты. Люди придумавшие эти шаблоны тоже когда-то наступали на все те же грабли, и придумывали способы их грамотно обходить.

п.с. Есть даже книга ActionScript 3.0 Design Patterns. У нее даже перевод на русский есть. Советую почитать.
Не могу сказать, что книга просто супер, но некоторое представление о том как все должно работать даст однозначно.

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

В дополнение к сказанному, — учиться, пробовать и писать код :)

Вы его меньше слушайте, он и не такое ляпнуть может. :D

Спасибо за советы, буду вникать в эту тему :)

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

смотря что является оптимальной структурой,
идеальный вариант, это найти исходный код чужой игры и тырить оттуда фишки для своей,
но не концепцию игры, а принцип построения кода

maloun365, спасибо.

Лучше писать код, использовав паттерн МVC или МСV :)))
Где слой модели - M отделен от вида V контроллером С, который с ними и взаимодействует и они взаимодействуют друг с другом через него. Поэтому лучше писать логику в контроллере. Если вам надо сообщить что-то от Модели Виду используйте диспатч, но не используйте диспатч если находитесь в Контроллере и хотите узнать что-то от вида V или модели М, просто используйте их напрямую. По максимуму применяйте наследование от какого-то базового класса BaseClass для модели, контроллера и вида, чтобы избежать дублирования переменных. Если вы планируете использовать классы, создаваемые не вами (которые по факту чаще слабосвязанны с ядром), используйте механизм интерфейсов, в которых описывайте методы, с помощью которых эти сторонние классы будут общаться с ядром, а ядро с ними. Но искусственно не плодите интерфейсы, а тем более не начинайте проектирование системы с описания интерфейсов. Потому, что их чаще приходиться модифицировать. А раз так значит это затронет все классы которые имплементируют данный интерфейс. Выносите все данные в XML, тогда методы доступа к данным будут по сути методами доступа к нодам. Смело используйте XPath и XMLList. XPath, к сожалению, не нативен, но позволяет параметрически программно задавать запросы используя строковые переменные. Используйте класс Dictionary для организации ассоциативных структур, но можно обойтись и XML))) Для начала хватит.

Babylon, ну завалили теорией!
пееходя от теории к практике, берём проект с MVC и разбираем как он работает
http://www.codeproject.com/Articles/...troller-Design

памоему этот на Java написан, но не имеет значения на каком языке написан проект,
другой язык даст более глубокие знания о программировании в целом, хотя удобнее найти проект на том же языке