AI War 2 News

New build! https://wiki.arcengames.com/index.php?title=AI_War_2:The_Great_Refactor#Beta_3.754_Player_Types

This one adds a whole lot, all at once! This paves the way for some MAJOR cool things that we are going to be doing in the near future, and that modders can also do.

First of all, there's a whole new system where modders can now expand the central GameEntityTypeData in ways that were impossible previously. This gives a lot of power for adding custom functionality for various factions, and the necromancer code that already existed for DLC3 has been ported to this.

Secondly, the necromancer "faction" is now gone, which has been the plan for a while, and now there is a necromancer "player type." Specifically, there are no longer multiple types of player factions that you can choose independently (that was a real pain in the interface for players, and hard to find what was available, as well as a pain in the code). Instead, you just choose a "player slot" and can then choose, easily and quickly, from any of the various options that affords.

In the base game, that will be Human Empire and Spectator (being able to watch a game while not being part of it at all is always fun). In DLC1, we'll have Ark Empire added, as something of a throwback to the earliest versions of this game. I'm considering a Spire-Infused Empire hybrid for DLC1 that pulls from the fallen spire concept but makes it a bit more direct. We'll see if there's time. In DLC3, we'll have two forms of necromancer: Lone Necromancer, and Necromancer Empire. I'm also thinking about adding in a Solo Ark mode, which probably would be for DLC3 also, since it would work best with the vassals feature from there.

There were some other various bugfixes, and some code improvements. This is (maybe) the last of the REALLY large refactoring-type things that I have on my list for this game, so this is a great milestone to have hit. There are still some known issues with the lone necromancer right now, but they're listed and they're not super critical.

More to come soon.
Enjoy!

New build! https://wiki.arcengames.com/index.php?title=AI_War_2:The_Great_Refactor#Beta_3.753_Necromancer_Externalizing

This one is the earliest part of the work to allow for multiple types of human player factions without actually having to choose separate factions. This part of the work is mostly focused on moving a lot of the Core code (closed source) for the necromancer to be in External code (open source, and thus also moddable). The goal is for modders to have the flexibility to implement custom player types as well without having to alter the core game code.

Tom found a variety of more bugs to slay, and slew them, which is super awesome and I'm really grateful. Badger also fixed some bugs, and added some more features for the necromancer, which gives them decloaking abilities.

Tom and Strategic Sage have been talking a bit, and looking at the design document that Sage and I were working on all the way back in May (good grief!) relating to fuel in Expert mode. Tom has started a rough implementation on that based on that design, which is really unexpected and super cool. Right now it's implemented as part of a mod, since it's just a roughed-in version so far. But getting this in place to be able to start testing out the ideas Sage and I had will be a really big boost for making sure it is actually a feasible design that is fun, so this is a big win.

More to come soon.
Enjoy!

New build! https://wiki.arcengames.com/index.php?title=AI_War_2:The_Great_Refactor#Beta_3.752_Pathfinding_Efficiency

In the past, whenever I've talked about the efficiency of pathfinding, I've universally been speaking about CPU usage or "number of paths calculated per second" or something along those lines. This time, I'm talking about RAM efficiency -- how much RAM is used, how it gets reused, and so on. We do a lot of pathfinding on a lot of threads for a lot of reasons, and that data can be absolutely enormous if we're caching it for too long. Similarly, in the past, we've had major CPU load caused by not caching it enough.

What I've done at this point is kept the caching to the level of "this current slice of time for this thread," whatever that means. Sometimes it means "this frame" when we're talking about the UI. A lot more frequently, it means "this simulation step," when it's something for the simulation itself (aka, for 100ms). Even vastly more frequently, it means "this run of long-range-planning operation," which is something that happens intermittently for each faction every few seconds and lasting for usually part of a second, but up to several seconds if need be.

The TLDR is that the amount of CPU computation should be roughly the same as before, but the RAM usage is reduced by around 300ish MB on midsize games with a fair number of factions in a slightly larger than average galaxy. It may also be a fix to yet another memory leak, but I can't be certain. It is a solution to an annoying thread-contention issue that I still don't understand the full nature of, but have decided to work around in this particular case by just making everything so much more efficient in the first place.

