Xenonauts A.I. - Introduction
Foreword
Welcome to the first in a series of posts on the A.I. implementation of Xenonauts, a game by GoldHawk Interactive! In this initial post I will outline the game itself, the requirements of the A.I. and the initial setup of my approach.
Xenonauts Introduction
For those of you not familiar with Xenonauts, I recommend a quick look at their website.
Essentially it is a remake of X-Com done by GoldHawk Interactive, an independent video game development studio based in Hackney, London.
Xenonauts is a game with 3 major aspects: Geoscape (Strategic), Air Combat (Tactical), Ground Combat (Tactical).
In this series, we will be focusing on development for the Ground Combat which is turn-based, squad-based combat.
The Requirements
As with almost all game projects nowadays, the deadline for finishing is extremely tight: by 9th of October we need to have a somewhat finished A.I. system which shows substantial improvement over the old system.
However, I am allowed to improve the system in place afterwards.
The implementation requirements presented are:
- The A.I. system in place needs to be moddable by the community; a Hierarchical Finite State Machine (HFSM) which is editable through XML is preferred.
- Support for alien units, friendly AI soldiers and civilians.
- Appropriate movement and pathfinding logic to achieve mission objectives.
- Intelligent interaction with the battlefield, including interaction with cover and avoiding dangerous battlefield elements / areas.
- Intelligent use of weapons and equipment and target prioritization for AI-controlled units.
- Shared sight and co-ordination across the AI teams.
- Use of alien “abilities” (such as psionic powers, teleportation, regeneration etc).
- Behavior differentiation between different races of alien units.
The light switch on your wall, for example, is a very simple finite state machine. It has two states: on and off. Transitions between states are made by the input of your finger.
Quake-style bots are implemented as finite state machines. They have states such as FindArmor, FindHealth, SeekCover, and RunAway. Source
Hierarchical Finite State Machine – Any state can be a substate of some larger state.
The Approach
The initial deadline leaves little room for error, thus mandating a system that is quick to setup.
However as I am allowed to improve the system after October 9th, the system we will be implementing will need to be designed with expansion in mind in terms of both feature-set and performance.
Furthermore, I need to implement a system that is in someway moddable by the community.
Because of this time frame, I will separate the implementation in three portions which I will design and implement in succession:
- Knowledge system and general pathfinding: I will start by constructing the underlying knowledge systems the A.I. uses in its decision making process, and answer the question: “How will I get where I want to go?”
- Goal selection for pathfinding: Using the knowledge systems I will then work on: “Where do I want to go?”
- Goal oriented action planning: i.e.: “What do I want to do, and in what order do I want to do it?”
Why this heavy emphasis on path finding and positioning? It’s simple: Any good tactician knows that a battle is won or lost by positioning.
It will also be the main area where players will find the A.I. doing either stupendously stupid, or outrageously brilliant things.
In the current game A.I. landscape, the (H)FSM is king, as they can be both relatively easy to implement and straightforward to design.
The popular use of a HFSM is to a define series of static behaviors which describe a current goal.
Essentially the HFSM IS the A.I. as it dictates what the target must do, when the target must do it, and how it must be done.
The HSFM itself then reads as a simple script of conditions with associated actions; a script you need no technical background to design. The downside is that this “script” can become bloated because it lacks expressive power (You need to formulate each and every aspect of behavior), and can’t adapt to situations not described in the script.
Why is this approach so popular then you ask? Because it is one of only few that works when the game industry (sadly) demands a clear separation between Game Design and A.I. Engineering.
Luckily indie development studios do not have big budgets, so I’m allowed to both design and implement the A.I.!
I will then try to find a middle ground in this; in my design the HFSM will only be allowed to stipulate the higher-level goals the A.I. will be trying to satisfy.
There will be a clear separation between the systems that stipulate what must be done; and how it must be done.
That’s it for today; this series is continued in: Xenonauts A.I. – Knowledge Systems pt. 1
