Category: Most Popular

Review games on Steam that you love — or hate. “Results are determined by those who show up.”

SteamDiscoveryUpdateWell, the new steam storefront is very interesting, and I think it’s a breath of fresh air.  For a lot of reasons.  It gives a lot more power to recommendations and peers and even news outlets.  This new curators thing is going to be awesome, I’ve wanted them to add something like this for years.

Still — it’s a brave new world, in other respects.  We’ve been on Steam for 5 years now, and (as tends to happen pretty much continuously) a lot of our past experience on how to be successful is out the window.  One of the things that I noticed immediately was the new way that user reviews are highlighted in terms of the number of positive and negative ones, basically like rotten tomatoes.  I think that’s an awesome thing to do, and way more useful than showing metascores.  Hooray!

I also do think, though, that not showing them weighted by how many people find a given review useful is a bit less helpful, though.  If there are 20 negative reviews that almost nobody finds helpful, and then 40 positive reviews that are found to be generally very helpful, you still come out with a 66% overall user score, which shows up as a mixed reception.  And that’s what has happened with The Last Federation, to my surprise.  Interestingly, most of the rest of our games kind of mimic their general reception, although Bionic Dues is higher-scored than I would have expected based on its sales numbers.

Given the sales numbers of TLF, though, and the general really positive reception to it, I find it a bit strange how the game shows up as mixed.  At the moment there are two negative reviews in the top FIVE pages of most-helpful user reviews for the game.

If you’re curious, this is the listing for Arcen as a publisher on Steam, where you can see the breakdowns for everything.

ArcenOnSteam

 

And So We Come To The Point

Much as with democratic elections, referendums, and primaries, you now have a voice on Steam.  This is very exciting!  But also as with voting in real elections, the results are determined by those people who show up.

You should never go astroturfing for anyone, and you should never go on a smear campaign against someone, either.  But I think that it’s now really important to give reviews, more than ever, to help light the way for those who come after you and wonder if they should spend their money.  Do you like a game?  Review it and give it at least a brief explanation.  Don’t like a game?  Review it and hopefully say more than “this is boring” or “this sucks.”  A sentence or two of articulation in a negative review (or a positive one, for that matter) really goes a long way.  Not everything has to be a novel.

I really feel like this is getting to be like Amazon.com.  I absolutely rely on the user reviews on Amazon, because they are so helpful — the good, the bad, and the ugly.

The point is, for a lot of indies, there are either very few reviews, or no reviews at all.  And yet the games are selling, sometimes really well, and the experiences of those people just aren’t being shared at all.  That’s a bit of a shame, and I think makes it harder for people to find (and trust) the niche sorts of products that people around here like.  And I’m not just talking about Arcen’s products, either.  I know so many indie developers who struggle a lot more than we do — if anything, we manage to get far more press than the average indie developer, even if we aren’t in the upper echelon.

4xGames

What This Means For Niche Games In Particular

I think that the more niche a game is, the more the reviews of that audience are important.  When you get a game that is, say, a super-hardcore historical strategy game (a genre that Arcen has never dabbled in, so I’m free to use that as an example), you can wind up with situations where the reviews are skewed.

Some people jump in and try it just because they like strategy games.  But boy, that game is too hardcore and the learning curve is steep and it’s not what they are looking for.  Those people SHOULD write negative reviews, with at least a short explanation saying why it was negative for them.  This can warn off other generalized strategy gamers who might make the same mistake.  But it’s not going to deter someone who thinks “you didn’t like the complexity?   That makes me MORE interested!”

Even so, you wind up with a skew towards the negative — and we see this on Amazon all the time with all sorts of products — because generally people with an axe to grind are the ones most likely to do a review.  Which really sucks, particularly if you’re a fan of a niche genre and you want to see more games in that genre.  If you DO like super-hardcore historical strategy games, and you want to see more good ones, then you frankly owe it to yourself to write a review.  If you find one you love, write about it.  Find one that is okay, but not stellar, write about that, too.  Find one that is in the genre you like, but that just doesn’t pull it off, write about THAT, too.

That way the people who are actually interested in the same sorts of things you are can learn from you — and if they reciprocate, then you from them.

appleappstore

This Is Incredibly Better Than The Apple App Store

This whole thing really democratizes the process, and I am so absolutely thrilled to see how this is happening.  Apple curates a few titles, and beyond that it’s mostly the top lists for things that are already popular.  That means you get a lot of derivative games, and a lot of games featuring birds because people do a lot of searching for the word bird by now.  Despite the plethora of games on the Apple App Store, far more than on Steam, the variety is incredibly more anemic there.

The awesome thing about the new Steam system is that it doesn’t fall prey to any of those problems.  And so I’m hopeful that we’ll see more niche games that actually find the audience they were seeking.  Not people who buy it by mistake and then hate it, and not titles that languish in obscurity despite overwhelmingly positive user reviews (ahem, Bionic Dues).

And hey, when the public generally doesn’t like a game by a developer (ahem, Shattered Haven), then that’s good for the developer to know, too.  And good for players.  We still get people who buy Shattered Haven and love it, but they go in eyes open thanks to user reviews.  They understand that by the market’s opinion is that it’s a rough gem at best, and something that only will appeal to a certain set of players (of which I am a member, incidentally — I in no way feel it’s a bad game, but I understand why some others do).  I would rather sell 100 copies of Shattered Haven to people who will actually enjoy it rather than 1000 copies to people who never load it up or who get angry when they try it because it’s not what they thought.

amazontransformers

Reviews, reviews, reviews!  You don’t have to write long articles, and you don’t have to review games you haven’t really played enough to form an opinion on.  But if you’ve played a game and have an opinion — goodness, certainly if you’ve put a few dozen hours into it — you really ought to write a review.  It’s good for developers, and it’s good for players, and it’s what will make the Steam store the sort of environment that we all hope it will become.

I’m really optimistic about this new storefront, and it’s something that we’ve known was coming for quite some time.  I didn’t realize it would be today, or anywhere near this soon, but I knew that Valve was planning these changes and I just absolutely could not wait for them.  All change is scary, so I’m a bit nervous about this even though I believe it will be a good thing.  But the only thing that really scares me, honestly, is that people won’t take the time to do reviews for niche games.  If nobody does, or if only the people who aren’t really into that niche do, then those niches are only going to get smaller.

All right, that’s my sermon. ;)  I hope you find lots of new and exciting games with the new Steam store!

 

Click here for the forum discussion on this post.

Free tool for game developers: Random Game Title Generator (with source code)

Bear with me, because this is going to sound strange.  First, let’s get the premise out of the way: naming games is hard, and it’s also incredibly important.

Why is it so important?  Well, take the following screenshot of Steam:

ImportanceOfTitles

Unless you have banner rotation featuring, this is ALL people see of your game.  Even when your game is on sale, all they see is this, the base price, and the slashed price.  No screenshots, no trailer, no description, no tagline, nothing.  Just the little capsule image, the title, and the genres.

And you know what?  I’m okay with that.  Can you imagine how cluttered a storefront it would be if every game had even just a tagline?  Forget about it.  That would make people (including myself) glaze over even MORE when looking at the front page or the scanning through the discounts page.  The same is true of pretty much all the other major stores, incidentally, so this isn’t limited to Steam.

But something that Steam does that the others do not is give us information about our clickthrough rates when our game is in a featured spot, so we learn how effective this stuff is — JUST the information you see above, before anyone even gets to trailer or screenshots, etc.  The clickthrough rate for Bionic Dues was abysmal — about half the global average for games on Steam.  The clickthrough rate for The Last Federation was incredible, more than twice the global average.

Obviously you have to have a good trailer, description, screenshots, and GAME on the other end of that clickthrough, but still — if nobody clicks through, you can have a great game that everybody overlooks.  Bionic Dues is one of those games that gets a really positive reception, got respectable reviews, and yet is very much overlooked.  At least one reviewer told me flat-out that the name was awful, and that he was frustrated by that because he felt like it would turn people away from the game.

There are a lot of reasons games sell or don’t sell, so we can’t blame anything entirely on the name for any game.  If a game is good enough, it will sell no matter what you call it.  If everyone is talking about a game, that will also overcome a mediocre name.  But what about all the games that are not inherently darlings with the press, that are exciting to a niche audience, and that therefore rely on storefront discoverability?  There the clickthrough rate is really important as a first step, and if that clickthrough rate is too low then you may just be kneecapping yourself.

logo9Spectral Empire

After much brainstorming back in June, the name that we came up with for our upcoming 4X title was Spectral Empire.  I originally wanted something like Age of Ashes or Proto Colony, but those were really unpopular with our players.  And they didn’t really feel right to me, either.  After many many many attempts at names, we found one that was overwhelmingly popular: Spectral Empire.

That said, it’s only with a small group of our most dedicated fans, and in particular a group that was already weary from us trying out so many dozens of names on them.  There was some concern that “spectral” sounds like a fantasy game rather than a sci-fi one, but we all kind of brushed that aside as a cost of the process.

More recently, as we’ve been working on the internal prototype for the game, I’ve been getting more and more unhappy with the name.  I brought that up, and immediately some of the other staff said they’d been having the same feeling.  It wasn’t really a conscious thing at first, I don’t think, it was just a growing discomfort that wasn’t fully noticeable until a certain amount of time had passed.  (Which is one of many good reasons not to name your game at the last second, incidentally).

So now we are again trying to find a name for our 4X game with the help of our players, and thus far not coming up with anything that really immediately excites any of us.  Lots of brainstorming, which is great, but there’s nothing yet that makes ANY of us just go “oooh, that’s the one!”

Putting Together Puzzle Pieces

A name for a game can obviously be a variety of things.  It can be off-the-wall and eye-catching for that reason.  It can be pretty and symbolic and thus make people curious.  It can be funny.  It can be evocative of its genre, and thus pique interest in that way.

Of course, they all carry risks.  Off-the-wall is likely to miss a lot of people who have no idea what it is.  Pretty and symbolic may be a turnoff to some people who think it is pretentious and/or again have no idea what it is.  Humor is a fine line no matter what you do, since all people don’t find the same things funny.  And with “serious” games like the strategy or simulation genres, or even with hardcore first person shooters for that matter, a funny title can really be a mood-killer.  Being evocative of its genre is ALWAYS a good idea if you can manage it, but you risk delving too far into “Generic Game #56” names.  Let’s call it “Empire Combat: Age of War!”  Er… no.

So if you’re having trouble coming up with a name, and are anything like me, then what you wind up with is an increasing collection of possible words that can go in a name.  But what combination of them?  And in what order?  The more you brainstorm, the more potential words you wind up with, and the harder it gets to even consider all the various combinations.  I realized it was hitting a point where my brain just couldn’t do the job well anymore, and so I coded up a little tool to help.

Random Title Generator

First of all, you can download the compiled version here.  If that version doesn’t quite do what you need, then here’s the C# source code for it.  I hope it helps.

Now, how to use it?

RandomTitleCreator

The left column is your dictionary of interesting words.  If you decide you don’t like one after all, you can highlight it and hit delete or backspace.  You can save that list to disk with the button above the column, and you can load a list from disk with the other button above the column.  Easy peasy.

The middle column is kind of the “working column,” and gets used for two purposes.

Purpose one for the middle column is as a place to show potential game names.  If you hit the “> Titles From Dict” button, then it will make a list of randomized two-word combinations of words from the dictionary on the left.  Obviously your title may not be two-words, but when you see something like “Lords Cities” that almost-kinda makes sense, it can spark you to think “ah, Lords of Cities.”  And of course that name stinks too, but anyway my point is that just doing two-word pairings is I think the simplest way to inspire even titles that have more words than that.  If you disagree and come up with a better approach for multi-word titles, then definitely feel free to re-share your altered version of the source code and/or executable.

The right-hand column is actually a big textbox.  You can paste anything you want into there.  Paste the words of a sci-fi novel in there.  Paste the names of every strategy game ever made into there.  Whatever you like.  Then click Parse Text To Possibilities, and it will write the distinct words into the middle column.  That’s purpose 2 for the middle column.  When you do this, it will order the central column by the most frequently used words.  So if you post the collected works of Issac Asimov, for instance, you can find all the most commonly used words by him and potentially get some inspiration from there (after you sort through all the “if” “you” “he” “she” “it” clutter, of course).

When you want to move something from the middle column into the left-hand dictionary column, then select the row(s) that you want to move, and click the “< Words To Dict” button.  That will move just the selected stuff over, and clear those selected items from the middle column.

The Clear button over on the far right just clears the middle and right columns.

Anyway, so that’s how you build up your dictionary, and how you then generate potential names from that.

Also, I suggest the One Look Reverse Dictionary as an awesome resource.  It’s very much like a thesaurus in many ways, but the two are definitely distinct.  The reverse dictionary is a lot less literal and gives you some extended phrases and ideas that can be further afield.  It’s particularly useful for naming things.  I wind up using both quite a bit, and then the resulting words can just be fed right into the dictionary here.

 

Now back to trying to find a name that isn’t rancid for me…

 

Click here for the official forum discussion on this post.

Welp, Apparently I Can Retire Now

Not really, and certainly not financially.  But apparently we’ve hit a point where My Work Here Is Done.

Let me explain.  Ever since I was introduced to Boatmurdered, which is an epic LP (Let’s Play) for Dwarf Fortress, I’ve wanted to create a game that could inspire something similar.  To me, Boatmurdered is one of the best things on the internet in terms of humorous content (except maybe this or this).

Boatmurdered?

Why is Boatmurdered so awesome, and what does it represent to me?  Well, it starts of slow, pretty much explaining the basics of the game in a slightly-funny way, and seeing the setup of your fortress.  But then you have all these further entries in which the players get into a progressively worse situation, and write about it with utter hilarity.  Each player has their own style of writing and playing, and so the fortress winds up being this heaping pile of conflicting designs that is part deathtrap and part psychological-horror-movie for its denizens.

None of that was done intentionally by the players, it’s important to note — they were all playing their best, near as I can tell.  They were a victim of a combination of the complexity/randomness of the game, their own mistakes, and their own conflicting goals that they set for themselves.

This isn’t a game with a story in a classic sense — it’s not a handcrafted emotional story like Final Fantasy 6 or Silent Hill 2, two of my favorite games.  Rather, this is a game where the story emerges dynamically as each game progresses, and the story is always different.  There’s enough complexity there that the opportunities for crazy one-of-a-kind things to happen are abundant, and this causes a very unique story to arise in the minds of the players.

For me, ever since I read Boatmurdered it has been a personal goal of mine to create a game in which a story like that would unfold in the minds of players.  And then, just as importantly, to have someone funny document their experiences like happened with Boatmurdered.  That goal has now been met. :)

