AI War 2 v0.754 Released! “Shifting That Furniture”

Release notes here.

Last Reminder About Giveaway

We’re still running our #loveindies giveaway through the end of today.  Or really, through “whenever I remember to turn off submissions tomorrow.”  Sign up to potentially get a free copy of AI War 2 or Stars Beyond Reach.  On the subject of #loveindies, would you mind leaving a Steam review for some/any of our games?  It doesn’t have to be much more detailed than a thumbs up, but if you like a game we made and want more people to find it, that’s how you make it happen.  Like most indies, we could really use the support.  Reviews make a material difference in pushing us out of the obscurity of the sludge that often surrounds indie titles on the storefront these days.

Please note that you don’t have to leave a review in order to enter the giveaway; and you shouldn’t leave a good review if you don’t think good things.  Reviews don’t help your chances in the giveaway, blah blah blah let’s just clearly keep things ethical.

About This Release

Okay!  Now on to the actual business at hand.

  • There are a couple of bugfixes in here, although nothing really groundbreaking.  Not a whole lot of content on that front, but some good bits.
  • The main planet view GUI itself has been HUGELY rearranged in order to be more usable and to block less of your view.

Regarding the new planet view GUI changes, one of the things I want to remind you is that it will definitely feel awkward at first if you’ve been playing the game and got used to the sidebar being on the right.  And, to head off any potential controversy: yes, if people really freak out about this, we’ll change it back.

THAT said, having this on the left actually makes a lot more sense, as has been pointed out to me recently.  Your eyes have to do less work, the overall interface reads in a more sensible order, and so on.  I’ll be honest that I’m still getting used to it, myself (it’s been all of a couple of hours for me that this has been on the left, and none of that was really playing the game, just testing the gui).  It feels strange, as all change does.

My guess, though, is that if someone comes to the game cold, they’ll not find it strange at all, and it’s demonstrably more convenient in its proximity to the tooltips and general eye gaze.

Less controversially, the top bar has been ergonomically compressed in a helpful way, the ships sidebar lost some elements that were unused or just plain cluttery, and the concept of a galaxy map minimap is something that I’m discarding because frankly I don’t have time to do it while polishing everything else, and it takes up too much space.  It doesn’t feel needed.

Overall, your view of the screen is now a lot better, and you can always tell what planet you are at easier, too.  Even if we move the sidebar back to the right, those other bits were a win.  Oh –and regarding the sidebar, I’ve figured out a new sizing technique for it that is going to be key in some of the lobby work I have planned, too.  So that’s really really good.

Quick reminder of our new Steam Developer Page.  If you follow us there, you’ll be notified about any game releases we do.



AI War 2 v0.752 Released! “Mathematics Milestone”

Release notes here.

First note: we’re still running our #loveindies giveaway through the end of tomorrow.  Sign up to potentially get a free copy of AI War 2 or Stars Beyond Reach.  On the subject of #loveindies, would you mind leaving a Steam review for some/any of our games?  It doesn’t have to be much more detailed than a thumbs up, but if you like a game we made and want more people to find it, that’s how you make it happen.  Like most indies, we could really use the support.  Reviews make a material difference in pushing us out of the obscurity of the sludge that often surrounds indie titles on the storefront these days.  Please note that you don’t have to leave a review in order to enter the giveaway; and you shouldn’t leave a good review if you don’t think good things.  Reviews don’t help your chances in the giveaway, blah blah blah let’s just clearly keep things ethical.

Okay!  Now about this release of AI War 2. 🙂

  • FINALLY, oh goodness finally, I’ve got ships translated over to using DrawMeshInstanced and thus running way more efficiently.  This has been on my todo list for TWO YEARS at this point.  Last week I got the shots, this week the ships.  I’m super stoked!
  • There are some other performance improvements here, and some various visual improvements related to these, too.
  • Badger made it so that you can tune the allegiances of the Devourer, Macrophage, and Nanocaust from the lobby.  So many possibilities with this one!  On the extreme silly end, you can basically have a game where the Borg and Unicron go do all the fighting for you while you hang back, if you just want to watch a simulation you barely take part in.
  • AI Progress is now tracked for factions other than players, and there’s a lot of nuance that will be coming in how the AI deals with these other threats if they are neutral to you or hostile to you and the AI.  Badger has cool plans there.
  • Dealing with remains rebuilders and engineers is now a lot better when in the midst of battle, since they no longer die to remains.
  • Seventeen metric tons of bugfixes.  More to come.

