Хорошее MVC

[Котяра]

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

[Psycho Tiger]

@Котяра: просто начал уже более-менее разбираться. Объясняю чтобы проверить твёрдость моих теоретических знаний )

Конечно, MVC не панацея, иногда он создаёт даже излишние неудобства, в плане скорости разработки на ранних стадиях. MVC у меня в голове проецируется как танк. Хочешь рулить - бери танк, но он тяжелый и сложен в управлении. Нужно что-то лёгкое, быстрое, простое в написании и понимании - MVC не твой выбор.

[-De-]

Ээ, картинки, звуки, анимации, ну т.е. ассеты - это данные.
Я не против MVC, просто я лично птица гордая, надо пнуть. И хрен бы со мной, но я ж (конечно же, какие сомнения) не для себя, думаю я не один такой. Для кармы там полезно обьяснить неразумным преимущества MVC, как отмазка от ментов может прокатить и пр. =)
ЗЫ: дикий оффтоп и вброс, но если у вас не меняется логика игры в процессе производства, то вы - не игродел %)

[Psycho Tiger]

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

Звуки, картинки, анимации - это не модель, в общем случае. Всё, что юзер видит на экране - это вьюшка. Модель хранит количество патронов в обойме, количество обойм и идентификационный номер автомата. Вьюшка берёт эти 3 числа и устраивает на экране... да хоть 2 мировую.

[-De-]

Да, возможно у меня в голове неправильное MVC, но для того MVC, что у меня в голове, я вон выше обьяснил, зачем оно нужно вообще.
А у вас выгоды не видно. Проверка на выгодность: меняем поведение автомата при том, что "количество патронов в обойме, количество обойм и идентификационный номер автомата" остается одним и тем же, меняем в одном месте, скорее всего простые и понятные штуки (интересно, кстати, какие например). Вроде ок. А если нет вьюшки, т.е. ваша модель берёт 3 числа и устраивает непристойности, то... то же самое! Зачем платить больше?
Т.е. есть вот автомат. Есть его какие-то данные, которые "одни для всех" - они модель. Они - на сервере вообще. Зачем флэшке об этом знать? Флэшка должна по этим данным данным свыше изобразить автомат. Если меняется характер этих данных (сплэш там добавляется например), то один хрен надо править флэшку. И хорошо бы, чтоб в минимальном числе мест. Если автомат становится супермеганавороченным классом, лазить по которому грозит похуданием, то есть куча других способов сгруппировать куски автомата по разным классам.

[Psycho Tiger]

Своё виденье я описал в посте №180.

[КорДум]

Как трудно уследить за всеми контроллерами? Если контроллеров куча, а это, я думаю, очень хорошо (конечно, если правильно структурировано). Ведь проследить, что там что куда посылает, если что-то там случилось, довольно трудно, разве нет? Плюс держать в голове, что же там у нас во вьюшке, а что у нас в контроллерах. Не говоря уже о том, что там у нас творится с данными в модели... Пока я вижу только одно удобство у MVC, как Тигер сказал, править нужно только вьюшку. Но мне не видится удобным, ибо в голове как-то сформировался синглтон, все действия объекта пишутся в классе этого объекта и взаимодействуют через статичные ссылки Main. Да, в теории может быть MVC и очень даже хорош. Но практика взрывает мозг.

[Волгоградец]

Блин, всю ветку не осилил, может было уже, но спрошу все равно... Как обрабатывать событие enterFrame? По идее логику должен обработать контроллер, передать в модель, а та в, свою очередь, во вьювер должна передать команду обновить экран. Как-то мне кажется это замороченным - гонять кучу данных по кругу. Да, вьювер может сам себя обновить, минуя контроллер и модель, но какой же это тогда MVC?

[Psycho Tiger]

Примеры? Были долго тупые бока, из-за того, что (в терминах MVC) вьюха меняла модель. Причем все отлично знали, что такое делать нельзя

Эээ... вьюха отображала то что видит игрок №1, потом зрителю захотелось увидеть где сидит противник - вьюха поменяла модель и зритель стал видеть что видит игрок №2.

Передача данных во вьюху только по значению - единственное, что спасло бы, но как-то оно не гибко.

Я передаю данные во вьюху из контроллера только если эти данные не нужны системе. Например, просмотр инфы об игроке - окошко с этой инфой не должно существовать или оставлять следов существования (кэш не рассматриваем), когда его закроют - поэтому я миную модель и отправляю команду прямиком в вьюху. Подход не совсем правильный - модель по идее должна иметь информацию какое окно смотрим, но мне удобно.

В MVC надо думать, что же добавить в модель + всё равно думать, какие действия на какие условия ты завязываешь, у меня давно отображение логику не портит (багов особо меньше из-за этого не стало, правда).

MC+V?

Не согласен насчёт обьёма кода, ведь собсно надо написать "рисуем такую-то штуку по таким-то данным", а где это писать - не так важно, в MVC ещё и потеряем из-за накладных на передачу данных. А на уровне кружочков работать можно и без MVC (лично знаю, работали).

Можно и синглтон в качестве центральной логики использовать. Прелести MVC вылезают где то после полмегабайта "свежего" кода - т.е. кода, написанного только под этот проект. Кружочки-кругляшки я говорил абстрактно, имея ввиду что отображаем кое-как, а игра работает правильно.

Чем при MVC легче? "Рисуем сверху", "рисуем сзади" придется писать примерно одинаково, разрулить, когда как рисовать - никаких проблем.

Другой вопрос что пока ты делаешь вид сверху кто-то делает вид сбоку, опираясь на известный интерфейс моделей. Разруливать всегда хуже чем изначально избежать неудобств: делая вид сбоку я не хочу знать о том, как сделан вид сверху и откуда растут ноги, чтобы разрулить.

Но практика взрывает мозг.

Ты сам виноват, начав консультироваться сразу по композитным MVC)

По идее логику должен обработать контроллер, передать в модель, а та в, свою очередь, во вьювер должна передать команду обновить экран.

Не, модель не передаёт команд. Модель говорит о том, что изменилась - а вьювер сам принимает решение, стоит ли ему новые данные визуализировать или нет.

Как обрабатывать событие enterFrame?

enterFrame чего, вьюхи? Типа очки плавно возрастают с 0 до 500? Это заботы сугубо вьюхи, в модели было значение 0, потом сразу стало 500.
Если речь о нужде события enterFrame в контроллере - тот создаёт DisplayObject и хватает у него этот enterFrame. Композиция, короче.

[Котяра]

ну по энтерфрэйм/таймеру можно менять модель тоже (например xPos,yPos,zPos)
а во вью это отображать.
так у меня сделана одна 3D стрелялка.
вью в этом случае это viewport камеры, модель - это координаты 3D объектов.
делать каждый 3D объект вьюшкой нельзя. вернее они тоже вьюшки, но другого уровня - слушают например поле модели статус и исходя из него меняют свою текстуру/форму.
Но вообще в таком случае чистый мвц не очень подходит.