ООП и архитектура простой игры

[undefined]

наиболее универсальным был бы внешний XML,хотя я предпочитаю JSON

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

слушатели взаимодействия с объектами

это не то, что можно хранить

[lesnoj]

Сообщение от undefined

наиболее универсальным был бы внешний XML,хотя я предпочитаю JSON

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

это не то, что можно хранить

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

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

Main.as - точка входа
DisplayManager.as - управление экранами
Objects.as - все динамические объекты

Хочу уточнить, что вся анимация покадровая, по этому взаимодействие с объектами - это событие клика -> условие проверки на доступность -> запуск анимации/добавление или удаление объектов

У меня почти полностью готовы исходники (локации, анимации и пр.), но реализовать я могу лишь одну локацию в одном классе. А правильно разделить на классы и связать в одну работающую программу не могу. Обидно.

[undefined]

Как я и думал напишите все за меня.Нет уж.Для начала рекомендую описать по-минимуму в json свои игровые экраны: какие объекты на них находятся, координаты.Дальше грузишь этот json,и генерируешь по нему свои игровые экраны.Там же и вешаешь свои слушатели на событие клик.

по этому как я уже писал ранее, количество классов ограничено до

Глупое ограничение. Классов должно быть ровно столько, сколько нужно.Например, я не знаю что ты хочешь разместить в Objects.as, видимо,какое-то описание логики игровых объектов.Зачем все объекты в одну кучу валить?Это будет т.н. спагетти-код.Тут по хорошему надо определиться какой функционал будет общим для всех объектов и вынести его в базовый класс GameObjectBase.as и потом все игровые объекты наследовать от GameObjectBase.Тогда objects надо сделать пакетоми в него положить GameObjectBase.as и всех его наследников.
Итак дальнейшие шаги:
1)Описать игровые экраны в json файле
2)Определиться с тем, что общего у всех игровых объектов.По-минимуму у каждого игрового объекта должно быть визуальное представление.Соответственно все игровые оъекты должны уметь выставлять себе внешний вид:

package objects 
{
	import flash.display.DisplayObjectContainer;
	import flash.display.Sprite;
	import flash.utils.getDefinitionByName;
	/**
	 * ...
	 * @author 
	 */
	public class GameObjectBase extends Sprite 
	{
		protected var view:DisplayObjectContainer;
		public function GameObjectBase() 
		{
			super();
 
		}
		public function setView(linkage_id:String):void {
			var cl:*= getDefinitionByName(linkage_id);
			if (cl is Class) {
				view = new cl() as DisplayObjectContainer;
				addChild(view);
			}
		}
 
	}
 
}

Если выяснится еще какой-то общий функционал для всех игровых объектов, будешь добавлять его в этот класс.
Для начала хватит.
PS:Все идет к тому, что весь код за тебя буду писать я.Так не пойдет

[lesnoj]

За меня ни в коем случае! (разве что самую малость)
За подробные подсказки спасибо, именно это меня интересует в первую очередь.

[dimarik]

Там еще MVC есть.
А вообще тут столько материала, что можно пять игр написать не парясь. Нужно только с 2004 года все топики осилить.

[Wolsh]

undefined, чем обусловлено использование типа DisplayObjectContainer?
Вы собираетесь в него что-то добавлять? Или всё-таки Вы его добавляете в отображение? Так для этого достаточно более общего класса DisplayObject. Сужая тип до DOC, Вы отсекаете возможность использовать в качестве view битмапы, векторные шейпы и текстовые поля.

lesnoj, ООП это несколько больше, чем "когда код написан не в кадрах, а в отдельных классах". ООП вообще не относится к коду, это концепция Проектирования, в основе которой лежит понятие Объекта. У каждого Объекта есть Ответственность (в идеале — одна). То есть каждый объект отвечает за какую-то конкретную часть функционала Приложения. Разделение функционала Приложения и выделение соответствующих объектов (классов) называется Абстрагирование. Почему так? Потому что каждый Объект должен быть максимально самодостаточен, независим. Он "абстрагируется" от других объектов и общей возни, как бы заявляя "у меня есть одна конкретная задача, вот её я и буду делать, и не лезьте ко мне ни с чем другим". Например, кнопка обязана уметь "нажиматься", и всё. Это ее Ответственность. А то, что после нажатия на кнопку происходит переход на другой сайт или смена экранов в Приложении, или со счета снимаются деньги — это ответственность НЕ кнопки. Кнопка только отображает, что ее нажали, и извещает другой, заинтересованный, Объект об этом нажатии Событием. Кнопка ничего не решает, не принимает на себя ответственность за то, что сделает Приложение в ответ на это нажатие. Такой подход позволяет, в частности, иметь ОДИН класс "Кнопка" и создавать нужное количество экземпляров кнопок одного класса, назначая разные действия — поскольку действия не "зашиты" в сами кнопки.
//ООП это еще много всего.

[undefined]

Сообщение от Wolsh

undefined, чем обусловлено использование типа DisplayObjectContainer?
Вы собираетесь в него что-то добавлять? Или всё-таки Вы его добавляете в отображение? Так для этого достаточно более общего класса DisplayObject. Сужая тип до DOC, Вы отсекаете возможность использовать в качестве view битмапы, векторные шейпы и текстовые поля.

Согласен, писал на коленке, особо не запариваясь.Lesnoj,поправь у себя тип у view на DisplayObject, и приведение в setView.

[dimarik]

var cl:*= getDefinitionByName(linkage_id);

Такая штука очень небезопасна.Скорее всего такой процесс разработки для новичка не катит.

[undefined]

Сообщение от dimarik

var cl:*= getDefinitionByName(linkage_id);

Такая штука очень небезопасна.Скорее всего такой процесс разработки для новичка не катит.

А что не так, тип *?

[lesnoj]

Сообщение от undefined

Согласен, писал на коленке, особо не запариваясь.Lesnoj,поправь у себя тип у view на DisplayObject, и приведение в setView.

Объясните пожалуйста по вашему коду:

• Мы обратились к DisplayManager из Main

  DisplayManager.init(this.root as DisplayObjectContainer);

  , но откуда у нас к нему доступ?
• Что происходит в DisplayManager проверке

  if (curScreen !=-1 && screens && screens[curScreen].parent) {

  ?
• Почему нет ф-ции конструктора в DisplayManager?
• Какой класс расширяет DisplayManager?
• Для чего метод

  public static function get rootDO():DisplayObjectContainer {

  ?