Good find Spelk.

I liked this info too. 30,000+ units in over 80 battlefields at the same time. That's what you call scope.

Here are some tutorial videos of the game that are buy the devs and very informative.

Oh moving this post to the Space RTS area. And a link to this website will be added to the link list.

Darkone, thanks for posting the extra info with the videos, etc for the game. I'm actually the developer of the game (we're a new, small indie shop), so it's really nice to see positive word of mouth spreading about the game. Thought you might be interested to know that the "30,000+ units" claim that we make is actually on the low end of what actually happens in the games.

In a single player game against a pair of level 7 AIs, it generally starts with about 20,000 units in the game and then creeps up to 35,000 or so over the course of 10-12 hours. Out of that, you'd be controlling 3,000 to 8,000 ships by the end (depending on what kinds of ships you specialize in, etc), and the AI would have the rest.

In a 4 player game, with a pair of level 7 AIs, it generally starts more like 30,000 units and then creeps up to 55,000 or so ships.

On the extreme end of things, with 8 players and two level 10 AIs and a 120 planet map, you're going to start off with 60,000 ships and go up from there. Until the version 1.004 version (which comes out this Tuesday/Wedndesday), only the most top-end CPUs (3Ghz or more on the first core) could run this extreme particular simulation without some slight lag at the least, but in the 1.004 version it has a performance improvement that lets me run that scenario at double speed, which is pretty cool. So presumably, if you had a really long and hard 8 player game on the largest (120 planet) map, against the very hardest AI types, you could get up to around 120,000 ships without much or any lag on your average 2.4Ghz CPU.

Thought you might find those aspects interesting, since the unit counts caught your eye. 🙂

First off, Welcome X4000.

Always great to see devs talking about there games and answering questions (WOW you got here quick this was posted yesterday). It is really the main reason why I made the site, I want to let people know about all these space related games out there (and there is a lot of them). And I try to encourage devs to please post and talk about there games and updates to them.

But back to AI War. In excess of 30-60k units in a game at once that is truly impressive. I guess i'll be the first one to ask the how is this done questions.

1. This is a multi-player based game so I take it the game load is distributed across the players systems that are playing?

2. I know in the when playing MMO's and if you had a few hundred people on the screen in combat your screen started skipping and there was lag. How can you accomplish 30K units with minimal or no lag/skipping? I know you mention multi-threaded host for the AAI so does this mean the players machines have to be fairly beefy in specs or are you doing the multi-threading in software?

I thought this was a nice feature since the game lengths can be in excess of 10hrs:

Thanks X4000 for answering some of the questions and when I get some time I will try and play the demo. And give people more of simple review. But those tutorials are very nice to get going.

-D1-

Thanks for the welcome, Darkone. I keep an eye on incoming links to the Arcen Games site, so that if people are talking about the game around the 'net and there is something I might be able to add, I can. It's a shame for good questions to go unanswered. 🙂

