- Give each monster an attribute
goal which is one of ignore, follow, attack, or flee.
- A monster with the
ignore goal never tries to attack the player. They generate an action at random as usual; if they attempt to move into a space occupied by the player, the action fails; it is not converted into an attack.
- A monster with the
follow goal attempts to walk in the direction of the player and similarly does not attempt to attack.
- A monster with the
attack goal checks if the player is within attack distance and attacks the player. Inform the player via some div that they're being attacked, and the outcome of that attack. If not within attack distance, it moves towards the player.
- A monster with the
flee goal attempts to move away from the player; if there is no way to move away and the player is within attack range, they attack. That is, a fleeing monster "backed into a corner" will fight.
I mentioned before that games are essentially "state machines". They have a start state, they take inputs, inputs are evaluated in the context of the current state, and cause updates to state. State machines are often composed of many smaller state machines, and this is a good example. Monster goal is a state machine, and the inputs are the things that happen to the monster.
For example, you might have a hostile orc that begins existence in attack mode. Once in combat, if its hit points fall below half maximum, it switches to flee. You might have a giant killer bee that begins in ignore mode but switches to attack if a player gets too close. Or you might have a friendly dog that follows the player around.
A possible enhancement to the player-vs-monster combat system is: instead of automatically converting movement towards a cell occupied by a monster into an attack, check to see if the monster is in ignore or follow mode, and produce an do you want to attack? Y/N message. Accidentally attacking a powerful monster that is ignoring you, or worse, kicking a friendly dog, are things the player wants to avoid.
goalwhich is one ofignore,follow,attack, orflee.ignoregoal never tries to attack the player. They generate an action at random as usual; if they attempt to move into a space occupied by the player, the action fails; it is not converted into an attack.followgoal attempts to walk in the direction of the player and similarly does not attempt to attack.attackgoal checks if the player is within attack distance and attacks the player. Inform the player via somedivthat they're being attacked, and the outcome of that attack. If not within attack distance, it moves towards the player.fleegoal attempts to move away from the player; if there is no way to move away and the player is within attack range, they attack. That is, a fleeing monster "backed into a corner" will fight.I mentioned before that games are essentially "state machines". They have a start state, they take inputs, inputs are evaluated in the context of the current state, and cause updates to state. State machines are often composed of many smaller state machines, and this is a good example. Monster goal is a state machine, and the inputs are the things that happen to the monster.
For example, you might have a hostile orc that begins existence in
attackmode. Once in combat, if its hit points fall below half maximum, it switches toflee. You might have a giant killer bee that begins inignoremode but switches toattackif a player gets too close. Or you might have a friendly dog that follows the player around.A possible enhancement to the player-vs-monster combat system is: instead of automatically converting movement towards a cell occupied by a monster into an attack, check to see if the monster is in
ignoreorfollowmode, and produce ando you want to attack? Y/Nmessage. Accidentally attacking a powerful monster that is ignoring you, or worse, kicking a friendly dog, are things the player wants to avoid.