Thanks for the added explanation -- and I'm glad you found the second article more interesting. It has only one audience (programmers), which makes it easier to write. The other perhaps has too many target audiences. Switching up the relative weights of the preferences, and having the AI retain information and learn over time, is quite interesting. Beyond the scope of what I can probably accomplish in this game simply because of data size issues and such in a networked game (unless the AI had a permanent local database, and each computer's version of the game would thus have different intelligence). But very interesting, and I suspect I will probably try something more advanced along those lines in the future.

That's under discussion, but the game is coded in C# .NET 3.5, which currently isn't supported by mono. As mono progresses, we'll be looking at porting it -- aside from the .NET 3.5 support, assuming that performance in Mono holds steady with the main .NET Framework for things like LINQ, there should be a Linux/Mac port sometime in the future.

This is a really interesting post, and some of it goes a little bit over my head. Like I've said, I'm a database programmer, not an AI programmer. I might experiment with things like neural networks and such in the future, but right now the AI is doing as well as I could possibly hope for. That was a big part of the point of my article: using the fancier techniques is not even always needed for something like an RTS game, because you can get surprisingly good results with comparably little code.

I'm sure I will experiment around with this more in the future, but I bet you somebody else builds on my approach and does something more impressive before I even can. Anyway, future articles in my aI series will go more in-depth and will also include relevant code snippets to help illustrate my points. Feel free to use and abuse them, and expand away.

The second article is now up, to appease those hungry for some source code and a bit more of an in-depth discussion on a couple of sub-topics: Designing Emergent AI, Part 2: Queries and Code.

I'm not going to release the game for free, given that if I'm to be able to continue to pursue game development it can't continue to be in my hobby time forever. For similar reasons, I'm not going to release the entire code as open source. However, I've already open-sourced a lot of smaller things from my code (force feedback code from my other game, fixed-int math from this game, etc). Also, I've now added a second part to the article which has some partial AI code from the game, and people are free to use the ideas there and build off of them as much as they want. I don't want people to make AI War clones, but rather to think about the ideas that I am presenting and implement them in their own way. The AI War code is not the only way to approach this general design philosophy, not by a long shot. Here's part 2 of the article, with the added code and such: Designing Emergent AI, Part 2: Queries and Code

And we give credit to Daniel Cook in exactly the manner he requests. Really awesome of him to provide that sort of art for free, indie games are the better for it.

The game isn't online, it's client-server between players. The "host" is just another player.

Quite valid -- intelligent agents are not a new idea (I'm the dev from the article). However, the vast majority of RTS games are still using decision trees, I guess because the prevailing wisdom is that such is needed because of the complexity of RTS play. Is it so surprising that industry lags behind academia? But, even my approach is not purely an intelligent agent approach, but rather combines in a bit of global logic as well (for reinforcements, choosing global attack targets, etc). I think that a hybridized sort of approach is really needed for RTS games, since they do have so many levels at once.

Hi there -- I'm actually the dev from the article. This is a very interesting suggestion, and I'm sure that people will try this at some point. My main issue with that approach is that it requires a huge amount of ongoing data, which I'm not sure quite how to deal with at this stage. But like I've said, I'm fundamentally a database programmer and not an AI programmer. With my approach, what I wanted to do was have basically a "stateless" set of AI logic, which could look at any given situation and make a decision based on what it sees. Kind of how an expert chess player can look at any chess board and tell you the best (or at least a very good) next move. They don't need to historically see what the other player was doing. I think there's room for both approaches, but I went with what I know (naturally).