Quick reminder of our new Steam Developer Page.  If you follow us there, you’ll be notified about any game releases we do.



Arcen #loveindies Giveaway!

We’re taking part in #loveindies week!

If you’ve enjoyed any of our games and want to give a brief impression, or even just a thumbs up, that’s a really big deal to us. If you feel the burning need to go in there and warn folks off of one of our titles, that’s of course perfectly acceptable as well. 😉 Our catalog is here.

As part of this celebration, we’re giving away ten (10) copies each of AI War 2 and Stars Beyond Reach (20 overall winners). To enter, all you have to do is fill out this form — you don’t have to actually leave any reviews.

We’ll be running this contest through the end of Friday, July 20th, and picking winners on Monday, July 23rd. Thank you so much for your support!

AI War 2 v0.750 Released! “My Friend The Marauder”

Release notes here.

Lots of happiness in this one!  So first, a picture for you:

I have absolutely hated how the forcefields looked in this game ever since the start.  I’ve kept working on new versions, but never was happy with them.  Thanks to work by Oranged Keys, we’ve finally got a version that makes me go ooh!  As a good forcefield should.

Anyhow, that’s just a minor cosmetic thing.  What really matters in this release?

  • First off, BearPerson took a dive into our code and fixed the multithreading issue, as well as providing a lot of feedback on what our actual problem is.  That provides an excellent point for Keith to take the baton on this one.  Super huge thanks to BearPerson.
  • Secondly, Badger has made it so that Marauders, which we talked about the coolness of last release, can now be friendly to you, and there can be multiple factions of them.  In short, your galaxy can get darn busy with the goings and comings of these ruffians, which is super cool.
  • On my end, I finally finished the framework for DrawMeshInstanced, and have gotten that applied to shots, which now take only a fraction of the time they used to.  This not only uses a more efficient way of drawing, but it also uses SIMD off your processor for more efficient math tracking the position updates for your shots.  Ships are coming soon on this front!  Battles will run a lot faster after that, and they already run a bit faster (shots were already way more efficient than ships even prior to now).
  • And then there is just a huge laundry list of other things.  Some of the highlights:
  • Randomness should be more random.
  • Cross Planet Attacks should actually work now.
  • Reprisal waves don’t happen so early in the game now, and got a nerf in general.
  • A few parts of the GUI are now more efficient.
  • Dark Spire are now fixed up quite a bit and probably work, but feedback is desired.

Not bad for two days.

Quick reminder of our new Steam Developer Page.  If you follow us there, you’ll be notified about any game releases we do.



AI War 2 v0.749 Released! “Release The Hounds”

Are you a programmer interested in helping out on a multithreading issue?  Be sure to see the bottom (or this forum thread).

Case Study of Modding: Marauders

Before talking about the release or multithreading, this is a great time to talk about the power that our Modder #1 (and volunteer developer to boot), Badger, has been able to exert thus far.  He’s made a ton of factions, but right now let’s talk about Human Marauders, which were in the first game as well.

If you don’t remember them from the first game, that’s because they weren’t too exciting; marauders were units that would periodically show up from the gravity well edge (not a wormhole) and cause some trouble. They were hostile to the player only, and were generally pretty insignificant.  It added a tiny bit of spice, but not much.

Enter Badger.

He started from scratch when implementing these in the new game.  His version of Marauders are hostile to everyone.  They will attack any system they deem “weak enough to take,” then drop in from the edge of the gravity well.  If they destroy all the defenses, then they start building Outposts, turrets and additional ships. They’re already starting to defend the planet as their own.  If you leave the planet alone, the Marauders will keep making outposts, and each outpost will get stronger (ie it will build stronger defensive ships and more turrets).

Once an outpost hits Max Rank, it starts to build Raiders (powerful starships). Once the Marauders have built enough Raiders, they will attack adjacent-through-wormhole systems that they think are “weak enough to take.” If you leave outposts at Max Rank, the marauders will be able to attack more and more often — their “Attack Budget” gets bonuses based on how many Max Rank Outposts there are. Also the Max Budget gets increased every time they capture a planet.

Fun fact: If you take out all the defenses on a swath of AI planets around your empire (but haven’t actually captured or defended the planets) then the Marauders will rapidly take all of them over and potentially become a real threat.  To you… and the AI and other factions.
TLDR: Instead of just launching quick raids, these Marauders are here to take their own stab at conquering the galaxy.