I'm all for it! It's sometimes a little bit like pulling back the curtain and seeing the real Wizard of OZ (technical trickery is rarely as spectacular as we might imagine they would be), but my alpha testers know how all this works and still find the game quite engaging, so I don't think this would ruin anyone's experience, haha. Personally, I've learned to steer clear of "behind the scenes" stuff with movies, because it takes away something for me, but with games I'm always wanting to know all the tricks (as a dev, I guess that's kind of obvious). But, to your actual questions:

Ah, this is a really great question, I'm surprised no one has actually asked me this before. This is so good, it's actually going to be the basis of my next article about the game. 🙂

The game load idea is a good one in theory, but in an RTS game that just wouldn't be feasible except maybe on LAN games because of the frequency at which state of each of the units is changing. There is just too much unit data to pass back and forth, so all of the processing for the game simulation itself has to be run on all the computers in the game. Years ago there was a great article on Gamasutra called 1500 Archers on a 28.8: Network Programming in Age of Empires and beyond. That's a rather technical article, but it basically outlines the approach that pretty much all RTS games use to their networking and simulation. AI War is no different, and in fact as the unit counts go up we are even more dependent on this approach because there is even more data in the simulation.

The big difference in AI War from any other RTS game that I know of is how the AI is handled. Essentially, what we did was separate out the real "thinking" portion of the AI into a separate thread. Most non-programmers don't know this, but that actually requires an entire copy of all of the relevant game data for the secondary thread (two threads cannot easily share data, or you get all sorts of "locking" and "blocking" issues that very much adversely affect performance). Anyway, so the main game thread passes data to the secondary AI thread, which then analyzes it on its own time and passes commands back to the main thread.

So far, most of that is done by other recent RTS games, such as for example Supreme Commander. The key difference here is that our AI thread is only run on the host computer. If you read the 28.8 article above, you already know that player-issued commands are requested during one 200ms "turn" and then simultaneously executed in the next turn by all computers in the game. My reasoning was: why can't the AI issue commands in the same way? Even though the commands often have different content from human-issued commands (since the AI has some differences in how it manages its economy, etc), but the same basic approach works without increasing network load too heavily, and without requiring an AI simulation on any machine other than the host.

All of this multithreading basically gets us to the point where the AI is on the host only, so the host greatly benefits from multiple cores, and yet the rest of the simulation is run on all of the clients in a game, and thus the primary requirements for the main processor in a game is the same all computers in the game. In early versions of the game, we topped out at around 10,000 units in a game before lag set in, but through a series of optimizations on our simulation code I got that up to 60,000 units, and now that number has increased to theoretically around 120,000 units (though I have never run more than 80,000 units in one game, since that just doesn't happen very much).

Mainly the optimizations were something that just required thought, code profiling, and lots of time and testing (more on that in a minute), but there were also a few key advantages that I had based on the design of the game itself:

1. The game is set in space, and I am treating it as pseudo-3D space even though the game is 2D (aka, ships can pass one another because they are presumed to be on slightly different Z axes). This meant that collision-detection between ships is not really a major focus of the simulation, since the only thing that really stops movement is force fields. There are still shot-collisions, and collisions with mines, but I was able to get a lot of optimizations out of this aspect of setting the game in space in the manner that I did.

2. The game is set in space, and so the straightest path between two points is always a line. So that means that pathfinding, which is a huge part of the CPU load in terrestrial RTS games, was a nonfactor for AI War. That freed up some CPU cycles to do something else -- in my case, I decided to have much more intelligent auto-targeting of ships in the game, using that CPU that the lack of pathfinding freed up. This ultimately started using even more CPU than pathfinding typically does, but later optimizations resolved that. Side note: my other game, Alden Ridge (which is not yet released, but actually predated AI War in terms of development), has very heavy pathfinding as part of the core of it. I actually found some awesome ways to optimize pathfinding for that other game, but scaling that up to an RTS game would have been a challenge.

3. Like many space-based games, AI War is divided up into individual planets. This is a huge benefit to processing the simulation, because when two ships are on different planets, you know there can't possibly be any interactions between them. This basically acts as a massive pre-sorting of all the ships, so that when you are doing things like target-selection or collision detection or whatever, you are working with smaller batches of ships at a go (which can still be in excess of 5,000 or 6,000 ships at once, but it's not likely there would ever be 60,000 ships all in one system).

Okay, so those were the advantages that the overall design created for me, and I decided to make full use of them. But even with those advantages, some serious optimization was needed in order for the game to support even 20,000 units (which is about double what you see in the largest versions of most other large games in the genre). These optimizations were integrated on an ongoing process through our alpha and beta development, and even now occasionally one occurs to me and I put it in (such as with the 1.004 release).

Here's a list of a few of the key optimizations that were made:

1. Fixed-int math is used instead of floating-point. This was needed to insure consistent simulations between differing CPU architectures, but it is also faster. A lot of handheld consoles, like the DS for instance, doesn't even have a floating-point system and so fixed-point math is always used there. There were not many good examples of fixed-point math that I could find in C# (the language AI War is coded in), so there was some discussion on StackOverflow on how to do this best. If you are curious, here it is, along with the working code I ended up with for that: http://stackoverflow.com/questions/605124/fixed-point-math-in-c

2. Through profiling, I discovered that the single-biggest CPU eater in alpha versions of the game was range checks. As in, "how far apart are these two objects?" Range checks are needed for all sorts of things, from collision detection to target selection to moving to a destination point. The range checks were particularly slow because the standard formula involves taking a square root, which is expensive in terms of processor (it is an iterative function in programming -- it makes 16 guesses, each of which gets closer to the real square root). With so many ships in the game, I was often having half a million range checks or so per second, and that was really limiting with the square root in there.

The solution turned out to be to move to a square-root approximation method (which unfortunately I don't have the link to, but it was a C implementation that I converted to use in C# -- if another dev or anyone else wants my code for that, I'll post it). Anyway, the realization was that most ranges don't need to be super precise, because it's more a question of "which ships are relatively closer." But even for things like movement and collision detection, the less precise range checks work until units are very close together, and then I switch to the more precise, more CPU-intensive range check. But that really mitigates the CPU load, and now the game sometimes is running more than a million range checks per second without any slowdown.

3. Like most games, AI War has a game loop. It's runs 22 iterations per second, which through testing was determined to be the sweet spot for having a reasonable framerate but the best possible performance on midrange PCs. So this was a bit of a cheat, but no one has commented or has even seemed to notice. When given the choice between a 60fps game and a game that has huge numbers of units making complex decisions, I opted for the latter.

4. One sizable optimization involved calculating movement more efficiently. Units move at all sorts of angles in AI War, like in most RTS games, and I'm not using a sub-pixel position scheme, so that means that floating-point style math (fixed point math in my case) is needed. Basically, to move from point A to point B, a ship must move at a certain angle, but as the ship moves that angle changes slightly because of the integer nature of the pixel coordinates. So the tendency is to recalculate every ship's movement angle (and thus the x/y components of that movement by taking the sin and cos), and that gives smooth, perfect lanes of travel.

That works great, but optimizations are sorely needed when you start talking about 30,000+ moving objects (which can happen if you play against two of the Special Forces Captain AI types, which have very few non-moving ships). The trick I am using is to only recalculate the angle every 1 turn (so roughly 4 times per second) instead of once per cycle (which would be 22 times per second). The difference is imperceptible to the players -- even I can't tell a difference visually, but I'm doing much less processing for movement.

5. Another big optimization was to do with collision detection. Ships are not allowed to stop on top of one another, so whenever a ship reaches a destination point it must check to see if it is on top of other ships, and if so then move to an open space. This is iterative, and as you can imagine eats up a lot of CPU on planets with many ships on them. If a lot of ships are collision-detecting at once, the CPU starts to flag, which in alpha versions would cause a lot of lag when big fleets came out of a wormhole, etc.

The solution was to spread out the collisions of this sort, since there's not really a practical reason that they have to be done right away. The game thus only processes 25 collisions of this sort per CPU cycle, or 550 per second. This means that sometimes you see ships bunch up when coming out of a wormhole or all moving to a big point, and then they fly out of the center in waves, which is actually a very cool visual effect that was completely unintentional to start with. Bear in mind that this is just referring to collision detection for ships that might have started on one another -- when talking about collisions with force fields or mines, that happens in closer to realtime, but there are fewer cross-checks to do with those, so that works out CPU-wise.

6. Pre-sorting of ships was a huge improvement across the board for AI War, and I don't think most RTS games bother with this because their unit counts are often too low to really see much of a benefit from it. I come from a SQL database background, though, where indexing tables is a key to good performance. That's another programming environment with vast numbers of data points (a table with 100,000 rows is a pretty small one), and I took a lot of ideas from my experience there. Basically, whenever I need to make decisions about ships, I pre-sort them into smaller per-purpose collections that can be looped over much more efficiently. These sorts of rollups cause more load when a new ship is created or when it moves from one planet to another, but that's a minuscule difference that is not compounded by looping, and it makes for huge gains in later processing.

7. Commands that are sent across the network are batched and compressed before being sent. All of the requested commands (from human players and the AI) are batched on the host computer and then compressed as one big chunk and sent via TCP to the clients for decompression, parsing, and execution. This works well with the 200ms turn-based approach outlined in the 28.8 article above. Having commands to 4,000 units actually compresses pretty well, so you tend not to see any network lag on broadband connections even with 4 or more players. But you do need to turn off any background upload/download processes going on, because those can be hefty. And if the game host's connection is less than ideal, or there are a lot of players in the game, then one of the clients should be the voice chat host (using Skype or Teamspeak or whatever).

It might surprise other devs that we are using TCP instead of UDP, but we wanted robustness and reliability over speed. With compression, we already had all the performance we needed and more, even with so many units in the game. I actually started out with a UDP solution in early alpha versions, but it was problematic in many ways and so I just recoded everything using TCP sockets, and I've been much more pleased with the results of that.

8. The last major optimization I'll talk about is to do with target selection. The AI thread and the human players of course do a lot of the target selection themselves -- choosing targets to chase, or to move over to, etc. But one of the nice things about spaceships is that they can typically fire while moving. So if ships don't yet have a target, or are not yet in range of their AI/human-given target, they should shoot at whatever they pass on the way. And if they are left unattended somewhere by the player, they should shoot at whatever comes in range. And if players put them in attack-move mode or the new "free roaming defender" mode from version 1.004, then the ships need to respond to threats in an automated fashion. Plus then you have engineers which need to find targets to repair or assist, and you've got tractor beams that need to look for targets to grab, and tachyon beam emitters that need to find targets to tag, etc. All of this happens as part of the main simulation thread, because it needs to happen on an interval shorter than once per 200ms turn, which is the interval on which human/AI commands are issued.

Target selection thus became the single biggest bottleneck for having more units in the game, and especially for having thousands of ships from multiple teams on a single planet. There were a lot of small optimizations that I made with this process (the range-check efficiency improvement that was already mentioned being one key one), but the biggest thing was to also stagger these target selection checks. The game currently processes around 1,100 target-selection-checks for ships per second per player. In a game with 60,000 ships, that might not sound like a lot, but never fear -- there are rarely more than 10,000 ships all in battle at one time, and that's even a rare case with most battles being between 1,000 and 3,000 ships. The other things is that since that is per player, if you have 60,000 ships in your game you probably have at least 4 players, so that would only take it around 13-14 seconds to do a full target selection loop for all ships -- but in reality, as I've said already, it takes much less time since not all ships are in battle and they don't require target selection checks if there are no enemies on their planet.

9. Related to the target-selection optimization, I'll talk briefly about the optimization in version 1.004 that lets the game make the leap to almost double capacity. Basically, I came to the realization that if there were 50,000 ships sitting on enemy planets that I am not attacking, and there are only 10,000 ships that I am actively engaged with attacking or defending against at the moment, then I can completely ignore those other ships unless they have specific orders (like moving or collision-detecting, etc). This lets the CPU be concentrated on ships that actually need it, and those other ships just don't do anything. This is an easy state to detect because of all the rollups in point 6 above.

Whew! That's it for now on that subject. Let me know if you have more questions, but I suspect that may already be more than you wanted to know. 😉

Well, this is another great question. As I mentioned in my above response, the AI thread is run only on the host, so the requirements there are heavier. The host probably needs to be a dual core 2.4Ghz machine for the highest difficulties and for multiplayer games, but a 2.4Ghz machine works reasonably well as the host of a single-player game. There are really two parts to your question there -- on-screen characters causing lag, and then other general performance considerations. I've already addressed the latter, but I haven't talked at all about graphics performance just yet.

The game is 2D, but it uses Direct3D9 under the hood. That lets us do 3D effects like the zoom (the parallax effect of the planets is just a simple parallax effect, it's not true Z depth), and it also lets us take advantage of hardware acceleration. There were a lot of optimizations we had to make in that part of our engine (which is custom from the ground up, by the way), but those are fairly standard and prosaic, so I won't bore you with those.

For lower-end graphics cards, showing a few thousand ship sprites at once can still be a challenge because of the way that the graphics card has to do texture state changes. So we have a settings option that lets the game do more efficient sorting for the graphics card, but which does cause some strange/incorrect graphical overlap on occasion when you are all the way zoomed in. Most players don't even notice the difference, and the increase in performance is notable if you are on a laptop card (as two of our alpha testers were) or a card that is more than three or four years old.

Oh yeah, there's no way anyone would want to play a campaign all in one go. Or at least not on a regular basis. 🙂 If you plan for multiplayer saves from the start, it's really not a hard feature to program. And it fits right in with a lot of the other optimizations that are made in terms of rollups, etc, in the game. A lot of games these days seem to practically just do a partial memory dump as a savegame (resulting in 50MB+ save files in Neverwinter Nights, for example), and thus multiplayer save becomes infeasible. There are a lot of benefits, multiplayer save and peformance perhaps chiefly among them, to using a more database-style approach to a game's internal object structure. A number of other recent games, like Sins of a Solar Empire, also look to be using a similar sort of approach for this.

No problem!

I cobbled together a brief review of the game, so far

http://www.ukgamer.co.uk/2009/06/ai-war ... mmand.html

In my little spare time I have been trying to play through a simple match in AI Wars to compile some questions (more gaming and direction questions). I know I'm getting older and the brain doesn't react like it used to so I may have some newbish style questions x4000 🙂

But please if you have any questions you wish to ask x4000 please post them here or send them to me to get them answered. Download the demo http://www.arcengames.com/aiwar_buy.php .

Hey, no worries, I'm always open to any questions! 🙂

A bit late to report it here, but Chris (the developer of AI War, aka x4000) agreed to do an interview for UKGamer about AI War and indie development, so heres the link to it..

http://www.ukgamer.co.uk/2009/07/interv ... i-war.html

Well Arcen Games has been busy improving and adding on to AI War. Update V1.301 was released a few days ago and with reading over most of all the notes from my test release that was at v1.006 here has been quite the few changes to AI War.

Checkout some of the updates and changes to AI War here: http://arcengames.com/forums/index.php/ ... 422.0.html

With v2.0 coming soon I would suggest you download the latest demo and give it a try.

Get demo here: http://www.arcengames.com/aiwar_buy.php

Thanks for the post, Darkone! Glad to see AI War is still getting some love over here. 🙂

I do my best to make the rounds x4000 🙂 Sorry took me this long to get the thread updated. But the obvious I noticed over the v1.006 demo build is the graphic updates that you have made.

With all those fixes and updates you have been making for AI War i'm surprised your still able to read other websites. Those release notes are pretty large, always great to see developers supporting their games. That's one of my biggest buying points when looking at games now is whether the development house has the rep for supporting there customers.

I read that the next DLC will be a addon pack which will have a small cost to it. But is that considered v2.0 of AI War?

No worries on the timing! Yes, it's definitely been a busy few months, that's for sure. The 2.0 version of the game will be free, and we'll still be having free DLC periodically on pretty much an ongoing basis. The only paid updates are going to be our expansion packs, the first of which (AI War: The Zenith Remnant) will be going on preorder in October. That's a $12.99 expansion, and includes a bunch of new content. The balance tweaks, bugfixes, interface/AI adjustments that are made, even as "part of the expansion" will be free to all customers of the base game, and we'll keep doing free DLC in the form of a few ships now and then even as the expansions, and other future titles, are worked on.

More exposure for AI War

http://diehardgamefan.com/2009/10/16/re ... ommand-pc/

Looks like its coming to Steam soon..

http://thereticule.com/2009/10/chris-pa ... -part-one/

http://thereticule.com/2009/10/chris-pa ... -part-two/

http://www.co-optimus.com/interview/305 ... igner.html

If you've been holding off this title until now, it might be time to take the plunge..

Also version 2.0 just been released as of the 21st. Here is a good link showing the improvements and differences between 1.0 and 2.0.

http://arcengames.com/aiwar_20vs10.php

They must have changed their minds about it being free since everywhere I look asks for 19.99$.

No it is free as long as you have the 1.0 version. You can download it here: http://www.arcengames.com/share/AIWar1000To2000.zip

The expansions cost $$$ but the 2.0 AI Wars is still the same price the org 1.0 was. Steam is selling this one this week cheap... http://store.steampowered.com/app/40400/

Cheers, I'll check that Steam copy out.

Yeah, sorry about the confusion there. What I meant was that all of our patches are free, even the really big ones like 2.0. The base game itself, and the expansions, are the only things that cost any money. And patches and DLC that come out after the expansion is out will still be free for people without the expansion, to boot. Thanks for your interest in the game!

Looks like Arcen Games has been busy and has released a new expansion to AI War, called The Zenith Remnant.

Some of the new features you will see are:

* 122 new ships, including:

- 14 new ship classes with a variety of abilities.

- 7 massive capturable "Golem" ships.

- Dozens of other new capturables, including Experimental ships.

* 12 new AI Types.

* 4 Zenith alien minor factions (NPCs).

* Over 40 minutes of new in-game music tracks.

* Several new map styles.

* Several new AI behaviors and many related special AI weapons.

You can try the demo here: http://www.arcengames.com/aiwar_buy.php

And if you like it you can buy the whole game with expansion for $19.95.

[youtube][/youtube]

Yeah, it's been a busy time all right -- gah, I meant to post about that here, but I've been so backlogged with work. We've tripled our playerbase since November, and the resulting flood of correspondence has been overwhelming. Thanks for posting about it!

Looks like there is a good sale on right now on the entire AI Wars Bundle on Steam

http://store.steampowered.com/sub/8281/

Get the whole collection for $4.24