The Biscuit Federation

What starts off as basically explaining the game in a funny fashion turns into a funny war story.  Not only is this explanation by TotalBiscuit, the #1 PC gaming critic on Youtube, but the whole thing is freaking animated Julian GD.  Holy frick!  I still have plenty of other career goals, but for me this was a really major one, and it’s been met in a really dramatic fashion!  It’s in two parts:

Side Note: Hey, Where Have I Been Lately, Anyway?

You may notice that the date on the second video here is June 17th, so I’m two months late to the party.  I knew that the first video had gone up on June 3rd, and really loved it.  But somehow the fact that the second part escaped my notice until literally yesterday.  I had kind of given up on the second part ever happening (thinking it might be like the tragically cut-short LP of AI War done by Rock Paper Shotgun — which is also hilarious and something I’m honored led to an ongoing joke at their site about Quinn “not having enough iron”).

Anyway.  I had been waiting until the Biscuit Federation was complete before I posted about it, and I didn’t realize until now that that was the case.  So hence the delay.

But Seriously, Where Have I Been?

If you just follow TLF and not our other games, then you may notice my conspicuous absence lately.  I had planned on getting the upcoming expansion for that out a lot sooner than is actually happening, among other things, but that hasn’t been the way events actually unfolded.  TLF is in a really good state, so for the most part I’ve been letting it be for the time being.

In the meantime, I spent the bulk of my time porting our entire back catalog of games to Linux, because I’ve been meaning to do that for years and finally felt like I had the time.  That process took me surprisingly longer than I expected, but now AI War, Tidalis, Valley 1 and 2, and Skyward Collapse are all Linux games in addition to the Windows and OSX support that they already had.  Bionic Dues and TLF already supported Linux, so I was surprised by how long it took to get the other games straightened out, but such is life I suppose.

I also took that opportunity to do some other housekeeping with general business stuff, some tweaks and bugs in older tiles, and so forth.

And then lastly, I’ve also been trying to keep ahead of Keith and the artists (Blue and Cath), who are working on Spectral Empire, our upcoming hex-based 4X.  That’s not launching until April 2015, so there’s quite a way to go on it, but that’s what the rest of the staff is primarily focusing on now, and so I’ve been needing to hold up my end.

They all already finished their work on the new TLF expansion for the most part, so all that remains is for me to carve out time in my own schedule to resume working on that and the other planned free enhancements to the base game.  Now that all the porting work and other business housekeeping work is done, all the portion of my time that was devoted to that can now be redirected back to TLF.  Mostly that is going to kick off next week, but from here on out I’m going to be dividing my attention between TLF and SE.  Thanks for your patience in the meantime!

Followup to last year’s AI War postmortem (now discussing Bionic, TLF, etc).

Last June I wrote a postmortem of AI War, which also wound up being a form of history of Arcen as a whole.  But now a whole year has passed, and we’ve released Skyward Collapse: Nihon no Mura, Bionic Dues, and The Last Federation in that time.  We also have a lot more data on Skyward Collapse, Shattered Haven, and A Valley Without Wind 2.

Rock Paper Shotgun picked up that postmortem in their Sunday Papers yesterday (they may have previously, too, but neither they nor I remember for sure or can be bothered to go back and check, so anyhow).  One of the readers who popped over to check out the postmortem, Alban, had a great followup question:

Just coming here late following RPS’ Sunday Papers. As this post mortem is one year old there’s no data for Bionic Dues.
How does it fare? Will you apply the same kind of long term free/paid support as AI War ?

I’m going to get to his question, but first some background.  And in general an updated view of the company.

AirshipEternalConceptScreenshotThe Role of Luck (A long tangent, but something I’ve been thinking about)

Creating any sort of game or other creative work is a bit of a funny thing, because there is a certain amount of luck involved.  There are a lot of examples from the past of great games that inexplicably didn’t sell well.  I want to say System Shock 2, but I can’t recall if that is correct.  There were some others along those lines.

And then there are some that are clearly the recipient of good luck, going above (sometimes even far above) what you would expect them to.  Not that they aren’t good games, but that they simply were the recipient of good luck in the same way that the other games were the recipient of bad luck.  Angry Birds and Minecraft are two examples of games that are great, but that also were lucky.  AI War I also feel like was lucky, in that same sense.  I feel like Skyward Collapse was, too, frankly.

I’m getting ahead of myself a bit, but here’s how I would rate our games and expansions in terms of their luck (among other factors):

  • AI War (base game): Very lucky, and also the right game at the right time for the market.
  • AI War expansions: Not particularly lucky, as they don’t get press coverage much.  However, they are steady earners because they build on something else that was already successful. (There is some further clarification about what I mean on this in the forums).
  • Tidalis: Moderately unlucky, but also just really the wrong mix of casual visuals with hardcore depth.  This game had tons of chances to do well, with excellent reviews and lots of coverage, so really I think a lot of this is down to our blowing it more than luck.
  • A Valley Without Wind: Quite lucky in the main, but not as successful as we needed because we spent too much making it.  And misread the signs after it had been out for a while.
  • A Valley Without Wind 2: It’s hard to really gauge the luck here, as I handled the game in general so phenomenally stupidly.  We gave it away to all the customers of Valley 1 because of a promise I had made about a free art upgrade to the first game (which later turned into the sequel), and while I am glad I kept my word I am quite sorry I made that promise in the first place.  It’s hard to know how this game would have done, since we gutted our potential market by literally giving it away to most of them.  That said, the reviews were in the main pretty decent (certainly above Valley 1), but at the same time there was not all that much other coverage (compared to Valley 1), so I would classify its luck factor as middling in general.
  • Shattered Haven: This game has seen only niche success, mainly I think due to the graphics (which I am really frustrated how those graphics turned out, the criticism there is deserved), and with how slowly the game “gets to the good stuff” (which we later adjusted in post-release patches to get you to Stantonsburg quicker, but a lot of people gave up prior to that).  This game is one I’m quite proud of, but in general it just doesn’t connect with most of the market (though some people really love it), and I don’t think luck really has anything to do with it.
  • Skyward Collapse: This was just a fun little project, and a really quirky idea in a small package.  That this got as much coverage as it did, and sold as well as it did, definitely smells like a lot of luck to me.  I think that the game is fun and good, don’t get me wrong, but I think there was also a confluence of events that helped make this get more notice than on average a game like this would.
  • Skyward Collapse: Nihon no Mura: Blah, this was extremely unlucky.  We thought that if we followed the AI War model of just putting out expansions to something that was already successful, then people would show up for that.  Turns out that was not so much the case — or part of it, really, was just how insanely inexpensive this title is, which makes it very hard to break even on it.  More on this later, but I think there was some lack of luck here as well as some substantial stupidity on my part.
  • Bionic Dues: Boy this project was just a model of perfection internally.  We just did everything right, I feel like, and were firing on all pistons across the board.  We were SO fast, however, that we didn’t have time to really do any advance marketing, which was… a problem.  But there was also just a distinct lack of luck with this one.  I’d classify it as extremely unlucky, to be honest.  Some things were in our hands, but others were just out of our hands.
  • The Last Federation: This project was a longer and larger one than I had intended, and the combat model in particular was something we struggled to get right, burning up a lot of development time on that.  We ran ourselves down to our last dime (and then some, literally), making this game, and had to shrink from a fulltime staff of 7 to a staff of 4.  Which is frankly more inline with our income, anyway, but not something I wanted to happen.  Then the game came out and was just a phenomenal hit for us, far and away above anything we’ve ever done.  I think we made a really great and fun game here, but at the same time, as with AI War I recognize that there were some distinct places where we also got really, really lucky.  It’s kind of the inverse of the Bionic Dues situation, where some things were just out of our hands, but went very very much in our favor.

What sorts of things do I mean by “luck?”  Well, we try to pick release dates that make sense for purposes of the wider market, but there is a lot of luck in that, anyway.  Bionic Dues got squashed by other releases on launch and disappeared from view before people could really evaluate it well.  The Last Federation dominated the Steam front page for days, which was partly based on the high clickthrough rates to it but also based on just being at the right place at the right time.

In terms of getting the attention of people in forums, of reviewers, of press in general, etc, there’s also a luck factor.  Skill in PR/marketing, too, but also luck.  Some games we put out are loved by major reviewers or youtubers, and they tell us this privately, but then they never wind up having time to actually do a review or video, because of other titles that are more pressing in terms of their audience and what will make them money on views, etc.  Then by the time they do have time for a theoretical review, the game is old news.  That happened to Bionic Dues in multiple instances.  But for TLF, we had the opposite luck, where a lot of big names just jumped on it immediately and wrote or did a video about it immediately, rather than having a delay.

You could argue that that is partly due to the degree to which they connected with one game versus the other, and that is surely partly true, but I think that anyone who denies the role of luck in books, movies, games, and basically all creative things is kidding themselves.  You can’t get lucky if you aren’t prepared and actually having something worth talking about, but it is possible to do everything right and still fail.  There are indies all over the place where that is the case.  The most notable recent example of that, to me, is Source by Fenix Fire.  That game got a ton of press attention, looks gorgeous, seemed to do everything right on Kickstarter, had a hilariously modest goal for a game like that ($50k), and yet still failed to get funded.  WTF?  That’s just bad luck, and something those devs need to realize and not feel too bad about.

Please don’t misunderstand and think that I think luck is the only factor that matters, though.  There’s a lengthy followup discussion in the forums where longtimer ptarth raises a number of really interesting points and question (about both the role of luck and other things), if this topic interests you further.

Okay, back to the actual question.

AIWarDestroyerOfWorldsWallpaperAI War’s Ongoing Performance – Solid

AI War is now somewhere north of $1.3 million, I’m not sure exactly where.  We’re at over 5 years of the game being out now, and our 6th expansion is in the works for release this August.  There’s not a lot to really say here, this just continues to be a strong game for us.  It’s fallen a lot in terms of how big a portion of our yearly income it is, but that’s mainly because of the rise of other games for us, rather than a fall of AI War itself.

Bionic Dues – Not So Hot

colour_sniper2_png_by_arcengames_d6fez36_by_cassiopeiaart-d6iirw6Bionic Dues, as noted above, was a recipient of bad luck.  It hasn’t sold abysmally, it’s not like Shattered Haven or Tidalis, but it just hasn’t really been “discovered” yet, in a lot of senses.  Overall it’s had a really solid reception, and certainly some major press.  We bungled some things with Bionic in terms of advance press, but a big part of that was the fact that we weren’t really ready to show anything until the last second because the development cycle on Bionic Dues was so short.  Our “luckier” titles had longer development cycles with more teasing of stuff prior to them.

Bionic is at a semi-respectable $95k(ish).  It’s not something we’ve broken even on yet, although I have to go back and calculate exactly how much we spent making that one.  We will break even on it eventually, but it’s much slower than expected.

We were planning on doing an expansion for Bionic, but unfortunately the support just isn’t there to make that viable.  We had already done some features that we were going to include in an expansion for Bionic, and with the decision not to go ahead with an expansion we just rolled those out as new free features to the base game a week or so ago.  There aren’t going to be many updates to Bionic aside from bugfixes; it’s a complete, self-contained game at this point.

That’s actually true for all of our titles now except for AI War and The Last Federation.  Though we are going back and adding Linux support to everything that didn’t already have it (even Tidalis, after all!).

moon collides with planetThe Last Federation – Phenomenal

Our latest title, The Last Federation, just passed $500k in 10 weeks, so it’s our new most-amazing success.  AI War has still earned more than twice as much, but it did it over 5 years rather than 10 weeks, and with 5 expansions as opposed to zero.

As noted above our 6th expansion is in the works for AI War, nevertheless — we’re not abandoning that game just because we have something newer and more successful.  And naturally an expansion for TLF as well.  TLF continues to go great guns, and is basically single-handedly funding our work on our next title, Spectral Empire, a 4x which will come out next April.

To say that we are amazed and grateful for the reception that The Last Federation has had would be a huge understatement.  To put things in perspective, if you take an average of how the entire rest of our catalog has sold over 2014 so far, and then compare 10 weeks of that average to the first 10 weeks that TLF was out, TLF outsells everything else in our catalog combined by 7:1.  TLF was expensive to make, but it broke even somewhere around 7 weeks after coming out.  Skyward Collapse broken even much faster than TLF, but it also cost something like 1/8th as much to make.

MacGameStoreBannerShattered Haven – Worse And Worse

Well, this is our worst-selling title ever, even “topping” Tidalis, which I had not expected to ever manage to do.  We have  a lot of disparate income from various bundles and whatnot now, so it’s harder and harder to collate exactly how much specific games are making unless we keep careful track of it.  With TLF, you bet we were watching that with fascination (and it hasn’t been in any bundles, anyway).  For Shattered Haven, we’ve not been watching the numbers super closely.  I would hazard a guess that the total gross is around $30k total, based on the concrete numbers that I am looking at at then going from memory on the smaller gaps.

The Silver Lining On Shattered Haven (And Similar Games That Don’t Fare Well)

That said, I’m really gratified to see that some people do connect with it as much as I do, and come into the forums and say how much they love it.  Here’s an awesome thing: every single game that we have ever made is somebody’s favorite game that we’ve ever made.  In other words, even our “worst game” is one that somebody (that I’ve never met) feels is our best game.  In some cases, we get people saying that our “worst game” is actually their favorite game ever in a genre — or even out of all games in general!  That’s a huge honor, and always takes me by surprise.

Cynics will go “there’s no accounting for taste,” and sure, that’s true in a literal sense.  I think all of us like certain things that are not popular, and it’s not because we’re hipsters.  Shattered Haven’s gameplay was very inspired by both Zelda 1 and Lode Runner: The Legend returns, and I think that people who like the latter in particular (or games like that) are likely to respond well to Shattered.  Story-wise, some people think that it’s not really a good story (and some say the same about Tidalis).  But for those who connect with the emotion in Shattered, or the humor in Tidalis, it’s really quite wonderful.  It comes down to taste.

I mention this because this is also true of lots of other games around the Internet.  I see it in the forums of other indie developers all the time.  They make something that the market hates, that the critics spurn, and that is a financial ruin for them.  Yet there are strangers telling them how much they love that title.  It’s an odd thing to experience.

In some ways, I guess I kind of feel fortunate to have both this experience and the experience of having something much more widely popular and accepted.  Being able to recognize the nature of personal taste, and the role of luck as well, kind of helps take the sting off of my failures.  Or at least helps me put them in some kind of context, if that makes sense.  Very few people love every game we’ve ever made, and plenty of people don’t like ANY game we’ve ever made, but somebody loves every game we’ve made, and some games are loved by a LOT of people, and that has to be good enough for me; that’s the best anyone can really expect, I think, in all honesty.  Think about it; even for someone like Stephen King, who is like the Notch of novels.

