Это может помочь вам представить модель как своего рода игровой API. К чему бы сводилась ваша игра, если бы для игры, назначенной с самого начала, вообще не было пользовательского интерфейса? Вы упоминаете, что вы имеете в виду РПГ, поэтому в этом случае вы можете представить, что персонаж модели, его / ее инвентарь, заклинания, способности, неигровые персонажи и даже такие вещи, как карта и правила боя, являются частью модели. , Это подобно правилам и частям Монополии без специфики того, как финальная игра отображает это или как пользователь будет взаимодействовать с ней. Это похоже на Quake как абстрактный набор трехмерных объектов, движущихся по уровню с вычисленными вещами, такими как пересечение и столкновение, но без рендеринга, теней или звуковых эффектов.
Помещая все это в модель, сама игра теперь не зависит от пользовательского интерфейса. Он может быть подключен к текстовому интерфейсу ASCII, как в играх Rogue, или к интерфейсу командной строки, похожему на Zork, или к веб-интерфейсу или к 3D-интерфейсу. Некоторые из этих интерфейсов могут быть ужасно приспособлены в зависимости от игровой механики, но все они будут возможны.
Уровень просмотра является зависимым от интерфейса уровнем. Он отражает конкретный выбор пользовательского интерфейса, с которым вы работали, и будет в значительной степени посвящен этой технологии. Он может быть ответственным за чтение состояния модели и отображение его в 3D, ASCII или изображениях и HTML для веб-страницы. Он также отвечает за отображение любых механизмов управления, которые игрок должен использовать для взаимодействия с игрой.
Слой контроллера - это клей между ними. Он никогда не должен содержать никакой реальной игровой логики, и при этом он не должен отвечать за управление слоем View. Вместо этого он должен преобразовывать действия, предпринимаемые в слое «Просмотр» (нажатие кнопок, нажатие на области экрана, действия джойстика и т. Д.), В действия, выполняемые с моделью. Например, сброс предмета, нападение на NPC, что угодно. Он также отвечает за сбор данных и выполнение любого преобразования или обработки, чтобы слой View мог легче их отображать.
Теперь, как я описал это выше, как будто есть очень четкая последовательность событий, управляющая игрой, которая, вероятно, действительно подходит только для веб-игры. Это потому, что на это я потратил свое время в последнее время. В игре, которая не управляется запросом пользователя и ответом сервера, таким как сеть (например, игра, запущенная на компьютере пользователя), вы, вероятно, захотите убедиться, что на уровне модели хорошо реализован шаблон Observer. Например, если действия выполняются в модели из-за того, что время идет, вы можете не захотеть, чтобы слой «Вид» постоянно опрашивал модель на предмет обновлений. Вместо этого, используя шаблон Observer, Модель может уведомлять любых наблюдателей об изменениях объектов Модели по мере их возникновения. Это, в свою очередь, может быть использовано для немедленного обновления представления, чтобы отразить изменение.
Тогда, если 60 секунд прохождения привели к некоторому ремонту базы игрока, база может произвести ремонт и немедленно уведомить всех прикрепленных к ней наблюдателей, что база обновлена. Вид может быть присоединен в качестве наблюдателя, и имейте в виду, что ему необходимо повторно отобразить базу, поскольку ее состояние изменилось. В самом уведомлении могло содержаться достаточно информации для обновления представления, или ему может потребоваться развернуться и обратиться к модели для обновления, но результат будет таким же.