|
|
|||||
Lorem ipsum
|
Цитата:
События, требующие визуализации актуального состояния, слушает вью. Как-то так.
__________________
Поймай яблоко 2! |
|
|||||
[+4 06.05.14]
|
Цитата:
а) сколько у тебя контроллеров или он один? б) сколько у тебя моделей? ( если ли общая модель, или же просто разрозненные типа PlayerModel, IFaceModel и т.п. ) в) Что у тебя происходит в иерархии событий и т.п. когда игрок движется вправо-влево, что происходит , когда ловит яблоко? Я как обычно не претендую на гуру, но как по мне в данной игре достаточно всю логику спокойно уместить во вью, а контроллером только посылать на сервер скоре игрока и т.п. , а модели чисто хранить какие то данные, ну и совсем малость где, обновлять вьюху, но это прям 1-2 метода не более.
__________________
Марк Tween |
|
|||||
Lorem ipsum
|
Контроллеров несколько, дерево.
Моделей несколько, тоже дерево. Вьюх тоже несколько, и да, опять дерево. Главный контроллер проводит игру по кругу: меню-игра-меню-игра… "от пункта к пункту". Контроллер слушает свою модель и свои контроллеры. Например MainController ждет от MainMenuController событие "CLOSE". Дождался — приложение идет дальше — GameController.open(), предварительно подписавшись на его CLOSE. Тот же GameController в свою очередь слушает от GameModel событие GAME_OVER и решает, что делать дальше, после того, как персонаж "запаркуется" на стартовой позиции (тоже по событию от модели поймет): откатать рекламу, например, или сразу посылать событие CLOSE, чтобы MainController снова открыл меню. Таким образом контроллер(ы) заведуют движением приложения. Т.е. вся логика происходит в моделях. Отображение актуальных состояний реализуют вьюхи с помощью прослушивания событий от моделей. Контроллеры берут на себя рутину — что делать дальше, и когда это делать (дали старт окну закрыться — стоим, курим, ждем завершения анимации, вьюха сообщит когда). Вправо-влево, генерация яблок, падение яблок (формула равноускоренного падения, привязанная ко времени), фиксация улова, когда яблоко ниже уровня корзины (формула, реализующая фиксацию улова не в данный момент, а тогда, когда яблоко пересекло линию, так мы устраняем эффект от лагов) — все это происходит в модели. Кроме отображения информации, важной для игры GameView делает еще вещи, которые вообще не должны волновать ни модель, ни кого-либо другого: анимирует появление яблока из листвы, топает ножками персонажа и т.д. Ну вот условно так.
__________________
Поймай яблоко 2! |
|
|||||
Регистрация: Oct 2006
Сообщений: 2,281
|
мне кажется zebestov достаточно ясно разделил:событие запускает дальнейший флоу?Да - ловим его в контроллере,нет(типа надо просто обновить очки) - ловим во вью.
|
|
|||||
.
|
Цитата:
Добавлено через 10 минут Цитата:
Добавлено через 17 минут Такая же фигня, братюня ) |
|
|||||
[+4 06.05.14]
|
Дима
Цитата:
А двоякое ощущение, потому что ты пишешь слегка непонятно, *все нормально в парадигме* - это значит ты не запрещаешь раз в 100 лет дернуть метод модели из вью? Или ты говоришь наоборот, что парадигма должна быть выполнена как положено, клик вью, пересылка в контрол, пересылка в модель, рассылка всем ??? Добавлено через 1 минуту Цитата:
__________________
Марк Tween |
|
|||||
Регистрация: Oct 2006
Сообщений: 2,281
|
Цитата:
|
|
|||||
блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
|
Цитата:
Имеется ввиду, что самый ок вариант – это когда есть условный `ISerializator`, который всем этим и занимается. Весь код приложения к нему, по большей части, агностичен. Юзкейс: проверять доступность транспорта до тех пор, пока не найдется лучший. Например: используем [веб]-сокеты, если клиент/платформа может в них. Если нет, то long-polling (это когда HTTP request висит в "ожидании" до тех пор, пока данные не пришли). В первом случае сериализуем в бинарном виде компактненько, во втором – только жирно строками (json/base64/xml/etc). (Конечно, юзкейз требует ещё и `IServerConnector`, которых тоже два – слать в сокет и слать хттп реквесты – суть та же самая)
__________________
Тут мужик танцует и поёт про флэш |
|
|||||
.
|
Разъяснил как мог:
Цитата:
Десериализация — процесс перевода последовательности битов в структуру данных (via wikipedia). Парсинг, а точнее, синтаксически анализ, это и есть часть процесса десериализации. В случае, если модель будет работать с JSON, то произойдет такая цепочка (вариант 1): 1. Чтение из источника потока байтов (файловая система или сетевой протокол), представляющих собою plain текст, который полностью подчиняется грамматике JSON; 2. Преобразование текста (десериализация и парсинг) в ActionScript Object; 3. Чтение полей из этого Object и заполнение полей конкретного объекта(ов) модели. Второй пункт часто избыточен, поэтому десериализацию можно сделать без него (вариант 2): 1. Чтение из источника потока байтов (файловая система или сетевой протокол), представляющих собою кастомный протокол; 2. Поток по неким правилам анализируется десериализатором, который пишет в поля конкретного объекта(ов) модели. Пример: есть протокол AMF1/3, с помощью которого происходит десериализация данных непосредственно в strong typed объект ActionScript. Однако с помощью него нельзя переписать поля существующего объекта. Десериализация потока этого протокола средствами флеша всегда приводит к созданию новых объектов. Так вот десериализатор из второго пункта "варианта 2" может быть: а) встроен в объекты модели; б) внешним по отношению к объектам модели. Пункт "а" подразумевает, что по мере чтения из потока, некто, анализируя его, извлекает из модели нужный объект и передает в него поток. Этот объект модели последовательно читает из потока нужные ему данные. Предыдущая итерация повторяется столько, сколько есть данных для модели в потоке. Пункт "б" предпочтительнее. Некто извлекает из модели объект и сам пишет в него. Затем повторяет. Этот некто и есть десериализатор, зависящий от конкретного протокола. Именно в нем заложены правила разбора протокола. Последний раз редактировалось dimarik; 01.03.2018 в 22:01. |
|
|||||
Регистрация: Oct 2006
Сообщений: 2,281
|
и это все лишь бы не создавать новый объект на каждый респонс?Оно того не стоит имхо.
|
Часовой пояс GMT +4, время: 13:01. |
|
« Предыдущая тема | Следующая тема » |
Теги |
MVC , mvo , Проектирование |
|
|