Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Блоги Правила Справка Пользователи Календарь Поиск рулит! Сообщения за день Все разделы прочитаны
 

Вернуться   Форум Flasher.ru > Flash > ActionScript 3.0

Версия для печати  Отправить по электронной почте    « Предыдущая тема | Следующая тема »  
Опции темы Опции просмотра
 
Создать новую тему Ответ
Старый 27.06.2021, 23:05
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 1  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
По умолчанию MVC - вопрос по иерархии

Добрый вечер!

Как известно, я выбрал подход MVC для своей игры и пока не жалуюсь. Но за те два года, что я занимаюсь, я писал исключительно то, что называется core gameplay, т.е. взаимодействия с NPC: общение, сражения и т.п. и не заморачивался менюшками и прочими рюшками.

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

Что я имею сегодня. Класс Main запускает контроллер, который выглядит вот так:
Код AS3:
public function Game (host: MainView) : void
{
	_host = host;
 
	_model = new GameModel (foregroundCharactes);
	_view = new GameView (_model, _host);
	_host.addChild(_view);
 
	_model.init();
 
	_view.addEventListener(ViewEventTypes.MENU_SELECT, menuCommandHandler);	// Подписываемся на выбор меню
}
То есть сразу после запуска приложения игрок сразу попадает в режим сражения: выбирает действия, получает обратную связь.

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

Напомните, пожалуйста, как это правильно сделать. Спасибо.
__________________
Не сломано - не чини!

Старый 05.07.2021, 00:23
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 2  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Вспомнил, что этот вопрос уже обсуждался, на всякий случай привожу выжимку из той темы, если кому потребуется:

Цитата:
Zebestov:
Контроллеров несколько, дерево.
Моделей несколько, тоже дерево.
Вьюх тоже несколько, и да, опять дерево.
Главный контроллер проводит игру по кругу: меню-игра-меню-игра… "от пункта к пункту".
Контроллер слушает свою модель и свои контроллеры. Например MainController ждет от MainMenuController событие "CLOSE". Дождался — приложение идет дальше — GameController.open(), предварительно подписавшись на его CLOSE. Тот же GameController в свою очередь слушает от GameModel событие GAME_OVER и решает, что делать дальше, после того, как персонаж "запаркуется" на стартовой позиции (тоже по событию от модели поймет): откатать рекламу, например, или сразу посылать событие CLOSE, чтобы MainController снова открыл меню. Таким образом контроллер(ы) заведуют движением приложения.
Т.е. вся логика происходит в моделях. Отображение актуальных состояний реализуют вьюхи с помощью прослушивания событий от моделей. Контроллеры берут на себя рутину — что делать дальше, и когда это делать (дали старт окну закрыться — стоим, курим, ждем завершения анимации, вьюха сообщит когда).
Вправо-влево, генерация яблок, падение яблок (формула равноускоренного падения, привязанная ко времени), фиксация улова, когда яблоко ниже уровня корзины (формула, реализующая фиксацию улова не в данный момент, а тогда, когда яблоко пересекло линию, так мы устраняем эффект от лагов) — все это происходит в модели.
Кроме отображения информации, важной для игры GameView делает еще вещи, которые вообще не должны волновать ни модель, ни кого-либо другого: анимирует появление яблока из листвы, топает ножками персонажа и т.д.
Ну вот условно так.

Appleman:
Увидел тут мельком, речь зашла о ветвлении Моделей и Контроллеров. Я как раз до этого в своём проекте дошёл. Вот смотрите, есть игра, в ней у героя инвентарь. Его функционирование обеспечивается своей персональной триадой MVC, верно. Когда пользователь жмёт кнопку инвентаря, это событие слушает главная Вью и посылает событие в главный Контроллер. Главный Контроллер создаёт дочерний Контроллер инвентаря, который в свою очередь создаёт Модель и Вью инвентаря. Дальше все манипуляции обрабатываются дочерней MVC, и только событие на закрытие остаётся за главным Контроллером, который, получив его, свернёт всю лавочку и даст команду главной Модели продолжать.
Верно я всё написал?

Zebestov:
Контроллеры создает контроллер. Модели — модель. Вьюхи плодятся во вьюхе.
Ко всем этим дочерним элементам есть доступ по геттеру, например.
Триада создается путем создания нового контроллера, который всегда имеет в аргументах как минимум две ссылки: необходимые ему для работы модель и вью.
Есть только один контроллер, который создаем модель и вью — это MainController. В нем создаются MainModel и MainView. Больше ни в одном контроллере модели и вьюхи не создаются. Они подаются в конструктор (или метод-инициализатор).