People have been giving lots of balance feedback on the Marauders, as well as positive impressions for that faction on Discord.  This also illustrates two pretty key points:

  • The marauders are an example of what can be done with the modding tools of AIW2, but which was basically impossible for AIWC even for us as developers.  Gives a bit of context as to why making this sequel was important.
  • It’s also a really good example of how a “Decent but not exciting” AIWC faction turned into something way cooler in AIW2, so buy AIW2 to get cooler stuff. 😉  There are a lot of factions like that (all-new ones and revised ones), even though we’re pivoting the core mechanics to be more like AIWC.  For anyone worrying that this is just AIWC HD, please fear not!

The Actual Release

Okay, right: release notes here.

Where to even start?  This release is pretty sizeable.

  • There’s been a bunch of balance to minor factions.
  • Mercenaries got some extra oomph.
  • AI Waves were previously capped at 100 units (cough, whoops), but now will gleefully flood your planets properly.
  • There are auto-build options for your convenience now available in the game settings.
  • The salvage and reprisal mechanics from the first game are added back in.
  • Golems are now available again — five of them, anyway!

…and all of that stuff is just what Badger, a volunteer, has put in this release.  To say we’re indebted to him is an increasingly sharp understatement with every week.  Holy smokes.

On my end of things, I upgraded the game to Unity 2018.2 and mono-.NET 4.6.  Some performance improvements were possible from this, and a lot more multithreading options.  A few boosts happened out of the gate, and I was able to explore (and then discard) the Lightweight Rendering Pipeline as an option.

I spent a fair bit of time on the multithreading problem, but at this point I’ve been hitting a wall where I can’t get the performance any higher.  I’m sure with more time I could figure it out, but in the meantime there are bigger fish for me to fry in terms of performance blockers (namely the front-end vis layer’s extreme performance hits, which I talked about two releases ago).

Multithreading Help Wanted

Last release I asked for some help on the multithreading problem, which was clarified here.  At this point, I’ve basically hit a wall in my ability to improve the threading without getting really excessive in my expenditure of time.  There are a variety of other things that really need my attention right now, so I’m having to put this on the back burner.

That said, I’ve open-sourced our multithreading code and our core sim loop, so if there are any kind souls who want to take a look at it and help more directly with revisions, that would be super appreciated.  I know folks were a bit hampered by being blind to the code before.

How to get at/test code:

  1. Make sure that Steam has updated you to the latest build of the game (0.749 or later).
  2. Inside the install folder for the game, open the AIWarExternalCode.  There you’ll find a AIWarExternalCode.sln visual studio solution.
  3. You can open that with visual studio community edition 2015 or 2017, and then it should let you compile directly to the GameData/ModdableLogicDLLs folder.
  4. Running the game after having compiled a new version into that folder will run it with your changes in place.
  5. If you want to use a different IDE, or even no IDE and just compile manually, you can do so.  Badger has scripts for doing so on linux, for example.
  6. The actual scripts of relevance are in the AIWarExternalCode/src/Sim folder (and its subfolders), which has a variety of C# files that I’ve added comments to.  There are other files that call into and out of those files, but all of the multithreading bits and the main-thread-bits that call them are all there.
  7. I’ve made a mantis ticket on our bugtracker that has the savegame, plus instructions on how to see the issues.

Any help is appreciated!  And I’m happy to answer questions.  I have made a forum thread that is probably the best and easiest place for us to discuss this.

Right, Back To The Release

Anyway, that’s enough out of me.  This new release is pretty cool.



I again wanted to mention: we have a new Steam Developer Page.  If you go there and follow us, you’ll be notified about other upcoming releases (including this one, of course).

AI War 2 v0.748 Released! “Macrophage Teeth”

Release notes here.

This week hasn’t exactly gone as I expected, but it’s been very productive.  I had planned on working on the lobby, first of all, but then some performance-unfriendly saves came to light and I decided I’d work on that instead.  The biggest hog in large battles is the vis-layer movement of ships around, and last release I talked about how I was going to look into System.Numerics and DrawMeshInstanced to solve that.  I also basically decided to upgrade to Unity 2018.2, even though that’s still in beta, because it has some things we need.

Well, that didn’t happen either!

Badger fixed up the “unit testing” program that we have for the sim layer, and for the first time I fired that up.  It’s an area that was previously out of my domain, but that’s been expanding a bit lately just due to necessity.  At any rate, I spent almost all of this week on performance improvements to the sim layer.