Valley2Wallpaper1A Valley Without Wind 2 – Sigh

The gross total last year on Steam for the package that includes both this and Valley 1 was a mere $109k.  That’s… pretty pathetic, honestly.  Given the huge expense of making this game, the Valley 1 and 2 package has been pushed so far into the red that they are never going to climb out of the hole.

People always complained about the graphics in Valley 1, but then once we did Valley 2 (which is vastly prettier, I think), people started complaining about how they preferred the character animations in Valley 1.  Go figure.

Valley 1 also is excessively more popular in terms of playtime.  It gets played more than Valley 2 by about a 5:1 ratio.  Valley 2 is the one that I actually prefer out of the two of them, although both are really fun.  But it was a complete genre shift from being a Metroidvania to being a Contra-like.  And the crafting and mild citybuilding from Valley 1 was instead replaced by procedural bonuses, character classes, and a semi-intimidating strategic layer in Valley 2.

A lot of fans of the first game didn’t respond all that well to the shift, because they basically wanted more of the first game, but prettier.  Which I can understand.  Valley 2 probably would have been better received as a completely standalone separate game with no connection to the first.  Though critics did like Valley 2 better.

For myself, behind AI War, I think the game I have put the most time into playing recreationally from our library of games is a tossup between Shattered Haven (with my wife) and Valley 2 (with my 4 year old son).  Go figure!  This is kind of what I mean about there being no accounting for tastes.  Sometimes my taste is really odd to the point the market goes “what?” and that’s something I’m having to learn to live with (and to try to avoid, where possible, as it really risks the company).

Skyward Collapse and the Nihon no Mura Expansion – Ehhh…

Zuess_finAt the time this came out, it did phenomenally well.  Its first month was not our highest-grossing launch, but it was our most units moved by a large margin.  It broken even in 3 days, and was 6% of our historical revenue within a month.  That’s more or less where we left things at the last postmortem, a year ago.  Well, what’s happened since then?

Sales tapered off pretty fast, actually.  The expansion came out to a resounding lack of interest from all except the core players, and gaming moved on.  This seems to be what happens to most games — that’s why the initial launch is so important — but for Arcen the long tail has always been where the meat of our income comes from, so this was a surprise to me.

With the expansion, we deliberately released that in August just to see what would happen.  That’s a real dead period in gaming, and we figured we could pick up some extra press due to that, and that we’d make up the initial shortfall in sales via long-term sales in discount promos and whatnot.  It was a reasonable plan, although a speculative one, and we knew the risks when we tried it.  It didn’t pay off.

Actually, by putting so much work into Skyward 2.0 and the expansion, we managed to UN break even on the game that broke even in 3 days.  Facepalm.  But, by the end of 2013 we had re-broken even on the combination of the two, although the role of the expansion in that was questionable at best.

Looking At Company-Wide Numbers – Strength In Numbers, Actually

Still, despite the above, overall Skyward Collapse did respectably for last year.  The base game generated about $125k gross in that year on Steam, out of about $510k total for all our products on Steam last year, so Skyward was 24% of our Steam income last year.  That’s no slouch at all!  And frankly, Valley 1 + 2 were 21% of our Steam revenue from last year.  By the end of last year we had 7 full games released, plus 1 expansion for Skyward and 5 expansions for AI War.  That’s a lot of back catalog, and it’s not the sort of back catalog that starts to look stale after a few years like the latest 3D games do.  Our graphics start out retro and stay retro, and I think that’s part of the long tail that we experience.  And a number of other 2D or retro-styled games by other developers, frankly.

Anyway, aside from a dip in 2012 (I think it was the Q4 economy there, which hurt everyone), Arcen has always had at least around a 10% growth in year over year income.  Our big problem was always having expenses that grew at that rate or higher, thanks to my bringing on more and more staff.  So despite the constant growth, there was also a constant struggle.  Anyway, last year Arcen grossed over $700k in all, and no one product was more than 40% responsible for those numbers.  That’s a big win for us, given how dominant AI War has been in our history.

Our strategy in 2013 was kind of the opposite of what we did in 2011 and 2012, where we focused on just one or two really giant games.  Instead we focused on a larger number of smaller titles, the two chief amongst those being Skyward and Bionic.  That strategy paid off in some respects, but by the same token it doesn’t create titles with the longevity of AI War or The Last Federation.  So 2014 has seen us swing back the other way, working on larger titles again, but with more of an emphasis of keeping steady pacing without runaway expenses.

SpectralEmpireMock-7-14-croppedHistorical Performance, Updated

Overall, Arcen has now grossed somewhere around $2.7 million dollars. $500k of that came from The Last Federation in the last couple of months.  About $1.3m of that came from AI War over a span of 5 years.  That leaves $1.8m divided amongst all the rest of our products combined (6 games).  Valley 1 and 2 are the largest component of the rest of that, with about $500k in gross income between the two of them (since April 2011).  Skyward and its expansion and complete version account for about $180k.  Tidalis, something like $110k.  Bionic Dues, $95k or so, and Shattered Haven at something like $30k.

So, we’ve been all over the map, in terms of financial success.  I’m okay with that, so long as we stay solvent and free, though.  I look at Maxis games from way back in the early and mid 90s, and I really admire what they did.  They had some really hit games (SimCity, sort of SimTower), but then they also had a sizeable number of ones that never really took off.  But someone loved all of their games, even the “flops,” and there was value and innovation in everything that they created.  I’m okay with a track record like that.

That said, our next title is a semi-traditional 4x, so we are playing it somewhat safe.  Granted, it has our own twists and uniquenesses on it, but we’re not mashing up two unrelated genres like we so often have.  In the end it just boils down to being able to make what we’re most interested in making at the time, and then doing the best job on it that we can.  With a lower amount of expenses, and more money shelved away for security, we currently don’t have to run around with our hair on fire quite so much.  I’ve been basically in crunch mode for 5 years, and it’s really nice to be able to actually take a more reasonable amount of time to do things.

Anyway.  For the moment, things are looking very much up, and I’m feeling very fortunate for the situation that we’re in.  I had hoped to stabilize as a fulltime staff of 8, but ultimately we wound up stabilizing at a fulltime staff of 4.  That’s the one thing that really kills me, but it’s just more realistic for a company of our nature.  All in all, despite the many bumpy things last year, we managed to have a really solid year, and despite a very scary start, this year has now exceeded last year in every way.  Here’s to the future.

Forum discussion.

PS: In the forums, I was asked about what I think about Jeff Vogel’s recent posts about how the indie bubble is bursting, and what that means.  Unfortunately, I agree with him on most of his points.  If you’d like to read that discussion, it is here.

PPS: The forum discussion continues to be wide-ranging and detailed on a variety of subjects, some only tangentially related.  It’s an interesting read if you like this sort of thing.

Behind The Scenes: Iterative Combat Design In TLF

The Last Federation is a really unique game in that it is a strategy/tactics game set inside a simulation game.  Check out its game page for details, or swing by the forums for the game.  This is Arcen’s largest title ever, and we’re really excited to share it with folks.

Alpha Information! Private alpha testing with players is currently in progress, and we will be adding more players throughout the coming weeks leading up to release.  If you’re interested in signing up, please see this forum post.

One concern I’ve seen lobbed our way every so often at Arcen in general is that some folks don’t like the idea that we “crowdsource” our design ideas.  Aka, that we listen to player feedback, really.  The common way this is phrased is that we should step up and “be the designers” properly, with a singular vision that we won’t compromise for anyone.

That’s… all well and good, I suppose.  If you have a singular vision for a game, go right ahead and do that.  And if it’s perfect on your first try, that’s amazing.

But the thing is, we’re not “crowdsourcing” our design ideas at all.  We get feedback.  It’s the same thing that authors of novels do when they show their rough drafts to their spouses, to their reading group, to their test readers.  They aren’t trying to pander, they aren’t trying to get other people to help write the book themselves, or anything like that.  They want more sources of data from which to consider their creations from alternate points of view.

To the specific matter at hand, the changes in TLF’s combat system from the earliest RTS-like versions to the current system have all come squarely from me, in the end.  Players were enjoying the RTS-like stuff in alpha, sort of, and were giving lots of feedback on things that were annoying them or that needed to be refined to make it better.  There was a sense that “something is really missing here,” but the feedback was all really in the vein of “how can we fill in the missing links with what is here.”

 The old RTS-style combat model with ship deployments, from earliest alpha with player involvement and our first public video of the game.

I looked at all that feedback and felt something else.  Familiarity.  It was getting too similar to AI War, and to solve the problems we were having here, we’d have to move increasingly in the direction of AI War.  Which is all well and good — I still love AI War — but the battles here were supposed to be a lot shorter than that, and not always against an entrenched enemy, etc.

One player in particular, I believe it was Cyborg, had noted (to paraphrase from memory) “the combat has this really different feel from the main game, where you are a little guy doing things in a wider solar system; the combat is more about clashes of equal forces.”

So I took a step back, and said.  “Okay, we’re supposed to be ‘Batman in space’ here, so that’s clearly a problem.”  We were in territory that was familiar in a way that I didn’t want to get into again (there’s more we will do with AI War, but I don’t want to try to do that in this game as well).  And any solutions I thought of with the combat as an RTS would make the individual battles take longer, be more complex in terms of controls and keybinds, and in general be way more divorced from the solar map sections.

Originally this game had 1v1 ship combat from a side view, and it was more of a minigame.  This was before we had any players testing it at all, it was just us.  We were excited about the ideas, but eventually we ran into problems I felt were intractable, so we had shifted to the RTS model.  I really loved what the RTS model had brought to the table… except I really wanted to get back to having just a single player ship.

 A very early prototype screen from when the game was still side-view 1v1 ship combat.  This is the first time we’ve ever actually shown screenshots from this version of the game at all!

So that’s what we did!  And players had also noted that they wanted to see multi-sided battles, which has been something I’ve always loved, too.  That was one of those “why didn’t I think of that?” sort of moments.  So we made that a big focus, too — again it made the combat more like the solar map in terms of the overall feel of you being the little guy caught in larger scuffles.

We spent about a month working privately on this, without giving any new builds to our alpha players.  I wasn’t happy with it enough yet to bother getting feedback, because they would just be telling me things I already knew.  If I didn’t enjoy it yet, then nobody else would, either.  That’s one of our mantras, is that somebody on the staff has to enjoy the game or else we’re really doing it wrong.  Almost always, that person is me.  The exceptions are when I’m not the lead designer, which has only been on Tidalis (which I did quite enjoy) and the aborted Exodus of the Machine project.

Anyway, we got the multi-faction stuff working, the combat scenarios, the single-ship stuff, etc.  All of that was my design, it wasn’t “crowdsourced” or even discussed with players.  Though Josh Knapp (former staff member) and I did discuss it quite a lot during the first week or so, and he was instrumental at that period.  But it evolved from there.

We got all that working… but still it just felt “off” to me.  It was doing everything that I wanted, but I found that without the need to order squadrons of ships around, there wasn’t enough for me-the-player to do.  I was setting courses for my ship, and watching it auto-fire, and so forth.  It was… boring.  The overall tactics of the battle were there, and working perfectly, but the moment-to-moment stuff was dull as dull could be.

The solution quickly came to me, really — based on our past work with things like the A Valley Without Wind games, it sprang readily to mind.  I needed a gun that I could point and shoot myself.  That sort of rotational shoot-anywhere gun from Valley 1 is just super fun.  So we put that in, and suddenly I was having a blast.  It took more balancing and tweaking, but after another week or so we finally released that version to our alpha testers (and let in a new batch of alpha testers) after a month of being incognito.

This is how the combat looked around that time.  We already had the special abilities in place, but note that there are only 5 of them, and none of them are equip-able weapons.

So this is the point when I created the hour-long gameplay footage video of the game, which showed off not only the new combat, but also showed off the solar map stuff for the first time.  Alpha players were by and large loving the new combat just as much as I was, and much happiness was had.

But.  There were still two issues, both of which were niggling at me personally, and also which some players picked up on and commented on. 

Firstly, the combat felt a bit shallow in the moment to moment bits.  The tactical aspects were still there, but since you could only have one gun at a time, your solution to any incoming ship was “shoot it a lot.”  That is fun in a bubble-wrap-popping sort of way, but it’s not something that is sustainably interesting.  And it cuts out some of the moment to moment tactics.  Yes you had 5 special abilities to pop off here and there, but your main gun was in general so effective (and had to be) that this was only of some real use.

The solution to that did come from a player, not from me, and it was another of those head-smacking “why the heck didn’t I think of that?” moments.  Histidine pointed out that having only one gun, and not being able to switch guns, was limiting.  Durr.  In that short space of time, he was the only one to comment on it, and I didn’t see it yet.  I’m sure I and the other alpha testers would have figured it out before too long, but he saw it immediately. 

So within two days I put together a new build that had a bunch more guns, rebalanced combat around specializations, and six overall “abilities” on your bar, although 3 of them were just guns that you could switch through (reducing the former trigger-style abilities from 5 slots to 3, in other words).  I put in a bunch of other things to differentiate the flagships from one another, and really beefed up the uniqueness of all the classes. 

This was over a weekend, and I was working alone, incognito, away from players and staff during that period.  I’m not saying that to brag — great ideas come from all sorts of sources, and often those sources are not me.  But to someone who thinks that we’re “crowdsourcing” our games, I feel like it’s important that they actually understand what’s going on.  This is how you want game developers to work.  You want them to listen to you, and you want them to then use their feedback to fuel their own vision, rather than just blindly following what you say, or sitting you down in a conference room to have a design-by-committee.

This is a screenshot I took 5 minutes ago, of combat with the new weapon-switching at the bottom and the various other enhancements.

So here we are.  The combat is really fun in the moment-to-moment bits, and it’s also much more mentally-involving in terms of making sure you not only use the battlefield properly, but also use the right weapons for the right enemies.  You can adjust the play speed to whatever you want, so it doesn’t have to be a twitch game if you need time to aim.  Me, I like it fast and twitchy, and play on a more moderate difficulty level to compensate.  Play as suits you.

This brings us to the second problem that I mentioned (a while back) above, and which is as-yet unresolved, but next on my to-do list: identity crisis for the game.  Is this a thoughtful 4X, or is this a SHMUP-like?  Valley 1 and 2 both struggled with this exact same identity crisis.  You could love one part and loathe the other, and that would make for a challenging time.  Personally I loved both in both, but limiting our audience to the intersection of two rather disparate genres would be… well, stupid.  That’s a good way to go out of business. 