Appleman:
У меня в голове как-то плохо умещается взаимодействие элементов триады MVC, если каждый из них САМ создаёт своих дочек. Правильно я последовательность себе представляю:
1. Главный Вью создаёт дочерний Вью. В главном пишем геттер для дочернего. В дочернем пишем сеттер для дочерней Модели.
2. Главная Модель создаёт дочернюю Модель и к ней также геттер.
3. Главный Контроллер из главного Вью забирает по геттеру дочерний Вью, а также из главной Модели ссылку на дочернюю Модель и создаёт дочерний Контроллер, передавая в его конструктор ссылки на дочерние Модель и Вью. Дочернему контроллеру есть на что подписываться (связка "V-C") и чем командовать (связка "C-M").
3. Наконец, дочерний Контроллер, уже имея ссылку на дочернюю Модель, просто устанавливает её для дочернего Вью через сеттер. Дочерний Вью подписывается на дочернюю Модель, "закрываю" последнюю связку "M-V". Всё готово.
Всё верно или я опять перемудрил? И не будет ли косяков, связанных с очерёдностью создания дочерних элементов в таком порядке? И в какой DOC должен быть добавлен дочерний Вью?
И ещё вопрос. Нормально, когда Модель вообще одна, а разные Контроллеры появляются в комплекте с разными Вью по необходимости?

Zebestov:
В принципе стройненько все вышло, кроме одного момента:
1. Дочернему Вью его модель (дочерняя) передается сразу в конструкторе, ведь главный Вью имеет ссылку на главную модель и может передать все необходимое сразу.
Сейчас начал реализовывать на практике, есть ощущение какой-то неправильности и, извините, ректальности. Zebestov рекомендовал создавать модели в моделях, и вью во вью, а затем подавать их в дочерний контроллер. Но по факту (по крайней мере у меня) всё начинается с контроллера. То есть например, пользователь в процессе игры кликнул иконку главного меню, GameView это поймала и послала событие в GameController. Игровой контроллер видит, не моё, а вышестоящее, пересылает событие выше. Главный контроллер видит, ага, моя вотчина, нужно главное меню, создаём его MVC.

И вот в этот момент, как написано выше, главный Вью должен создать дочерний MainMenuView, а Модель - дочернюю MainMenuModel. Причём оба должны быть не просто созданы, а записаны в переменную и возвращены в главный контроллер, который передаст их в конструктор создаваемого дочернего контроллера главного меню. Выходит, главный контроллер должен ломиться в главную Модель, а потом и в главный Вью, запускать в них методы создания дочек. Выглядит не кошерно. А если этого не делать, то как последние вообще "узнают" о том, что им вообще нужно что-то создавать?
__________________
Не сломано - не чини!

Старый 09.07.2021, 12:40
udaaff вне форума Посмотреть профиль Отправить личное сообщение для udaaff Найти все сообщения от udaaff
  № 3  
Ответить с цитированием
udaaff
...

модератор форума
Регистрация: Sep 2006
Адрес: Minsk
Сообщений: 4,286
Привет! Предлагаю использовать или ознакомиться (и почерпнуть идеи) с уже готовым архитектурным решением:
https://github.com/robotlegs/robotlegs-framework
https://www.oreilly.com/library/view...9781449311193/

Старый 11.07.2021, 21:42
СлаваRa вне форума Посмотреть профиль Отправить личное сообщение для СлаваRa Найти все сообщения от СлаваRa
  № 4  
Ответить с цитированием
СлаваRa
 
Аватар для СлаваRa

блогер
Регистрация: Feb 2008
Адрес: http://playtika.com
Сообщений: 1,119
Записей в блоге: 5
Отправить сообщение для СлаваRa с помощью ICQ Отправить сообщение для СлаваRa с помощью Skype™
robotlegs - это далеко не самое лучшее с чем нужно знакомится вообще, если только не рассматривать его как антидвижок, в этом ключе он ок!
__________________
местонахождение

Старый 13.07.2021, 01:30
udaaff вне форума Посмотреть профиль Отправить личное сообщение для udaaff Найти все сообщения от udaaff
  № 5  
Ответить с цитированием
udaaff
...

модератор форума
Регистрация: Sep 2006
Адрес: Minsk
Сообщений: 4,286
Цитата:
Сообщение от СлаваRa Посмотреть сообщение
robotlegs - это далеко не самое лучшее с чем нужно знакомится вообще, если только не рассматривать его как антидвижок, в этом ключе он ок!
Аргументацией бы еще какой-то подкрепить это утверждение, да хорошим примером годного для знакомства/использования архитектурного фреймворка

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


Последний раз редактировалось udaaff; 13.07.2021 в 03:09.
Создать новую тему Ответ Часовой пояс GMT +4, время: 01:37.
Быстрый переход
  « Предыдущая тема | Следующая тема »  
Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


 


Часовой пояс GMT +4, время: 01:37.


Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.