One interesting comment that I've been seeing a lot lately around various message boards and such where people talk about AI War is the comment that the game is a labor a love, and that I'm clearly not looking to get rich off of it. It's actually refreshing to see that sort of opinion, since I was all but accused of being pretty mercenary (and in one case "one step above a viagra ad") in the early days of trying to promote the game (a super, super, hard thing for a new indie developer with no track record and no connections).
Which opinion is right? Am I a merciless scammer, or am I a idealistic philanthropist that is making games for pocket change and the good of mankind? While I am in some senses flattered by the latter view, I think I clearly fall somewhere in the middle, like pretty much anyone who starts a small business.
Why Start Coding A Game?
Yes, originally I did start coding this game because it "scratched an itch" that I personally had (for a large, complicated co-op RTS game with great AI), but I had already been coding games for a long time before that. I always saw it as a hobby until I started working on the Alden Ridge game, which I originally saw as a promotional item that I would give away for free to generate publicity for the novel by the same name that I was writing at the same time.
Alden Ridge (the game) eventually took on a life of its own, and truthfully I had started coding that to scratch a different itch, anyway: I love the game Lode Runner: The Legend Returns, but none of its sequels, and I wanted something that in some senses was similar, but really different. So a cooperative top-down game with zombies chasing you was born. As Alden Ridge took on more and more of a life of its own, I realized how many hundreds of hours I was sinking into it, and started to think it would be nice if I could actually get some money for that.
Transcending Hobbyism
I mean, I love making games and in some senses view it almost as a hobby, but then again they take a lot of time to code and I don't want to spend all my off-hours time doing it. I want my "hobby" to be my job (doesn't everyone?), and so to do that I need to charge some money and actually have people find and play my games. There's a difference between charging a fair price and gouging people, though, and I try to stay well on the side of the former, of course. I also don't go for the glitzy features that I think will grab people superficially, instead focusing on fun factor and the sorts of features I'm interested in. I try to make the best sort of product I can, for my main audience (me), and then I try to make sure that it turns out to be as accessible as possible for other people once that original vision is somewhat codified. I mostly only start thinking about other players fairly late in the process, because that's the point where the core game has become something interesting and fun in its own right (and hopefully somewhat original, since I wasn't trying to follow trends or mimic other games too heavily).
I guess that is one thing that makes me not a hobbyist, though -- I do think about what other people want, intensely, and I spent months refining the product to be as easy to pick up as possible. I just wait until really late in the process before I start doing that, otherwise all the inital designs start trending toward unoriginal directions.
Anyway, so I primarily made AI War for my own RTS group when I realized that there were no other products on the market that did specifically what we wanted, and that there didn't seem to be any on the horizon (we'd been playing on RTS after another for 10 years by the point I started coding AI War, and none of them had been exactly the right match for more than a year at a time, so I guess that goes without saying). Given that through Alden Ridge I had already come to a realization that it would make sense to do game development as a fulltime job instead of working a separate business software job and then coming home and doing game development, I knew from the start that I was planning on selling AI War. I still went about designing it in a really personal fashion, though, and I think a lot of what is original about the game came from that sort of design attitude.
What Are The Real Motivations?
So why am I doing this? For love or for money? Because clearly I love doing it and for a long time I did this sort of thing for free, but now I'm charging money and trying to make a functioning business out of this, with staff and everything. I guess the answer is both. Am I trying to get wildly rich off of this? Well, not in the sense of someone who thinks they are cashing in or following a get-rich-quick scheme. Game design is hard, it takes a ton of work, and then once the game is "done" it is still not done. I do a lot of work for free even after the product is "done," when most developers big and small pretty much walk away or issue a few minor patches. There are definitely some notable exceptions, such as the Evochron Legends developer, who so far as I can tell has a pretty similar outlook to mine.
Free Content
If I was a big publisher I'd probably be charging for my weekly free DLC releases, but instead I give them away for free. Why exactly am I creating those releases, anyway? Well, they make the game better, in some cases a lot better, but I was already getting really positive reviews before most of the free DLC that has already come out, so I probably could have gotten away with just a couple of bugfix patches. Doing the free DLC certainly generates a lot of goodwill, and a certain amount of word of mouth, but I'm not certain that it's entirely enough to really warrant the amount of time that goes into that free DLC if I was just looking at dollars and cents.
Oh, so that's why people think I'm doing it for love instead of money. Well, I guess they're right. I improve the game because I want to, because coding the game is almost like a game to me in some senses, and because I play the game myself and want it to get ever bigger and better. And because I'm just a polisher and a completionist by nature, I suppose.
Generating My Own Funding
But I'm also in it for the money. I want AI War to sell well enough that I can afford to hire a few people (composer, artist, another game designer or two, and maybe one other programmer in addition to myself), and so that we can be financially secure for a few years as we work on other games. The more security we have, the more likely we are to not try to trend-follow or rush products to market so that we can pay our mortgages, etc. So from that sense, I'm very serious about the money and do as much promotion as I can. Because I love it, and I want to be able to do this as my fulltime job, forever. I don't want to have to consult a publisher about every little decision, and I don't want to go into debt to finance projects, so that means that my earlier projects like AI War need to sell well enough to finance the later ones.
Really, I think that's pretty typical for your average startup company. They want to make enough money to keep doing what they love to do for as long as they can. I guess some startups form with an eye towards burning through venture capital and then selling the company for a profit, but personally I don't ever plan on selling Arcen Games unless something really drastic happens. It's not part of the current plan, anyway -- that's completely counter to my goal of being able to do what I love for as long as I can. Suppose I did sell the company, what would that get me? If it gave me a bunch of money, I'd just use that to start another game development company, so what would the point be? Vacations are nice, but I'd get bored as hell sitting on the beach drinking fruity beverages.
If AI War continues on its present track, I actually stand to make a good deal of money -- potentially millions, if it goes really well. Am I counting on that? No. If it happens, am I going to run out and buy a porshe? Also no. I'm going to invest that money as conservatively as I can, and then hire myself and a small team, and we're going to get cracking on lots more games. We'll then make the best damn 2D games we can make, for as long as we have money to make them. At best, I see myself living an upper-middle-class lifestyle, with a reasonable but not extravagant house and the financial independence to make the sort of games that I want, while still having time to spend with my family.
Don't Piss It All Away!
When I look at other indie developers that made it big, and then spent the money on huge crazy salaries and bonuses, expensive office space, and other serious nice-to-have window dressings, it makes me really sad. That's why people start assuming they were all about the money, I think. If they really have a passion for making games, they'll do everything in their power to make sure they can keep doing just that. Of course, I have the advantage of having ridden the small business roller coaster in the past, and I've seen from front row seats what extravagant, wasteful spending can do to a company.
That's the key thing that I think a lot of people misunderstand about money. They assume that it's a constant inflow, that if they hit it big with their first game that all their later games will be similarly well recieved. I have no such illusions. I very much hope that all my games will be well recieved, but I want to be able to create ones that are more niche than commercial in nature (whatever that means -- by many measures, AI War is pretty niche, but at the same time there still seems to be quite a commercial market for it). I want AI War to make a lot of money so that the second and third games can flop and it won't kill the company. Not that I want those games to flop, but I want to have the buffer there. I also want to have the buffer of time, so that if I need an extra 6 months of development, that's no problem instead of something that the company has to go into debt for.
Financial Independence = Creative Freedom?
Part of why the biggest game development companies (Blizzard and Valve and Nintendo, I'm mostly thinking of here) are so successful is that they have financial independence. Valve could afford to go six years between products, and then Half Life 2 was amazing. Nintendo can afford to put a lot of time and money into some really tangential things (the Wii in general, Wii Fit, etc), and then is able to polish them to the point that they turn out to be really good and thus also successful. Same with Blizzard and their products.
I'm not Blizzard, Valve, or Nintendo. But financial independence should be the goal of any game developer, or indeed any software developer in general. That's the only cure I know of for rushed deadlines, buggy releases, or too-conservative designs that wind up being very derivative.
I make games because I love to. Period. But I also need money so that I can hire a staff to help with things like music and art, and so that I can actually do this as my day job myself. So, like anyone else who is serious about game development, I'm doing it for love and money. Only hobbyists do it purely for love, and I don't think anyone can make real games if they are doing it purely for money. That's what those movie tie-in games are often about, and many of them hardly deserve the moniker "game." So while I'm flattered that people see how much I love what I do, and assume such altruistic motives, the reality is a little more gray than either black or white. Isn't it always?
Tuesday, July 28, 2009
Wednesday, July 22, 2009
Thoughts on Piracy and DRM
First, DRM Stinks
I try to make it known that AI War doesn't contain any DRM -- there's a license key to transform the demo version into the full version, and that's it. No phoning home, no usage tracking, no limited numbers of installs, no crazy drivers that take over your system. DRM sucks, in so many ways, and I've always hated it. When I buy music, I use Amazon MP3 because it's DRM-free. When I have music, I want to be able to use it on any device I have, or any computer -- I use a laptop as well as a desktop, and switch back and forth between both.
With games, it's much the same thing. I want to own the game, whether I got it through an online distribution service or from a brick and mortar store. I want to be able to play that game ten years from now. I still pull out my original cartridge of Mario 2 every few years, or Quake II, or Half-Life, or Silent Hill, or The Ocarina of Time, or Emperor: Rise of the Middle Kingdom, or a dozen others. With some sort of crazy DRM with those titles, I'd probably have to resort to piracy just to play them at all at this late stage. Thankfully, none of those titles have more than a CD check and license key (and obviously the console titles don't have even that).
For all of the above reasons, plus many others -- such as the fact that most DRM gets immediately cracked anyway -- I don't support DRM.
But, Piracy Also Stinks
Today Google Alerts notified me of a page on NowTorrents, which informed me that over 40,000 people have been tracked downloading illegal copies of AI War. Is that number accurate? Who the heck knows, but it sure outpaces the number of sales we've had so far. I've read all sorts of articles by other developers who fall on various sides of this debate, and from what I can tell a piracy rate of 90% or more is very common. Depending on how many sites people are pirating AI War through, and how accurate tracker numbers are, we're probably at that number or even well above it. It's hard to say, because there's no one central reliable source that tallies pirate downloads.
So, I should spring right into action, right? Start adding DRM to my games, or... or... or something, right? Despite the fact that this will alienate my existing and potential good customers, if I can convert even a few of the pirates to paying customers, that might pay off pretty well, right? I seem to recall some other articles talking about the conversion rate of pirates to paying customers being something like 1 in 1,000 pirates can be converted. That's just 40 sales from all those NowTorrents pirates. That's pretty sobering, isn't it?
Even if it was 400 sales, I don't think the negative consequences from adding DRM would be worth it. Goodwill is worth more. So, for all intents and purposes, this is a non-event for me. People are pirating my game, like I knew they would if it ever became popular. I didn't try very hard to stop them, because I knew I couldn't. No one ever has, and I'm against DRM anyway. But it's still kind of a kick to the nuts to see this sort of thing.
So, How To Stop Piracy?
I have never seen a stronger argument for console development than this sort of thing. Pirating of console games is very hard because of all the specialized hardware -- sure you get a lot of knock-off discs in China and so forth, but not so much over here. I have nothing against consoles, but I'm frankly a PC developer at heart. I love the platform, and I don't really want to switch. I imagine I'll port some titles to consoles in the future at some point, but I can't imagine a time when they are my primary focus.
Well, okay, so what can we do to shore up the PC? The reason that piracy is harder on consoles is because of all the specialized, non-cross-compatible, vendor-locked, or otherwise proprietary hardware. So that's what we need with the PC, right? Some sort of crazy anti-piracy stuff built right into our hardware, or maybe we should have specialized hardware dongles like high-end software packages sometimes do. Wait a minute, though -- isn't the awesome thing about PCs how configurable and open they are? I really don't want to change that -- my biggest gripe with Apple is how closed all their hardware is, after all. I'd probably use OSX if it could run on my PC hardware, but I refuse to buy proprietary hardware from a single vendor for a computer. Any sort of changes in that direction are not a positive step forward for the PC, and I think that myself and most other PC enthusiasts do not want to live in a future where that is the norm.
Okay, so that leaves some sort of central server authentication -- well, but wait, that can be hacked out, it's basically just DRM. Well, if people have to be logged in at all times, like with an MMO, then that's pretty hard to hack. Actually, that seems like a pretty darn good way to stop piracy to me, but usually that is paired with a subscription fee, which seems unfair to customers except in the MMO context (and I don't even play those, because I don't want to be saddled with a subscription where I feel like I have to play a game a certain amount each month to feel like I'm retaining the value of my money). And anyway, there are a lot of people who have a lot of issues with the MMO model, and I'd be alienating all of them if I switched to any sort of online-only model. Look at all of the (largely well deserved) flak that Starcraft II is getting for the removal of LAN play.
Uh... okay, so what does this leave? Basically I think that rules out everything. I can't stop piracy without doing something quasi-nefarious myself, and that wouldn't really even fully stop the piracy, anyway. So I guess that puts us in sociological territory, where I need to make people not want to pirate the game. If price is the barrier, then maybe setting a lower price would convert some people -- but wait, AI War is already 1/3 the price of its competitors. Even less expensive games, like World of Goo, have been pirated more than mine. So price doesn't seem to affect this.
What else makes people want to pirate? The inclusion of nasty DRM is an often-cited example -- but I already avoided that. Once again, I'm out of ideas.
Sticking it to the Man
Price, DRM... those are the two biggest-cited reasons for excusing piracy. Stick it to the man, and all that (but if a tiny indie developer has become "the man" then I don't know what to say to that). In the end, people pirate because they want to. They either don't have any money, or don't have enough to spend on all the entertainment they want. So they buy some entertainment, and then steal whatever overflow they can't afford. Or maybe it's just that they are in the habit of piracy, and hardly even think about it because it is, essentially, a victimless crime against rich fat cats and celebrities who don't really need the money, anyway. Or maybe it's just because piracy is so easy.
Who the heck knows -- I certainly don't. I don't think there's any one reason. People have been violating copyright and pirating and plagiarizing since long before the modern era. There's just something, deep down, that makes people believe that these sorts of ethereal products, or knowledge, can't or shouldn't be protected. In a lot of senses, when it comes to things like patents, I agree that the current laws are ridiculous. We definitely give too much protection to patent holders (or grant too many frivolous patents, one way or the other). But when it comes to products, items that most people would never dream of stealing off the shelves of a retail store, I take issue with the attitude that it's okay to steal it if it's digital.
The Only Solution Is Not Really A Solution At All
The value of a product, be it a CD, a book, a movie, or a game, is not in the plastic and cardboard of the item sitting on store shelves. It's in the product itself. As we move ever more towards a digital-only or digital-primarily age of distribution for these sorts of products, that's something that people need to remember. That's the only solution to piracy that I can see. In real life, we depend on people doing the right thing even when there are no authority figures or policemen present. Our society would collapse if people committed crimes every time big brother wasn't watching. Without being too melodramatic, I think it's reasonable to say that there are similar ethical issues at stake with online/digital societies. If we can't trust each other, at least to some degree, then there isn't much of a society there.
I'm not big brother, I'm not "the man," I'm not a rich fat cat that won't notice a few missed sales. Any indie developer, and frankly most developers period except maybe those at the very top of the sales charts, need all the sales they can get. I'm not an authority figure, I'm not watching you, and I'm not pointing a bunch of nasty DRM weapons at you or your computer. Please don't steal from me if you like the products I create. And if you don't like the products I create, why are you downloading it from a torrent? Either way, pirates or no, life goes on. There's nothing content providers can really do about it except appeal to people's better nature, but so far that hasn't really seemed to make much of a difference. That's rather sad.
If you took the time to read an article on this subject, chances are that you're not part of the problem, anyway.
I try to make it known that AI War doesn't contain any DRM -- there's a license key to transform the demo version into the full version, and that's it. No phoning home, no usage tracking, no limited numbers of installs, no crazy drivers that take over your system. DRM sucks, in so many ways, and I've always hated it. When I buy music, I use Amazon MP3 because it's DRM-free. When I have music, I want to be able to use it on any device I have, or any computer -- I use a laptop as well as a desktop, and switch back and forth between both.
With games, it's much the same thing. I want to own the game, whether I got it through an online distribution service or from a brick and mortar store. I want to be able to play that game ten years from now. I still pull out my original cartridge of Mario 2 every few years, or Quake II, or Half-Life, or Silent Hill, or The Ocarina of Time, or Emperor: Rise of the Middle Kingdom, or a dozen others. With some sort of crazy DRM with those titles, I'd probably have to resort to piracy just to play them at all at this late stage. Thankfully, none of those titles have more than a CD check and license key (and obviously the console titles don't have even that).
For all of the above reasons, plus many others -- such as the fact that most DRM gets immediately cracked anyway -- I don't support DRM.
But, Piracy Also Stinks
Today Google Alerts notified me of a page on NowTorrents, which informed me that over 40,000 people have been tracked downloading illegal copies of AI War. Is that number accurate? Who the heck knows, but it sure outpaces the number of sales we've had so far. I've read all sorts of articles by other developers who fall on various sides of this debate, and from what I can tell a piracy rate of 90% or more is very common. Depending on how many sites people are pirating AI War through, and how accurate tracker numbers are, we're probably at that number or even well above it. It's hard to say, because there's no one central reliable source that tallies pirate downloads.
So, I should spring right into action, right? Start adding DRM to my games, or... or... or something, right? Despite the fact that this will alienate my existing and potential good customers, if I can convert even a few of the pirates to paying customers, that might pay off pretty well, right? I seem to recall some other articles talking about the conversion rate of pirates to paying customers being something like 1 in 1,000 pirates can be converted. That's just 40 sales from all those NowTorrents pirates. That's pretty sobering, isn't it?
Even if it was 400 sales, I don't think the negative consequences from adding DRM would be worth it. Goodwill is worth more. So, for all intents and purposes, this is a non-event for me. People are pirating my game, like I knew they would if it ever became popular. I didn't try very hard to stop them, because I knew I couldn't. No one ever has, and I'm against DRM anyway. But it's still kind of a kick to the nuts to see this sort of thing.
So, How To Stop Piracy?
I have never seen a stronger argument for console development than this sort of thing. Pirating of console games is very hard because of all the specialized hardware -- sure you get a lot of knock-off discs in China and so forth, but not so much over here. I have nothing against consoles, but I'm frankly a PC developer at heart. I love the platform, and I don't really want to switch. I imagine I'll port some titles to consoles in the future at some point, but I can't imagine a time when they are my primary focus.
Well, okay, so what can we do to shore up the PC? The reason that piracy is harder on consoles is because of all the specialized, non-cross-compatible, vendor-locked, or otherwise proprietary hardware. So that's what we need with the PC, right? Some sort of crazy anti-piracy stuff built right into our hardware, or maybe we should have specialized hardware dongles like high-end software packages sometimes do. Wait a minute, though -- isn't the awesome thing about PCs how configurable and open they are? I really don't want to change that -- my biggest gripe with Apple is how closed all their hardware is, after all. I'd probably use OSX if it could run on my PC hardware, but I refuse to buy proprietary hardware from a single vendor for a computer. Any sort of changes in that direction are not a positive step forward for the PC, and I think that myself and most other PC enthusiasts do not want to live in a future where that is the norm.
Okay, so that leaves some sort of central server authentication -- well, but wait, that can be hacked out, it's basically just DRM. Well, if people have to be logged in at all times, like with an MMO, then that's pretty hard to hack. Actually, that seems like a pretty darn good way to stop piracy to me, but usually that is paired with a subscription fee, which seems unfair to customers except in the MMO context (and I don't even play those, because I don't want to be saddled with a subscription where I feel like I have to play a game a certain amount each month to feel like I'm retaining the value of my money). And anyway, there are a lot of people who have a lot of issues with the MMO model, and I'd be alienating all of them if I switched to any sort of online-only model. Look at all of the (largely well deserved) flak that Starcraft II is getting for the removal of LAN play.
Uh... okay, so what does this leave? Basically I think that rules out everything. I can't stop piracy without doing something quasi-nefarious myself, and that wouldn't really even fully stop the piracy, anyway. So I guess that puts us in sociological territory, where I need to make people not want to pirate the game. If price is the barrier, then maybe setting a lower price would convert some people -- but wait, AI War is already 1/3 the price of its competitors. Even less expensive games, like World of Goo, have been pirated more than mine. So price doesn't seem to affect this.
What else makes people want to pirate? The inclusion of nasty DRM is an often-cited example -- but I already avoided that. Once again, I'm out of ideas.
Sticking it to the Man
Price, DRM... those are the two biggest-cited reasons for excusing piracy. Stick it to the man, and all that (but if a tiny indie developer has become "the man" then I don't know what to say to that). In the end, people pirate because they want to. They either don't have any money, or don't have enough to spend on all the entertainment they want. So they buy some entertainment, and then steal whatever overflow they can't afford. Or maybe it's just that they are in the habit of piracy, and hardly even think about it because it is, essentially, a victimless crime against rich fat cats and celebrities who don't really need the money, anyway. Or maybe it's just because piracy is so easy.
Who the heck knows -- I certainly don't. I don't think there's any one reason. People have been violating copyright and pirating and plagiarizing since long before the modern era. There's just something, deep down, that makes people believe that these sorts of ethereal products, or knowledge, can't or shouldn't be protected. In a lot of senses, when it comes to things like patents, I agree that the current laws are ridiculous. We definitely give too much protection to patent holders (or grant too many frivolous patents, one way or the other). But when it comes to products, items that most people would never dream of stealing off the shelves of a retail store, I take issue with the attitude that it's okay to steal it if it's digital.
The Only Solution Is Not Really A Solution At All
The value of a product, be it a CD, a book, a movie, or a game, is not in the plastic and cardboard of the item sitting on store shelves. It's in the product itself. As we move ever more towards a digital-only or digital-primarily age of distribution for these sorts of products, that's something that people need to remember. That's the only solution to piracy that I can see. In real life, we depend on people doing the right thing even when there are no authority figures or policemen present. Our society would collapse if people committed crimes every time big brother wasn't watching. Without being too melodramatic, I think it's reasonable to say that there are similar ethical issues at stake with online/digital societies. If we can't trust each other, at least to some degree, then there isn't much of a society there.
I'm not big brother, I'm not "the man," I'm not a rich fat cat that won't notice a few missed sales. Any indie developer, and frankly most developers period except maybe those at the very top of the sales charts, need all the sales they can get. I'm not an authority figure, I'm not watching you, and I'm not pointing a bunch of nasty DRM weapons at you or your computer. Please don't steal from me if you like the products I create. And if you don't like the products I create, why are you downloading it from a torrent? Either way, pirates or no, life goes on. There's nothing content providers can really do about it except appeal to people's better nature, but so far that hasn't really seemed to make much of a difference. That's rather sad.
If you took the time to read an article on this subject, chances are that you're not part of the problem, anyway.
UK Gamer Interview with Chris Park about AI War
UK Gamer interviews Chris Park, the developer of AI War, about design decisions made in the game, promotion methods for indie developers, and the future of AI War and Arcen Games.
Read The Interview
Read The Interview
Sunday, July 19, 2009
Designing Emergent AI, Part 4: Asymetrical Goals
The first part of this article series was basically an introduction to our AI design, and the second part of this article series took a look at some of the LINQ code used in the game, as well as discussing danger levels and clarifying a few points from the first article. The third part of this series covered the limitations of this approach. The topic, this time, is the asymmetrical system used for things like resource management in AI War.
This topic is a very challenging one for me to approach, because there are such heated feelings on both sides of it amongst game designers. Just recently I remembered that I had actually already written an article on this topic, targeted at my alpha testers in order to explain to them the conceptual shift that I was planning at that time. They were skeptical of the idea at the time (as I would have been if someone else had suggested it to me), and this article went a long way toward convincing them that the concept might have some merit -- the most convincing thing of all, of course, was when they could actually see how well the AI worked in practice.
The game had been in development for less than three months at the time I originally wrote this, but amazingly almost all of it still holds true now, 2 months after the game's public release (the things that no longer hold true are how some of the AI types played out in the end, and the division of AI ships into offensive/defensive groups -- these are minor points that existing AI War players will notice the discrepancy in, but otherwise this makes no difference to the overall ideas being presented here).
ABOUT THE ARTIFICIAL INTELLIGENCE IN AI WAR
Originally Written January, 2009
About the AI in most RTS Games
Most Real-Time Strategy (RTS) games use a style of AI that tries to mimic what a human player might do. The AI in these games has all the same responsibilities and duties as the human players, and the success of the AI is predicated on it properly simulating what a human might do.
These sorts of AI rely heavily on exceedingly complex Finite State Machines (FSMs) -- in other words, "if the situation is X, then do Y, then Z." This sort of deterministic algorithm takes a long time to design and program, and is overall pretty predictable. Worst of all, these algorithms tend not to have very interesting results -- invariably, facing this sort of AI is sort of like playing against another human, only stupider-yet-faster. Clever players are able to trick the AI by finding patterns and weaknesses in the algorithms, and the AI tends to be slow to respond to what the players are doing -- if it responds at all. This is after months of work on the part of some poor AI programmer(s).
Nondeterministic AI in other Games
In most modern AI design, nondeterminism is an important goal -- given the same inputs, the AI shouldn't always give EXACTLY the same output. Otherwise the AI is inhumanly predictable. The chief ways of combating this predictability are fuzzy logic (where inputs are "fuzzified," so that the outputs are also thus less precise) or some variation of a learning AI, which grows and changes over time (its historical knowledge makes it act differently over the course of its existence).
The problem with a standard learning AI is that it can easily learn the wrong lessons and start doing something strange. Debugging is very difficult, because it's hard to know what the AI thinks it is doing and why. Also, until it has some base amount of historical data, it seems that it will either be a) wildly unpredictable and unproductive, or b) using deterministic methods that make it predictable. It can be like teaching an amoeba to tap-dance -- but instead it starts setting things on fire, and you wonder what made it think that was part of what it should do.
Therefore, even with a learning AI, you're likely to have a pretty predictable early game. Plus, if the game supports saving, the entire historical knowledge of the AI would have to be saved if the AI is to keep track of what it was doing (and keep its learned intelligence). This can make save files absolutely huge, among other various disadvantages.
Semi-Stateless AI in AI War
For AI War, I wanted a nondeterministic AI that was not dependent on having any historical knowledge. Of course, this means a pretty fair amount of fuzzy logic by definition -- that is indeed in place -- but I also wanted some of the characteristics of a learning AI. Essentially, I wanted to model data mining practices in modern business applications (something I'm imminently familiar with from my day job). My rule of thumb was this: At any given point in time, the AI should be able to look at a set of meaningful variables, apply some rules and formulas, and come to the best possible conclusion (fuzzified, of course).
A human example: At chess tournaments, often the grandmasters will play against the normal-human players 40 or so at a time (purely for fun/publicity). The 40 lower-ranked players sit at tables in a ring around the room, each with their own chess game against the grandmaster. The grandmaster walks slowly around the room, making a move at each game in sequence. There is no way that the grandmaster is remembering the state of all 40 games; rather, he analyzes each game as he comes to it, and makes the best possible move at the time. He has to think harder at games where there is a particularly clever player, but by and large the grandmaster will win every game out of the 40 because of the skill gap. The general outcome is that the grandmaster picks the cleverest of the other players, and lets them win on purpose (if there is a prize -- if the grandmaster is showing off, they'll just beat everyone).
The AI in AI War is a lot like that grandmaster -- it is capable of coming to the game "blind" about once per second, and making the best possible choices at that time. Minor bits of data are accumulated over time and factored in (as the grandmaster might remember details about the cleverer opponents facing him), but overall this is not necessary. The AI also remembers some data about its past actions to a) help it follow through on past decisions unless there is a compelling reason not to, and b) to help prevent it from falling into patterns that the opponents can take advantage of.
Decentralization of Command In Other RTS Games
One important factor in creating an interesting AI opponent is that it must be able to do multiple things at once. In all too many games, the AI will just have one military arm moving around the board at a time, which is not what a human player would typically do. Where are the diversions, the multi-front attacks, the flanking?
In AI War, it was important to me that the tactical and strategic commanders be able to perform as many different activities as makes sense given the units at hand. Typically this would be accomplished by creating multiple independent "agents" per AI player, and assigning control each unit to a particular agent. You then run into issues of the agents having to negotiate and coordinate among themselves, but in AI War's semi-stateless environment it is even worse -- how do you intelligently divide up the units among these arbitrary agents if you have to keep reassigning them? And how to know when to spawn more agents, versus consolidate useless agents? These problems can all be solved, but they are not something to be attempted lightly, and nor will they be kind to the CPU. The central problem is that of resource management. Not only the delegation of control of existing units, but trying to balance tactical/strategic elements with the generation of resources and the production of new units.
Which brings me to my next point...
Resource Management In AI War
I struggled with the command decentralization issue for several days, trying to come up with a solution that would meet all of my many criteria, and ultimately came to a realization: what matters is not what the AI is actually doing, but what the visible effect is to the human players. If the AI struggles with all these things invisibly, burning up programmer hours and CPU cycles, and then comes to result A, wouldn't it be better to just shortcut some of that and have it arrive at result A? Specifically, I realized that the economic simulations had a very low payoff as far as the players were concerned. If I took out the human-style economic model for the AI -- no resources, no techs, just a generalized, linearized ship-creation algorithm -- what would the impact be?
First of all, this change makes it so that the AI players do not use builders, factories, reactors, or any of the other economy-related ships. This changes the gameplay to a mildly significant degree, because the human players cannot use the strategy of targeting economic buildings to weaken the AI. This is definitely a drawback, but in most RTS games the AI tends to have so many resources that this is generally not a viable strategy, anyway.
Having decided that this gameplay shift was acceptable, I set about designing a ship-creation algorithm. This is harder than it sounds, as each AI has to know a) what ships it is allowed to build at any given point in the game, b) how much material it is allow to spend per "resource event," and other factors that keep things fair. Note that this is NOT your typical "cheating AI" that can just do whatever it wants -- the AI plays by different rules here, but they are strict rules that simulate essentially what the AI would otherwise be doing, anyway.
Decentralization of Command In AI War
Now that the economy is handled, we are back to the issue of decentralization. Each AI is now allowed to build a certain number of ships of specific types during each resource event, but how to intelligently choose which to build? Also, how to decide what to do with the ships that already exist?
First off, the AI needs to divide its units into two categories -- offensive and defensive. Most games don't do this, but in AI War this works very effectively. Each AI decides that it wants to have a certain number of ships of certain types defending each planet or capital ship that it controls. It's first priority is production to meet those defensive goals.
Any units that aren't needed for defense are considered offensive units. These get handed over to the strategic-routing algorithm, which is described next. Each unit-producing ship controlled by the AI player will build offensive units based on a complex algorthm of fuzzy-logic and weighting -- the result is a fairly mixed army that trends towards the strongest units the AI can produce (and the favored units of a given AI type), but which never fully stops building the weaker units (which are always still useful to some degree in AI War).
Strategic Routing in AI War
The strategy planning in AI War consists of deciding what units to send to which planets. Defensive units tend not to leave their planet unless the thing they are protecting also leaves, so this pretty much just means routing around the offensive units.
This takes the form of two general activities: 1) attacking -- sending ships to the planet at which they should be able to do the most amount of damage; and 2) retreating from overwhelming defeats, when possible (no other RTS game AI that I have encountered has ever bothered with this).
The AI does not use cheap factors such as player score, who the host is, or any other non-gameplay variables in these sorts of decisions. All its decisions are based on what units are where, and what it currently calculates the outcome of a conflict is most likely to be.
Tactical Decisions in AI War
When it comes to tactical decision-making, this is actually one of the conceptually simpler parts of the AI. Each unit tries to get to its optimal targeting range, and targets the ships it is best able to hurt. It will stay and fight until such time as it dies, all its enemies are dead, or the Strategic Routing algorithm tells it to run away.
AI Types in AI War
When I think about the human-emulating AI found in most RTS games, it strikes me that this is extremely limiting. In most genres of game, you face off against a variety of different enemies that have powers that differ from those of the human players. Some opponents are vastly stronger, others are weaker, and all are distinctive and interesting in their own way. In RTS games, everyone is pretty much the same -- or at least things are balanced to the point of approximate fairness -- and I think this harms the longevity of these games.
What seems more interesting to me, and what I've decided to do in AI War, is to provide a wide variety of types of AI, each with their own strengths, weaknesses, and genuinely unique behaviors. Some have ships that the player can never get, others start with many planets instead of one, some never capture planets but instead roam around the neutral planets as lawless raiders. The possibilities are endless, especially when playing against multiple AI types in a single game.
The result is situations that are often intentionally unfair -- as they would be in real war. You can simulate being the invading force into a galaxy controlled by evil aliens, or simulate the opposite -- they're invading you. I think of this as being rather like the situation in Ender's Game. You can have AIs that are timid and hide, or others that come after you with unbridled aggression -- Terminators, or Borg, or whatever you want to call them. Some will use strange, alien combat tactics to throw you off guard, while others will routinely use confusing diversions to mask what their true objective is. Others will outclass you in terms of technology from the very start, others will have vastly more manpower but inferior technology -- the list goes on and on.
The whole goal of a game like this is to provide an interesting, varied play experience for the players. If all the AIs are essentially the same except for their general demeanor (as in most other games), that doesn't provide a lot of options. AI War's style of varied AIs is not "AI cheating" in the traditional sense -- each type of AI has specific rules that it must follow, which are simply different than the rules the human players are held to.
Think of this as the offense and defense in a football game: each team has wildly different goals -- one to score, one to not let the other team score -- but the overall success of one team versus another is determined based on how well they do in their respective goals. In football, the teams also routinely switch off who is on offense and who is on defense, and that's where the analogy to AI War starts to break down a bit. In AI War, it would be more like if one football team always played offense, but the defenders were allowed to have an extra three guys on the field. Maybe the defenders could only score by forcing a turnover and running the ball all the way back, but that would be significantly easier due to the extra players.
The AI Types in AI War are like that -- they unbalance the rules on purpose, not to cheat, but to provide something genuinely new and varied.
The Future of AI in AI War
At present, the AI does not yet make very interesting tactical decisions -- flanking, firepower concentration on key targets, etc. These and other "behaviorlets" will be added to future iterations of the AI. The AI will evaluate the behaviorlet conditions during tactical encounters, and employ them when it deems it makes sense to do so.
In fact, this concept of "behaviorlets" is the main thing that is left to do with the AI all across the board. Right now the AI is very by-the-numbers, which makes it predictable except where the fuzzy logic makes it somewhat randomized. This is comparable to the end state of many other RTS game AIs (yet it took me days instead of months or years), but with the architecture of AI War, I can continue to add in new "behaviorlets" in all aspects of the AI, to make it progressively more formidable, varied, and human-seeming. Example behaviorlets include scouting, sniping, mine laying and avoidance, using staging areas for attacks, economy targeting, use of transports, planet denial, and more. All of these things can be programmed into the existing architecture with relative ease; the complexity is bounded to the behaviorlet itself, rather than having to worry about how the behaviorlet will interact with larger elements of (for example) your typical AI finite state machine. This makes for a very object-oriented approach to the AI, which fits my thinking style.
Computer Requirements
This is a very modular AI system that can be extended over time, and yet it is also extremely efficient -- it is already able to control tens of thousands of ships without significant slowdown on a dual-core computer. However, it is being designed with dual-core computers in mind, and it is highly unlikely to run well at all on a single-processor computer.
On the other hand, the AI logic is only run on the game host (also unusual for an RTS game -- possibly another first), which means that single-threaded computers can join someone else's multiplayer game just fine. Given that this is the largest-scale RTS game in existence at the moment in terms of active units allowed during gameplay (by at least a factor of two), this is also pretty notable.
In Conclusion (We Return To The Present)
As noted at the start of this article, the main body of this article was written when the game was still in alpha stages, with the prior few months having been spent testing out the mechanics, the networking, the graphics pipeline, etc, in pure player-vs-player (pvp) modes. I had spent a week or so with the AI in a more traditional model, and felt like that was not working the way I wanted on any level, and so I decided to go back to the underlying principles of what I was trying to accomplish to see if there was a simpler approach.
After a few more days of thought, and then maybe three days of coding, I had a basic prototype of the AI working. I wrote this article then to let my alpha testers know what I was planning, and then spent the next three months refining, expanding, and completing the AI (and the rest of the game) before a beta in April. The game spent a month in beta, ironing out bugs and balance issues, and then went on sale on the Arcen site and then Stardock's Impulse in May.
This asymmetrical AI is the aspect of the game design that is most commonly criticized by other programmers or game designers who have not actually played the game. From my growing list of players, and the few reviews that the game has received so far (our exposure is still low, but growing due to the game's huge popularity on Impulse and elsewhere), this hasn't seemed to be an issue for anyone who actually plays the game. That comes back to my core realization with the AI: it doesn't matter what the AI is really doing, it matters what the AI seems to be doing, and what it makes the player do.
This style of AI creates a lot of unique gameplay situations, provides a good, fair-seeming challenge, and in general provides a degree of variety you don't encounter with other AIs. This isn't going to power sentient robots anytime soon, but in terms of creating an interesting game it seems to have paid off. That's really the goal, isn't it? To create a game that people find fun, challenging, and interesting? To get too hung up on the semantics of one approach versus another, and which is more "authentic" is counterproductive in my book. We really ought to have more games experimenting with various approaches to AI design, because I think it could make for some really fun games in all sorts of genres.
Next Time?
I have a number of other articles planned about the game, most notably a series on game design ideas that flopped for one reason or another and thus didn't make it into the final game -- an exploration of the failures-along-the-way is always fun and illuminating. But as far as the topic of AI goes, I've covered all of the points I set out to cover. Unless readers bring up more topics that they'd like me to address, this will probably be the final article in my AI series.
Part 5 of this series is a transcript of a discussion about the desirability of slightly-nonideal emergent decisions versus too-predictable "perfect" decisions.
AI Article Index
Part 1 gives an overview of the AI approach being used, and its benefits.
Part 2 shows some LINQ code and discusses things such as danger levels.
Part 3 talks about the limitations of this approach.
Part 4 talks about the asymmetry of this AI design.
Part 5 is a transcript of a discussion about the desirability of slightly-nonideal emergent decisions versus too-predictable "perfect" decisions.
Part 6 talks about player agency versus AI agency, and why the gameplay of AI War is based around keeping the AI deviously reactive rather than ever fully giving it the "tempo."
This topic is a very challenging one for me to approach, because there are such heated feelings on both sides of it amongst game designers. Just recently I remembered that I had actually already written an article on this topic, targeted at my alpha testers in order to explain to them the conceptual shift that I was planning at that time. They were skeptical of the idea at the time (as I would have been if someone else had suggested it to me), and this article went a long way toward convincing them that the concept might have some merit -- the most convincing thing of all, of course, was when they could actually see how well the AI worked in practice.
The game had been in development for less than three months at the time I originally wrote this, but amazingly almost all of it still holds true now, 2 months after the game's public release (the things that no longer hold true are how some of the AI types played out in the end, and the division of AI ships into offensive/defensive groups -- these are minor points that existing AI War players will notice the discrepancy in, but otherwise this makes no difference to the overall ideas being presented here).
ABOUT THE ARTIFICIAL INTELLIGENCE IN AI WAR
Originally Written January, 2009
About the AI in most RTS Games
Most Real-Time Strategy (RTS) games use a style of AI that tries to mimic what a human player might do. The AI in these games has all the same responsibilities and duties as the human players, and the success of the AI is predicated on it properly simulating what a human might do.
These sorts of AI rely heavily on exceedingly complex Finite State Machines (FSMs) -- in other words, "if the situation is X, then do Y, then Z." This sort of deterministic algorithm takes a long time to design and program, and is overall pretty predictable. Worst of all, these algorithms tend not to have very interesting results -- invariably, facing this sort of AI is sort of like playing against another human, only stupider-yet-faster. Clever players are able to trick the AI by finding patterns and weaknesses in the algorithms, and the AI tends to be slow to respond to what the players are doing -- if it responds at all. This is after months of work on the part of some poor AI programmer(s).
Nondeterministic AI in other Games
In most modern AI design, nondeterminism is an important goal -- given the same inputs, the AI shouldn't always give EXACTLY the same output. Otherwise the AI is inhumanly predictable. The chief ways of combating this predictability are fuzzy logic (where inputs are "fuzzified," so that the outputs are also thus less precise) or some variation of a learning AI, which grows and changes over time (its historical knowledge makes it act differently over the course of its existence).
The problem with a standard learning AI is that it can easily learn the wrong lessons and start doing something strange. Debugging is very difficult, because it's hard to know what the AI thinks it is doing and why. Also, until it has some base amount of historical data, it seems that it will either be a) wildly unpredictable and unproductive, or b) using deterministic methods that make it predictable. It can be like teaching an amoeba to tap-dance -- but instead it starts setting things on fire, and you wonder what made it think that was part of what it should do.
Therefore, even with a learning AI, you're likely to have a pretty predictable early game. Plus, if the game supports saving, the entire historical knowledge of the AI would have to be saved if the AI is to keep track of what it was doing (and keep its learned intelligence). This can make save files absolutely huge, among other various disadvantages.
Semi-Stateless AI in AI War
For AI War, I wanted a nondeterministic AI that was not dependent on having any historical knowledge. Of course, this means a pretty fair amount of fuzzy logic by definition -- that is indeed in place -- but I also wanted some of the characteristics of a learning AI. Essentially, I wanted to model data mining practices in modern business applications (something I'm imminently familiar with from my day job). My rule of thumb was this: At any given point in time, the AI should be able to look at a set of meaningful variables, apply some rules and formulas, and come to the best possible conclusion (fuzzified, of course).
A human example: At chess tournaments, often the grandmasters will play against the normal-human players 40 or so at a time (purely for fun/publicity). The 40 lower-ranked players sit at tables in a ring around the room, each with their own chess game against the grandmaster. The grandmaster walks slowly around the room, making a move at each game in sequence. There is no way that the grandmaster is remembering the state of all 40 games; rather, he analyzes each game as he comes to it, and makes the best possible move at the time. He has to think harder at games where there is a particularly clever player, but by and large the grandmaster will win every game out of the 40 because of the skill gap. The general outcome is that the grandmaster picks the cleverest of the other players, and lets them win on purpose (if there is a prize -- if the grandmaster is showing off, they'll just beat everyone).
The AI in AI War is a lot like that grandmaster -- it is capable of coming to the game "blind" about once per second, and making the best possible choices at that time. Minor bits of data are accumulated over time and factored in (as the grandmaster might remember details about the cleverer opponents facing him), but overall this is not necessary. The AI also remembers some data about its past actions to a) help it follow through on past decisions unless there is a compelling reason not to, and b) to help prevent it from falling into patterns that the opponents can take advantage of.
Decentralization of Command In Other RTS Games
One important factor in creating an interesting AI opponent is that it must be able to do multiple things at once. In all too many games, the AI will just have one military arm moving around the board at a time, which is not what a human player would typically do. Where are the diversions, the multi-front attacks, the flanking?
In AI War, it was important to me that the tactical and strategic commanders be able to perform as many different activities as makes sense given the units at hand. Typically this would be accomplished by creating multiple independent "agents" per AI player, and assigning control each unit to a particular agent. You then run into issues of the agents having to negotiate and coordinate among themselves, but in AI War's semi-stateless environment it is even worse -- how do you intelligently divide up the units among these arbitrary agents if you have to keep reassigning them? And how to know when to spawn more agents, versus consolidate useless agents? These problems can all be solved, but they are not something to be attempted lightly, and nor will they be kind to the CPU. The central problem is that of resource management. Not only the delegation of control of existing units, but trying to balance tactical/strategic elements with the generation of resources and the production of new units.
Which brings me to my next point...
Resource Management In AI War
I struggled with the command decentralization issue for several days, trying to come up with a solution that would meet all of my many criteria, and ultimately came to a realization: what matters is not what the AI is actually doing, but what the visible effect is to the human players. If the AI struggles with all these things invisibly, burning up programmer hours and CPU cycles, and then comes to result A, wouldn't it be better to just shortcut some of that and have it arrive at result A? Specifically, I realized that the economic simulations had a very low payoff as far as the players were concerned. If I took out the human-style economic model for the AI -- no resources, no techs, just a generalized, linearized ship-creation algorithm -- what would the impact be?
First of all, this change makes it so that the AI players do not use builders, factories, reactors, or any of the other economy-related ships. This changes the gameplay to a mildly significant degree, because the human players cannot use the strategy of targeting economic buildings to weaken the AI. This is definitely a drawback, but in most RTS games the AI tends to have so many resources that this is generally not a viable strategy, anyway.
Having decided that this gameplay shift was acceptable, I set about designing a ship-creation algorithm. This is harder than it sounds, as each AI has to know a) what ships it is allowed to build at any given point in the game, b) how much material it is allow to spend per "resource event," and other factors that keep things fair. Note that this is NOT your typical "cheating AI" that can just do whatever it wants -- the AI plays by different rules here, but they are strict rules that simulate essentially what the AI would otherwise be doing, anyway.
Decentralization of Command In AI War
Now that the economy is handled, we are back to the issue of decentralization. Each AI is now allowed to build a certain number of ships of specific types during each resource event, but how to intelligently choose which to build? Also, how to decide what to do with the ships that already exist?
First off, the AI needs to divide its units into two categories -- offensive and defensive. Most games don't do this, but in AI War this works very effectively. Each AI decides that it wants to have a certain number of ships of certain types defending each planet or capital ship that it controls. It's first priority is production to meet those defensive goals.
Any units that aren't needed for defense are considered offensive units. These get handed over to the strategic-routing algorithm, which is described next. Each unit-producing ship controlled by the AI player will build offensive units based on a complex algorthm of fuzzy-logic and weighting -- the result is a fairly mixed army that trends towards the strongest units the AI can produce (and the favored units of a given AI type), but which never fully stops building the weaker units (which are always still useful to some degree in AI War).
Strategic Routing in AI War
The strategy planning in AI War consists of deciding what units to send to which planets. Defensive units tend not to leave their planet unless the thing they are protecting also leaves, so this pretty much just means routing around the offensive units.
This takes the form of two general activities: 1) attacking -- sending ships to the planet at which they should be able to do the most amount of damage; and 2) retreating from overwhelming defeats, when possible (no other RTS game AI that I have encountered has ever bothered with this).
The AI does not use cheap factors such as player score, who the host is, or any other non-gameplay variables in these sorts of decisions. All its decisions are based on what units are where, and what it currently calculates the outcome of a conflict is most likely to be.
Tactical Decisions in AI War
When it comes to tactical decision-making, this is actually one of the conceptually simpler parts of the AI. Each unit tries to get to its optimal targeting range, and targets the ships it is best able to hurt. It will stay and fight until such time as it dies, all its enemies are dead, or the Strategic Routing algorithm tells it to run away.
AI Types in AI War
When I think about the human-emulating AI found in most RTS games, it strikes me that this is extremely limiting. In most genres of game, you face off against a variety of different enemies that have powers that differ from those of the human players. Some opponents are vastly stronger, others are weaker, and all are distinctive and interesting in their own way. In RTS games, everyone is pretty much the same -- or at least things are balanced to the point of approximate fairness -- and I think this harms the longevity of these games.
What seems more interesting to me, and what I've decided to do in AI War, is to provide a wide variety of types of AI, each with their own strengths, weaknesses, and genuinely unique behaviors. Some have ships that the player can never get, others start with many planets instead of one, some never capture planets but instead roam around the neutral planets as lawless raiders. The possibilities are endless, especially when playing against multiple AI types in a single game.
The result is situations that are often intentionally unfair -- as they would be in real war. You can simulate being the invading force into a galaxy controlled by evil aliens, or simulate the opposite -- they're invading you. I think of this as being rather like the situation in Ender's Game. You can have AIs that are timid and hide, or others that come after you with unbridled aggression -- Terminators, or Borg, or whatever you want to call them. Some will use strange, alien combat tactics to throw you off guard, while others will routinely use confusing diversions to mask what their true objective is. Others will outclass you in terms of technology from the very start, others will have vastly more manpower but inferior technology -- the list goes on and on.
The whole goal of a game like this is to provide an interesting, varied play experience for the players. If all the AIs are essentially the same except for their general demeanor (as in most other games), that doesn't provide a lot of options. AI War's style of varied AIs is not "AI cheating" in the traditional sense -- each type of AI has specific rules that it must follow, which are simply different than the rules the human players are held to.
Think of this as the offense and defense in a football game: each team has wildly different goals -- one to score, one to not let the other team score -- but the overall success of one team versus another is determined based on how well they do in their respective goals. In football, the teams also routinely switch off who is on offense and who is on defense, and that's where the analogy to AI War starts to break down a bit. In AI War, it would be more like if one football team always played offense, but the defenders were allowed to have an extra three guys on the field. Maybe the defenders could only score by forcing a turnover and running the ball all the way back, but that would be significantly easier due to the extra players.
The AI Types in AI War are like that -- they unbalance the rules on purpose, not to cheat, but to provide something genuinely new and varied.
The Future of AI in AI War
At present, the AI does not yet make very interesting tactical decisions -- flanking, firepower concentration on key targets, etc. These and other "behaviorlets" will be added to future iterations of the AI. The AI will evaluate the behaviorlet conditions during tactical encounters, and employ them when it deems it makes sense to do so.
In fact, this concept of "behaviorlets" is the main thing that is left to do with the AI all across the board. Right now the AI is very by-the-numbers, which makes it predictable except where the fuzzy logic makes it somewhat randomized. This is comparable to the end state of many other RTS game AIs (yet it took me days instead of months or years), but with the architecture of AI War, I can continue to add in new "behaviorlets" in all aspects of the AI, to make it progressively more formidable, varied, and human-seeming. Example behaviorlets include scouting, sniping, mine laying and avoidance, using staging areas for attacks, economy targeting, use of transports, planet denial, and more. All of these things can be programmed into the existing architecture with relative ease; the complexity is bounded to the behaviorlet itself, rather than having to worry about how the behaviorlet will interact with larger elements of (for example) your typical AI finite state machine. This makes for a very object-oriented approach to the AI, which fits my thinking style.
Computer Requirements
This is a very modular AI system that can be extended over time, and yet it is also extremely efficient -- it is already able to control tens of thousands of ships without significant slowdown on a dual-core computer. However, it is being designed with dual-core computers in mind, and it is highly unlikely to run well at all on a single-processor computer.
On the other hand, the AI logic is only run on the game host (also unusual for an RTS game -- possibly another first), which means that single-threaded computers can join someone else's multiplayer game just fine. Given that this is the largest-scale RTS game in existence at the moment in terms of active units allowed during gameplay (by at least a factor of two), this is also pretty notable.
In Conclusion (We Return To The Present)
As noted at the start of this article, the main body of this article was written when the game was still in alpha stages, with the prior few months having been spent testing out the mechanics, the networking, the graphics pipeline, etc, in pure player-vs-player (pvp) modes. I had spent a week or so with the AI in a more traditional model, and felt like that was not working the way I wanted on any level, and so I decided to go back to the underlying principles of what I was trying to accomplish to see if there was a simpler approach.
After a few more days of thought, and then maybe three days of coding, I had a basic prototype of the AI working. I wrote this article then to let my alpha testers know what I was planning, and then spent the next three months refining, expanding, and completing the AI (and the rest of the game) before a beta in April. The game spent a month in beta, ironing out bugs and balance issues, and then went on sale on the Arcen site and then Stardock's Impulse in May.
This asymmetrical AI is the aspect of the game design that is most commonly criticized by other programmers or game designers who have not actually played the game. From my growing list of players, and the few reviews that the game has received so far (our exposure is still low, but growing due to the game's huge popularity on Impulse and elsewhere), this hasn't seemed to be an issue for anyone who actually plays the game. That comes back to my core realization with the AI: it doesn't matter what the AI is really doing, it matters what the AI seems to be doing, and what it makes the player do.
This style of AI creates a lot of unique gameplay situations, provides a good, fair-seeming challenge, and in general provides a degree of variety you don't encounter with other AIs. This isn't going to power sentient robots anytime soon, but in terms of creating an interesting game it seems to have paid off. That's really the goal, isn't it? To create a game that people find fun, challenging, and interesting? To get too hung up on the semantics of one approach versus another, and which is more "authentic" is counterproductive in my book. We really ought to have more games experimenting with various approaches to AI design, because I think it could make for some really fun games in all sorts of genres.
Next Time?
I have a number of other articles planned about the game, most notably a series on game design ideas that flopped for one reason or another and thus didn't make it into the final game -- an exploration of the failures-along-the-way is always fun and illuminating. But as far as the topic of AI goes, I've covered all of the points I set out to cover. Unless readers bring up more topics that they'd like me to address, this will probably be the final article in my AI series.
Part 5 of this series is a transcript of a discussion about the desirability of slightly-nonideal emergent decisions versus too-predictable "perfect" decisions.
AI Article Index
Part 1 gives an overview of the AI approach being used, and its benefits.
Part 2 shows some LINQ code and discusses things such as danger levels.
Part 3 talks about the limitations of this approach.
Part 4 talks about the asymmetry of this AI design.
Part 5 is a transcript of a discussion about the desirability of slightly-nonideal emergent decisions versus too-predictable "perfect" decisions.
Part 6 talks about player agency versus AI agency, and why the gameplay of AI War is based around keeping the AI deviously reactive rather than ever fully giving it the "tempo."
Range Checks - Approximation vs Accurate
Range checking is a hugely important topic for AI War, since it is relevant for targeting, movement, and calculation of other values such as danger levels, etc. So some of the key optimizations that I talked about in the past had to do with using distance approximation methods instead of more highly accurate distance calculations.
Here's the accurate distance calculations:
public static int DistanceBetweenPoints( Point P1, Point P2 )
{
int xd = P2.X - P1.X;
int yd = P2.Y - P1.Y;
FInt preSqF = (FInt)( ( (long)xd * (long)xd ) + ( (long)yd * (long)yd ) );
int val = Sqrt( Abs( preSqF ) ).IntValue;
if ( val < 0 )
return -val;
return val;
}
public static FInt DistanceBetweenPointsF( Point P1, Point P2 )
{
int xd = P2.X - P1.X;
int yd = P2.Y - P1.Y;
FInt preSqF = (FInt)( ( (long)xd * (long)xd ) + ( (long)yd * (long)yd ) );
return Mat.Abs( Sqrt( Abs( preSqF ) ) );
}
public static double DistanceBetweenPointsD( Point P1, Point P2 )
{
int xd = P2.X - P1.X;
int yd = P2.Y - P1.Y;
return Math.Abs( Math.Sqrt( Math.Abs(
( ( (long)xd * (long)xd ) + ( (long)yd * (long)yd ) ) ) ) );
}
Three different variations there show you how to get an integer, double, or fixed-integer format result. This uses my FInt struct, which you can get the full source code for over at StackOverflow.
Those are the less-efficient methods of calculating a range check, and I've posted them mostly for illustrative purposes. If you need a highly accurate range check, or if you need to just run a few range checks, by all means use those. However, they run vastly more slowly than a distance approximation method primarily because of the use of the Sqrt function (either the FInt version below, or the built-in .NET one for doubles). Sqrt is a surprisingly expensive call in terms of CPU, because it is an iterative function. See below:
public static FInt Sqrt( FInt f, int NumberOfIterations )
{
if ( f.RawValue < 0 ) //NaN in Math.Sqrt
throw new ArithmeticException( "Input Error" );
if ( f.RawValue == 0 )
return (FInt)0;
FInt k = f + FInt.OneF >> 1;
for ( int i = 0; i < NumberOfIterations; i++ )
k = ( k + ( f / k ) ) >> 1;
if ( k.RawValue < 0 )
throw new ArithmeticException( "Overflow" );
else
return k;
}
public static FInt Sqrt( FInt f )
{
byte numberOfIterations = 8;
if ( f.RawValue > 0x64000 )
numberOfIterations = 12;
if ( f.RawValue > 0x3e8000 )
numberOfIterations = 16;
return Sqrt( f, numberOfIterations );
}
All of this goes to show the need for a distance approximation method when you don't need quite as high a degree of accuracy, or when you only need to tell relatively how far apart two points are compared to one another. In AI War's case, this is good enough for 99% of all distance checks. The only times I need to use the more CPU-intensive, precise methods above is as a final check when ships are moving the last little bit of space in towards a destination, and other similar situations. Everywhere else, the following distance approximation method is instead used:
EDIT: Thanks to a reader comment, I finally have the original source for this again: Rafael Baptista The approximate distance function is all his, and his article does a great job of explaining the way the accuracy works. Please his article for the approximation method used.
Here's the accurate distance calculations:
public static int DistanceBetweenPoints( Point P1, Point P2 )
{
int xd = P2.X - P1.X;
int yd = P2.Y - P1.Y;
FInt preSqF = (FInt)( ( (long)xd * (long)xd ) + ( (long)yd * (long)yd ) );
int val = Sqrt( Abs( preSqF ) ).IntValue;
if ( val < 0 )
return -val;
return val;
}
public static FInt DistanceBetweenPointsF( Point P1, Point P2 )
{
int xd = P2.X - P1.X;
int yd = P2.Y - P1.Y;
FInt preSqF = (FInt)( ( (long)xd * (long)xd ) + ( (long)yd * (long)yd ) );
return Mat.Abs( Sqrt( Abs( preSqF ) ) );
}
public static double DistanceBetweenPointsD( Point P1, Point P2 )
{
int xd = P2.X - P1.X;
int yd = P2.Y - P1.Y;
return Math.Abs( Math.Sqrt( Math.Abs(
( ( (long)xd * (long)xd ) + ( (long)yd * (long)yd ) ) ) ) );
}
Three different variations there show you how to get an integer, double, or fixed-integer format result. This uses my FInt struct, which you can get the full source code for over at StackOverflow.
Those are the less-efficient methods of calculating a range check, and I've posted them mostly for illustrative purposes. If you need a highly accurate range check, or if you need to just run a few range checks, by all means use those. However, they run vastly more slowly than a distance approximation method primarily because of the use of the Sqrt function (either the FInt version below, or the built-in .NET one for doubles). Sqrt is a surprisingly expensive call in terms of CPU, because it is an iterative function. See below:
public static FInt Sqrt( FInt f, int NumberOfIterations )
{
if ( f.RawValue < 0 ) //NaN in Math.Sqrt
throw new ArithmeticException( "Input Error" );
if ( f.RawValue == 0 )
return (FInt)0;
FInt k = f + FInt.OneF >> 1;
for ( int i = 0; i < NumberOfIterations; i++ )
k = ( k + ( f / k ) ) >> 1;
if ( k.RawValue < 0 )
throw new ArithmeticException( "Overflow" );
else
return k;
}
public static FInt Sqrt( FInt f )
{
byte numberOfIterations = 8;
if ( f.RawValue > 0x64000 )
numberOfIterations = 12;
if ( f.RawValue > 0x3e8000 )
numberOfIterations = 16;
return Sqrt( f, numberOfIterations );
}
All of this goes to show the need for a distance approximation method when you don't need quite as high a degree of accuracy, or when you only need to tell relatively how far apart two points are compared to one another. In AI War's case, this is good enough for 99% of all distance checks. The only times I need to use the more CPU-intensive, precise methods above is as a final check when ships are moving the last little bit of space in towards a destination, and other similar situations. Everywhere else, the following distance approximation method is instead used:
EDIT: Thanks to a reader comment, I finally have the original source for this again: Rafael Baptista The approximate distance function is all his, and his article does a great job of explaining the way the accuracy works. Please his article for the approximation method used.
Saturday, July 18, 2009
techZing 10 - AI War
"Justin and Jason talk with Christopher Park, founder of Arcen Games and developer of a space-based RTS game called AI War: Fleet Command, about how he was able to release a sophisticated computer game in under seven months and create a formidable artificial intelligence in only a matter of weeks. The discussion also covers the marketing of an independent game, cooperative game play, multi-threading, optimizing .NET, LINQ, GPUs, SlimDX and the future of artificial intelligence."
Listen to this podcast on techZing!
Listen to this podcast on techZing!
Subscribe to:
Posts (Atom)