Jumpgate Evolution - AI

SAL-9000: “Will I dream?”

Dr. Chandra: “Of course you will. All intelligent beings dream. Nobody knows why.”

I can distinctly remember this scene from 2010; and it is a most amazing moment in a Science Fiction movie, I find. Amazing not only because it shows some kind of sentience in a machine (we got plenty of that in 2001), but because of the response. Nobody knows why. When you consider how things in games work, that mantra comes up over and over again. Most things in games are the result of nobody knowing why. Why is that wonderful thing that happens when all the pieces come together and things just seem to work. It’s a moment we all work for. It’s a moment we all hope for. It’s what games are all about.

 advertisement 

<a href="http://www.gameads.com/" target=_blank>Game Ads</a> banner requires iframes.

Let me back up a few paces and go over why we thought AI was necessary in Jumpgate Evolution. The obvious reason is that you need to have stuff for players to do. One of those things is to blow things up. In order for blowing those things up to be interesting they must behave in some kind of predictable or unpredictable way. They need to fly, shoot, miss, hit and vary in difficulty. All of this is pretty much expected at this point. But we wanted a bit more than that.

Our chief goal when thinking about AI for Jumpgate Evolution is to use it to help create a believable and emotional universe. These are very important features of games. Players want to believe, they want to feel that they are in your world; and any opportunity you can give them to enforce that will always be appreciated. So we began the task of figuring out the bits and pieces that make for a believable space universe. The ironic thing is that it wasn’t that hard to make the list. All you have to do is come up with a list of stuff you want to do in space: fight, mine, trade, transport, patrol, explore – those are the major ones anyway. Since those are things players can do, they should also be things that non-players should be able to do.

With these basic goals in mind, our AI programmer, Darren, went to work on some basic architecture. We decided early on that AI would run as its own dedicated server. This is not uncommon in the MMO space as you want to be able to scale hardware demands based on player activity. Then we set about deciding what is needed to define an AI element. Since we are a space game, they need to come from somewhere (launch from a station, spawn from a “vortex” (i.e. appear in mid air) etc. They also needed to fly around in various ways so we put together a database to define their ships attributes and equipment.

The next step was to give them behaviors. For example, if you want something to “patrol” then it needs to have a series of destination points and ways of figuring out how to get there. This kind of functionality can be reused over and over again as well. If something was going to fight it needed to have a sense of what is hostile and what is friendly, evaluate whether to attack or not, when it runs away, etc., so we made up values for those things. These are all pretty much straight forward AI things as well. You have a set of rules and behaviors and set the things into motion and watch them work their magic.

We did, however, take an additional step in that we added things that allowed the AI to respond to things that were happening in the game world. The example I always use is the station in sector X being low on carbon for some weapon that it wants to build (based on its production queue). So the station broadcasts “Hi! I need carbon! Oh, won’t someone please give me some carbon?” Some other station in some other sector can then check its carbon supply and, sure enough, it has a surplus. Now, it’s possible that players could buy the carbon, fly it over to sector X and make some money. However, it’s also possible for the AI server to generate a hauler, fill it with carbon, chart a course to the sector (either the quickest path, safest path or some mix) and then start its journey. Deep in the heart of sector Y is a group of pilots that are patrolling around. When this hauler jumps in, they might decide “Wow. Look at that big fat hauler flying around all undefended, let’s get it!” So they decide they are going to attack. The hauler, of course, may then call for help to which some nice a friendly defense drones may reply and a big fun battle ensues! These are the kinds of things we want to have happen. The next step is to allow players to interact with these events. So if the besieged hauler asks for help it would be fun if the player could respond and then go take out the pirates and collect some reward.

The final step in this experience is to communicate the state to the players. For example, when a hauler is docking, having a nice sound play that it’s requesting permission to dock. If a hauler is under attack have it radio you for help and ask for it. Those are the kinds of things that help sell the believability more – and that is what you really want, isn’t it? It is not particularly useful to have all this cool stuff going on and then the player is robbed of the full experience.

In the end there are thousands of little things that go into it and I hope that my description is not too watered down to be useful. When all those things start to work together they really produce some cool and unexpected results, and guess what. Nobody knows why.