Is enemy / bot A.I. part of the model or controller in an MVC game

Question

It could be part of the model because it's part of the business logic of the game.

It could be part of the controller because it could be seen as simulating player input, which would be considered part of the controller, right? Or would it?

What about a normal enemy, like a goomba in Mario?

UPDATE: Wow, that's really not the answer I was expecting. As far as I could tell, A.I. is an internal part of the autonomous game system, hence model. I'm still not convinced.

Answer 1

It seems to me like it's simulating a human player, thus it should be at the same position a human player is. So, it's an external element that interacts with the controller. (For obvious reasons, a display isn't really necessary for it.)

EDIT: Actually, I take that back. It will have a display, just not a human-readable one. The "display" will be responsible for communicating game-state information to the AI, even if that means streaming serialized data to it.

Part 2: Oh, I see... That's not quite the same type of AI as I was thinking of. I suppose it could still be handled the same way, but then that would force new functionality to be exposed in the controller that might not make sense. (For instance, the controller would have to expose moving both the players' units and the computers' units.)

I would put the behaviour in the model:

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

And then the invocations of that behaviour go in the controller.

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

Answer 2

Think of a simple game like tic-tac-toe where you would want different computer difficulty levels to play against. If you make each difficulty level a Strategy, it's easy to drop in different implementations.

Answer 3

The enemy AI has a model - its intelligent innards that specify how to play the game - and it uses the controllers available to both human players and NPCs to manipulate its state in the game environment.

Answer 4

the enemy AI model would have knowledge of the game's rules and change its internal state according to those rules. The game controller(s) provide the AI with knowledge of the external game's state that it can use to decide how it should change its internal state.

(What I first wrote here:)

The part of the AI that interacts with the game world would be in the controller. The part of the AI that makes decisions as an autonomous agent would be in the model. The controller would update the AI's model with the state it needs to base its decisions on and the controller would also modify the game and render the view based on any changes in the AI model.

For a Goomba, the game controller would update the Goomba model with Mario's location (if it's in its sight) and the Goomba model would update itself as to where it intends to move. The controller would then move the Goomba (i.e., update the model's location) if there aren't any obstacles and render the view with the Goomba's new state.

Answer 5

MVC works very well as an architecture for a large number of applications. Some applications may find that MVC works well for the external interfaces, especially User Interfaces as part of a more complex architecture.

If you find yourself trying to "force fit" a problem into a pattern, it probably isn't the right pattern. Use MVC for the UI - use other patterns (Message Bus, or Observer/Listener, etc...) or other OO techniques for the AI (@Bill the Lizard's suggestion of Strategy still applies).

Use your entire toolbox - not just the hammer. ;-)

Answer 6

I am not sure where it would fit into MVC. This psudo code is an extremely simplified version of how I have done A* path finding AIs.

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)
}

Answer 7

Hi

In my opinion, in any MVC implementation, model should hold domain logic - whenever it is autonomic object (logic is stiched-in inside the methods) or socket-stream wrapper (where logic is performed via external resource - yes, think about multiplayer). Controller should be used as caller/handler of model based on some outside variables (e.g. CLI parameters, event dispatcher). And then return required data (as array, serialized vars or some kind of Data Transfer Object) to the proper view (gamescreen, console terminal).

Cheers, Alan

Answer 8

Neither. I would program an AI as an independant agent communicating with the model via the controller. Or if you like, the AI is A model, but not the model.

Answer 9

Remember that MVC was originally purely a GUI architectural pattern. So it is of no surprise that it doesn't map well to AI, networking, or whatever. But there are still some benefits to using it here. But what the code achieves is not as important as where it sits in the chain. Just because something looks like it's internal, doesn't mean that it is, and therefore shouldn't be counted as such.

eg. If you're writing a bot, chances are high that you will essentially just be writing scripts to manipulate the characters. So in that sense, the script interface is the pre-existing Controller, and your scripts are completely external to that. You don't even go anywhere near the Model to write that high level AI..

Now if you were the original programmer, who had to write low level AI functionality, which is triggered off either by player interaction (eg. clicking somewhere to start walking there) or by a bot-style script, then you would have been writing that into the Model.

It may seem unintuitive to have any single concept such as 'AI' span all the way from model, through controller, and right out to whoever or whatever manipulates the controller, but that's how it goes when you attempt to map 2 very different concepts onto each other. It is obvious when you look at it from the perspective of a developer trying to present the same interfaces for non-player characters as they do for player-characters - ultimately the AI has to comprise both the high level decision making that an actor outside of the system would make, in addition to the low level implementation that typically exists for both players and non-players within the system.