Badger also fixed some notable bugs, such as the Macrophage not actually doing damage when they attack.  That concludes my summary of the release notes other than to talk about performance.



I again wanted to mention: we have a new Steam Developer Page.  If you go there and follow us, you’ll be notified about other upcoming releases (including this one, of course).

Performance Hunting

I’ve tried using three different profilers in this period: NProfiler (which is awful despite promising big things), JetBrains dotTrace (which seems fine), and RedGate ANTS (which is maybe a bit better, but it’s hard to be sure).

At first these tools were lobbing up really juicy bits for me that I was able to majorly optimize, leading to quite a bit of savings.  I spent way longer than I expected just trying to optimize squareroot again for our use cases, and finally cut that to a tenth or less of the load it used to represent.

I thought I was going to have to create a new form of data structure for tracking lists of entities in our code, and I came up with one in my head that I haven’t implemented yet (a wrappered, pooled, linked-list structure that is super fast at adding, removing, and iterating, but has no random access possible).  It turns out that the things that I thought were going to require that MAY have been a profiling artifact, but the vote is still out on that.  I’m undecided on whether or not I need to make an adjustment there.

At the moment, what I am winding up finding is a suspicious “speed limit” on the sim code that is related to the framerate in some fashion (and no, it’s not any of the obvious things; in this case it’s a virtual framerate, but that still adjusts the speed limit).  At any rate, that’s the next thing I need to dig into, because I think no other changes I make will show a result at the moment because all the background threads are presently running below that speed limit, making it the limiting factor.  Some of the later performance improvements I made show up with no benefit in actual gameplay yet, but they show up fine in unit testing if I set the virtual framerate really low.  Fun for soon.

One of the things that I’ve observed is that the background threads aren’t hitting the other processors on my CPU as much as I expected, which was suspicious to me.  I’ve gone in and looked around, and my first thought was that our threads are spending too long transitioning from idle to active.  I’m still not sure that isn’t the case.  We’re using Thread.Sleep(1) in order for them to wait while being alive and then turn on as soon as a bool is set that says “your data is here — now go!”

The problem is… apparently Thread.Sleep doesn’t guarantee that it will only wait one ms.  Instead it will apparently average 12-15 ms.  That is an eternity!  No wonder things are not very busy on the secondary processors.  So that’s no go.

I started using SpinWait to spin the cpu instead of Thread.Sleep(1), and that does indeed peg the CPU at 100, but there’s 88% wasteage on spinning according to the profilers when that happens.  That’s going to slow down the main thread and lose framerate as well as making the other threads slower to sync, too.  So that’s really kind of a no-go.

I need to figure out what that mysterious “speed limit” in our code is and get rid of that, and that will solve a lot of the problem.  Other than that, though, I’ve got to figure out a way for the multithreading to be a bit more snappy in when it does things and stops doing things.  Right now it’s 12-15ms at best from the word go to it actually doing anything (on almost a dozen background threads, individually).

We could supposedly use the Monitor class to help with synchronization, but I’ll be honest that I don’t yet fully understand how that would best be used while not pegging the CPU.  Offhand, it sounds like using objects to lock against and monitor instead of using a bool to check against — still one per thread — but I’m not positive.  Any multithreading-in-C# experts in the crowd that want to help out?  Either with some explanations or taking a look at our code, or even making some changes on your own?  We’re pretty slammed, workload-wise.

Anyway, another option that is still on the table is potentially just switching to using the ThreadPool or some other form of multithreaded job class rather than threads that we keep warmed up and running and managed on our own.  That might be the simplest approach, we shall see.  I’ve done this in plenty of applications before, but none with ms-level speed required.  AI War Classic only had one secondary thread, and it didn’t block the sim when it was idle, so we never ran into this with it.  With Stars Beyond Reach, we used a ton of threads, but it was done in such a way that a 12-15 ms lag was utterly invisible.

So that’s what’s going on lately!



AI War 2 v0.747 Released! “Improper Handling Of Forcefields”

Release notes here.

We remain back on a quicker release schedule, now that we’re past that initial hump of the pivot.  At this point there’s a fair bit to clean up, though, so I’ve been focusing on that instead of heading straight for the lobby revamp.  I’m pleased with the progress that we’re seeing, based largely on the excellent testing and feedback we’ve been getting lately.

This build fixes up the nanocaust and risk analyzers (read: spire civilian outposts replacement) so that they’re functional again.  There are more new units from Keith, and then a grab bag of fixes and improvements from Badger and myself.

