Враг / бот А.И. часть модели или контроллера в игре MVC

Question

Это может быть частью модели, потому что это часть бизнес-логики игры.

Это может быть частью контроллера, потому что он может рассматриваться как имитирующий ввод игрока, который будет считаться частью контроллера, верно? Или это будет?

А как насчет нормального врага, такого как гумба в Марио?

ОБНОВЛЕНИЕ: Вау, это действительно не тот ответ, который я ожидал. Насколько я могу судить, А.И. является внутренней частью автономной игровой системы, отсюда и модель. Я до сих пор не убежден.

Answer 1

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

Если вы обнаружите, что пытаетесь «подогнать» проблему к шаблону, это, вероятно, неправильный шаблон. Используйте MVC для пользовательского интерфейса - используйте другие шаблоны (Message Bus или Observer / Listener и т. Д.) Или другие методы OO для AI (@Bill the Lizard предлагает стратегию по-прежнему).

Используйте весь свой набор инструментов, а не только молоток. ; -)

Answer 2

Вражеский ИИ имеет модель - его интеллектуальные внутренности, которые определяют, как играть в игру - и он использует контроллеры , доступные как для игроков-людей, так и для NPC, чтобы манипулировать его состоянием в игровая среда.

Answer 3

Подумайте о такой простой игре, как крестики-нолики, в которой вы хотели бы играть с различными уровнями сложности компьютера. Если вы сделаете каждый уровень сложности Стратегией , то легко реализовать различные реализации.

Answer 4

Помните, что изначально MVC был чисто архитектурным шаблоном GUI. Поэтому неудивительно, что он плохо сопоставляется с ИИ, сетью или чем-то еще. Но есть все еще некоторые преимущества использования здесь. Но то, чего достигает код, не так важно, как то, где он находится в цепочке. То, что что-то выглядит как внутреннее, не означает, что оно есть, и поэтому не должно учитываться как таковое.

например. Если вы пишете бота, высока вероятность того, что вы будете просто писать сценарии для манипулирования персонажами. Таким образом, в этом смысле интерфейс сценария является уже существующим контроллером, и ваши сценарии совершенно не зависят от этого. Вы даже не подходите близко к Модели, чтобы написать этот AI высокого уровня.

Теперь, если бы вы были первоначальным программистом, который должен был написать функциональность ИИ низкого уровня, которая запускается либо взаимодействием с игроком (например, щелкая где-нибудь, чтобы начать там ходить), либо скриптом в стиле бота, то вы бы писал это в Модель.

Может показаться неинтуитивным иметь какую-то единую концепцию, такую ​​как «ИИ», охватывающую весь путь от модели, через контроллер и вплоть до того, кто или что-либо манипулирует контроллером, но так оно и происходит, когда вы пытаетесь отобразить 2 очень разные понятия друг на друга. Это очевидно, когда вы смотрите на это с точки зрения разработчика, пытающегося представить те же интерфейсы для неигровых персонажей, что и для персонажей-игроков - в конечном итоге ИИ должен включать в себя как принятие решений на высоком уровне, так и актер за пределами система создаст, в дополнение к низкоуровневой реализации, которая обычно существует как для игроков, так и для не игроков в системе.

Answer 5

модель искусственного интеллекта противника должна знать правила игры и изменять свое внутреннее состояние в соответствии с этими правилами. Игровые контроллеры предоставляют ИИ информацию о состоянии внешней игры, которую он может использовать, чтобы решить, как ему следует изменить свое внутреннее состояние.

(То, что я впервые написал здесь:)

Часть ИИ, которая взаимодействует с игровым миром, будет в контроллере. Часть ИИ, которая принимает решения в качестве автономного агента, будет в модели. Контроллер обновляет модель ИИ в том состоянии, на котором он должен основывать свои решения, и контроллер также модифицирует игру и отображает представление на основе любых изменений в модели ИИ.

Для Goomba игровой контроллер обновит модель Goomba, указав местоположение Марио (если оно будет видно), а модель Goomba обновит себя относительно того, куда она собирается двигаться. Затем контроллер будет перемещать Goomba (то есть обновлять местоположение модели), если нет никаких препятствий, и визуализировать вид с новым состоянием Goomba.

Answer 6

Мне кажется, что он симулирует игрока-человека, поэтому он должен находиться в той же позиции, что и игрок-человек. Итак, это внешний элемент, который взаимодействует с контроллером. (По очевидным причинам, дисплей на самом деле не нужен для этого.)

РЕДАКТИРОВАТЬ: На самом деле, я беру это обратно. У него будет дисплей, просто не читаемый человеком. «Дисплей» будет отвечать за передачу информации о состоянии игры AI, даже если это означает потоковую передачу сериализованных данных на него.

Часть 2: О, я понимаю ... Это не совсем тот тип ИИ, о котором я думал. Я полагаю, что он все еще может быть обработан таким же образом, но тогда это заставит новые функции быть открытыми в контроллере, что может не иметь смысла. (Например, контроллер должен выставлять движущиеся как юниты игроков, так и юниты компьютеров.)

Я бы описал поведение в модели:

Goomba.move()
{
    /* Move Goomba forward one unit. */
}

И затем вызовы этого поведения идут в контроллере.

Controller.advanceTime()
{
    foreach(Goomba goomba in state.getGoombas())
    {
        goomba.move();
    }
}

Answer 7

Ни. Я бы запрограммировал ИИ как независимого агента, связывающегося с моделью через контроллер. Или, если хотите, AI - это модель A , но не модель .

Answer 8

По моему мнению, в любой реализации MVC модель должна содержать доменную логику - всякий раз, когда она является автономным объектом (логика встроена в методы) или оболочкой потока сокетов (где логика выполняется через внешний ресурс - да, думаю про мультиплеер). Контроллер должен использоваться как вызывающий / обработчик модели на основе некоторых внешних переменных (например, параметров CLI, диспетчера событий). А затем верните необходимые данные (в виде массива, сериализованных переменных или какого-либо объекта передачи данных) в соответствующий вид (игровой экран, консольный терминал).

Ура, Алан

Answer 9

Я не уверен, где он будет вписываться в MVC. Этот псевдокод является чрезвычайно упрощенной версией того, как я сделал AI для поиска пути.

sprite {
  x,y
  image // this object contains everything about drawing
  path[] // an array of path nodes generated by my AI
  onNode(node) {
    if (x == node.x) && (y == node.y) return true
    return false
  }
  update () {
    moveto(path.last())
    if (onNode(path.last())) path.pop()
    if (path.empty()) path = doAI()
  }
  doAI() {
    ...
    return newPath
  }
  moveto(node) {
    ...
  }
  draw (screen) {
    if (screen.over(x, y)) image.draw(x-screen.x, y-screen.y)
  }
}

screen = //something the platform would create
spriteCollection = //my game objects

foreach (sprite in spriteCollection) {
  sprite.update()
  sprite.draw(screen)
}