Month: July 2018

The big news is that the Warden and Hunter fleets now get off their butts again and will actually come after you in a majorly scary way. The Dark Spire also spawn at a more menacing rate, and the minor factions no longer do the job of killing tachyon sentinels for you. Oh, and hey, the hunter and warden types now actually have more than one entry each!

This should change up the game a ton, just on its own. Major thanks to Badger on basically all of it.

On my end, I’ve been working on the stats revamp that comes prior to the procedural stats mentioned in that giant essay from last release. It’s coming along well, and I hope to have all that out this week.

The Usual Reminders

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

Also: 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. Reviews make a material difference, and like most indies, we could really use the support.

Okay, this one has some huge marquee features, and I have some other things on my mind, too. Let’s get to it!

First off, it’s pretty obvious that there are absolutely copious numbers of bugfixes in here. Also, if you downloaded this build within the last couple of hours, then you’ll want to restart Steam to trigger a re-download, because we fixed yet more bugs (and added a couple of other bits). I say “we,” but I really mean “Badger did.”

My favorite bug that was fixed recently was the one where ships would visually explode when going through wormholes. 🙂 I knew there would be some fallout from the overhaul I did of the ship rendering code, but I didn’t expect one that funny.

Now, onto the big-deal stuff.

Arks Return!

We’ve been talking about Arks returning since we laid out the pivot document a few months back, and the idea was always to make them basically like Champions from the first game. The lobby doesn’t handle these super gracefully yet, but basically if you select an Ark then you get a nifty unit that is powerful and can fly around and attack stuff. Their stats DO vary, so it’s not just cosmetic.

What’s different about these from all other ships, however, is that after a certain amount of killing-of-enemies on the same planet the Ark (either by the Ark or by other ships of yours), you’re able to spend some science to unlock a higher-level version of the Ark. Do you do it? That’s up to you. The higher-mark ones have new abilities, like a shield, zombifying gun, etc, etc. They basically become like Golems.

If Arks die, they go to remains and you have to go repair them with engineers. WARNING! If they die in enemy territory, you’ll have to capture that planet before you can repair them to working status. Ouch. So do be careful with them.

Unlike the pre-pivot versions of AI War 2, these are not required to be part of your game, and nor are they the “king unit.” Your home command station is your king, as was the case in AIWC. It can’t leave the planet it started on. That just feels a lot better. All the various other things from Arks in pre-pivot AIW2 are also gone, like the Arks aggro’ing enemies majorly when present there, or being required for hacking, or being the source of warhead deployment. All that’s gone. Hackers will do hacking, missile silos will spawn warheads — as with AIWC.

Arks are a bit of a funny beast. They definitely change up the game and give you a major edge, too. So what’s the AI going to get in order to counterbalance this? Well… nothing. 🙂 My goal is going to be for Arks to be optional, but for the game to essentially be balanced around assuming you have them there. So if you play without them, you’re just playing at a handicap, and there’s nothing wrong with that at all. But Arks themselves should be things you don’t fear to use, and that don’t come with a lot of negative consequences — they should feel powerful and fun. Playing without them should feel exciting and dangerous, like playing down a rook from the start of a Chess match. Both should be a lot more positive experience-wise compared to if we started applying a stick to people who use Arks.

Arks will continue to evolve prior to Early Access and into it, I’m sure. We also have a bunch of other Arks that we’re going to add, that we already have graphics done for. I think it’s 6 or 8 more, I can’t even recall. Blue did fantastic work on them months ago, and I just haven’t had time to integrate them yet. For the moment, there are 5 arks to choose from.

I’ll need to adjust the story some regarding the nature of the arks, but the canonical story will be assuming an ark is present, as now. I suppose rather than the last bastion of humanity, it’s now more like the Starship Enterprise or somesuch. Sorta.

AIs Re-Taking Planets Again!

This was a really Big Deal feature that people always wanted in AIWC, and that we had in pre-pivot versions of AIW2. As part of the pivot, they were stripped away. Now they’re back, but in a new form. They come as waves, give you notification, and have to be turned on in the lobby as an option. This is a really exciting thing to have back in a new form, because this is one of those marquee features, so far as I’m concerned.

Waves Against Other Factions

This is a fun one. For factions that go about capturing planets, the AI now gets pissed and sends waves at them, too. So now you’re not the only one singled out for that. Should make for even more organic chaos going on that you can take advantage of (or hide from).

Destruction Points For Certain Techs

Remember how I said the Arks have to have a certain amount of destruction happen around them before you can unlock their techs? Well, we have a version of that which is for “whatever else,” too. In this case it only counts AI ships that are immobile. So it’s offensive destruction done by you personally (not allies). You can’t farm waves, etc.