I again wanted to mention: we have a new Steam Developer Page.  If you go there and follow us, you’ll be notified about other upcoming releases (including this one, of course).



Postscript: Technical Investigations of Performance

Today has been a bit of a funny one, for me.  I’ve spent a fair bit of time looking into SIMD, in particular Unity’s new ECS/Jobs system, but also System.Numerics from Unity’s implementation of .NET 4.6.  Doug originally turned me onto SIMD a while ago, but you had to manually include Mono.simd.dll, which made me nervous in a multi-OS environment.  Since then, user “dv = i ln(w0 / wf)” has turned me on to the ECS stuff.

I’ve been heavily considering my options on this, now.  I need better performance out of the vis layer of our game, because right now in a midsize battle I’m seeing some performance bottlenecks on the CPU side where it’s doing calculations to decide what models to send out to the GPU, what to cull from the view frustum, and then of course vector and matrix math.

I’m not sure which is the more expensive thing at the moment on the CPU, the culling and whatnot or the vector/matrix math.  I have a feeling that the culling is the killer, but the unity profiler is nonspecific enough (the very act of profiling causes a skew in the results of the profiler; repeated calls of small methods are weighted more negatively than a few calls to actually-more-expensive methods because of the overhead of instrumenting) that I can’t be sure.

I’ve been talking about switching to DrawMeshInstanced forever now, but I’ve not been excited about having to do the frustum culling manually in C# — the logic is simple enough, but I worry about the performance hit of it.  Potentially now if I use System.Numerics to get fast SIMD-based math, it won’t be an issue anymore.  Plus I can adjust the frustum culling to only work at the squad level, not at the individual mesh level, which would be a big savings in the number of checks in any case.  It’s just a fair bit of work without a guaranteed payoff, so I’ve kept putting it off.

I think that the time has more or less come for that this week, though.  I’ll probably dip my toe into this with shots, and then move on to ships and squads.

The benefits of ECS/Jobs are notable in that it lets us forego GameObjects and then push things to being multi-core.  And that is attractive, but it’s not meant for production environments yet and the syntax there is horrific in my opinion.  It has a lot of advantages in the core functionality of things being very well-ordered in memory, but that comes at the cost of readability and heap-flexibility in exchange for stack usage.  Frankly I think that I can cut out GameObjects on my own without doing that, and keep everything away from expensive virtualized methods just like they do, and stick with something that is vastly more readable and maybe 80% as performant.  I just pulled that number out of my rear, but it’s a gut feel based on reading their specs in detail today and being aware of the sort of performance I’ve seen in other similar situations in our other titles that were largely GameObject-free.

So I think that means I’ll wind up wierding things in terms of making our own C#-based pooled objects that then use DrawMeshInstanced, and which use System.Numerics for calculations, and that should be a pretty good translation.  I might start out without frustum culling and see if that’s “good enough for now,” and then add that in later if need be.  Or sooner than later if it’s a problem, I guess.

I keep going back and forth on whether or not we should make the leap to Unity 2018.2 or not even though it’s still in beta.  That has a more mature version of .NET 4.6 in it, which would be useful for my purposes.  It has a few other benefits, as well.  It also includes the Scriptable Render Pipeline (SRP), which I’m very interested in.  I’m particularly interested in the potential savings of the Lightweight Render Pipeline, but I’m REALLY not sure that it will be much savings in our particular case (since we only use one directional light as it is), and I’m not super keen on re-coding all my shaders to work with that only to then find out there’s some issue.  Other developers have complained that it’s still not lightweight enough in general, anyway, since apparently some of the culling work is still a bit non-ideal.  With DrawMeshInstanced I’d be bypassing that anyhow, so my gains would be even less, potentially.  It is open source, which is really nice, but I’m also concerned about compatibility.  Most notably with Amplify Bloom, which I don’t know if it functions on the lightweight SRP or not.  It’s really hard to get non-flickery bloom without that particular product, so I wouldn’t want to just move to the regular post-processing stack v2 (believe me, I’ve already tried that a ton).

So there’s a lot of food for thought that I keep mulling over.  Biggest hitters are probably DrawMeshInstanced and getting rid of so many GameObjects, then changing to having System.Numerics in place, so for now I’ll start there.  I’m pretty sure that even if I went to ECS/Jobs eventually, I’d still need to take this approach for truly excellent performance in the vis layer, so I think I can do this with a pretty high degree of confidence I’m spending time on the right thing.

Now I just have to start ripping into that…