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

Я зеленый в ООП, можно уточнить...
Как сделать оптимальную структуру игры, не используя кадры.
Например, у нас есть главный класс 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 написан, но не имеет значения на каком языке написан проект,
другой язык даст более глубокие знания о программировании в целом, хотя удобнее найти проект на том же языке

Подозреваю, что для аркад МVC не годится.
Для них лучше использовать набор объектов, у которых каждый кадр вызывается метод Update(). Причём не грех срастить логику, данные и отображение одного объекта.

Очень спорный момент. Хотя не понятно что конкретно Вы предлагаете делать, так что может и не спорный.

Нет, не на Java. Это C#. Иногда другой язык слишком отличается от того, что интересует. Поэтому я бы не сказал, что язык не имеет значения.
Откуда уверенность что код чужой игры написан хорошо?
Вариант по-лучше - читать грамотные книжки, хороших авторов. Мне от o'reilly больше всего нравятся, хотя даже среди них шлак попадается. Friends of Ed тоже неплохие

для игр mvc не очень (он хорош для интерфейсов)... последнее время пишу игру на MVP (model view presenter)

Конечно можно заваливать г/к. Разгребать его все равно не вам. Не зависимо от глубины.

Добавлено через 5 минут
Дело не в инструменте, а в умении им пользоваться :)

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

может иногда неплохо заглянуть в книжку и посмотреть что и как работает,
но в отличии от исходного кода который написан и работает,
в книге в основном куча теории и код предназначен на все случаи жизни,
а не под ваш проект, тем более большинство книг ужасно оцифрованы
или ещё хуже лежат на книжной полке, где-то очень далеко от дома,
искать по такой книге инфу не проще чем вбить в гугл интересующую проблему + example

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

Вроде есть прописные истины:
- Если код не использует MVC - это не значит, ни что он плохой, ни что его трудно править, ни что его трудно писать
- Если код использует MVC - это не значит что он хорош. Самый отборный "г/к" я разгребал как раз в проекте написанном на PureMVC (хотя там многие концеции MVC как раз шли лесом из-за особенностей фреймворка, и многое можно объяснить тем, что код правило до 5 человек, слабо контактирующих между собой)
- Мир на MVC клином не сошёлся, MVC в принципе не может быть хорош на все случаи жизни.

Я с помощью XML всё делаю. Агрегатирование, обмен данными c сервером, layout, описание структуры и доступа к объектам как в модели, так и в представлении и даже бэктрекинг планирую:). Удобно.

Дык не типизированное же оно.
Обмен с сервером - да(хотя, вроде AMF поудобнее и покомпактнее, но тут смотря какие требования к обмену с сервером), Статичные справочники, загружаемые клиентом - да. Но саму модель делать динамически типизированной и таскать по всей игре xml-объекты вместо типизированных экземпляров классов - это уже ооочень спорный момент (впринципе рабочий - мы динамические объекты такскали и делали доступ типа int(item[Item.Price]), но спорный)

UI на XML тоже спорная вещь.
Не первый раз слышу. Но каковы преимущества? Я нашёл только одно:
- не надо компилировать игру, чтобы пододвинуть кнопку на 1 пиксель.

Какие ещё?

PureMVC хороший фреймворк, также как и RL. Кто то правильно написал, что RL это оттюннингованный Pure

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

Вы всё правильно говорите getDefinitionByName вам в руки. А, что вы таскаете по всей игре я не представляю? Класс имеет имя по любому.

Не буду подымать холивар. Но факты таковы, что половину as3-кодеров выворачивает от PureMVC, половина его как-то нездорово любит. Я честно пытался понять зачем там что и как - для меня PureMVC - набор антипаттернов и усложнений на ровном месте, хотя я делал архитектурные вещи на порядок сложнее. Просто, ИМХО, проблема не в сложности PureMVC - он весьма прост, проблема в неверности набора концепций. И почему его любят - загадка.

Но не будем о грустном, откройте если не сложно секрет, какие еще преимущества есть у GUI на xml?

Добавлено через 3 минуты
Речь про данные. Я так понял Вы предлагаете использовать в качестве модели в игре голый xml объект, нет?

С чем надо сравнивать?

Про UI?
С накидываинем компонентов UI тупо кодом (хардкод)
Есть еще способ с рисованием в FlashIDE, но очень мало его использовал, не будем о нём.

Преимущества. По памяти :) Для чего используется XML? Я уже отмечал агрегатирование, доступ к объектам их коллекциям, описание спецификаций для сторонних разработчиков. По-моему достаточно.
Пример. Опишите мне GUI Weapon, а ведь их weapon, как правило, не один и не два. Какие-то свойства постоянны, логично запихнуть в @, какие то переменны - это в ноды. Ну это азы вообще-то. Для тех кто понимает конечно не спрашивают подобные вещи.

Как раз теорию и нужно знать. В этом я уже давно убедился. Сначала теория, потом практика. Так гораздо лучше понимаешь все происходящее. А то у нас инструкция как правило читается уже после того, как что-то сломалось ))

Скорее, тек кто работает в вашей конторе не спрашивают подобные вещи. А я вот не понимаю в каком контексте вы говорите.

Хорошо, вот есть форма логирования, так она выглядит в коде(утрированно):
Вот в чём удобство использования здесь XML?
Как там просто подписать обработчик?
Как искать описки?
Как просто убирать и перемещать элементы (например нажали на кнопку - текст исчез - появилась другая кнопка)?
Вобщем, я об этом.

Стоп. Вот про Weapon. Т.е. Вы хотите сказать, что генерите на лету xml под данным, передаёте некой системе и она отображает по нему GUI? O_o

XML это формат для обмена и представления данных. Где в этом классе модель? Это виджет - LoginWindow. Как вы передаете данные модели и как вы делаете layout этого виджета сугубо ваше личное дело. Вы же не передаете виджет на сервер или от него. Вы передаете серилизованный xml,байтэррей или json
<widgets>
<LogWindow>
....
</LogWindow>
</widgets>
В конторе моей никто не работает, как и я,впрочем, в ней. А, что у вас есть вакансии :)?

Добавлено через 7 минут

<events>
<event type="маус клик" func="хэндлер" />
<event type="маус овер" func="хэндлер овер" />
</events >

Добавлено через 10 минут
XML это и есть данные и они динамические, что еще надо-то:)

xml Ваш, насколько понял, отдалённо походит на mxml флексовый. Но код функции обработчики надо передавать из вне.

Я привык думать, что есть данные, а как отобразить их - другой вопрос.
А тут получается что вот данные, но по этим же данным _однозначно_ собирается GUI.

Про то же оружие: дальность, дамаг и т.д. - это одни данные, а <Label text="Дамаг:" name="damage"/>.... - это уже другие ведь?
Т.е. как это работает, так?
Или так?
И где-то сбоку тут ещё должно быть прилеплено изменение UI в процессе работы

ну немного теории не помешает, но для этого есть гугл, википедия и форумы

Вы все правильно поняли. Только между UI xml и gui лежит контроллер. Между ними ещё можно положить медиаторы, но это если у вас много виджетов и сервисов. mxml и xaml это зло, придуманное индусами. Я думаю не случайно adobe покидают известные евангелисты.

Мощно вы тему раскрутили :)

К сожалению, ничего нового. Всё давно пережёвано в других топиках тем же димариком :)