@Tails

Столько написал, что даже смогу более конкретно описать проблему.
Получается, что если длительность какого либо действия зависит от длительности анимации или звука, тогда это значение нужно записать в модель, как параметр и просто засекать нужное время в тот момент когда виду подается команда на отображение/озвучку. Но тогда нужно полностью отказаться от родной покадровой анимации. В случае тормозов длительность кадра/кадров может сильно увеличится, но таймеру на это плевать. Значит анимацию нужно прокручивать вручную с расчетом прошедшего времени. Я правильно понял?

Такое ощущение, что Вы книжку (или что там) начали читать с пятого параграфа.
Модель создает, хранит, обрабатывает и отдает ДАННЫЕ.
Вью обеспечивает физический ИНТЕРФЕЙС с пользователем.
Контроллер обеспечивает программный интерфейс между Вью и Моделью.

Akopalipsis, Ваши трудности происходят из смешения двух противоречащих концепций, MVP и MVC. Вы цитируете взятое из MVC поведение тонкого контроллера, но при этом продолжаете мыслить контроллер как средоточие логики и класс, который всем заправляет. "Создавая сервис, контроллер должен..." — нафига контроллеру сервис? Вы покупаете кабель и к нему компьютер, или как? Контроллер принадлежит сервису. Он ЕГО контроллер. И это контроллер, не имеющий никакого отношения к контроллеру из MVC. Это личный склад Модели. Отношения Модели и сервиса не входят в парадигму MVC. Вы можете найти какие-то параллели, конечно, представить Модель как Вью для сервиса, или наоборот сервис как этакий Вью, поскольку от него что-то поступает и, если постораться, то через отдельный контроллер.. Но Модель не Вью. И сервис не Вью. MVC просто О ДРУГОМ. Никто же никогда не говорил, что MVC описывает ВСЁ приложение в деталях, каждое отношение во всей программе. От таких мыслей Вы дойдете до того, что "контроллер создает Модель и Вью" и прочей ереси, неизбежной, когда "есть только контроллер, вью и модель". Они все независимы. В этом парадигма MVC. Никто из них не может создавать другого, это приведет к жесткой связанности через импортирование конкретного класса.

К сожалению, ничего дельного по MVC еще не читал. Я просто ярый перестраховщик/универсализатор/рационализатор/оптимизатор. Иногда могу себя в такие дебри загнать, что... Уже не раз ловил себя на мысли, что к своему универсальному инициализатору я собираюсь писать инициализатор :( И слава богу, если к нему не прийдется такой же писать.

Метания с дробовиком я, если честно, вообще не понял.
Он стреляет когда?
Откуда эта идея, что "стреляет модель"? Стреляет юзер! После выстрела дробовик перезаряжается (во вью) и юзер НЕ МОЖЕТ выстрелить в этот момент. Какая разница, сколько времени длится перезарядка? Юзер сможет снова выстрелить, только когда она закончится. Так при чем тут модель? С какого перепугу она-то должна стрелять, пока юзер не нажал "выстрел"? А он не может нажать, пока идет перезарядка. Модели даже знать не надо таких параметров как скорострельность и т.п., она просто получает от контроллера "юзер нажал выстрел" и считает последствия, меняет кол-во патронов в обойме и считает нанесенный ущерб. Это ДАННЫЕ. А остальное — забота вьюхи. Да. "Может ли вот сейчас выстрелить дробовик" это забота вьюхи. Все что ей надо для этого от модели — это кол-во патронов.
Что я думаю не так?

Akopalipsis,

1. Модель ничего не должна определять, она сухо указывает, что убит монстр, осталось - 0.
2. Контроллер решает, что 0 монстров - это "конец" и заканчивает игру в модели (модель высылает событие завершения)
3. Тут вью тихо ловит событие завершения - выгружает свой визуализатор уровня.
4. Контроллер открывает главное меню во вьювере на прямую и работает с ним. Модель не должна содержать информаций о текущем экране меню, если в этом нет непосредственной необходимости. (Момент вполне может показаться спорным, но к такому выводу я однажды пришёл и готов подискутировать на эту тему)

Tails, Вы только сбиваете Akopalipsisа своим толстым контроллером. Да и топик-стартера тоже (он же в самом начале писал о том, что работает именно над схемой с тонким контроллером).
Ваш второй пункт можно смело засунуть в первый: Модель решает, что 0 монстров - это "конец" и заканчивает игру в модели (модель высылает событие завершения).
Про меню (п4) мне лично тоже интересно. Я пытался как-то сделать через "модель состояний" внутри модели, но получалось очень криво, аж медиаторы начали выглядывать из-за деревьев и призывно махать ручками, а я их очень не хотел.

Я тут мимо проходил и сильно тему не читал – не осилил.
Хочу накинуть такую тему: стреляли по кружочкам, а потом геймдизайнер сказал – вместо кружков воткнуть параллелограмм! Проблемы нет, только придётся менять как модель, так и вью.

Я за то, чтобы не болеть фанатизмом: в примере стрельбы по кружкам вью вполне себе сама может определить попал-не попал.

В общем я пришёл к выводу, что пора уже открыть книгу и почитать. Открыл, читаю, могу сказать так - что пока не дочитаю не буду вообще на эту тему рассуждать...
Wolsh Вам огромное Спасибо! ТС - обязательно читайте книгу. Там вообще всё не как я до этого на форуме читал...

Akopalipsis, по MVC в AS3 советую прочитать в этой книжке

Полностью поддерживаю (правда читал на русском)).