It was worrying me from the start, and players all immediately brought it up, too.  In all their cases except for one (Cyborg, as it turns out), they were loving both sides, but were worried others would not.  Cyborg tried to like the new combat, but just ultimately can’t stand it.  And I understand that — I loved the Total War titles, for instance, but I loathed their realtime parts.  So I just used auto-resolve and played it as a 4x and had a great time.  For everyone else who liked the realtime parts, they were free to play that, and that’s great.

But it comes down to even more than that.  Much as I love the action-oriented combat here in TLF, sometimes I just want to get on with it.  That’s another thing with Total War: by auto-resolving all the battles, I could just play one continuous, fluid strategy game.  I wasn’t constantly interrupted by 5 or 10 minute battles where I would then have to go “now what was I doing again?” when I finished them.  If I clearly had the superior force for a battle, I also didn’t just have to go through the motions, either, it’s worth noting.

So that’s currently my thing: making an alternate combat mode that is a little more involved than your traditional Total-War-style auto-resolve, but at the same time quick and fluid and cerebral-only.  In other words, keeping it a pure 4x if you use that instead of going into the action bits.  And you know what?  Much as I love the action bits, I plan on using that feature quite a bit myself.  Sometimes I just want to get on with things, as noted above.  And this way I can play the action-y combat exactly as much as I want, without ever having to weary of it.  Which is important.

The solar map portion of this game is a big, beautiful 4x simulation that is way more involved and interesting than anything Arcen has ever done before, in my opinion.  I would hate to exclude the very type of audience that most appreciates that simply because they hate SHMUPs.  And I also don’t want every game I play to take me 12 hours because I’m in combat for half the time.  I want to play it the way I want to play it, when I want to play it, based on how I’m feeling at that moment.  That’s what’s coming.

And that’s how we listen to our players.

More Musings On Iterative Game Design

I’ve written before, in depth, on my process for iterative game design and why I use it.  That blog post was a year and a half ago, however, when it was just Pablo, Phil, and myself and we hadn’t even started working on the first expansion to AI War yet.  I was the only game designer on the staff at that point, and the only programmer, and none of us did this fulltime.  Then our game came out on Steam and Direct2Drive and changed all that.

So!  Seems like it’s time for an update about iterative design, especially in light of our major design shift for AVWW last week.  After all, now I’ve had the pleasure of working with a Lars as lead designer on the Tidalis project (while taking the role of producer), and with Keith as my co-designer on the AVWW project.  And we’ve put out three expansions for AI War, the second two of which were co-designed with Keith as well.

What’s Changed Since The Last Blog Post?
Despite all the changes to the company, to my life, and to what projects we’re working on, the process actually hasn’t changed one iota.  This is surprising even to me, honestly.  But it’s the nature of why we were able to make the shift to side view in AVWW, and why it wasn’t as ballsy a move as some people seemed to think it was (though we appreciate the kind words on that score).

Our Process, In Brief
If you want the hugely detailed post, check out Iterative Game Design The Right Way, my original post that I linked to above.  But the short of it is that we decide, at the start of the project, what our “immutable design goals” are, and then start chipping away at the ‘ol block of marble.

As the joke goes, you just have to “chip away everything that doesn’t look like an elephant” to carve an elephant out of a block of marble.  That’s really an apt description of what we do.  We start with a collection of ideas, things that the project absolutely must accomplish in some manner, and then we start brainstorming designs until we have something that seems likely.

Once we have a strong-enough-seeming design, and the time and manpower lined up, we start on the project.  That’s when the iteration begins.  The first designs are always flawed and rarely fun, but they are illuminating.  They teach us why other game designers probably did this or that, and what mechanic X or why means to the player.  They help us build a technical prototype, and form both an art style and a musical/sound style.

Nothing is sacred except those immutable design goals, so we wind up having a very free discussion of ideas that actually works best with multiple designers.  Keith and I both freely suggest things that are outlandish and half-thought-out, and just get the others’ first reaction to it.  If it seems like something worth pursuing, we do, but it’s also perfectly natural to let such trains of thought just fade once they’ve shown they aren’t worth it.

I always like to say that if a design was so obvious that we could have thought of it right from the start of the project, then everybody would be doing it.  You can set a direction for a project at the start, and you can and should set immutable design goals, but if you try to create a massive design document that is set in stone, you’re not going to make a very original game.  All the best stuff comes out of the iterative process, and that takes time and iterations.  To me, this is what it means to be an indie: this freedom to experiment.

An Experienced-Focus Way Of Looking At Immutable Design Goals
Another way of looking at immutable design goals is based on the player experience.  In my other post, I said that my immutable design goals for AI War: Fleet Command were:

1. AI War must support co-op play in a way that is fun and painless.
2. AI War games must be long — 8-12 hours perhaps — and must continuously evolve as they progress.
3. There must be a huge number of viable options available to the player at any given time, or every game will start to feel the same.
4. The game must be designed in such a way that it does not reward fast-clicking over real thought, or my dad (and players like him) will not really enjoy it.
5. There must never be a “best path” for players to learn, or the game has just died. There must be enough variability and randomness in each game that players must somehow have to make different decisions based on the current situation.

And those are all true.  Those were the parameters of how I wanted to play the game.  But that’s also like describing how an elephant is posed, not what an elephant actually looks like (awkwardly returning to the carving-an-elephant analogy from above).  These sort of immutable design goals are important, but there’s an even higher order of goal that I pay even more attention to: how does this game make me feel.

Imitative Feel
I think that any indie developer, when setting out to make a game, has an idea of what they want it to feel like to play that game.  Often it’s imitative: “I want to recapture that feeling I first got when I played Ocarina of Time.”  That’s a specific goal, and so long as the actual mechanics of how your game works are sufficiently different, it’s not to say that the final game will have much in common with OoT.  We’re talking about the impact of OoT, not its literal design.

Of course, that can result in games where designers simply try to imitate the form of the original game in hopes that the feel will follow; it never does, so that’s a waste of time.  But that’s a whole other discussion that I won’t get into here.

Art Imitating Life
Another way to establish the primary-immutable-goal for a game is to think about things outside of gaming.  For instance, people that design golf video games are presumably trying to make something that feels increasingly like the real game of golf , not something that gives them the feel of the Tiger Woods games.  These people presumably like playing golf, and want to capture what that means in the form of a digital game.

In the case of AI War, once the decision was made to set the game in space, I knew exactly what I wanted the game to feel like: I wanted to feel like Ender Wiggin.  I wanted to feel clever and outnumbered and to win against all odds.  It’s surprising, perhaps, that the idea of an asymmetrical AI didn’t occur to me until halfway through the project, but there you go — it wasn’t something any other multiplayer RTS game had ever done.

Setting Yourself Up For Epiphanies
At some point as I was chipping away at the game of AI War, I realized that a lot of my smaller goals were being met, but that I still didn’t feel like Ender for some reason.  And that’s when the epiphany hits.  That’s the big benefit of iterative design, is that you set yourself a goal that nobody else has ever accomplished, and then you keep working closer and closer to it until you have all the epiphanies you need in order to make it happen.

Another analogy I like to use is that of walking down a long and twisty corridor.  You know where you are, and where you want to end up, but you don’t know all the intermediate steps.  You can see around a corner or two as you go, and can make decisions that should take you closer to your goal, but you can’t know absolutely for sure.  Since you can only see around so many corners at once, that means you have to put in the time and do the walking to really find the right path; and sometimes that leads to backtracking.

Backtracking, in this sense, isn’t a tragedy or even a surprise, it’s just part of the process.  I’m not one of those people who thinks that the first idea I have on a subject is the best I’ll ever have.  I rather think that the more I know about a subject, and the longer I think about it, the better my ideas about it will become.  That’s what the iterative design process takes advantage of.

Conclusion
You might be wondering what the overarching immutable design goal was for AVWW — after all, it started out as a post-apocalyptic top-down game and is now a purely-fantasy side-view game.  The core idea of that game is and always has been “I want to go adventuring in an exciting, dangerous-feeling, infinite world.”

This is an elephant that we’re still very much chipping away at, but I think you can probably see via our regular videos and developer journals how this sort of process evolves: we mention most of what we’re working on, so you see some features appear and then later disappear.  That’s the process of walking down these corridors and finding out which ones really lead us to the end destination we’re striving for.

Anyway, it’s a process that I very much believe in and that I think others should use.  So far it’s worked every time for us!

Horizontal vs Vertical Game Development Phases

This is going to be a three-post day, to hopefully. make up for having neglected the blog for three weeks.  In the last post, I talked about the design process for A Valley Without Wind, at least at a high level — that’s a complex topic, so I might write more on that in the future.

One particularly interesting concept that Keith and I have adopted in our design lingo is a delineation between “horizontal” and “vertical” types of game development.

Horizontal Game Development
When you’re developing horizontally, you’re adding new classes of features.  In Tidalis, a new horizontal feature was when we added the ability to have items, or to have an adventure map.  With AI War, a new horizontal feature was when we added the ability to have minor factions, or “event attacks,” or campaign types.

In AVWW, examples of horizontal features we’ve done so far are having multiplayer, having enemies, having the world map, having building interiors, having regions and all the effects those on the character, having crafting at all, and so on.

Horizontal features are major game-changers, as they add whole groups of new functionality to the game that were not there before.  Another way to describe them is that they are scaffolding: in AVWW, we added “the ability to have enemies” weeks ago, but we only added a single enemy, the Skelebot.

Vertical Game Development
When you’re developing vertically, you’re still probably adding little bits of scaffolding here and there, but that’s not the core focus.  To use AVWW as an example again, when we finally get to adding more than a single enemy, that will largely be vertical game development.

Horizontal game development can be the most exciting thing for some designers, and from looking at some indie games it always makes me wonder why there wasn’t more vertical development (awesome ideas packaged in a really short game without a replay value is a bugbear of mine).  But vertical game development is just as critical to the game, overall — AI War is fun and varied because there is so much to explore and to discover in the galaxy.

As an example of just how important vertical game development can feel to players: The Zenith Remnant is our best-selling expansion for AI War, and it’s pretty much 80% vertically-developed.  It added a few horizontal things — golems and minor factions, most notably — but the bulk of that expansion is more content, more to explore, more to make each galaxy feel like a living and unique place.

Side Note: Indies Vs. The Big Boys
I don’t want to name any names, but I think that if more indie developers focused on a vertical development phase after their excellent horizontal work, that they’d really be even more competitive.  There’s something to be said for a highly polished, focused, finite experience, of course — and I’m in no way advocating simply “padding out a game” with repetitive stuff.  But when you have an awesome new concept, it just seems to me like a waste not to explore it fully, in all its permutations and variations.

Truthfully, we never would have been able to make three expansions for AI War had we just been running on the strength of the ideas that I had, though.  I had enough ideas for part of one expansion, but not even for that full thing.  Players, though — man are they a font of ideas, and that’s what made the expansions to AI War possible.  It’s something I’d be delighted to see more indie developers doing in general.

A Valley Without Wind’s Pre-Alpha Horizontal Development
With AVWW, we’ve been doing a ton of horizontal development to get all the various subsystems in the game working and proven out in a broad sense.  That’s why you see one enemy, and why we have multiplayer but not yet any prediction or smoothing, and why I had planned not to include shadows for a while (until I was overruled by players).

This mostly-horizontal period of development has taken up most of our time on the game so far, but thankfully we are nearing the end of that process — my favorite part of game development is, as you might guess, actually the vertical.  We still have more to do with the general mechanics of crafting, NPCs, and the like, but in terms of what we’re doing before alpha, the list is actually pretty short. 

Things like Settlements, “Hopes” (our version of “Quests”), and Deeds (the game remembering your past victories and losses in a meaningful way) are going to be our primary areas of horizontal expansion during the alpha phase, and having all three of those in place and fully the way we want will likely mark our transition to beta.

In the meantime, once we get our last push of horizontal development done here, we’re going to really be pushing into the vertical, trying to get as many enemies, traps, spells, craftables, general objects, characters, weapons, consumables, buildings, floorplans, dialogues, and so forth into the game before we hit alpha in another 3-4 weeks.

By now we have this amazing skeleton, but we need to start focusing on getting some meat on them bones.  For those that have worried that the game is going to be about “kiting” enemies, for example, that’s a fear based out of our simply having implemented one prototype entity, but the reality is even that one enemy won’t continue functioning in that simple manner by the time we hit even alpha.  Lots to do, and for me this is the fun part — we’ve built most of our toolkit, and part of a world, and now it’s time to start really building a world using that toolkit.

Designing Emergent AI, Part 6: The “Tempo,” and AI vs. Player Agency

In the fifth installment of this series, I talked about the reasons for not over-engineering AIs and thus letting them fall into traps by making them too predictable. That was intended to be the final article in the series, unless more questions came up that I needed to address. Recently a new topic has arisen, however, in the form of a question about player agency and why the AI in AI War is deviously reactive rather than taking matters into its own hands too much. This post is actually as much about game design in general as it is about AI design, but those two areas often go hand-in-hand.

Why Does The Human Player Always Have The “Tempo?”

Q: In AI War, you’ve made the AI play by different rules to the player. Much of this works, but the bit that I think is a bold red, font 100 minus is what seems to me could only have been a conscious decision to make it a passive, reactive and predictable creature.

In the classic pvp strategy games, after the learning curve, each player knows at least roughly how well each of their units do against their enemy’s units. At the macro level, the core game is about out-thinking your opponent, deploying the strategy that counters the opponent’s current strategy, aware of the likely reaction from the opponent because of your current strategy, and being prepared to change your own strategy in the near future to stay one step ahead. It is about acting and reacting. It is this dynamic which keeps people playing, which explains why Chess and Starcraft are still going strong.

A pvp game inherently has a huge imperfect information mechanic: you don’t know exactly what your opponent is going to do. Since AI War is played against an AI, one which does not actually have a macro strategy, which only reacts to the player’s moves, never initiating any, you don’t have this mechanic or depth. I’m hoping to get across why I think AI War’s gameplay is lacking that special something to get it from ‘very good’ to ‘excellent’

Response from Chris Park, AI War’s Lead Designer:

AI Modifiers and Other Existing Features

Are you aware of the AI modifiers for cross-planet waves and no wave warnings? A lot of what you are looking for is accomplished by that alone. You may even want larger waves on in order to tailor the experience even more that direction. The macro AI is actually quite devious in terms of what it does with ships once it has a bunch of them free as threat — a lot of what you are describing happens already in those circumstances, but if you’re effective at keeping the AI Progress too low then you wouldn’t see that much; it’s entirely possible you’re on too low of a difficulty there.

Thoughts On the Tempo, And Why The PVP Model Is Not The Goal Here