The purpose of this is to gate certain techs until later in the game. We won’t be using this a ton, but it’s a useful mechanic to have. It accomplishes a couple of things:

Because of this, you’re able to get access to new stuff beyond the start of the game without actually having to capture specific planetary targets. This is a pretty big new idea, because most everything else is territory-based. This is, instead, territory-agnostic. You have to have been doing SOMETHING to earn these unlocks, but the specific geography doesn’t matter. I can see us using this in a variety of ways.

This is a way for us to gate off too-powerful-if-early techs, if we want or need to. But rather than it being something lame like a time limit (people play at different speeds), it’s based instead around your offensive progress.

This is also a way for us to mildly gate off too-confusing-for-new-folks techs at the very start of the game, and these pretty much overlap with the category mentioned above (too powerful).

Now, before the inevitable complaint here: there’s plenty going on at the start of the game, and nobody should be feeling like we’re intending to dumb down the early game in some sort of forced tutorial. This isn’t a tutorial mode.

Right now the only item that uses this is the Auxiliary Space Dock, which is something that is potentially exploitable if someone is willing to waste clock time in the early game to just rack up salvage, etc. The auxiliaries (AIWC-style mercenaries) are meant to be an outlet for excess metal in the later game, not a crutch in the early game. It’s worth noting, however, that even seasoned AIWC players were a bit surprised and confused by the presence of mark IV auxiliary ships on their planets early in the game. Making these have a moderate destruction point cost, and a very mild science cost, solves both problems at once.

One other unit I’ve been thinking of putting behind this is the mobile builder, although I’ll be honest I don’t have a super good justification for that. It just feels right, somehow. I’ll be curious if anyone has any thoughts on that.

Beyond that, I see this as being for the first bullet point — a territory-agnostic way of revealing late-game stuff that is new — rather than something that gates off things you’re already used to. So please breathe a sigh of relief. 😉

More Factions Can Be Selected!

We made some hacky changes to the existing lobby — which is still slated for ripping-out, and which we’ll be sharing some designs for to get feedback on soon — so that there’s now room for you to select more factions at once. So now you can actually test more than just two at a time, which is very nice.

That GUI…

I’ve done a fair bit of technical work on that for this release, a lot of which isn’t really that exciting for you if you’re just looking at it.

But the text is more crisp now, which is a win, and part of that is because of my switch to the perspective camera (orthographic cameras can’t be used in deferred rendering mode, which we’re now using only for the gui camera, specifically to get that crisper text).

It’s also now possible for us to do things like rotate and tilt the GUI, or to mix 3D objects in with the GUI with that having proper perspective. That was something I was planning to make more use of, but after testing that out it didn’t really look all that good, so for now that’s shelved. The capabilities being there is still a win, though, and this was still required work in order to get the clearer text rendering.

The big thing that has been bugging me lately with the GUI is the theming of it, and what that should be. I’ve had people say that they don’t like how colorful it is, and I get that to a certain extent. Badger has also noted that he wishes it looked more like a military display, like the first game felt, and I definitely agree with that. I think that a military display can have attractive colored sections on it like I’ve been doing thus far, but the theming just isn’t correct yet.

The problem is that I’m trying to avoid anything too glitzy and crazy when it comes to how the GUI looks, but at the same time theme it so that it feels… cool. Like something you want to be looking at, but subtle enough not to feel cluttered and like it’s dazzling your eyes. That’s a tough order. I’m trying to tackle a lot of that myself, because I’ll be honest I don’t really have funds to pay for Blue to go through iterations on it right now. I’m not quite sure what I’d even ask her to do, just yet, anyhow, so it’s moot at the moment. There are some pre-designed GUI skins that I’ve been thinking of adapting and building in from graphic river, but there are none that are fully what I want, and I’m in a money-shy position where I’m not just jumping on a bunch of them at once.

Anyhow, so it’s something I’m thinking about. One thing I spent a goodly amount of time on today was coming up with a way to put blue and red pixels into a single image, for glows, and to then colorize the result based on that. Aka, having the main color get applied where it’s white and red, with red being darker sections, and having the border color go where it’s blue. It was a clever bit of shader code, and it works well. I can also push the colors into the HDR range by doing this, which would be intersting for bloom. But the actual result wasn’t any better than what is there now, so I shelved that for now and just hung onto the code. It’s there in the ModdingAndGUI project folder, if you want to look at that. A test image and material, too. I may wind up returning to this in the future as a way of having more compact dictionaries and less overdraw, and thus saving some work on the GPU, but for now I have bigger priorities.

