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

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

Версия для печати  Отправить по электронной почте    « Предыдущая тема | Следующая тема »  
Опции темы Опции просмотра
 
Создать новую тему Ответ
Старый 04.12.2017, 11:33
caseyryan вне форума Посмотреть профиль Отправить личное сообщение для caseyryan Найти все сообщения от caseyryan
  № 21  
Ответить с цитированием
caseyryan
 
Аватар для caseyryan

Регистрация: Jun 2012
Адрес: Новосибирск
Сообщений: 6,644
Записей в блоге: 4
Цитата:
Пока вся логика выбора портрета целиком заложена во Вью. То есть при изменении параметров персонажа, вью "спрашивает" Модель, сколько HP осталось, и в зависимости от этого подбирает нужный портрет. И только Вью "знает", сколько всего спрайтов предусмотрено и для какого случая. Если я захочу, например, усложнить этот механизм, и к кровище на лице добавить выражения ярости или страха, в зависимости от значений других свойств, то всё равно вся эта логика останется во Вью. Верно?
Конечно
__________________
Ко мне можно и нужно обращаться на ты)

Старый 04.12.2017, 15:45
Wolsh вне форума Посмотреть профиль Отправить личное сообщение для Wolsh Найти все сообщения от Wolsh
  № 22  
Ответить с цитированием
Wolsh
Нуб нубам
 
Аватар для Wolsh

модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
Логика "ЧТО" — уровень НР — в Модели,
логика "КАК" — какую картинку подобрать — во Вью.
__________________
Reality.getBounds(this);

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

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Друзья, подскажите ещё плиз на счёт MVC.

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

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

Старый 20.12.2017, 20:53
Wolsh вне форума Посмотреть профиль Отправить личное сообщение для Wolsh Найти все сообщения от Wolsh
  № 24  
Ответить с цитированием
Wolsh
Нуб нубам
 
Аватар для Wolsh

модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
Да, это правильно.
__________________
Reality.getBounds(this);

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

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

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

Старый 15.01.2018, 15:32
ZergMaster вне форума Посмотреть профиль Отправить личное сообщение для ZergMaster Найти все сообщения от ZergMaster
  № 26  
Ответить с цитированием
ZergMaster
 
Аватар для ZergMaster

Регистрация: May 2008
Адрес: Питер
Сообщений: 385
Отправить сообщение для ZergMaster с помощью ICQ Отправить сообщение для ZergMaster с помощью Skype™
Я бы выдавал моделью только те действия, которые актуальны. Хотя если нужно, чтобы неактивные тоже отображались, то в каждом действии бы завел свойство .active и отображал по нему.
__________________
while(live()) { hope(); }

Старый 15.01.2018, 15:45
Wolsh вне форума Посмотреть профиль Отправить личное сообщение для Wolsh Найти все сообщения от Wolsh
  № 27  
Ответить с цитированием
Wolsh
Нуб нубам
 
Аватар для Wolsh

модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
Согласен с ZergMaster, Вью не должна определять доступность действий. Это не та ситуация, когда кнопки временно "дизаблятся" вьюхой по соображениям UI или пока отыграет какая-то анимация. Здесь всё-таки доступность является вопросом игровой логики и основывается на данных модели.
__________________
Reality.getBounds(this);

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

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

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

Старый 17.01.2018, 18:56
caseyryan вне форума Посмотреть профиль Отправить личное сообщение для caseyryan Найти все сообщения от caseyryan
  № 29  
Ответить с цитированием
caseyryan
 
Аватар для caseyryan

Регистрация: Jun 2012
Адрес: Новосибирск
Сообщений: 6,644
Записей в блоге: 4
Цитата:
на фига тратить вычислительные ресурсы на те действия, которые игрок может даже и не увидит, т.к. не кликнет на соответствующую группу. И проверка на активность переползла во Вью в момент "раскрытия" группы меню перед выводом списка действий. Там же ещё есть динамически подбираемые тултипы.
В чем разница, с точки зрения вычислительных ресурсов?
Флеш работает в одном потоке, и если делать какие-то тяжелые расчеты в момент нажития кнопки или раскрытия какого-то меню, это легко может привести к неприятным фризам. Лучше всего сразу скармливать вьюшке готовую информацию, чтобы она ее только отобразила. Очень сомневаюсь конечно, что в подобной игре есть какие-то ресурсоемкие вычисления
Ну и второй момент. Он не касается конкретной игры, а скорее об играх в общем. Представим такую ситуацию: модель работает на сервере, а клиент представляет из себя только вью. Модель отдает вьюшке все необходимые данные, а она там у себя уже решает что отобразить, а что сделать не активным. Но с позиции модели активно все. Какой-то кулхацкер взламывает эту вьюшку и слегка правит код, чтобы ничего не блокировалось. Вуаля, ему доступны все действия и модель с удовольствием принимает все его решения. Я хочу сказать, что в подобном случае, это дикая дыра в безопасности. Ей непременно воспользуются, если игра станет хоть чуточку популярна
__________________
Ко мне можно и нужно обращаться на ты)

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

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


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

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

Создать новую тему Ответ Часовой пояс GMT +4, время: 14:15.
Быстрый переход
  « Предыдущая тема | Следующая тема »  

Теги
MVC , mvo , Проектирование
Опции темы
Опции просмотра

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

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


 


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


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