Beyond that, though, you are entirely correct that the human players are given the “tempo” in this game. That makes it much less like the AI is a full opponent, as you are noting, and more like it is a cross between an opponent and a “game master” in terms of a pen and paper RPG or similar. This, as you might guess, is by design — this game is about the player, and what they want to do. The AI does indeed throw in some monkey wrenches from time to time, and will kill you if you’re not careful, but it’s not as independent-acting in a macro strategy sense (most of the time having very few free Threat ships), because that’s simply not the goal.

And why not have that as a goal? Well, here’s why I hate pvp RTS games, as a blanket statement: the other player is doing stuff invisibly, I’m doing stuff invisibly, and then we finally see what we are doing when we meet, and whoever randomly did the best thing wins that encounter. If you built lots of horsemen and I built lots of pikemen, I win. If I built regular foot soldiers, you win. Then, depending on how unmatched we were, one of us might completely kill the other, or the losing player might scrape by and survive and battle back. Repeat.

To me, that’s all those games are, and it hasn’t been fun for me since Age of Empires II when I realized what the deal was. I was very much a fan of pvp RTS in the Warcraft II, AOE, and AOEII days, and even to a smaller extent with Empire Earth, but round about that time I was done with it and haven’t looked back, and have been eking out an existence in a sort of scaled-down co-op purgatory against the AIs since then. I’ve had a ton of players write me to say that they haven’t played any RTS since the Warcraft III days or similar, but then got back into strategy games via AI War, and I think this is a large part of the reason why.

Player Agency, Comparisons To Espionage Games and Tower Defense

Because, in the end, AI War is as much a puzzle game as anything else. It’s a very complex puzzle that changes slowly over time and has some ability to throw monkey wrenches at you every so often, but overall it is an engine for letting you devise very complex and long-term plans, and then see them out. Of course you have to change your plans as the AI grows and the situation changes and such, but in the main it’s about you and your team’s cleverness in a complex scenario.

Think of it like one of those espionage games where you play as a team of commandos that has the building schematics where the terrorists are, and you plan out a route and then go busting in to save the hostages. The terrorists react and move around and generally foul up your plan, but if you plan is well designed then overall it still goes vaguely like you had hoped. The fun parts are the initial planning, the ongoing adaptation that the monkey wrenches cause, and that feeling of satisfaction at having bested the scenario.

Actually, that’s what is great about the best tower defense games, too, like PixelJunk Monsters. And it was the thing that kept me going with all the other RTS games that I played over the years, from AOEIII to Rise of Nations, etc. The AI might be doing whatever on those maps, but overall it was just a matter of finding your way through the puzzle of their stock behaviors to grind them down. That was always very fun, to a point, but once the AI became too predictable and once I had my build patterns down, I was done.

How AI War Blends All That Together, And How It Has Grown

AI War was therefore built around having the players constantly off balance and having to adjust their strategies, and having much deeper and longer-term strategies compared to the “comp stomping” in those other games. That said, the AI is always growing an changing, too — layering on many sorts of complexity in its behavior makes for a more interesting and varied experience, and makes it more effective at surprising the player.

There was a time when the AIs just had waves, special forces, guards, and “free” ships that ran right at you most of the time. Then Cross Planet Attacks and retreat/regroup behavior was added, and a lot of the finer mechanics were tuned. Astro Trains have always provided another layer of AI behavior, but they’ve had mixed popularity at best. Then we added minor factions of various sorts, which shook things up almost as much as the CPAs. The recent Border Aggression feature is another major step for the AI, adding on a lot of potential complexity for them in the later game in particular.

And we’re planning further minor factions and have that new “entourage” behavior for starships and fortresses and similar in the works, which should also make things varied in yet another way.

All of these things combine to create an AI that is varied and that can surprise players, and that is always getting better and doing so. It has a lot of various emergent activities at this stage that genuinely surprise me when I play, because I never programmed anything of the sort in, and it’s fascinating to me to see how that sort of thing comes out of those layers of complexity based on multiple simple overlapping rulesets. That’s why I keep focusing on adding more rulesets as much as possible, because that leads to even greater variance. And having more ships with varying attributes and gameplay mechanics attached is also related to that. It’s something that has to be done pretty carefully over time, though.

Even So, The AI Won’t Have The Tempo, And Here’s A Better Example Of Why

And, of course, none of that is ever really going to lead to an AI that has the tempo, as that’s something I studiously avoid for the reasons noted above. There’s a reason that the terrorists in Rainbow Six don’t use squad tactics and come flanking you and executing deep strategies — that would take all of the fun parts of the strategy away from the human players in those games. I’ve played many other FPS games where the AI adversaries do indeed use much more strategy, but since those strategies are largely invisible all it tends to affect is how many guys you wind up facing at a time, and where.

Perhaps my favorite example of great FPS AI is Far Cry 2, because they act like real people and respond intelligently (most of the time) to what I do, but I’m hiding in the bushes and moving around sniping them off, creating distractions, and so forth. If I make a mistake and break cover that will be my death, and if I do something stupid like rushing straight into the camp with guns blazing, then they will also kill me. Heck, if I approach a camp and just sit in one position firing on them, they’ll flank me and kill me, so I have to keep moving and really act like a guerrilla. Come to think of it, Red Faction: Guerrilla did much the same sort of thing, too, and I really enjoyed that there. But in both of those games, as long as I keep hidden and/or behaved so that I’m not noticeable, the AIs are entirely no real threat to me. I have the tempo and can do recon, decide when and how to strike, and then am left with the challenge of dealing with the hornet’s nest that I’ve just kicked.

AI War is like that — that’s the intended design, and it would be a pretty fundamental thing to change it and give the AI the tempo. If the bad guys in Far Cry 2 were constantly prowling the jungle on high alert for me, that would have just made it Half Life 2, which I found to be a wonderful game but much less satisfying tactically.

In Conclusion, The Tempo Thing Is Neither An Oversight Nor Accidental In The Design

Starcraft and Age of Empires and all those other games do what they do for good reason, and in a pvp type arena they provide a lot of what I used to enjoy in both Warcraft II and Counter-Strike. There is value in that, and I’m glad that other developers continue to make games of that sort, even if I’m not specifically interested in them myself anymore. But trying to bend the Rainbow 6es, the Far Cries, the Red Factions, and the AI Wars to be more like them is not something I’d want to do.

I hear what you’re saying, but it isn’t like it’s accidental that AI War is crafted the way that it is. I think the reasons that you mention that hold it back from being “excellent” to just being “great” is what makes some people consider it really excellent at all.

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.”

A Quick Guide: How To Recognize An Arcen Title

Overall, early reactions to Tidalis have been extremely positive, for which our entire team is really gratified. However, there have been a few predictable reactions along the lines of “how do you go from making a hardcore strategy game to an [insert slur on casual or puzzle games, or games with cheerful graphics or music]?” While not unexpected, this is a bit frustrating for me — did people really expect that we’d just make strategy games forever?

Granted, we are still adding free DLC to AI War, and have more expansions planned for that in the future, so it’s not like we’re leaving the strategy market; AI War is as important to us as ever. But that doesn’t mean that AI War is all we want to do, or that hardcore strategy is the only sort of game we are interested in. Personally, I’m a huge fan of action/adventure games (Zelda, etc), platformers (Mario, but also more than that), FPS games (all the great ones — and even some third person ones, like Red Faction: Guerrilla), sandbox games in general (Assassin’s Creed II, etc), puzzle games (Tetris Attack, especially), and also of course strategy games (I have favorites in the tactical, tower defense, RTS, and TBS sub-genres, as you can probably tell from AI War).

I also really enjoy sidescrolling action games (like Bionic Commando Rearmed), some racing games (Burnout Paradise, Midnight Club II, all the Mario Kart games), RPGs (the less-talky American RPGs, and the less-campy JRPGs). I have even been known to enjoy sports games on occasion, though that’s not really my main thing at all. Same with Fighting games. And survival horror games in general, though Silent Hill 2 specifically is one of my favorite games ever. There are all sorts of outliers for me, too, like my love of playing drums on Rock Band or my enjoyment of Boom Blox and its sequel. Speaking historically, I grew up on classic arcade-style games on the Atari 2600, and later a wide swath of games on the NES, SNES, and Genesis. And then N64, and somewhat PSX.

In other words, like a lot of people, I am a Gamer with a capital “G.” I enjoy variety. I like to think as much as I like to have my reflexes tested. Sometimes I’ll play a game just for the sheer joy of the way the controls feel, and how immersive/fun the environment is — Far Cry 2 was a great game for me for that reason, despite the complaints some others had. But unless the mechanic is just incredibly fun, these days I get bored pretty quick if there isn’t some brainpower required to get better at the game and really succeed. I also really feel like there is a lack of classically-inspired 2D games that really shine — they are out there, but they are too few by comparison to their 3D counterparts. All of this contributes to how I go about making games.

In general, you’ll know an Arcen title because:

1. It’s probably in one of the genres noted above, or even more likely it blends several of them together.

2. It’s definitely going to have some hardcore depth to it, though in general our titles are going to be more accessible on the surface than AI War (closer on the scale to Tidalis).

3. It’s definitely going to have co-op, because playing with my family is important to me.

4. It’s either going to make you really think about things, or it’s going to have a really awesome skill-based mechanic that is just plain fun to play at a visceral level (all our games so far are in the first category, but I won’t rule the second category out).

5. All our games are likely to be 2D unless I ever break down and do something like an FPS game or a kart racer or something. I really would like to do an FPS game someday, but given the number of current quality FPS games constantly coming out, and the ridiculous production values on all of them, I doubt I could compete.

6. In general, you can trust that our games will never be more casual than Tidalis, or more hardcore than AI War. That’s basically the scale on which we’re operating. There is a huge stigma about “casual games,” and honestly I share that stigma in many cases. There are a lot of empty calories out there, so to speak, and a ton of games that are barely games. I don’t have any interest in that sort of thing; Tidalis is able to fit into our lineup because it very much delivers on every line item on this list.

7. We don’t do blood and gore.

8. There will always be a plethora of original ideas, and a unique feel, to each of our games. We don’t do clones or also-rans.

Given the above:

When you look at the list above, hopefully you can see the pattern on which we are operating. Tidalis was our next move after AI War partly because we really wanted to do a puzzle game and had a great concept in hand, but also partly because it was important to me that we go ahead and set the boundaries within which Arcen will be working. We were already starting to be typecast as a “strategy developer,” and that really bugs me. Our next game after Tidalis is a 2D action-adventure game (with strong environmental puzzle elements) with some aspects of survival horror (no gore, nothing even really that T rated, but with lots of suspense and zombies), called Alden Ridge.

Then after that action-adventure game will come the next expansion to AI War. Hopefully by the time that game comes out, people won’t think of Arcen in terms of any specific genre. Hopefully they’ll think of us simply as making great 2D games that they enjoy, and which have all the various characteristics from the list above. When our tower defense / JRPG hybrid, A Valley Without Wind, hits sometime next year, the goal is that won’t be any sort of surprise at all.

I can’t imagine the thought of being stuck in only one genre for the rest of my career, but we’re also not “abandoning” any particular genre after having made a single title there. I expect we’ll do more puzzle games sometime down the road. I suspect we’ll make a tactical strategy game (probably turn-based, but we’ll see), and I suspect we might make a larger TBS strategy game at some point, too. And I know Alden Ridge won’t be our last adventure game. And we’ll be doing more than one platformer, too.

A lot of companies might not be able to pull off this type of diversity of genres. But, that’s part of the flexibility of our being indie. And speaking from personal experience, I have worked on either hobbyist or professional projects in the past on games in the following genres: action/adventure, platformer, strategy, text-based adventure, sidescrolling action, JRPG, AD&D-style RPG, dungeon crawler, action puzzle, and FPS. It isn’t exactly a stretch for me to say I want to work in any of those genres, because I’ve been working in most of them on and off, largely as a hobbyist, for the last sixteen years.

So don’t sweat it. Good things are coming from Arcen, and if you’re not into puzzle games (or strategy games, for that matter), you might still want to watch out for our future titles. We have no intention of getting stuck into any sort of routine. Tidalis is not a game purely for the casual crowd (though casual players are welcome), and all of our future games are not going to be like Tidalis any more than they will be like AI War. I’m looking forward to sharing many of the ideas I’ve been storing up over the years with you!

Free Graphics For Indie Developers!

Here’s the link: Download The AI War 2.0 Graphics Library

And here’s the contents of our readme file:

————————————————————-
AI War 2.0 Graphics Library: Free To Use For Indie Developers
————————————————————-

I’m going to keep this as brief as possible, for the sake of clarity. This library contains the graphics for the indie space RTS AI War: Fleet Command, as of version 2.0 of that game. This readme is written by Chris Park, AI War’s creator.

Whoever you are, an indie developer or otherwise, you’re free to use the graphics in this library for whatever purposes you want. Don’t sell these graphics by themselves, but you can include them in your game, your pictures, whatever, and then you can sell your work with this art intact. You can modify them as much as you need for your purposes, as well. Make a new RTS, make some other genre of game, whatever. Just please be sure that you attribute the art to the artist(s) that created it.

———————
Who Created This Art?
———————

The original art for AI War 1.0 was all by myself (and not that good), or by Daniel Cook (mostly the ship graphics, but also some other aspects, and quite good). For almost everything that is by Daniel Cook and included in this library, it has also been modified by myself (Chris Park) to a greater or lesser degree. But the work is still primarily Danc’s (I mostly only bring up my involvement so that some of the… less appealing… compound works that are in the Daniel Cook folder are not mistaken as something that he put together. If it looks a bit lesser quality, that’s probably my hand at work).

After release, an AI War player named Hans-Martin Portmann, who is also an artist, was gracious enough to donate some art to help improve the game. His suggestions also led to a lot of the improved special effects, even for those where he did not directly contribute images.

After version 1.013 of the game came out, Philippe Chabot joined the Arcen Games team and upgraded much of the art, replacing a huge amount of it outright. He also did some significant upgrades to some of Danc’s/my work, making it larger, or animated, or more detailed in certain ways, or whatever.

So here’s how you know who the artist is, looking at the folders in this archive:

ChrisPark
———-
The work in this folder is original to me, and there is not a whole lot of it left at this stage.