Speaking of bloom, that sort of glowy GUI is something I keep experimenting with. We did that sort of thing in The Last Federation, for example. But when you do that sort of GUI, it can be pretty hard on the eyes after a while. And that was a much more sparse GUI than what we have here with SO many icons. And I can’t really get a good result, by hand or with bloom post-processing shaders, that doesn’t just wind up looking smudgy. I was hoping more for a computer screen look, but I just am not feeling it thus far with that. That’s part of why I’m not yet sure exactly what I want the GUI theming to look like; the nature of the icons that go on them, and in particular the ship icons that are a big part of it, has to fit with what’s behind it or it just feels very disjointed. I’ll figure it out, but it’s been a frustrating saga so far.

Coming Up Soon: Stats Revamp… and Procedural Stats???

Right, so I buried this one pretty low in this long, long post (thanks if you read this far). I wasn’t trying to hide it, I swear. 😉

First of all, right now the way we have stats set up in the game is really confusing, coming partly from a spreadsheet dumped out of AIWC, and partly out of a lot of very-indirect xml. I’m going to normalize all that data, and then dump it back into the XML in an easier-to-adjust-and-mod fashion. It will be harder to make mass edits, but it will be easier to mod specific units (and their descendants, mark-level-wise). So that’s coming up, and then I expect folks will start tuning some things along with us a bit more.

Anyway, the spreadsheet was intended to get us to having “exactly AIWC” as the balance for the first part of the pivot, which was a big goal of the pivot. However, despite that, we’re just frankly not having “exactly AIWC.” The squads throw things off, and the way that the AI behaves and is seeded is too different. There’s more to making it exactly AIWC than just the stats. I will say that we’re a lot closer to AIWC, and it feels like a proper sequel now rather than some other game, so I’m calling it good on that.

Prior to “calling it good,” we were supposed to hit a point where we verify “this game is fun.” Are we there yet? I’m honestly not sure, but I think so. I think a lot of that comes from the work Badger has been doing with all the new-style content, though. Moving back to having core AIWC-style mechanics has made it so that what the player does is more familiar, and that’s a big part of making it fun again, too — but the big thing is having new and interesting things to explore.

One of the continual themes of the content Badger has been adding has been “more chaos,” though, I think it’s worth noting. Basically more factions out there, doing what they do, and it makes it that much harder for you to predict what the heck is going to happen in the game. That was, in a sense, my original goal with AIWC all along. You can go back to my posts from 2009 where I was talking about how I didn’t want every campaign to play out the same, even from the very first few minutes of a campaign, and how I wanted people to be forced to find themselves in unexpected situations and then adapt.

Well… with all these factions running around, the amount of simulation complexity (in a good sense, not a CPU-draining sense thanks to multithreading) is WAY up. It’s a lot more like The Last Federation, or Galactic Civilizations or Star Control or something. It’s NOT any of those games, and doesn’t go to the depth of any of them. This isn’t a 4X in the sense of having politics or any of that stuff. But that sense of having Others out there doing things that often don’t involve you is… cool. Being able to stumble across opportunities that are genuinely unique to a given campaign just because of the luck of timing and the specific things that were seeded in this galaxy that were not in the last galaxy you played.

And THAT brings me to the topic of balance, and randomness, and my original intent with the plethora of units in AIWC. Here are a few observations:

In a PvE strategy game, true per-unit balance isn’t super important as long as you have a fun time, are challenged, and ultimately feel like you have a fair shot at winning.

The biggest risk is boredom, or always choosing the same strategy, in this scenario; having super-units that are clearly better than everything else every time, so be sure to pick them, stinks big time.

The individual unit-type caps, rather than a global cross-unit-type cap, is one way that we already try to combat this. Having tons of types of units, and not all of them being in the game at any given time, is another.

A huge challenge for us, however, is that with all that content it can take a LONG time before super units are teased out. We don’t have enough manpower or testers to make it so that someone’s first experience with the game won’t be them finding a super-unit and just blasting through the game and remarking on how poorly balanced the thing is.

THAT said, when it comes to roguelikes and dungeon crawlers with procedural loot, and you happen to get an exceptionally awesome sword or whatever… it’s worth noting that your thought isn’t “this is poorly balanced,” but “wow I’m lucky this go-round, I’m going to enjoy this power while it carries me for a while, because I won’t see it again.” And you’d be right.

