We've spoken a great deal in interviews and other articles about just how excited we are about Jumpgate Evolution's AI system. It has rapidly gone from being a system intended to solve one or two things, to becoming the tool of choice to address all sorts of interrelated game issues. Although we try to maintain perspective and recognize that employing the AI system is not always the proper solution to a problem, this is truly a case where the excited kid inside each of us tends to burst out and enthuse, "We can make the AI do that! Wouldn't that be great?" It's simply the case that our AI system is turning out to be very capable and versatile, so it's extremely tempting to make quite extensive use of it.

We began simply, with the AI system's chief task being to populate space. The plan was to make large numbers of AI ships that would travel around the game, performing real tasks in real ways, using a list of available behaviors and incorporating forms of mutual communication. To begin realizing this design, we considered the basic tasks that every player must employ simply to fly her ship around the Jumpgate game universe. Each possible role, be it hauling, mining, piracy, or whatever, was considered in terms of both its unique behaviors and common activities. Each process became an algorithm. Each major type of AI bot, as defined by role, became a class. The behaviors themselves became polymorphic functions inherited by the role-based classes from more generic parent classes, such as "mobile bots" or "stationary bots". As an example, nearly all mobile bots inherit and use a "Travel" behavior, which manages the process of long-range navigation. Likewise, there are common "Dock", "Launch", "Jump", and "Avoid" utility behaviors employed by everything that must move.

The list of behaviors becomes extensive when considering the special activities of each possible role. As an example, a bot simulating a mining vessel will employ a combination of common and unique behaviors to accomplish its task. First, the bot will be created with member data that includes such things as its location and what kind of asteroid it must find to mine. The bot will physically launch as the final step of its creation process. Once the launch algorithm ends, the bot must perform a detection step to see if there are any viable targets in the area. Failing that, it may travel to another location, avoiding collisions with objects along the way, and possibly jumping to an entirely different sector of the game to continue its search. At some point, we will assume for this example that a target match is detected, so the bot will approach the chosen asteroid using a unique mining behavior. Other bots would naturally use a collision avoidance behavior in the vicinity of an asteroid or similar object, but the mining bot instead must cozy up to a rock to do its job. The bot will halt close enough to the asteroid to use its mining equipment, functionally handing off to another behavior that controls the mining process itself. During mining, the bot will perform additional transactions with the servers that handle its inventory changes, much like any player would. Once the bot determines its inventory is full, it will revert to a common travel behavior to some destination to deliver its cargo. Upon arrival at the destination facility, the bot will execute a docking behavior, transfer the ore from member data to the facility's inventory, and be removed from existence by the system.

As can be seen by the example life cycle of a mining bot, even a pretty typical AI object must be able to accomplish a significant number of different things to serve its purpose in the game. The example doesn't even include most of the decision-making variability in the process, nor does it include any interesting interruptions; it's just the dull life of a pretty normal bot.

Interruption events turn out to be the real spice of life for a bot's decision making process, and from the start the AI system was built to make them a centerpiece of its operation. With the exception of collision avoidance, all the interruption events thus far defined for the system either are triggered by, or result from, some form of bot-to-bot communication. Just as with the behaviors, we built a list of types of bot-to-bot interactions, which became a list of message types. The messages function like invitations, "Attack me", "Pirate me", "Help me", and so forth. Every type of bot places specific messages in dedicated regional communications queues. Some types of bots poll these queues at intervals, and if they find an appropriate message type, they pick up the message and change behavior in reaction. A typical example of these interactions looks like this: a hauler bot, representing a cargo ship, jumps in and posts "Attack me" on the local queue, and continues traveling across the sector. An aggressor bot in the sector, representing a hostile alien Conflux, polls the queue, picks up the "Attack me" message, and switches from loitering to a set of behaviors that cause it to locate, fly to, and engage the hauler. The hauler, now interrupted in its travel by the attack, posts a "Help me" message in another queue. A defender bot, representing a factional fighter on patrol, polls the help queue and picks up the hauler's message. It breaks from its patrol behavior and streaks to the aid of the hauler, possibly posting its own version of "Help me" for other defenders to pick up on, gathering a posse. By choosing appropriate values for different polling cycles, we've already seen very exciting, lifelike activity in basic proof-of-concept work on the system. Broad implementation for all cases, though, is not yet completed. We fully expect to continue fleshing out the AI system through release.

The ultimate purpose, however, isn't to create a nifty network of thousands of bots that effectively play the game for us. That would make a delightful AI experiment and does have use as an excellent load testing tool, but ends up doing little for gameplay. The true power of the system will hinge upon tying the already operational message and queueing system into interfaces that players themselves have access to, and bringing the universe to life in ways that let players participate. Ideally, routine player activity will post similar messages to the AI queues for bots to react to, and players will be able to passively or actively perform some kinds of polling actions themselves, with appropriate and equivalent information displays to help them react to and participate in what will have become spontaneous events originated by the AI. This is really what has the development team so terribly excited about the potential represented by Jumpgate Evolution's AI system.

While the basic interlinks between the players' UI and the bots' queues are a significant part of what remains to be implemented, we surely intend to have some of this vast potential realized by release. Imagine that, rather than the defender bot rescuing the hauler, instead the nearby players see a HUD indicator flash with a message: "This is Free Trader [i]Beowulf[/i], calling anybody... Mayday, Mayday.... "*

- Steve "Istvan" Hartmeyer, Programmer

*partial box quote from the original Traveler game, by Marc Miller, (c) 1977, Game Designers' Workshop.