DanielCook (http://lostgarden.com/)
———————————–
Everything in this folder was created by Daniel Cook, and probably also altered to some degree by Chris Park. A few things that were orignal to Chris Park might have been stuck in here as well, but that’s just things like numbers or a check mark, etc.

Tyrian: http://lostgarden.com/2007/04/free-game-graphics-tyrian-ships-and.html
Iron Plague: http://lostgarden.com/2005/03/download-complete-set-of-sweet-8-bit.html
Hard Vacuum: http://lostgarden.com/2005/03/game-post-mortem-hard-vacuum.html

DanielCookPhilippeChabot
————————
The work in this folder started out as Daniel Cook’s work, and then way probably also altered to some degree by Chris Park, and then was altered to a much more significant degree (in most cases) by Philippe Chabot.

HansMartinPortmann
——————
The work in this folder is all original to Hans-Martin Portmann.

PhilippeChabot
————–
The work in this folder is all original to Philippe Chabot.

—————————————-
Why Are You Releasing This Art For Free?
—————————————-

As I mentioned above, AI War started out with just unimpressive programmer graphics mixed with the excellent work of Danc. The game went on sale in this state, and sold into the four digits of units sold without any art upgrades from Philippe. The primary determinant of our sales was the game itself, of course, but having graphics that weren’t all as terrible as they would have been if I had had to make them all myself was a huge boost, I think. I couldn’t afford to pay for art at the start, as I was developing AI War in my own spare time and had no budget to speak of.

Danc releases some of his old pixelart on his website — some of it is from Tyrian, and some of it is from some other older games of his that were not actually ever released — and it’s safe to say that AI War wouldn’t have existed in at all its released form without his having decided to do that. His generosity helped get AI War off the ground, and once AI War was to the point where it was making enough money that I could afford to hire an artist, I knew I wanted to give back in the same way.

All of Philippe’s art in this library was done as work for hire and so belongs to Arcen Games, but Philippe was very much on board when I pitched him the idea of making a library for other indies to be able to reuse from. There simply isn’t much out there aside from what Danc puts out and maybe four other sources for free pixelart that indie developers can use in commerical products, and so hopefully you’ll find this library useful. It’s our way of giving back to the indie community, in hopes of bootstrapping some other talented developer the way that Daniel Cook bootstrapped Arcen Games.

Iterative Game Design The Right Way

The industry standard way of designing games is to do so in advance, crafting a hefty “design document” that is basically the bible of how the game will be created. I can see the value of this when working with a huge team of staff, and certainly I can see the value of this when trying to get funding from a publisher. Many times the various realities of the industry simply dictate the designed-in-advance methodology.

Some design teams try to circumvent this a bit by prototyping — basically, while the design document is being crafted, a prototype is also being developed. Revisions and alterations and discoveries during this prototyping phase are then integrated into the final design document, and this almost invariably is going to result in a better end product.

For a large company with a large team, or for a company that must take their design ideas to investors, or a publisher, or management, in order to secure funding for a new IP, I can’t think of a better way to handle this. But, boy oh boy, does this make me happy to be an indie.

What Iterative Design Isn’t — And What I Mean By “The Right Way”
On the surface, it must seem pretty arrogant of me to proclaim that my way of iterative design is the “right” way, against all comers. To be fair, I don’t think this is the only valid approach, but the benefits are many and I’m basically just cross-applying some concepts from the larger pool of software development thought. It’s very much similar to Rapid Prototyping, or Agile Software methods, or to a certain extent Extreme Programming, etc. My background is in business programming, and these sorts of methods are much more common there — I’ve been using and refining my own shade of agile programming in a professional environment for about seven years now, and all I’ve done is carry it over to game design.

So what’s this “right way” business, then? Well, I think that iterative design has, in certain circles, become shorthand for “lazy” or “unprofessional.” As in, the designer just sits down without a plan, and cranks out whatever comes to mind. The end result of such an endeavor is rarely good, and/or generally isn’t very cohesive or original. It’s like sitting down to create a chair out of a bunch of wood, and just starting on the first leg without any plans or advance thought, then moving on to each other leg and the rest of the chair as you come to it. The end result is unlikely to sit particularly level, and for that matter the style of the later legs is likely to be subtly or majorly different from the first leg.

If that’s what you think iterative design is, no wonder you’d look down your nose at it. I have similar disdain for such a method as unprofessional and unlikely to work in a real production environment. Sure, there might be outlier successes using such a method, but that’s more luck than anything else. Fortunately, what I just described isn’t iterative design.

A Starting Point For Iterative Design: Goals
When you set out to iteratively design a game, or any other piece of software for that matter, the most important thing is that you don’t start with a completely blank slate. You must have some sort of immutable design goals, and these are ideally paired with some initial design concepts that will guide early prototypes.

In the case of AI War, for example, here were my immutable design goals, which I set several months before starting on the AI War prototype:

1. The game must support co-op play in a way that is fun and painless.
2. The games must be long — 8-12 hours perhaps — and must continuously evolve as they progress.
3. There must be a huge number of viable options available to the player at any given time, or every game will start to feel the same.
4. The game must be designed in such a way that it does not reward fast-clicking over real thought, or my dad (and players like him) will not really enjoy it.
5. There must never be a “best path” for players to learn, or the game has just died. There must be enough variability and randomness in each game that players must somehow have to make different decisions based on the current situation.

Additionally, here were my soft design goals (amongst a few dozen other lesser ones):

1. Ideally, it should have the feel and general controls of RTS. Also the realtime nature, i.e. no waiting for other players to do something as often happens in CivIV.
2. The game will be turn-based, with an emphasis on Line of Sight (LOS) as in Chess, to provide extra depth to tactics, and more strategy to the game overall.
3. The turns for players will be simultaneous, with “action points” being granted over some interval, to keep things moving.
4. The game will take place across multiple planets, with infinite effective play space around each planet.
5. The game will feature around 10,000 units in realtime, if possible, most likely with individual units combined into larger ur-units (“strike groups?” that are moved around as a single entity).

As AI War players will note, numbers 1 and 4 were kept (although the infinite playspace was removed and then reimplemented in a revised manner post-release), while 2 and 3 were completely discarded as nonviable rather early in alpha. #5 turned out to be vastly more feasible than I had anticipated, and the unit counts grew to 3x to 6x my original max estimation, making the ur-units completely unneeded (and thus saving me some valuable development time in being able to skip their implementation).

There were hundreds, perhaps a thousand or more, other soft design goals that rose and fell during the 7 month development cycle of the game, but this was just part of the iterative design process.

Implementing The “Immutable” Goals, Two Examples
In looking at my immutable design goals, not one did I have to deviate from. These were the core design tenets for the game, and spoke more to the feel and style of the experience than a particular methodology, after all. Experienced AI War players might look at that list and think of the specific end implementation that I arrived at and think that the end implementation is what I had in mind from the start — but that’s not true at all. Some examples out of the hundreds, nay thousands, of important iterative design processes relating to these immutable goals:

Example 1: Co-Op Play Shifts
Problem: For #1, an important sub-goal was that co-op players would never be “out of the game” early, because that would lead either to boredom on the part of that player, or, more likely, to all the players giving up and starting a new game. Having played other RTS skirmishes cooperatively for years, this was the age-old pattern that I really wanted to break.

Background: Early versions of the AI War alpha had the central unit of the game as the Flagship, a mobile starship (then called a capital ship) that had high firepower and defenses, but which was also what caused you to lose the game if destroyed. It was also what let you build most other ships (it was basically replaced by the Home Orbital Command Station, if you are familiar with the release versions of AI War). This also functioned kind of like the Supreme Commander unit in the title by the same name.

Initial Design Solution: When a flagship is destroyed, it turns into a “flagship core,” a weak ship that can nevertheless produce a limited number of four or five different kinds of “core” ships for the player, which are devastatingly powerful compared to normal ships but fewer in number. The players-who-are-out thus get to roam the galaxy with their small core of ships, wreaking havoc and causing problems for the opposing players wherever possible (note to AI War players: all of this was before the AI was asymmetrical, and thus before “core” ships took on Mark V status).

Problems With The Initial Design: The problems with this were many, and were interrelated with a whole host of other problems such as the fact that having a powerful, mobile “king” type unit was strategically unbalancing and too similar to Supreme Commander. However, the biggest problem was that playing as the “Flagship Core” with its associated ships was not very fun for very long. This violated immutable rule #3, of always having lots of options open to the player at all times.

Eventual Solution: In the end, many of the related game mechanics shifted, and the concept of the Flagship core disappeared entirely. I did not relish the thought of having to create an entire duplicate tech tree just for deceased players to use (to keep to immutable rule #3), so the decision was to let deceased players keep playing completely as normal so long as their team is surviving.

There is an economic penalty to losing your home command station (since it produces a high number of resources), but the options available to the deceased players are otherwise not diminished. If they are able to fight their way back up and claim some more planets, they can replenish their lost income and more. Each team wins or loses as an entire unit, which makes perfect sense for co-op and was one of those “it’s so obvious why didn’t I think of that before” moments when it later occurred to me.

Example 2: Number of Options Shifts
Initial Design Problem: For most of the alpha phase of AI War, any player could build any ship class at any time. They had to unlock more advanced versions of each ship type as they went, as now, but the available ship types were not constrained and so there were 30 distinct classes of mobile military ship available to the players at any given time, along with all of the classes of turrets, defensive ships, etc.

This, as you may expect, caused “analysis paralysis” in even the alpha testers, who were very experienced with the game. There were far too many options with too many factors to weigh at any given time. So players tended to gravitate to a few ship types they preferred, building only them, or they tended to just flail about building a random mix of ships. In either case, the strategy was all but killed for ship-building.

Eventual Solution: It was actually my dad who suggested limiting the number of ships available at the start. I was vehemently opposed to the idea at first, believing that it conflicted with my immutable rule #3, but over the course of a wide-ranging design discussion that lasted several hours one Sunday in late March or early April, I came to see the wisdom of what he was suggesting and added several twists of my own — the per-ship-type-and-level caps, the method of having start positions per map seed (with “bonus ship types” tied to each location), and the Advanced Research Stations.

This was a fundamental shift to the entire game, and really brought it into focus and made it very close to the final product that is now available. I had been so focused on creating a game without constraints on the player before that point, so that players could build their own civilization as they saw fit, that I failed to see that this very lack of constraints also fed into creating best paths for players (in violation of immutable goal #5), a severe problem that I was wrestling with through other angles until this solution was suggested.

A Point When Everything Comes Together
In the second example in particular, you can see how one solution solves a whole host of problems at once, including some problems that seemed unrelated to the issue at hand. In the first example, you can see some examples of how playtesting revealed an “obvious” course of action that never would have occurred to me just staring at design documents.

Basically, here’s how iterative design works: you start with good intentions, and some good basic rules, but you create something that is (at first) horribly flawed. Of course, it is horribly flawed, it was only designed in the loosest sense. However, you very quickly have a prototype that works, that is a product, if not a very fun one. But you can start playing it, and you can see what is fun and what is not. With playtesting, you can sometimes even see why certain things work and others do not.

But most importantly, you can see how all of the various ideas interact. AI War is an exceedingly complex game, built upon many different complex interrelating systems. I’m a smart guy, but there’s no way I could ever have conceived of all of that in advance. There are simply no other models in the genre to point to for a lot of this stuff, and the interrelationships are all too complex. There are too many nth order effects that only come up through playtesting, and which don’t always even come up immediately then.

Building a successful game that is highly complex and innovative is an exercise in constant revision. There are too many hidden problems and “gotchas” if you are trying to push the envelope and do something new. If you never stumble, if you never hit upon an idea that does not work, then you are either very lucky or not really innovating all that much. Because, the fact is, if you innovate in one area, that pretty much requires changes in other areas. And those secondary changes require tertiary changes, etc.

With iterative design, you can work and work and work until the point where everything comes together, twisting and turning each puzzle piece until the ones that fit together have created a beautiful mosaic. Not quite the mosaic you set out to create, but within certain bounds, and with a lot of never-before-seen qualities to it.

You Can’t See Around Corners
My theory is that AAA games stick to tried-and-true gameplay models with slight variations largely out of a need to manage these nth order effects in those original design documents that are so prized. It’s just too much complexity for any individual or even team to manage in advance of any actual playtesting feedback.

There are two main metaphors I like to use for this conundrum for up-front designs. The first is the image of a twisty hallway that stretches off into the future. You can see to the first bend, but no further. Planning your route in advance is nearly impossible, because you can only see around each corner as you come to the corner that precedes it (as in iterative design).

The other metaphor that I like is that of Chess. Let’s say that you are playing a sort of solitaire version of Chess, where each move you make has some sort of semi-predictable opposing reaction. You make a move, and the opponent makes a predictable corresponding move. A game of Chess, like the design of a game of any significant complexity, is going to comprise hundreds of “moves.” You can plan the first few with confidence. But as you get further and further into the future, it becomes harder and harder to keep the board state in your mind. There are simply too many variables, especially if you start wondering “what if I did X instead of Y” 5 turns back? That changes everything.

The Chess example is easy to grasp because we all know the supercomputing power required to play Chess at an expert level. Planning the whole of a highly original, complex game in advance requires a similar magnitude of computing power, and I posit that no human can do it. The best anyone can manage is some evolutionary steps in a variety of areas, possibly with some unexpected twists thrown in as data is gathered through playtesting and development. Granted, some highly original games have a lower base complexity, and can be planned out completely in advance. But, for myself at least, as well as many other agile designers/programmers, the idea of all the mental stress and strife involved in such an exercise in advance planning is just too much to bear.

A Chess Grandmaster can look 12 to 14 moves ahead, but that’s all. Asking even the best in the world to plan the entire game in advance, even if they knew how their opponent would definitely react to every move, is just too much. This isn’t slackness, it’s expediency and a desire to explore the unknown.

In Conclusion
Advance planning can indeed allow for the designer to come up with a number of innovations — even major ones. It happens all the time. My point is not to insult other designers who plan in advance (indeed, I’m in awe of the mental fortitude it takes to balance that many variables with little or no feedback). There is more than one way to design games, for that matter, and I don’t begin to suppose that my method of iterative design is the only valid way.

But rather, I posit this: given the same designer with the same initial goals, that designer will produce more innovation via a properly-managed iterative design process with continual feedback than they would trying to design in advance with nothing but self and peer conjecture for feedback. I contend that better data to the designer, earlier in the design process, will lead to better designs. Iterative design probably isn’t the only way to arm the designer with that sort of data (extensive past experience is certainly another valid route), but it’s a simple and effective method, and one that I think is erroneously scoffed at. AI War wouldn’t exist as you know it without iterative design, and that’s no joke.

UPDATE: If you want to read more on this subject, check out my post from a year and a half later, More Musings On Iterative Game Design.

Designing Emergent AI, Part 5: Don’t Squeeze a Handful of Sand

In the fourth installment of this series, I talked about the asymmetrical nature of the AI in AI War. That was intended to be the final article in the series, unless more questions came up that I needed to address. Recently a discussion arose on the Arcen Games forums, however, which I think really helps to illuminate an important point that I never managed to cover in this article series before now.

The Question, From User “dumpsterKEEPER”
I really like the AI behavior that allows for retreats when faced with overwhelming odds. On a number of occasions however, I’ve noticed this general scenario:

The AI has a strike force on one of my worlds when I jump a fleet in to defend it. As it’s a sizeable defense force, the retreat logic kicks in and the AI splits off into multiple groups heading towards exit wormholes. One or more of these groups travel to an undefended wormhole and exit the system without a scratch. However, another group will head straight towards a turreted/defended wormhole and get completely wiped out in their attempt to leave the system.

I would suggest that when retreating, the AI should attempt to prioritize exit wormholes that are undefended or lightly defended. This would make sense with their retreating posture and would leave more AI ships alive to attack again in the future.

My initial response
I thought about this, but it leads to some undesirable ways to then further trick the AI — leave a REALLY big force on the other side of the undefended wormhole, and then the AI pops out and gets slaughtered. This is one of those places (like the gap in the wall logic) that leads to too-predictable AI in other games. I agree, it will often make the AI act slightly non-ideal in this case, but it also protects it from being trapped into REALLY non-ideal situations, if that makes sense.

One of the forum moderators then suggested that I might consider simply having the AI probe undefended wormholes to see if it’s safe. My response to that:

Probing undefended wormholes requires

A) time, during which the AI ships have to do something (and during which time they might well just be getting killed, or giving the human player time to come up with a counter)

B) a way to evaluate if the other side is safe (is it safe if the wormhole is clear, but there are massive fortifications on the other planet? what about if it is a long string of planets, and the danger is somewhere further down? do we get into situations where the AI just runs back and forth between some planets because it can’t find an acceptable exit to punch through at either end?).

C) a lot of coordination between the AI ships, which isn’t super compatible with the whole emergent AI thing.

