X3 Reunion

From AIGPG Wiki
Revision as of 07:21, 16 July 2011 by Dave Mark (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


X3 Reunion
X3 - Reunion Coverart.png
Developer: Egosoft GmbH
Publisher: Deep Silver, Enlight, Linux Game Publishing, Steam
Year: 2005
Platforms: PC
Genre: Simulation, 4X
AI Era: Strategic

X3 Reunion is a single-player game developed by Egosoft GmbH centered around space exploration and empire-building in an open-ended environment. The motto of the X series of games is "Trade, Fight, Build, Think" - which perfectly captures the sorts of activity one is likely to participate in while playing the game. The simulation includes thousands of AI agents at various levels of detail, all acting autonomously to achieve their own assorted goals and missions within the game universe. Logic was implemented using a custom in-house byte-code compiled language called KC, and an additional domain-specific scripting language (referred to only as "the script engine") implemented on top of KC.

Contents

Description of AI Behavior

AI behavioral goals for X3 ranged from local traders swapping goods at various space stations, to full-scale battle fleets that would patrol the game universe looking for trouble. Agents could run scripts from a large library of different behavioral patterns. Additionally, two primary level of detail classes were implemented; many agents had full detail and ran complex behavior scripting, but the bulk of the ships in the game were simply filler running minimal state-machine-based routines.


Notable Behaviors

A major goal of the so-called "free trader" script mode in X3 was to provide agents who approximated the gameplay activities of human players, thereby providing competition for the player in the game's fully-simulated free market economy. This involved a comparatively rich knowledge representation of the local economic situation around a given agent, and sophisticated rules for handling various situations in the game. Players could also recruit free trader AI agents into their own empire, which enabled a set of features whereby the agent would "level up" and progress in skill and capacity much like a human player advancing through the game themselves.

Another highlight of X3's AI implementation was the selection of mission scripts implemented in KC, which would create dynamic and large-scale battle scenarios and other situations for the player to react to. A counterpart to the player-oriented missions was the "Global Decisions" or "GOD" module, which used hints placed throughout the game world by the designers to manipulate the game world on the fly. Such manipulations included creating and destroying space stations, generating invasion fleets, drastically crashing (or flooding) local economies, and so on.

One final important aspect of the AI in X3 was the sheer number of running agents. Fully-simulated agents numbered in the thousands in an average game, and several hundred more "filler" agents running the low-level-of-detail AI behaviors could be generated on the fly. This necessitated careful attention to level of detail and LOD transitions in order to maintain realtime performance on commodity PC hardware.


Architectures

KC Programming Language

This section is based on
first-hand knowledge
by AIGPG member,
Mike Lewis.
What does this mean?

KC was a custom byte-code compiled language developed by Egosoft. Its syntax roughly fell into the C family of languages, but it supported a limited object model and several other convenient abstractions for developing high-level game logic. Additionally, KC lacked raw pointers and reference types, instead referring to everything in the execution environment using 32-bit integer handles. An offline compiler processed the KC code for the game separately from the core game engine, which was implemented in a hybrid combination of C and C++. The C-based runtime for KC executed the bytecode stream as the engine ran, and marshaled data and function calls between the core engine and the KC logic layer, allowing limited but sufficient interoperation and communication across the engine/KC boundary.

One notable feature of KC was a simple asynchronous task execution system. Originally designed to run on single-core CPUs, the engine in the X series of games at that point in time was purely single-threaded. In order to manage the concurrent execution of thousands of AI agent scripts in the game simulation, Egosoft developed a time-slicing mechanism whereby each running task was allowed to perform a limited number of instructions each frame, or yield its timeslice to another task. Because KC was not truly multi-threaded or concurrent, the task system required minimal thread-safety-style infrastructure. Only one task executed at a time, so certain classes of shared-memory errors were impossible; however, tasks could be interrupted and continued across several frames or simulation ticks, so programmers had to be careful not to make assumptions about game state that might have been invalidated during a task's down-time. In general KC tasks were less error-prone and difficult to reason about than true threads, but substantially more complex and fragile than other approaches could have been.

The Script Engine

This section is based on
first-hand knowledge
by AIGPG member,
Mike Lewis.
What does this mean?

KC was used for game logic implementation as far back as X: Beyond the Frontier, the first title in the X series. (Indeed, it predated even the X series, although only in limited form.) Later on, the so-called "script engine" was introduced (in X2 The Threat) which built an additional domain-specific language on top of KC. This engine read XML-based script files from disk and converted them to a minimal series of integer opcodes in memory, which were then executed by a runtime environment implemented in KC. The script engine offered a small subset of KC's capabilities - most notably omitting the task-based asynchronous execution system - and exposed a simple syntax that could be used to write AI behaviors for the game.

The script engine included an in-game front-end that allowed curious players to view the built-in AI scripts and create modules of their own; this tool was immensely popular among the modding community and used to great effect. However, due to the layers of abstraction between these scripts and the game engine, great care was required to avoid creating nasty performance issues and memory wastage. While a substantial number of players experimented with the script engine, only a very small percentage ever became proficient in its workings, due largely to the fact that the internals were opaque, poorly documented, and heavily reliant on implementation quirks in KC itself, which was not available to the general public for experimentation or examination.

Level of Detail System

This section is based on
first-hand knowledge
by AIGPG member,
Mike Lewis.
What does this mean?

In order to accommodate thousands of active agents in the game world, X3 utilized a level of detail system. The game world was divided into relatively small "sectors", which were divided by "warp gates" that would teleport the player (or an AI agent) into an adjoining sector. Since the player was only physically present in one sector at a time, simulation for all other sectors in the game could be reduced to a minimal level of detail. This was internally referred to as "in sector" and "out of sector" situations.

In the out-of-sector case, physics was not simulated, flight pathing and steering were disabled in favor of simple linear interpolation, combat mechanics were simplified via heuristics, and AI tasks would yield their KC timeslices more often. The net result was that the vast majority of the game simulation could be carried out at very low computational cost.

When transitioning from the out-of-sector to in-sector mode, only a minimal amount of work was done to restore the simulation to a high level of detail state. Essentially, the positions of moving ships were linearly interpolated to update them to their current simulation tick, and then a quick check was made to ensure that objects did not interpenetrate. In the case where objects had collided in the low-level-of-detail state (which was not detected, as physics was not simulated) one object was randomly chosen as the "loser" and teleported into a random nearby area instead of its originally calculated location. This could result in nondeterministic behavior of the simulation when rapidly entering and leaving a densely crowded region of space, a phenomenon widely noted and largely disliked by the community.

Flight Physics

This section is based on
first-hand knowledge
by AIGPG member,
Mike Lewis.
What does this mean?

X3 introduced a semi-Newtonian flight mechanics model, whereby space ships had limited inertial characteristics. Unlike previous X games, where ships moved in a more "arcade style" model, ships in X3 could drift, fly backwards, and perform other interesting maneuvers by exploiting the physics of the game world.

This was implemented using a simple Newtonian model of damped inertia, whereby a ship's momentum was numerically integrated over the past several seconds, and the influence of momentum decayed over time. The result was fairly intuitive to control (unlike purely Newtonian vacuum models) and yet offered a difficult-to-master depth that offered unique challenges for players.

Unfortunately, it also offered a difficult challenge for the AI; indeed, even after several post-ship refinements, the AI never did behave particularly intelligently in the presence of the new physics model. For the most part, ships would fail to anticipate the effects of the inertia system, and therefore were somewhat easy to "fool" into wasting time correcting for their own momentum after overshooting a target. To bypass some of the difficulty of predicting flight paths in this physics model, when precise maneuvers were required (such as when docking with a space station) the AI would silently disable the inertia for itself and use animation tricks to conceal its altered behavior.

Reception by Public

Although generally regarded as successful, X3 as it shipped was initially plagued by bugs, performance issues, and incomplete features. Over time, Egosoft patched the game with exceptional after-release support, including numerous free expansions to the game content. The general consensus among the community was that the game was solid after several major patches, but as initially released was almost disastrously flawed. Critical reviews generally only examined the initial release, and were justifiably harsh, although a few notable reviewers were willing to overlook the glaring issues in the 1.0 release in light of Egosoft's past track record of after-release support and maintenance.

Although technically fairly sophisticated, the AI as perceived by the average player was generally found lacking. Disparaging nicknames for the game's "autopilot" feature became quickly popularized on the Egosoft message forums, and the poor collision avoidance (due to the inertial physics model) was the butt of plenty more jokes around the Internet. Despite the shortcomings of the game, however, X3 retains a small but fiercely loyal following of players.

References

(TODO)


External Links

Personal tools