Конечно

Логика "ЧТО" — уровень НР — в Модели,
логика "КАК" — какую картинку подобрать — во Вью.

Друзья, подскажите ещё плиз на счёт MVC.

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

Вопрос, где должны создаваться и храниться эти самые группы? Моя версия - Вью. Логика работы такая. Модель перебирает все возможные действия, отбирает среди них те, которые могут быть выполнены, и помещает их в массив. Этот массив передаётся Вью, которая "берёт в другую руку" известные заранее группы и выводит всё пользователю в нужном разрезе. При этом получается, если игрок выбирает опции, которые затрагивают лишь сам вывод (раскрыть группу или наоборот, вернуться назад), то все они отслеживаются и выполняются на уровне самой Вью. А выбор действия уже идёт в контроллер.

Да, это правильно.

Друзья, у меня вопрос в продолжении предыдущего на счёт группировки возможных действий. Сделал, как и планировал: Модель отбирает все возможные варианты действий, передаёт массив во Вью. Вью "знает", какие действия в какие группы объединить, формирует список групп на экране. При клике пользователя группа "раскрывается", Вью выводит уже наименования действий для выбора. Выбор передаётся в контроллер. Работает.

Но для действий ещё нужен статус активности или неактивности. Для ситуаций, когда действие по проверке условий "проходит" и должно выводится пользователю, но в данный момент оно не может быть выполнено (т.к. например, находится на cooldown-e или какого-нибудь восполняемого параметра не хватает у персонажа). Для таких случаев я завёл ещё одну группу условий - условия активности. Сейчас запрограммировал следующим образом. При клике пользователя на группе, перед тем как она "раскроется", Вью перебирает все содержащиеся в ней действия (предварительно отобранные Моделью) и проверяет для каждого условия активности. Если условия выполнены - то выводится активная кнопка. Если - нет, но неактивная. Вопрос, правильно ли это с т.з. MVC? Смущает тот факт, что Вью фактически занято игровой логикой, хотя в данном случае последняя напрямую оказывает влияние на то, как отображать и как взаимодействовать с пользователем. Просьба прокомментировать. Спасибо.

Я бы выдавал моделью только те действия, которые актуальны. Хотя если нужно, чтобы неактивные тоже отображались, то в каждом действии бы завел свойство .active и отображал по нему.

Согласен с ZergMaster, Вью не должна определять доступность действий. Это не та ситуация, когда кнопки временно "дизаблятся" вьюхой по соображениям UI или пока отыграет какая-то анимация. Здесь всё-таки доступность является вопросом игровой логики и основывается на данных модели.

ZergMaster, Wolsh, спасибо за ответ. Подтвердили мои сомнения :)

Собственно так и происходит. Причём изначально я думал сделать, чтобы Модель сразу же при подборе проверяла не только по критериям актуальности (возможность показать игроку), но и по критериям активности (возможность выбрать и выполнить), чтобы выдавать во Вью уже полностью готовый комплект. А потом подумал, на фига тратить вычислительные ресурсы на те действия, которые игрок может даже и не увидит, т.к. не кликнет на соответствующую группу. И проверка на активность переползла во Вью в момент "раскрытия" группы меню перед выводом списка действий. Там же ещё есть динамически подбираемые тултипы. Если действие выполнимо, то игроку показываются некоторые его параметры. Если нет - то причина, почему нельзя...

В чем разница, с точки зрения вычислительных ресурсов?
Флеш работает в одном потоке, и если делать какие-то тяжелые расчеты в момент нажития кнопки или раскрытия какого-то меню, это легко может привести к неприятным фризам. Лучше всего сразу скармливать вьюшке готовую информацию, чтобы она ее только отобразила. Очень сомневаюсь конечно, что в подобной игре есть какие-то ресурсоемкие вычисления
Ну и второй момент. Он не касается конкретной игры, а скорее об играх в общем. Представим такую ситуацию: модель работает на сервере, а клиент представляет из себя только вью. Модель отдает вьюшке все необходимые данные, а она там у себя уже решает что отобразить, а что сделать не активным. Но с позиции модели активно все. Какой-то кулхацкер взламывает эту вьюшку и слегка правит код, чтобы ничего не блокировалось. Вуаля, ему доступны все действия и модель с удовольствием принимает все его решения. Я хочу сказать, что в подобном случае, это дикая дыра в безопасности. Ей непременно воспользуются, если игра станет хоть чуточку популярна

caseyryan, спасибо, приму к сведению.


Очень просто. Если у нас 100 действий, распиханных в 10 папок, то в случае предварительной сплошной проверки, мы проверим все 100. А если по мере раскрытия пользователем папок, то проверим только 10. Потом скорее всего будет выбрано одно, и остальные 90 проверок окажутся неактуальными.

Да, тяжёлых расчётов пока не предвидится, это уже наверное такой перфекционизм новичка :)