OpenMortal AI Design

Table of Contents

• 1. Introduction
  • 1.1. Purpose of this Document
  • 1.2. Revision History
  • 1.3. Definitions
  • 1.4. Related Reading
• 2. Requirements
• 3. Algorithms
  • 3.1. Decision Making
  • 3.2. Decision Execution
• 4. Implementation

1. Introduction

1.1. Purpose of this Document

This document describes the methods used in the OpenMortal artificial intelligence (AI). The AI is designed to play the game as any of the playable OpenMortal charaters, and can be used for demos or a single-player game.

1.2. Revision History

1.3. Definitions

1.4. Related Reading

This document assumes knowledge of the Toplevel Design, and the basic working of Doodads and Fighters (described in the scripts Doodad.pl and Fighter.pl)

2. Requirements

The AI needs to comply with the following requirements:

1. Controllable difficulty. Ideally, the AI playing against a human opponent would start out easy, so that even beginners can win a round or two. Then the AI should get gradually harder to beat, to pose a challenge to experienced players. Only the most skilled players should be able to beat the AI at its harders level.
2. Diverse actions. The AI must be able to use every capability of the character, even its most useless skills. The AI must also use different tactics (kneeling, jumping, blocking, evading, etc)
3. Randomness. To the same situation the AI must not always respond in the same manner.
4. Speed. The AI must be able to make its choices fast in terms or processor speed. The game must not lag at any time because of the AI calculating its next move. This isn't chess.

3. Algorithms

The AI incorporates two distict steps: decision making and decision execution.

Decision making is not specific to any character (can perhaps be fine-tuned to suit individual characters, but this is unnecessary). It takes the current situation, represented by the Perl backend's internal state (Fighters' states, Doodads, etc), converts them to fuzzy variables (such as Distance and ThreatLevel), and comes up with a Decision.

The Decision is then fed to the decision execution, the second algorithm. This one has very good knowledge of the character's capabilities, and will carry out the decision based on this information.

3.1. Decision Making

Definitions

DangerZone :- ( HorizontalRange, ThreatHeight, DeltaT, Cause (Fighter/Doodad) )

Variables

Distance: VeryNear, Near, OutOfReach, Far, VeryFar (beyond jumpkick range), BehindMe

Position: Kneeling, Standing

ThreatLevel: RedAlert (will be in DangerZone "real soon"), YellowAlert (will be in DangerZone, but still have time), GreenAlert (will be in danger zone, but still plenty of time), BlueAlert (no threat)

ThreatHeight: AboveHead (mustn't jump), Middle (can be avoided by kneeling), Low (can be avoided by jumping)

ThreadSource: Fighter, Doodad

Decision: Wait, Block, Attack, JumpUp, JumpForward, JumpBackward, WalkForward, WalkBackward, KneelDown, StandUp, Attack, Projectile

Sample implications

[...]

3.2. Decision Execution

4. Implementation