|
|
« Предыдущая тема | Следующая тема » |
Опции темы | Опции просмотра |
|
|
|||||
Снова MVC: контроллеры мелких объектов
Допустим, делаю фермоподобную игру.
Уже на не первом проекте замечаю рост неподдерживаемой условной логики в общем для всех мороковок, животных и строений контроллере. Собственно, понятно, что: - базовая модель "карта фермы" содержит дочерние модельких мелких объектов (2-5 типов) (ничего не делает, только помогает в получении всякой информации и рассылает события) - главный контроллер а) забирает данные от сервера, наполняет и меняет соответствующим образом "карту фермы" б) принимает данные от кликов по объектам карты и меняет соответствующим образом модель и ее мелкие объекты с) считает время созревания/протухания/сбора каждого объекта, изменяя в нужный момент модель - вьюшка слушает модель, передает события действий пользователя контроллёру А вот что не понятно: как избавить контроллер от слежения за всеми типами всех объектов? - перенести логику в модель? не получится: а) Например при заходе к другу действия от пользователя надо обрабатывать по другому б) В зависимости, от выбранного инструмента нужно по-разному реагировать на действия пользователя с) Ну логику для разных типов мы разделим, зато загадим мелкую модель жуткой логикой для разных ситуаций - запихать во вьюху? а) приведет к дикому копипасту, т.к. одни и те же дейтсвия можно делать с помощью разных частей интерфейса б) опять же, загадим вьюху условной логикой для разных ситуаций. А выделить в ней классы-состояния при высоком уровне копипаста (см.пункт а) - нереально. - наделать по контроллеру на модельку? идея нравится, но вот как это сделать?, ведь требования такие: а) контроллер должен считать и помнить что он насчитал для своей модельки; б) решать какие действия доступны для его модельки; с) приводить вьюшку в соответствие с возможными действиями (заставлять всякие значки "скликни меня" рисовать) но при этом он должен быть отвязан от модели, т.к.: а) нужны разные контроллеры на одну и ту же модель для разных состояний игры - надо по-разному обрабатывать действия пользователя б) нужен механизм для смены контроллеров всех моделек при смене глобального состояния с) кто-то должен знать какой контроллер должен быть назначен модели - кто? Будь это моделька или вьюшка - проблем достаточно и в том и в другом случае. Есть какие-нибудь идеи? Последний раз редактировалось expl; 25.03.2011 в 01:22. |
|
|||||
strange mood
|
Цитата:
Цитата:
Цитата:
Как устроено: - Поведение (пачка методов, обрабатывающих действия пользователя) для каждого состояния описывается в отдельном классе, вся пачка классов-поведений имеет общий интерфейс. - Контроллер содержит ссылку на текущий объект-поведение (композиция) Как используется поведение: - Контроллер обращается к методам поведения по ссылке (динамическое связывание) При смене состояния: - Контроллер обращается к фабрике поведений, передавая туда новое состояние - Фабрика получает состояние и отдает соответствующее ему поведение - Контроллер запоминает полученное поведение как текущее Скорее всего, поведению потребуется ссылка на модель. Ее можно либо передавать в каждый метод (в таком случае поведение можно вообще сделать статическим классом), либо в конструктор объекта (через фабрику). А вообще, если реакция морковки зависит только от состояния, выбранного инструмента и ее модели, то зачем тогда плодить кучу одинаковых контроллеров? Можно сделать один контроллер для всех морковок, который хранит их модели в массиве, и тоже реализован по описанной выше схеме. Я бы сделал именно так.
__________________
тонкий тролль, осеянный благодатью Последний раз редактировалось Gaen; 25.03.2011 в 02:43. |
|
|||||
ох не для всех игр подходит MVC, совсем не для всех
долго там думать надо, чтоб архитектура более менее подходила к "тяжелой" игре как только много разветвленной логики и куча состояний/логики/анимации, нужны какие нить через-строчные конвейеры, на пару-тройку уровней данных каждый примерно можно описать как типизированные массивы Vector.<IData>, Vector.<IModel>, Vector.<IVisual> (скорость) ... каждый уровень обрабатывается желательно одним, и ОЧЕНЬ желательно маленьким обработчиком/контроллером (скорость) ... при обработке уровня не трогать другие уровни (скорость) и ессна не в каждом кадре, в каждом кадре можно только апдейтить анимацию из IVisual, да и то избегать события от сервера ставить в очередь и т.д. и т.п. в общем там куча действий по оптимизации, в схему МВС оно все вписывается тяжко, и обычно жутко мешает хотя бы самую тяжелую часть надо из МВС вытаскивать, делать одним VIEW |
|
|||||
блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
|
Цитата:
Может быть, Вы имели ввиду "MVC не самое лучшее решение для некоторых игр"? @expl, я не очень понял в чем загвоздка, но могу порекомендовать бабблинг. =) Смысл в том, что по клику на однотипные объекты рассылается бабблинг событие. Контроллер ловит это событие и может стянуть модель у вьюшки, по event.target.
__________________
Тут мужик танцует и поёт про флэш |
|
||||||||
2 GAIKER:
Цитата:
Цитата:
Или более сложный пример - выбираем место для посадки, таская морковку по всему полю - нам что, при этом модель менять? А если еще какая сложная подсветка ячеек при этом понадобится? Цитата:
Паттерн "состояние" рулит - это всё понятно. Но смущает 2 вещи: как хранить связь модель-контроллер? (например для карты контроллеры свои, для како-го нибудь магазина - свои, т.е. для каждой подсистемы связь своя) влепить ссылку в модель? - как-то не очень. Небольшой оффтоп по поводу связи вьюха - модель: Как по модели найти вьюху? Я тупо завожу хеш-таблицу в главной вьюхе, содержащей морковки и получаю так: _viewByModel[model]. Вьюха хранит ссылку на модель напрямую. Это нормально, или кто-то нашёл более вменяемый способ? Цитата:
2 ShockWave512 Цитата:
Цитата:
2 Psycho Tiger Цитата:
|
|
|||||
strange mood
|
Цитата:
Но тут уже вопрос, как разнести все это дело. Подсветка ячейки - это по сути тоже поведение, которое зависит от глобального состояния и выбранного инструмента, но только поведение вьюшки а не контроллера. При таком раскладе можно придти к вынесению каждого инструмента в отдельный класс, в котором будет содержаться логика для контроллера и для вью, хотя это уже выглядит странновато.
__________________
тонкий тролль, осеянный благодатью |
Часовой пояс GMT +4, время: 10:47. |
|
« Предыдущая тема | Следующая тема » |
|
|