This is one of those times where the emergent AI will make a slightly nonideal choice sometimes, but that slightly nonideal choice is actually better in the long term than always making the predictable 100% best choice. I intentionally avoid coding in hard rules like that, because as soon as the AI is too predictable, even if it is very smart, the players can formulate some second-order strategies to counter it. I know this because my play group (the AI War alpha group) is expert at finding these strategies in pretty much all RTS games. We never did find anything too exploitative for RoL or RoN thanks to the lack of walls, but we did for AoE2, AoE3, Empire Earth, SupCom, and all the various expansions — and the SupCom AI mods, as well, though that took longer.

This really goes to the fundamental nature of the AI in AI War, and why it is in the main better. Will it sometimes do things like this that are tempting to “fix?” Yes. When there is a direct way to evaluate this sort of thing on a per-ship basis, I try to do that while also still making sure it remains fuzzy. A lot of the recent minor AI rules updates have been that sort of thing. But when something requires a lot of intentional ship coordination, or a lot of looking-ahead or scouting or what have you, that’s where I start getting very nervous and staying away. The premise of this sort of AI is to stay away from those sort of things, because even though they fix the direct problem, they often cause a whole raft of other problems and exploits down the line…

More from dumpsterKEEPER
Ah, that makes sense. I hadn’t thought about it from the potential exploits perspective. Thanks for explaining your thinking though, that’s helpful to understand why the AI sometimes behaves the way it does. I can understand the hesitation to add specific rules to the AI as eventually you’d essentially end up with a decision tree AI.

In regards to this issue in particular, I don’t think it’s a huge deal, it just sometimes strikes me as odd that a group of AI ships will impale themselves on obviously placed defenses. On the other hand, occasional sub-optimal decisions do sometimes catch me by surprise and make the AI feel more “human.”

My closing notes
No problem! Glad it’s not too big an issue. And, for sure, sometimes those groups of ships will, in the process of impaling themselves, do something important. Or sometimes they’ll have enough strength to break through into the adjoining planet and do some real damage on the other side. One of the players in my game on Saturday actually lost his home planet to something like that.

When I was working on the AI code to start out, originally everything was rules-based. And when I switched to a more emergent style of AI code, I thought I’d have to build in more rules there, too. That’s why I was so surprised how quickly the AI started being effective, and from that stage on I became careful of second-order effects. I think that’s the unique bit of knowledge that I stumbled across by accident, which leads to more effective AI designs in general.

Effective AI is like holding a handful of sand: some sand will trickle uselessly from your hand no matter what, this can’t be prevented, but most game AI programmers squeeze the sand more tightly to try and save it, and wind up losing so much more sand in the process.

Next Time?
Once again, we come to the “end.” Unless readers bring up more topics that they’d like me to address, this will probably be the final article in my AI series. So, I’m sure that another AI-focused article will come up at some point, in other words, but I don’t have any idea when or what the specific subject matter will be. In the meantime, I do have other articles planned on other game-related subjects!

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.”

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.”

Designing Emergent AI, Part 3: Limitations

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 second article was basically just for programmers and AI enthusiasts, as is this third one. The topic, this time, is the manner in which this approach is limited.

This Approach Is Limited?
Well, of course. I don’t think that there is any one AI approach that can be used to the exclusion of all others. And our AI designs are already heavily hybridized (as the first article in the series mentions), so it’s not like I’m using any single approach with AI War, anyway. I used the techniques and approaches that were relevant for the game I was making, and in some respects (such as pathfinding), I blended in highly traditional approaches.

The purpose of this article is to discuss the limits of the new approaches I’ve proposed (the emergent aspects, and the LINQ aspects), and thereby expose the ways in which these techniques can be blended with other techniques in games beyond just AI War. Let’s get started:

Where Emergence Quickly Breaks Down
To get emergent behavior, you need to have a sufficient number of agents. And to keep them from doing truly crazy stuff, you need to have a relatively simple set of bounds for their emergence (in the case of AI War, those bounds are choosing what to attack or where to run away to. Basically: tactics). Here are some examples of places that I think it would be massively ineffective to try for emergent behavior:

1. A competitive puzzle game like tetris. There’s only one agent (the cursor).

2. Economic simulations in RTS games. That’s all too interrelated, since any one decision has potentially massive effects on the rest of the economy (i.e., build one building and the opportunity cost is pretty high, so some sort of ongoing coordination would be very much needed).

3. Any sort of game that requires historical knowledge in order to predict player actions. For example, card games that involve bluffing would not fare well without a lot of historical knowledge being analyzed.

4. Any game that is turn-based, and which has a limited number of moves per turn, would probably not do well with this because of the huge opportunity cost. Civilization IV could probably use emergent techniques despite the fact that it is turn-based, but Chess or Go are right out.

Why Emergence Works For AI War
1. There are a lot of units, so that gives opportunities for compound thinking based on intelligence in each unit.

2. Though the decision space is very bounded as noted above (what to attack, or where to retreat to), that same decision space is also very complex. Just look at all of the decision points in the LINQ logic in the prior article. There are often fifty ways any given attack could succeed to some degree, and there are a thousand ways they could fail. This sort of subtlety lets the AI fuzzify its choices between the nearly-best choices, and the result is effective unpredictableness to the tactics that feels relatively human.

3. There is a very low opportunity cost per decision made. The AI can make a hundred decisions in a second for a group of ships, and then as soon as those orders are carried out it can make a whole new set of decisions if the situation has changed unfavorably.

4. Unpredictableness is valuable above most all else in the tactics, which works well with emergence. As long as the AI doesn’t do something really stupid, just having it choose effectively randomly between the available pretty-good choices results in surprise tactics and apparent strategies that are really just happenstance. If there were fewer paths to success (as in a racing game, for example), the boundedness of decisions to make would be too tight to make any real opportunities for desirable emergent behavior.

Learning Over Time
One intentional design choice that I made with AI War was to keep it focused on the present. I remember seeing Grandmaster Chess players at Chess tournaments, where they would play against 50 regular ranked players at once, walking around the room and analyzing each position in turn. On most boards they could glance at the setup and make their move almost instantly. On a few they would pause a bit more. They would still typically win every game, just choosing whoever put up the best fight to cede a victory to (that person typically got a prize).

I figured it would be nice to have an AI with basically those capabilities. It would look at the board at present, disregarding anything it learned in the past (in fact, it would be just a subject matter expert, not a learning AI in any capacity), and then it would make one of the better choices based on what it saw. This is particularly interesting when players do something unexpected, because then the AI does something equally unexpected in response (responding instantly to the new, unusual “board state”).

I feel like this works quite well for AI War, but it’s not something that will evolve over time without the players learning and changing (thus forcing the AI to react to the different situations), or without my making extensions and tweaks to the AI. This was the sort of system I had consciously designed, but in a game with fully symmetrical rules for the AI and the humans, this approach would probably be somewhat limited.

The better solution, in those cases, would be to combine emergent decision making with data that is collected and aggregated/evaluated over time. That collected data becomes just more decision points in the central LINQ queries for each agent. Of course, this requires a lot more storage space, and more processing power, but the benefits would probably be immense if someone is able to pull it off with properly bounded evaluations (so that the AI does not “learn” something really stupid and counterproductive).

Isn’t That LINQ Query Just A Decision Tree?
One complaint that a few AI programmers have had is that the LINQ queries that I’ve shared in the second article aren’t really that different from a traditional decision tree. And to that, I reply: you’re absolutely right, that aspect is not really too different. The main advantage is an increase in readability (assuming you know LINQ, complex statements are much more efficiently expressed).

The other advantage, however, is that soft “preferences” can easily be expressed. Rather than having a huge and branching set of IF/ELSE statements, you have the ORDER BY clause in LINQ which makes the tree evaluation a lot more flexible. In other words, if you have just this:

ORDER BY comparison 1,
comparison 2,
comparison 3

You would be able to have a case where you have 1 as true, 2 as false, and 3 as true just as easily as all three being true, or having false, true, false, or any other combination. I can’t think of a way to get that sort of flexibility in traditional code without a lot of duplication (the same checks in multiple branches of the tree), or the use of the dreaded and hard-to-read gotos.

So, while the idea of the LINQ query is basically the same as the decision tree in concept, in practice it is not only more readable, but it can be vastly more effective depending on how complex your tree would otherwise be. You don’t even have to use LINQ — any sorting algorithm of sufficient complexity could do the same sort of thing. The novelty of the approach is not LINQ itself, but rather using a tiered sorting algorithm in place of a decision tree. You could also express the above LINQ code in C# as:

someCollection.Sort( delegate( SomeType o1, SomeType o2 )
{
int val = o1.property1.CompareTo( o2.property1 );
if ( val == 0 )
val = o1.property2.CompareTo( o2.property2 );
if ( val == 0 )
val = o1.property3.CompareTo( o2.property3 );
return val;
} );

In fact, throughout the code of AI War, statements of that very sort are quite common. These are more efficient to execute than the equivalent LINQ statement, so on the main thread where performance is key, this is the sort of approach I use. In alpha versions I had it directly in LINQ, which was excellent for prototyping the approaches, but then I converted everything except the AI thread into these sorts instead of LINQ, purely for performance reasons. If you’re working in another language or don’t know SQL-style code, you could easily start and end with this kind of sorting.

Combining Approaches
In AI War, I use basically the following approaches:

1. Traditional pathfinding
2. Simple decision-engine-style logic for central strategic decisions.
3. Per-unit decision-engine-style logic for tactics.
4. Fuzzy logic (in the form of minor randomization for decisions) throughout to reduce predictability and encourage emergence given #3.
5. Soft-preferences-style code (in the form of LINQ and sorts) instead of hard-rules-style IF/ELSE decision tree logic.

If I were to write an AI for a traditional symmetrical RTS AI, I’d also want to combine in the following (which are not needed, and thus not present, in AI War):

6. A decision tree for economic management (using the sorting/LINQ approach).
7. A learning-over-time component to support AI at a level for really great human players in a symmetrical system.

If I were to write an AI for a FPS or racing game, I’d probably take an approach very similar to what those genres already do. I can’t think of a better way to do AI in those genres than they already are in the better games in each genre. You could potentially combine in emergence with larger groups of enemies in war-style games, and that could have some very interesting results, but for an individual AI player I can’t think of much different to do.

For a puzzle game, or a turn-based affair like Chess, there again I would use basically the current approaches from other games, which are deep analysis of future moves and their consequences and results, and thus selection of the best one (with some heuristics thrown in to speed processing, perhaps.).

Performers or adventure games could also use mild bits of swarm behavior to interesting effect, but I think a lot of players (myself included) really do like the convention of heavily rules-based enemies in those genres. These games don’t really tend to feature AI that is meant to mimic humans, rather AI that is meant to just follow simple rules that the human players can learn and remember.

The sort-style decision tree might be easier to code and might bring results slightly more efficiently in all of the above cases, but the end result for the player wouldn’t be much different. Still, making AI code easier to program and read is a good thing for everyone (lower costs/time to develop, fewer bugs based on poor readability, etc).

Next Time
Part 4 of this series talks about the asymmetry in this AI design.

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.”

Designing Emergent AI, Part 2: Queries and Code

The first part of this article series has been a hit with a lot of people, yet criticized by others for being too introductory/broad. Fair enough, starting with this article I’m going to get a lot lower-level. If you’re not a programmer or an AI enthusiast, you probably won’t find much interest beyond this point.

