Хорошее MVC

[-De-]

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

[Psycho Tiger]

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

P.S. локализация и звуки это задачи сугубо вьюхи. к модели отношения не имеют.

[Котяра]

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

[Psycho Tiger]

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

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

[-De-]

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

[Psycho Tiger]

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

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

[-De-]

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

[Psycho Tiger]

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

[-De-]

Сообщение от Psycho Tiger

Вьюшка - отображает. Очень удобно тем, что невозможно отображением подпортить логику игры.

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

Сообщение от Psycho Tiger

Ещё удобно тем, что разработку можно вести на уровне кружочки-квадратики и не ощущать скованность из за неполноты представления - добавляя отображение мы меняем 33% кода, вместо всей 100 (если представить что модель-контроллер-вьюшка имеют равный объем кода, что почти всегда неверно ).

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

Сообщение от Psycho Tiger

Чертовски удобно когда несколько видов игры - например вид сверху и вид сзади (3д, но игра функционала такого же как в 2д).

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

[КорДум]

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