AI War 2 News

New build! https://wiki.arcengames.com/index.php?title=AI_War_2:Finalizing_Multiplayer#2.809_Self_Optimization

This one is mostly multiplayer-focused, but it has some core speed improvements to the singleplayer simulation as well as some bugfixes that also benefit everyone (particularly those with really fast AMD processors).

This also sees a number of improvements and updates to the SirLimbo suite of mods, and Space Planes and Expatriates have gotten some solid balance adjustments from CRCGamer.

So, what of multiplayer? This release is a pretty big deal! First off, major thanks to Bummeri and abuchris and their MP groups, because this would not have been possible without them.

1. There were STILL some ghosts possible on MP clients, but those seem to be well and truly dead now from several angles.

2. There was a major amount of ship "rubber banding" happening in combat with the AI sentinels in the last couple of weeks, due to a bug I accidentally put in when optimizing bandwidth a couple of weeks ago. That's now fixed.

3. The sync and ship-check data now uses vastly less bandwidth, and is structured so that it won't ever flood the client with too much information. There's now a call and response (ack, in network terms) going on, and this helps the network self-regulate to whatever its environment is. In other words, for this part of the network data, if the connection is slow and flaky, it will slow itself to compensate. If it's a speedy lan, it will up itself to match that. Overall in most cases this results in a lot of bandwidth reduction, and even more importantly it removes cases where potentially the client could get message-logged and get a lot of command lag from that.

MP is looking a lot more reliable now, knock on wood, which is really exciting. This has been quite a journey for it.

Enjoy!

Check out the latest podcast of eXplorminate, where Rob and Ben and I talk about AI War 2, the most recent beta period and resulting paradigm shift, upcoming DLCs, thoughts on AI design in general, and lots of other great design topics: https://anchor.fm/explorminate/episodes/Interview-with-Chris-McElligott-Park-on-AI-War-2-and-More-evpabk

New build! https://wiki.arcengames.com/index.php?title=AI_War_2:Finalizing_Multiplayer#2.808_MP_Ghostbusting

This one fixes up some remaining "ghosts" that were happening in multiplayer, so knock on wood hopefully that's the end of those. That was a fun thing where clients would still see certain dead ships that the host did not see.

This build also updates the Steamworks integration by about a year's worth of patches, so hopefully any Steam-specific networking issues are resolved via this. There's actually a newer version of the underlying Steam networking API in use, so that's an exciting thing that I didn't realize was even on the table as an option. Fingers crossed.

The hacking costs on ARSes have been substantially reduced compared to the prior build It was a misunderstanding that led to them being increased quite as much as they were. Sorry about that!

The Zenith generators got major buffs, and the AI Risk Analyzers got a major nerf. AI intelligence on difficulty 7+ went up quite a bit when you are trying to trap them via forcefields.

We also fixed a few bugs from the last patch, such as tutorials being broken and the AMU-based mods being broken. There's also a new "Hacker OS" planet name set by ZeroTheHero, and more beginner journals.

Enjoy!

New build! https://wiki.arcengames.com/index.php?title=AI_War_2:Finalizing_Multiplayer#2.807_Beginner_Journals_and_MP_Sync

This one fixes the last of the known serious multiplayer bugs, which is very exciting! I'm sure that there will be more, but there have been a couple that we have been chasing and trying to isolate since the start of MP, and the last of those got nailed today.

This version increases the hacking point costs for the ARS and FRS a bit, since people were getting just kind of stupidly overpowered with them previously. It might need more tuning up in the future, but we didn't want to go too crazy with it. The main goal here is trying to ease back toward the same sort of difficulty balance that the game had prior to the Paradigm Shift. We don't want to sprint in that direction (wow whiplash), but in general the way that difficulty drifted downward is not something that is intentional.

Also new in this build are some beginner journals that are contextual and give you some advice on first steps to take after 1 minute of gameplay. You obviously don't have to take the advice, but especially for folks who boot this up cold, it should be a help.

Blitzkrieg Turrets got a bit of a nerf, and Makeshift Drones got a bit of a buff. There was also a strange crash that could happen on linux machines in the prior build, and that is now fixed.

Enjoy!

New build! https://wiki.arcengames.com/index.php?title=AI_War_2:Finalizing_Multiplayer#2.806_Correctness_By_Attrition

The title of this one is a bit amusing, because again this refers to two different thing. On the one hand, attrition effects are now more correct in the game when they are interacting with stacks of smaller units, doing commensurate larger damage to them. On the other hand, network results are getting more correct, gradually, as I wear down the bloody errors in a lengthy process of attrition.

Speaking of multiplayer, this build is kind of a big deal for it, because I finally found and fixed a number of rather core issues that were cascading into other areas of the game. The number one thing that I fixed was that sometimes there were "ghost" units that the client thought were still alive, but the host knew was dead. These were sometimes missing the sync process, and persisting on the client indefinitely -- potentially for hours. This was causing a lot of wrong behavior and constant sim divergence and fixing, as you might imagine, for the ships that were reacting to the ghosts.

Similarly, the client could have a wrong idea of which AI subfaction owned certain units, and so the local simulation would give the wrong AI decision-making a go, causing a constant pop over and pop back. Most "rubber band" issues were something like that, where the client and host just couldn't figure each other out.

Lastly, for certain kinds of data sync, I had a sudden idea and put in some extra (configurable) delays into the existing time slicing that these have. With the default settings, this is a network traffic reduction of over 75% (actually closer to 84%, but hey it will vary by machine). The really critical stuff syncs as fast as ever, and so it's very likely that you'd never notice a difference other than things being snappier.

This is quite exciting. Enjoy!