This build sees a number of other bugfixes, and more of SirLimbo's AMU settings being implemented into the base game as options.

More to come soon.
Enjoy!

New build! https://wiki.arcengames.com/index.php?title=AI_War_2:The_Great_Refactor#Beta_3.751_Faction_Processing_Groups

Friday I was out because I was just exhausted and needed a day of recovery. Others went gangbusters on that day and over the weekend working on the game, though.

There's lots of bugfixes thanks to Badger, tom.prince, Puffin, and NR SirLimbo; improvements to contextual info provided by the ARS thanks to Badger; and the start of some of the "extended galaxy settings" from AMU being implemented into the base game thanks to NR SirLimbo.

Additionally, there's a number of new features and improvements in the unreleased DLC3 for our testers there, including some xml work by Puffin Emeritus, which certainly deserves special mention.

The big theme of the largest remaining errors I saw after the weekend were in our random number generators and pathfinding. In both cases, neither piece of code was actually the problem at all -- these were pieces of very good code that were simply canaries for "hey, two threads are using me at the same time, that doesn't work!" In all cases, it looks like the faction-specific Long Range Planning (LRP) code was still able to overlap itself sometimes.

I think that for that to happen, you needed to have some factions that shared data. AI border aggression and relentless waves do that in any game, but if you had multiple copies of a faction, then that would also do it in the prior build. Please note, of course, that all of those cases are supposed to work fine, but that seemed to be the conditions for replicating it for now.

Today I introduced a new xml-driven piece of data called a "faction processing group," which is basically a way for factions to say "I don't run while those others are running. Normally the LRP logic for general factions all runs at once, with the exception of factions that are multiples of one another, or which share some other processing logic like border aggression and relentless waves do. I had existing protections in place to already try to handle this exact concept, but they were code-driven, mildly hidden because of that, and also had a few errors relating to them.

At this point, code that was a bit more scattered around is a lot more linear and has been rewritten to hopefully work quite well. In my brief testing today after finishing this, I don't see these errors anymore, but it's impossible to prove a negative. So if you were one of the testers running into this, please do let us know if things are still an issue. Fingers crossed, I do think I got rid of it, and also fingers crossed, this seemed to be the only category of thread left that had this sort of effect.

More to come soon.
Enjoy!

Ho. Le. Mo. Le. Wheeew, new build: https://wiki.arcengames.com/index.php?title=AI_War_2:The_Great_Refactor#Beta_3.750_Smooth_Simulator

This one rips up the entire threading model that we've been evolving for the game since 2016, and replaces it with something more modern, as well as fixing a number of threading-related bugs and other issues. The TLDR is that it's faster than ever, especially on older computers, and it works REALLY well and is way easier for myself and others to debug, too.

The game was downright unplayable for the last few weeks in terms of things like stalled threads and a bunch of cross-threading issues. I've been really tearing my hair out, trying to figure out what on earth was going on, and simplifying code, simplifying it further, and lots of experimenting. Daniexpert really gets MVP once again for truly excellent help with bugtesting and reporting in this arena.

Special thanks also to tom.prince, who had lots of great ideas and commentary on the threading model and things that we'd have to consider. There were several cases where I was going to do one thing, and chatting with tom on discord let me skip a few steps of pain and jump to a better solution.

There's also a bunch of other improvements in here, and various features for DLC3. I am extremely weary, though, so I'm not going to enumerate all of them. I thought I'd be done with this threading thing days ago, and then I started wondering when on earth I'd be done with it at all. Very happy to say it seems to work well now, and if there are remaining problems, they will be much easier for me to debug.

Tomorrow, it will be time to move on and work on other bugs and features that have been delayed by this whole mess. I think this was first on my radar on October 27th, maybe a bit before, so this was QUITE a diversion. The release notes have pretty much the whole story, and the chris-talks-code-gameplay discord subchannel has the rest of it, if you're curious.

More to come soon.
Enjoy!