What Do You Mean, It Works Like A Database?
First question that most people are asking is in what way my AI code can possibly be like a database. In a past article (Optimizing 30,000+ Ships In Realtime In C#) I already talked about how I am using frequent rollups for performance reasons. That also helps with the performance of the AI, but that’s really not the meat of what I’m talking about.

I’m using LINQ for things like target selection and other goal selection with the AI in the game, and that really cuts down on the amount of code to make the first level of a decision (it also cuts down on the amount of code needed in general, I’d estimate that the entirety of the decision-making AI code for the game is less than 20,000 lines of code). Here’s one of the LINQ queries for determining target selection:


var targets =
//30% chance to ignore damage enemy can do to them, and just go for highest-value targets
( unit.UnitType.AIAlwaysStrikeStrongestAgainst ||
AILoop.Instance.AIRandom.Next( 0, 100 ) < 30 ?
from obj in rollup.EnemyUnits
where ( unit.GuardingObjectNumber <= 0 || //must not be guarding, or guard target must be within certain range of guard post
Mat.ApproxDistanceBetweenPoints( unit.GuardingObject.LocationCenter,
obj.LocationCenter ) < Configuration.GUARD_RADIUS )
orderby obj.UnitType.ShipType == ShipType.Scout ascending, //scouts are the lowest priority
obj.GetHasAttackPenaltyAgainstThis( unit ) ascending, //ships that we have penalties against are the last to be hit
(double)obj.GetAttackPowerAgainstThis( unit, usesSmartTargeting ) / (double)obj.UnitType.MaxHealth descending, //how much damage I can do against the enemy out of its total health
obj.IsProtectedByForceField ascending, //avoid ships that are under force fields
obj.NearbyMilitaryUnitPower ascending, //strength of nearby enemies
Mat.ApproxDistanceBetweenPoints( obj.LocationCenter, unit.LocationCenter ) ascending, //how close am I to the enemy
obj.UnitType.ShieldRating ascending, //how high are their shields
unit.UnitType.AttackPower ascending, //go for the lowest-attack target (economic, probably)
obj.Health ascending //how much health the enemy has left
select obj
:
from obj in rollup.EnemyUnits
where ( unit.GuardingObjectNumber <= 0 || //must not be guarding, or guard target must be within certain range of guard post
Mat.ApproxDistanceBetweenPoints( unit.GuardingObject.LocationCenter,
obj.LocationCenter ) < Configuration.GUARD_RADIUS )
orderby obj.UnitType.ShipType == ShipType.Scout ascending, //scouts are the lowest priority
( chooseWeaklyDefendedTarget ?
obj.UnitType.TripleBasicFirePower >= obj.NearbyMilitaryUnitPower :
( chooseStronglyDefendedTarget ?
obj.UnitType.TripleBasicFirePower < obj.NearbyMilitaryUnitPower : true ) ) descending, //lightly defended area
(double)obj.GetAttackPowerAgainstThis( unit, usesSmartTargeting ) / (double)obj.UnitType.MaxHealth descending, //how much damage I can do against the enemy out of its total health
obj.IsProtectedByForceField ascending, //avoid ships that are under force fields
obj.NearbyMilitaryUnitPower ascending, //strength of nearby enemies
obj.GetHitPercent( unit ) descending, //how likely I am to hit the enemy
unit.GetAttackPowerAgainstThis( obj, false ) descending, //how much damage the enemy can do to me
obj.Health ascending //how much health the enemy has left
select obj
);

Blogger eats a lot of the formatting there, but hopefully you can see what is going on based on the comments in green. In some ways you could call this a decision-tree (it does have multiple tiers of sorting), but the overall code is a lot more brief and (when properly formatted with tabs, etc) easier to read. And the best thing is that, since these are implemented as a sort, rather than distinct if/else or where clause statements, what you arrive at is a preference for the AI to do one thing versus another thing.

There are a lot of things that it takes into consideration up there, and there are a few different modes in which it can run, and that provides a lot of intelligence on its own. But that’s not enough. The loop that actually evaluates the above logic also adds some more intelligence of its own:


bool foundTarget = false;
foreach ( AIUnit enemyUnit in targets )
{
if ( enemyUnit.Health <= 0 || enemyUnit.CloakingLevel == CloakingLevel.Full )
continue; //skip targets that are already dead, or are cloaked
if ( unit.CloakingLevel == CloakingLevel.Full &&
enemyUnit.UnitType.ShipType == ShipType.Scout )
continue; //don't give away the position of cloaked ships to scouts
if ( unit.CloakingLevel != CloakingLevel.None &&
enemyUnit.UnitType.TachyonBeamRange > 0 )
continue; //cloaked ships will not attack tachyon beam sources
if ( enemyUnit.UnitType.VeryLowPriorityTarget )
continue; //if it is a very low priority target, just skip it
if ( enemyUnit.IsProtectedByCounterMissiles && unit.UnitType.ShotIsMissile )
continue; //if enemy is protected by counter-missiles and we fire missiles, skip it
if ( enemyUnit.IsProtectedByCounterSnipers && unit.UnitType.ShotIsSniper )
continue; //if enemy is protected by counter-sniper flares and we fire sniper shots, skip it
if ( enemyUnit.GetAttackPowerAgainstThis( unit, false ) == 0 )
continue; //if we are unable to hurt the enemy unit, skip attacking it
if ( unit.EffectiveMoveSpeed == 0 && !unit.UnitType.UsesTeleportation &&
enemyUnit.GetHitPercent( unit ) <>
continue; //stop ourselves from targeting fixed ships onto long-range targets

gc = GameCommand.Create( GameCommandType.SetAttackTarget, true );
gc.FGObjectNumber1 = unit.FGObjectNumber;
gc.FGObjectNumber2 = enemyUnit.FGObjectNumber;
gc.Integer1 = 0; //Not Attack-Moving
unit.LastAICommand = gc.AICommand;
AILoop.Instance.RequestCommand( gc );
foundTarget = true;
break;
}

//if no target in range, and guarding, go back to base if out of range
if ( !foundTarget && unit.GuardingObjectNumber > 0 )
{
Point guardCenter = unit.GuardingObject.LocationCenter;
if ( Mat.ApproxDistanceBetweenPoints( guardCenter, unit.LocationCenter ) >
Configuration.GUARD_RADIUS )
Move( unit, guardCenter );
}

Nothing real surprising in there, but basically it has a few more decision points (most of these being hard rules, rather than preferences). Elsewhere, in the pursuit logic once targets are selected, ships have a preference for not all targeting exactly the same thing — this aspect of them watching what each other are doing is all that is really needed, at least in the game design I am using, to make them do things like branching and splitting and hitting more targets, as well as targeting effectively.

Rather than analyzing the above code point by point, I’ll mostly just let it speak for itself. The comments are pretty self-explanatory overall, but if anyone does have questions about a specific part, let me know.

Danger Levels
One important piece of logic from the above code that I will touch on is that of danger levels, or basically the lines of code above where it is evaluating whether or not to prefer a target based on how well it is defended by nearby ships. All ships have a 30% chance to disregard the danger level and just go for their best targets, and some ship types (like Bombers) do that pretty much all the time, and this makes the AI harder to predict.

The main benefit of an approach like that is that it causes the AI to most of the time try to pick off targets that are lightly defended (such as scrubbing out all the outlying harvesters or poorly defended constructors in a system), and yet there’s still a risk that the ships, or part of the ships will make a run at a really-valuable-but-defended target like your command station or an Advanced Factory. This sort of uncertainty generally comes across as very human-like, and even if the AI makes the occasional suicide run with a batch of ships, quite often those suicide runs can be effective if you are not careful.

Changing The AI Based On Player Feedback
Another criticism that some readers had about the first AI article was to do with my note that I would fix any exploits that people find and tell me about. Fair enough, I didn’t really explain myself there and so I can understand that criticism. However, as I noted, we haven’t had any exploits against the AI since our alpha versions, so I’m not overly concerned that this will be a common issue.

But, more to the point, what I was actually trying to convey is that with a system of AI like what you see above, putting in extra tweaks and logic is actually fairly straightforward. In our alpha versions, whenever someone found a way to trick the AI I could often come up with a solution within a few days, sometimes a few hours. The reason is simple: the LINQ code is short and expressive. All I have to do is decide what sort of rule or preference to make the AI start considering, what relative priority that preference should have if it is indeed a preference, and then add in a few lines of code. That’s it.

With a decision tree approach, I don’t think I’d be able t to do that — the code gets huge and spread out through many classes (I have 10 classes for the AI, including ones that are basically just data holders — AIUnit, etc — and others that are rollups — AIUnitRollup, which is used per player per planet). My argument for using this sort of code approach is not only that it works well and can result in some nice emergent behavior, but also that it is comparably easy to maintain and extend. That’s something to consider — this style of AI is pretty quick to try out, if you want to experiment with it in your next project.

Next Time
Part 3 of this series talks the limitations of this approach.

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.”

Designing Emergent AI, Part 1: An Introduction

A lot of people have been curious about how the AI in AI War: Fleet Command works, since we have been able to achieve so much more realistic strategic/tactical results compared to the AI in most RTS games. Part 1 of this series will give an overview of the design philosophy we used, and later parts will delve more deeply into specific sub-topics.

Decision Trees: AI In Most RTS Games
First, the way that AI systems in most games work is via giant decision trees (IF A, then C, IF B, then D, etc, etc). This can make for human-like behavior up to a point, but it requires a lot of development and ultimately winds up with exploitable flaws. My favorite example from pretty much every RTS game since 1998 is how they pathfind around walls; if you leave a small gap in your wall, the AI will almost always try to go through that hole, which lets human players mass their units at these choke points since they are “tricking” the AI into using a hole in the wall that is actually a trap. The AI thus sends wave after wave through the hole, dying every time.

Not only does that rules-based decision tree approach take forever to program, but it’s also so exploitable in many ways beyond just the above. Yet, to emulate how a human player might play, that sort of approach is generally needed. I started out using a decision tree, but pretty soon realized that this was kind of boring even at the basic conceptual level — if I wanted to play against humans, I could just play against another human. I wanted an AI that acted in a new way, different from what another human could do, like playing against Skynet or the Buggers from Ender’s Game, or something like that. An AI that felt fresh and intelligent, but that played with scary differences from how a human ever could, since our brains have different strengths and weaknesses compared to a CPU. There are countless examples of this in fiction and film, but not so many in games.

Decentralized Intelligence
The approach that I settled on, and which gave surprisingly quick results early in the development of the game, was simulating intelligence in each of the individual units, rather than simulating a single overall controlling intelligence. If you have ever ready Prey, by Michael Crichton, it works vaguely like the swarms of nanobots in that book. The primary difference is that my individual units are a lot more intelligent than each of his nanobots, and thus an average swarm in my game might be 30 to 2,000 ships, rather than millions or billions of nanobots. But this also means that my units are at zero risk of ever reaching true sentience — people from the future won’t be coming back to kill me to prevent the coming AI apocalypse. The primary benefit is that I can get much more intelligent results with much less code and fewer agents.

Strategic Tiers
There are really three levels of thinking to the AI in AI War: strategic, sub-commander, and individual-unit. So this isn’t even a true swarm intelligence, because it combines swarm intelligence (at the individual-unit level) with more global rules and behaviors. How the AI decides which planets to reinforce, or which planets to send waves against, is all based on the strategic level of logic — the global commander, if you will. The method by which an AI determines how to use its ships in attacking or defending at an individual planet is based on a combination of the sub-commander and individual-ship logic.

Sub-Commanders
Here’s the cool thing: the sub-commander logic is completely emergent. Based on how the individual-unit logic is coded, the units do what is best for themselves, but also take into account what the rest of the group is doing. It’s kind of the idea of flocking behavior, but applied to tactics and target selection instead of movement. So when you see the AI send its ships into your planet, break them into two or three groups, and hit a variety of targets on your planet all at once, that’s actually emergent sub-commander behavior that was never explicitly programmed. There’s nothing remotely like that in the game code, but the AI is always doing stuff like that. The AI does some surprisingly intelligent things that way, things I never thought of, and it never does the really moronic stuff that rules-based AIs occasionally do.

And the best part is that it is fairly un-trickable. Not to say that the system is perfect, but if a player finds a way to trick the AI, all they have to do is tell me and I can usually put a counter into the code pretty quickly. There haven’t been any ways to trick the AI since the alpha releases that I’m aware of, though. The AI runs on a separate thread on the host computer only, so that lets it do some really heavy data crunching (using LINQ, actually — my background is in database programming and ERP / financial tracking / revenue forecasting applications in TSQL, a lot of which came across to the AI here). Taking lots of variables into effect means that it can make highly intelligent decisions without causing any lag whatsoever on your average dual-core host.

Fuzzy Logic
Fuzzy logic / randomization is also another key component to our AI. A big part of making an unpredictable AI system is making it so that it always make a good choice, but not necessarily the 100% best one (since, with repetition, the “best” choice becomes increasingly non-ideal through its predictability). If an AI player only ever made perfect decisions, to counter them you only need to figure out yourself what the best decision is (or create a false weakness in your forces, such as with the hole in the wall example), and then you can predict what the AI will do with a high degree of accuracy — approaching 100% in certain cases in a lot of other RTS games. With fuzzy logic in place, I’d say that you have no better than a 50% chance of ever predicting what the AI in AI War is going to do… and usually it’s way less predictable than even that.

Intelligent Mistakes
Bear in mind that the lower difficulty levels make some intentionally-stupid decisions that a novice human might make (such as going for the best target despite whatever is guarding it). That makes the lower-level AIs still feel like a real opponent, but a much less fearsome one. Figuring out ways in which to tone down the AI for the lower difficulties was one of the big challenges for me, actually. Partly it boiled down to just withholding the best tactics from the lower-level AIs, but also there were some intentionally-less-than-ideal assumptions that I also had to seed into its decision making at those lower levels.

Skipping The Economic Simulation
Lastly, the AI in AI War follows wholly different economic rules than the human players (but all of the tactical and most strategic rules are the same). For instance, the AI starts with 20,000+ ships in most games, whereas you start with 4 ships per player. If it just overwhelmed you with everything, it would crush you immediately. Same as if all the bad guys in every level of a Mario Bros game attacked you at once, you’d die immediately (there would be nowhere to jump to). Or if all the enemies in any given level of an FPS game just ran directly at you and shot with perfect accuracy, you’d have no hope.

Think about your average FPS that simulates your involvement in military operations — all of the enemies are not always aware of what you and your allies are doing, so even if the enemies have overwhelming odds against you, you can still win by doing limited engagements and striking key targets, etc. I think the same is true in real wars in many cases, but that’s not something that you see in the skirmish modes of other RTS games.

This is a big topic that I’ll touch on more deeply in a future article in this series, as it’s likely to be the most controversial design decision I’ve made with the game. A few people will likely view this as a form of cheating AI, but I have good reasons for having done it this way (primarily that it allows for so many varied simulations, versus one symmetrical simulation). The AI ships never get bonuses above the players, the AI does not have undue information about player activities, and the AI does not get bonuses or penalties based on player actions beyond the visible AI Progress indicator (more on that below). The strategic and tactical code for the AI in the game uses the exact same rules as constrain the human players, and that’s where the intelligence of our system really shines.

Asymetrical AI
In AI War, to offer procedural campaigns that give a certain David vs Goliath feel (where the human players are always David to some degree), I made a separate rules system for parts of the AI versus what the humans do. The AI’s economy works based on internal reinforcement points, wave countdowns, and an overall AI Progress number that gets increased or decreased based on player actions. This lets the players somewhat set the pace of game advancement, which adds another layer of strategy that you would normally only encounter in turn-based games. It’s a very asymmetrical sort of system that you totally couldn’t have in a pvp-style of skirmish game with AI acting as human standins, but it works beautifully in a co-op-style game where the AI is always the enemy.

Next Time
This provides a pretty good overview of the decisions we made and how it all came together. In the next article, which is now available, I delve into some actual code. If there is anything that readers particularly want me to address in a future article, don’t hesitate to ask! I’m not shy about talking about the inner workings of the AI system here, since this is something I’d really like to see other developers do in their games. I play lots of games other than my own, just like anyone else, and I’d like to see stronger AI across the board.

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.”