So what that brings me to is thinking about having randomized stats and modifiers on all ships that you and the AI control. At least on the fleetships, starships, and turrets, anyway. The idea here is that you’d be trying to tease out what is most useful in your CURRENT campaign, and not relying on an external wiki or overly-generalized advice like “always pick parasites,” or whatever. The ships would still be based around an ability or a general theme that would stay constant, but what they are strong against, how strong and fast they are, how much health they have… those things would vary, and would be part of the name. So you’d have things like Vicious Sluggish Fighter in one game, and Generalist Hardened Fighter in another, potentially.

With a change like that, the fact that we don’t have the manpower to balance things goes out the window, and frankly it feels like a marquee feature to me. I’m curious what others think, but to me it’s very much inline with the idea of “discovering unique situations and dealing with them using whatever you have.” Some games you’ll have a flamethrower, other games a box of hammers, and you need to figure out how to deal with things either way. Obviously the idea would be to make it so that you have a realistic number of good choices in all cases, but we’ve certainly been around the block on that front many times in the past. It’s a much more tractable problem than trying to individually balance hundreds of ships, and lets myself and modders and players focus on more interesting problems. And it creates genuinely interesting new gameplay… right? Am I missing something? Why didn’t I think of this before??

ALSO as part of this, something that I’d be able to do is cut down on the number of crazy bonuses and immunities and such that all the ships have. The tooltips are a mess just like in AIWC right now, and there’s no good way to solve that. Eric has been tearing his hair out. That’s a huge barrier to new players, and it’s a pain even to experience players trying to read all that junk. I want to have ships have just one type of hull they get a bonus against, and have that be picked from one of a few possibilities in a given campaign. So if you need to kill something with neutron armor, you can quickly look at your ships that hit neutron armor hard, but other than that it’s a matter of intuition and how you use your ships. The damage bonus needs to be huge against that given type in order to be worthwhile, and there may be certain types that you just have to take on without any bonuses. And vice-versa when the enemy is attacking you.

I want to then focus more on bringing a few crazy new ship abilities into the game that hopefully rely more on the background threads (where we have room on the CPU, still) versus just relying on “yet more ships and shots on the screen.” I still have more conceptual work to do there, but my hope is that drags things yet further into the “what the heck is this new situation” territory. Ultimately that’s what this game is about, for me: coming up with a goal you know you have, and then having to study the problem and attack it a few different ways before you crack it. It shouldn’t be about repetitive maneuvers hoovering around with your fleetball (unless you crank the difficulty down).

I know it seems like the 11th hour in terms of this stuff, but we are not getting enough people testing anyway, and this will only take me a day or three to implement (the procedural stats), so it seems worth a go. If people hate it, we haven’t lost that much time.

Curious on your thoughts, though, to be sure. This has been ultra-long. 3700 words! That’s like 15 freaking pages. Sorry about that, and thanks for reading. 🙂

The Usual Reminders

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

Also: 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. Reviews make a material difference, and like most indies, we could really use the support.

The drawing for the #loveindies Giveaway is now complete, and we have our 20 winners. Thanks to everyone who entered! In particular thanks to folks who left us encouraging comments on the form, that really brightened our day. I wasn’t sure why I put that field there, but it was a pleasant surprise on the results. 🙂

All names used with permission. Everyone on both lists should have an email from Chris at this point with their Steam key. If you don’t have an email from us, please check your spam and then contact arcengames at gmail and we’ll sort you out.

About Stars Beyond Reach

Just to clear up any potential confusion on this title, here’s the note I included on the email to all the winners:

This gives you access to a variety of alpha/beta versions that you can access via the Steam properties tab, and then click into the betas tab. It has a dropdown with various entries from during the development history of the game.

At the moment we still don’t have any concrete plans to restart development on this game, but in the event that we do, this is a key that will continue to have access to the full release version and beyond. Fingers crossed that we can come back to it someday, but in the meantime we hope you enjoy the alpha and beta versions that are up at the moment.

About Reviewing Indie Games In General

Holy smokes do we need this — it makes a material difference to us. Whether or not you entered the contest, if you don’t mind leaving a Steam review for some/any of our games that is always super appreciated. 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. It’s the difference between other potential customers finding us and not finding us, which is… important to us, as you might imagine.

Please note that you didn’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 didn’t help your chances in the giveaway, blah blah blah let’s just clearly keep things ethical.

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.

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.

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!

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?

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.

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!

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.

Make sure that Steam has updated you to the latest build of the game (0.749 or later).

Inside the install folder for the game, open the AIWarExternalCode. There you’ll find a AIWarExternalCode.sln visual studio solution.

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.

Running the game after having compiled a new version into that folder will run it with your changes in place.

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.

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.

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.

Enjoy!

Chris

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.

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

Enjoy!

Chris

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.