VооDоо,
То что менеджер соединяет все в целое и только он знает всех, это некий теоретический идеал на практике не совсем так, особенно для небольших проектов.
У вас в коде не совсем проявлены сущности, например переменная
score это глобальная переменная игры, почему она глобальная, если я правильно понимаю она должна быть в Модели, дальше
state это менеджер, которому известно об этой переменной? А нужно ли менеджеру напрямую знать об этой переменной? Какие задачи тогда у менеджера? Можем ли мы частично передать задачи менеджера модели, или визуализации? Или будем строго осуществлять взаимодействие Модели с Визуализацией через менеджера? Все это вопросы структуры программы, на которые лучше ответить до написания самого кода. Я бы к разработке игры дурака подошел так, есть три больших сущности Визуализация, Контроллер, и Модель, Визуализация должна уметь, 1. отображать начальное меню, где пользователь сможет задать некоторые настройки, например сколько игроков, какая колода 52 или 36, ну и любые другие. 2. Ситуацию игры за столом. 3. итоги игры. Далее Контроллер, должен сообщать(ответ) визуализации что отображать, и принимать(запрос) от пользователя через кнопки визуализации действия, события. То есть Визуализация ни чего не знает о Контроллере, лишь то что у неё на кнопках весят методы Контроллера, то есть пользователь по сути общается с Контроллером. При начальной загрузке, onload, контроллер как то должен понять что начало игры, и сказать Визуализации отобрази начальное меню, далее пользователь что то вводит, например 100 игроков, и нажимает начать игру. Контроллер принимает входные данные, тут надо решить кто будет проверять на соответствие входные данные, и сообщит что например что 100 игроков это много, может в самой визуализации уже будут стоять ограничения на вводимые данные, или контроллер, или модель, я бы все игровые моменты предоставил обрабатывать Модели, соответствие формату данных Контроллеру. Например если пользователь введет в поле количество игроков текст не число тут контроллер на такой запрос сообщает что бы визуализация отобразила ошибку, а количество игроков пусть обрабатывает Модель, вдруг у неё колода из миллиона карт. Дальше Контроллер не должен знать Модель вообще, какая там колода, какие игроки, какой бот, он должен знать только программный интерфейс Модели, который она предоставляет для взаимодействия с ней. Например получил Контроллер запрос от игрока СтартГаме(4 игрока), отправляет его Модели, Модель отвечает все норм, столько то карт роздано, козырь такой, у игрока который пользователь карты такие, ход его, Контроллер говорит Визуализации скрыть стартовое меню, отобразить игровой стол с такими то игроками, с такими то возможными действиями пользователя, Пользователь делает действие, посылая запрос контроллеру, контроллер проверяет соответствует ли действие формату, так как если на РНР пишем программу, какойнить хакер, вместо действия может отправить запрос совсем иного рода, вобщем Контроллер передал действие Модели, модель смотрит какой игрок должен ответить, смотрит дальше если игрок не пользователь, сообщает, ситуацию боту, причем бота достаточно одного на всех игроков, его задача принимать ситуацию и давать на неё ответ, ответ записывается в действие игрока, новая ситуация за столом передается от Модели Контроллеру, и он Передает её Визуализации, Пользователь смотрит принимает действие, и так по кругу.
Вот как то так я это вижу, суть в том что во первых я максимально абстрактно описал, структуру программы, не зависимо от языка, или фреймворков. Во вторых, одна сущность взаимодействует с другой, не на прямую меняя её переменные, переменные сущности это её личное дела, а через предоставляемый ею интерфейс. В общем глобальные переменные для структуры MVC как мне кажется не хорошо, ваша глобальная переменная игры score если её можно отнести к какой то сущности то лучше так и сделать.
Так же может вам будет интересно почитать
MVC для веб
И видео
Архитектура и проектирование ПО