AI War 2: The Pivot

From Arcen Wiki
Jump to: navigation, search

Contents

Known Issues

  • The lobby interface is currently temporary, and undergoing a complete overhaul.
  • Beam-weapon style shot graphics don't yet display, and a couple of AOE effects don't show quite correctly yet.
  • Balance needs a lot of attention, with your help.
  • The tutorial is currently missing, as we need to redo it.
  • Multiplayer is temporarily disabled while we focus on tightening up the single-player loop.
  • Arks are presently not used in the game, which means that also Chief Advisers are not used for now.
  • There are roughly 100ish ships/units that we still have not reimplemented from Pivot phases 3-5.
  • There are a variety of ships/units that don't have proper graphics or reuse icons at the moment.
  • There is not an in-game way to see and edit the control bindings yet.
    • But you can go into the created bindings file inside the PlayerData folder to edit them in a text editor.

What is this "Pivot?"

The full details are on kickstarter: Pivoting AI War 2: Bring The Fun!.

The short answer is that we're dropping back from what was considered a beta status, and instead proceeding with a revised design on our existing engine in order to make sure that this sequel fully lives up to the legacy of its predecessor.

Version 0.754

(Not yet released -- we're still working on it!)

  • The game no longer tells you popup messages when the behavior of ships is set; that was excessive, and you can see their status via the little flag on their icons anyhow.
    • Thanks to Ovalcircle, RocketAssistedPuffin, and Badger for suggesting.
  • Fixed an issue where some would blink out of existence at various camera angles if you had multiple forcefields on one planet. This had to do with the GPU instancing being enabled on them, and something in the culling and instancing logic (these use MeshRenderers, not DrawMeshInstanced) going bonkers. There are few enough of these, and they need to be z-sorted anyhow, so we just disabled instancing and they each take one draw call.
    • This is a reminder not to have dozens and dozens of shields on one planet in this game; shieldbearers were always a kludge in the first game, but they're EXPENSIVE on the GPU as well as CPU calculations (for collisions, etc). When there are a dozen or less or so, the expense is pretty minimal, but having 100 would be a bad idea, in short.
    • Thanks to RocketAssistedPuffin and Ovalcircle for reporting.
  • Soo... we found yet some more cases where the forcefields could improper occlude the ship icon sprites, even with all the changes we made yesterday to fix that up.
    • The core issue here is probably the precision of the z-buffer only being so large, and the distances at play being large; this only happened with icons that were sufficiently close to the forcefield graphics.
    • On a hunch, we decided to remove z-writing from the forcefields, but keep z-testing. With this done, the forcefields don't prevent overdraw, but they still get properly sorted with all the other geometry (both transparent and opaque), and they don't render over opaque ships that are near them. The worst that will likely happen is that you'll sometimes see some z-fighting between multiple overlapping forcefields, but even that's not super duper likely. And it's by far the least destructive case at this point.
    • With this change in hand, this also meant that we could back out the shift we had to make to draw all the sprites twice -- that was a lot more expensive in terms of overdraw on the GPU and depths sorting CPU work than the new overdraw that forcefields have. A lot a lot more work. So that's a really positive development, and hopefully the end of this particular saga. Fingers crossed.
  • Energy now uses the same sort of rounding and abbreviations up on the top bar that metal does. This looks better, and also fixes an issue if you have more than 1 million where that would go off the top of the screen.
    • Thanks to Ovalcircle for reporting.

Version 0.753 Yeah, You Like That Brick?

(Released July 19th, 2018)

With apologies! --Chris

  • Fixed a bug where in the prior version energy was not being read properly out of the AIWC spreadsheet anymore, making it so that nothing cost energy or produced energy. That led to all sorts of fun, and basically bricked the game.
    • Thanks to RocketAssistedPuffin for special sleuthing on this one.
  • Clarified the rally orders message so that it's not remotely so debuggy-seeming.
    • Thanks to RocketAssistedPuffin for suggesting.

Version 0.752 Mathematics Milestone

(Released July 19th, 2018)

  • Allow Debug_PlayerSpawnShips to spawn a greater variety of ships
  • Make turrets build a bit slower
  • Exogalactic Strikeforces now do notifications. New factions that want to generate Exogalactic Strikeforces just need to use the ExoData structure to manage the strikeforce and it will work.
  • Make Devourer, Macrophage and Nanocaust have tunable allegiances in the Game Lobby. They can each be 'Player Friendly Only', 'AI Friendly Only' or 'Hostile to everyone'.
    • This gives us 5 potential ally factions, including the Marauders and Dyson Sphere, which are capable of doing massive damage in the Galaxy on your behalf. Counting also the Human Resistance Fighters as well, we basically have a nice sandbox mode where you could have your friends beat up the AI
  • Instead of simply tracking the AI progress for the player, we now allow minor factions to all track their equivalent of AI progress separately. And more critically, to check whether a given faction has already generated AIP for a given planet. This also has the side benefit of allowing the AI to recapture planets, since you can always tell whether you have already paid the AIP price for a given structure.
    • This allows for things like "You take a planet and generate AIP. Marauders then take that planet from you and update their version of AIP. The Nanocaust then captures the planet from the Marauders, then updates their version of AIP. Then the AI retakes the planet, then you capture it again (and this time don't generate AIP)"
    • This code will not work on save games created before this release, though those save games should keep the old behaviour without incident.
    • Fix a few minor other issues.
  • New properties can be defined for ships:
    • rotation_z_of_ship rotates the ship on the z axis at all times.
    • rotation_x_of_ship does the same thing. These are useful for if you need to have a ship rotating on a tilted axis.
    • y_offset_of_ship_emission_and_hit_point defines an offset to the point at which shots come into and hit the ship.
      • We're now using this rather than actually defining that on the solomesh ships at all.
  • Writing to the DebugText on a ship now causes that to show up on the tooltip for that ship.
  • The mip weights on the bloom have been adjusted so that things aren't so foggy so far from bloom sources.
    • We fiddled a fair bit with going back to the bloom that is more cropped to the area of the light emission source, but it just felt flat and fake. The hazier bloom gives a more modern, Bladerunner-eqsue feel; but as with all things, moderation is key.
  • Redid the emissive values for colony ships, space docks, and cryo tubes to make sense in the new bloom environment. They were particularly out of bounds.
  • Space docks are now 1.6x larger than they were before, to make them easier to see since they are fairly important (understatement much?).
  • Made it so that when you try to place a self-building unit and it fails, it shows a nice log message on the right side of the screen instead of a giant scary error.
  • There is now a specific material that ships show when they are just remains, so that it's more obvious (from more than just their icon) that they are dead.
    • This material does not support instance batching very well, so even though we're using DrawMeshInstanced it has to use a max instance batch size of one.
      • This is admittedly inefficient to a certain extent, but we're submitting these instance calls back to back and so the GPU has to do very little context-switching, which is the most expensive part of the process. If it ever becomes a problem we can always change it, but the visual effect that this is using is pretty cool, shouldn't be frequent enough to be a problem, and can't be batched in general.
  • Updated the ship under-construction materials to also be a lot fancier.
    • As with the remains material, these don't support batching. But these should be even less of an issue, given how few things tend to be under construction and in view at once.
  • Shots are now either rendering their trail OR their main body, not both. Effectively that means just rendering their trail, now, for most of them.
    • This looks a lot better, has many many fewer tris required for large battles, and so forth.
  • New special entity flags for Hackers have been added, and the code now keys off of that instead of off of the king units. Basically this is paving the way for having a dedicated hacker unit instead of assuming that the Ark (which isn't even a king unit anymore) was the hacker like in the pre-pivot times.
    • The various places in the interface that previously would not have reacted properly to a new hacker type unit are now updated as well.
  • Updated the Dyson Sphere to be vastly less bright (it was overbright because of the newer bloom settings the game uses).
    • Thanks to Ovalcircle for reporting his newfound blindness.
  • When you set a rally point for a builder, it now shows the rally icon in green.
  • When you have a rally point set for a builder, it now says "this planet" if it is rallying to its current planet, rather than saying the name of the planet. This is a lot more clear.
  • The speed buttons at the bottom of the screen now adjust coarseness by default, instead of the frame frequency, since that doesn't increase CPU load but makes things a lot faster.
    • You can now hold Ctrl to make those buttons switch over and adjust frame freqeuncy instead.
    • And the tooltips on those are more informative about what the two of those things are.
    • In general this makes it WAY easier for players to quickly up the speed dramatically and then reduce it again.
  • Engineers and remains rebuilders no longer die to remains, which fixes a variety of issues with them. Particularly helpful with the auto-build options for them that recently were added.
    • Thanks to Badger and RocketAssistedPuffin for suggesting.

DrawMeshInstanced And GameObjectlessness for Squads and Ships

  • There were 22 ships that were using the old ArcenVisualShip multi-object class that was not compatible with DrawMeshInstanced. Those are now transitioned over to the newer ArcenVisualSolomeshShip class.
    • Multi-material ones: AICommandStation, HumanCommandStation, EconomicCommandStation, LogisticalCommandStation, MilitaryCommandStation, WarpJammerCommandStation, HumanHomeCommandStation, HumanHomeCommandStationCore, SpireShardReactor
    • Simply old ones that needed easier converting: HumanController (old), AIController (old), DerelictController (old), AttritionEmitter (old), BlackHoleMachine (old), Magnifier (old), PlanetaryCloaker (old), RaidEngine (old), TroopAccelerator (old)
    • Multi-material ones that also required new shaders: AIWarpGate, DysonWarpGate, AIOverlordPhase1 (partly done two releases back), AIOverlordPhase2 (partly done two releases back)
  • Removed that old ArcenVisualShip class and all of the animator and LOD classes that were used as sub-components of it. The solomesh ship class has its own more compact version of the LOD logic, and the animations are all now GPU-side-only.
  • There is now a InstancedRendererDeactivationReason that is passed around all over the place telling us why an entity is being removed from the sim layer, for use in debugging.
  • Removed a huge amount of indirection and queuing that contributed greatly to code complexity with the sim layer telling the vis layer what it wanted to have added in terms of ships and shots and whatnot.
    • This was absolutely required before in order to prevent very sharp CPU spikes based on adding a ton of GameObjects from unity, and all the overhead that goes with that.
    • But now we're not using GameObjects anymore for the affected areas, so we can have a much more direct, simpler approach.
    • This solves quite a lot of potential bugs, but in the short term probably creates new ones. The complexity of this was ridiculous, so our apologies if we have some bits that are off in the next release or two.
  • The squads and ships are now 100% GameObject-free, existing instead in a pooled and managed-only state like shots have from a recent version.
    • These now use hardware-accelerated math based on SIMD from System.Numerics, again like shots.
    • Activating squads, and moving ships into squads, is now orders of magnitude faster. It was ridiculously slow before, because of the transform hierarchy update propagation and other factors. None of that exists now, so it's lightning fast.
      • This means that, unlike before, clicking into a planet with a ton going on doesn't cause a hitch in the game (it was previously pretty harsh of a hitch, enough that it would cause multiplayer to stutter badly as players shifted planets).
      • This also means that during initial load of the game we don't have to create a bunch of ship or squad GameObjects to use as a pool, and so game startup is much faster. On a pre-cached start, it's 30% faster. On a cold start, it may be even faster than that, not sure.
    • As part of THIS, we may very well have introduced new bugs as well. This was even an order of magnitude more complex than the indirection and queuing removal. Goodness.
  • DrawMeshInstanced is now in use for all of the ships within squads, so these are gotten onto the GPU as efficiently as possible (frustum culling aside).
  • The "burning and dying" explosion effect now works in our new DrawMeshInstanced pathway. This was always going to be the hardest one. It's setting the float variable on the shader for how-far-dead-this-specific-ship-is through the material property block array property so that they will light up individually and progress properly on the GPU. This isn't really that hard, but just getting an efficient pipeline for it was.
    • Side note: you can have more entries in that array than you have mesh instances (matrix array entries), and it just uses the length you pass in for the matrix array, which is super helpful. Otherwise we were going to have to do some array copying that was going to be super wasteful, so this was very happy news (and not really documented officially, but assumedly by design based on the rest of the design in this area).
  • We're honestly not sure if the spawn-in and warp-out visual effects are working properly right now since the switch to DrawMeshInstanced, so if someone can confirm that and/or provide a quick repro case if it's broken, that would be appreciated. It was just quicker than trying to create a repro case on this one ourselves when there's a 99% chance it works, and it's a minor visual nit if it doesn't.

Bugfixes

  • Fix a bug where Golems were always being seeded.
    • Thanks to RocketAssistedPuffin for the bug report
  • Give the Dark Spire actual weapons again
    • Thanks to OvalCircle for reporting
  • Fix a fleeting hovertext bug for the macrophage for a game that has never been unpaused (either at game start or after reload).
    • Thanks to Ovalcircle for reporting.
  • Fix a typo in the build menu
  • Fix (hopefully) a problem with Assault Starships and Mercenaries getting confused
    • Thanks to DevoutHaruhiist for reporting
  • Removed our XorshiftRandom class, because it was giving too bad of a quality of random numbers.
  • Fixed a couple of issues in the Dark Spire's use of random numbers that might have led to desyncs in multiplayer (using the engine's permanent random like vis rather than using the current context's random).
  • Fixed an issue we didn't even know we had where, on the galaxy map, it was constantly trying to create and kill ship vis layer objects.
  • Fixed an issue where the game would try to autobuild energy collectors, engineers, or remains rebuilders even if their cap was hit, and then show errors to the player about it.
  • Fixed a bug where if you had ships selected when you exited the game to the main menu, you'd get an exception.
    • This one took some trial and error, because we weren't seeing it most of the time.
    • Thanks to RocketAssistedPuffin for reporting.
  • Fixed an issue where constructors that were under construction or in remains form were still showing entries on the sidebar.
    • This in turn was leading to newly-created constructors not showing up until you left the planet and came back after they were done.
  • Updated things like GetFirstMatching, GetCount, GetHasAtLeast, and GetNumberIn on the entity collections so that they now have three more parameters on each of them: an optional faction match that can be null, and two bools for if it can include remains or under construction entries.
    • There are a variety of places throughout the code where we were incorrectly returning entites from the wrong faction, or ones that were under construction or remains, and that had all sorts of bad effects.
    • It's worth noting that in a lot of places the faction parameter is absolutely redundant and should just be passed as null, since the collection is already "entities of a faction." But that entity collection class is used for more than just being on factions, so hence the redundancies.
    • This fixes some bugs that likely we didn't even know we had, one among which was that if you had a mix of space docks that were remains and not remains on a planet, there was a chance units wouldn't be produced at all. In some other cases, it helps the AI make better decisions about where to attack if there are a lot of remains on a player planet.
  • The lobby option for starting with build queues set up was not working previously, but should now.
  • There were a ton of references to fuel still in the codebase, which has been repurposed to energy since the pivot.
    • Renamed all of those to say energy instead, to avoid confusion.
    • Thanks to Ovalcircle for reporting.
  • A log message now displays that shows what planet the science was exhausted at when the science exhausted message plays.
    • Thanks to dv = i ln(w0 / wf) for suggesting.
  • The construction order voice responses are now controlled properly by the voice volume and mute controls.
    • Thanks to RocketAssistedPuffin for reporting.
  • Rally points and other unit orders now show messages telling you what you just changed, since it can be a frustrating lack of feedback otherwise.
    • If this winds up being TOO much feedback, we can dial it back or give you the option to disable it.
  • Fixed up a bug where non-one scales that were baked into ship prefabs were no longer being read into the game properly as of the last... while. Possibly since the pivot. This made some ships extremely tiny.
    • Thanks to Ovalcircle, dv = i ln(w0 / wf), and RocketAssistedPuffin for noting specific examples.
  • Fixed a bug where the forcefields were not zwriting or ztesting, leading to them having super strange-looking overlaps with ships near them. Uh... whoops!
  • AI units will now reinforce directly at their command stations, which previously they actually weren't doing!
  • Fixed a post-pivot bug in death logic that had some incorrect if logic and thus was firing way more often than it needed to. Probably harmlessly, but definitely eating some extra CPU every time a ship died.
  • Removed the whole idea of the "controller" unit that gets swapped back and forth ownership-wise between factions as planetary ownership changes.
    • This was a legit pre-pivot thing, but since the pivot it's just been something we kept for convenience in order to make minimal changes and get the pivot out faster.
    • The time has come to get rid of that, though, because it was causing a variety of tricky bugs like many ships being super interested in something invisible and way off to the southwest (it was the controller), among other problems.
  • Fixed a baffling issue where the forcefields and other transparent objects were acting like solid objects in terms of occluding the sprites. This is why we'd switched the forcefields over to drawing a bit funky in terms of their ztesting and zwriting, which in turn had made the forcefields and ships draw strangely near one another.
    • Basically we draw the sprites in a secondary camera above the main camera because we want them not to be impacted by color grading, bloom, and other post effects. However, even though we're not clearing the zbuffer there, something is changing enough that they're getting occluded. It's probably the classic transparency sorting issue and this avoiding zfighting across cameras, but at any rate it really stinks for our purposes here.
      • Incidentally, the reason we don't just clear the zbuffer entirely is because we do want solid objects to occlude the sprites or else things look super strange.
    • The solution we came up with is simply drawing all the sprites... twice. Once in the main camera, another time in the overlay camera. This comes out with a pretty cool look where anything that is occluded or partly occluded behind a forcefield gets a washed-out look from the bloom and such. It also gives a subtle bit of bloom around the sprites, which honestly looks pretty nice without being annoying.
      • The downside of this is somewhat the extra draw calls -- though honestly even with 2500+ squads on a planet, it was only about 50 draw calls extra, which is nothing -- but even more about the pixel fill rate and overdraw. It's a minor waste, but it probably won't be a problem on any remotely-modern GPU, and if it is a problem then the ships themselves are likely a problem before the sprites can be. At any rate, just looking at this mathematically, there's probably not a better way to do this. Losing all sprite occlusion would be one method, not caring about color grading adjusting the colors of the sprites would be another, but those are both suboptimal.
  • Fixed a visual bug that _may_ have only affected old savegames, but which would draw rally points way off to the southwest again.
  • Toggling pause using the pause button should now work in addition to the P button. We're not 100% sure on that, because Chris's keyboard doesn't have a pause button.
    • Thanks to Mckloshiv for reporting.

Version 0.750 My Friend The Marauder

(Released July 13th, 2018)

  • Golems: On High difficulty, the AI will send very primitive Exogalactic Strikeforces againt you. Medium and Low difficulties currently have no differentiation.
    • There is currently no warning for Exogalactic Strikeforces
  • Added a GetCurrentSeed() method onto the random generators, just for debugging purposes.
  • Adjusted the XorshiftRand seed list so that the 2nd through 4th seeds in its list of four seed cycles were not always the same thing. This may have been majorly hurting the level of randomness produced by this random number generator when the number of random calls was low.
  • Reprisal nerfs. Make the reprisal waves take a bit longer before they can be spawned. Nerf the rate AI collects salvage for reprisal rate.
  • Reprisal Waves can only happen once you've hit a per-Difficulty AIP threshold. You can see this threshold by mousing over the AIP section of the resource bar.
    • Thanks to Ovalcircle for the bug report
  • Add Auto FRD mode for Remains Rebuilders and Mark1 Engineers. This is available through the "Game" part of the Settings menu.
  • Bring a few more voice lines back online. These aren't in the game yet, but they will eventually.
  • Minor nerfs to Marauder Raiders to make them less OP
    • Thanks to Ovalcircle for the bug report
  • Fix typo in XML for ai type descriptions.
    • Thanks to OvalCircle for the bug report.
  • You can now see the Max Metal you can have by mousing over the Metal section of the resource bar
    • Thanks to DevoutHaruhiist for the bug report
  • Fix a bug where CPAs were never actually being launched, so the AI always had enough budget to launch a CPA (so you would always get the Incoming Wave warning)
  • Attempt to fix some null reference exceptions in reprisal waves and the audio for battles code just after load. I'm not sure about this fix, so let me know if it reoccurs.
    • Thanks to OvalCircle for pointing these out.
  • Fix a few bugs involving the Dark Spire. Unfortunately it still does not quite work right because of https://xkcd.com/221/
    • Thanks to OvalCircle for pointing this out
  • Improved how the GUI window bits are shown and hidden. Rather than disabling the entire object of each canvas, we now disable just the canvas itself. Per some unity optimization guidelines, this keeps the visual cache of those canvases from being cleared, and is helpful for when things are being shown and hidden (such as tooltips). This may also prevent errors with things like hiding the GUI, but we can't duplicate that at the moment.
  • The worldCamera is now being set on each of the canvases so that they will (supposedly) perform more efficient internal lookups for things like mouse events and whatnot. This is per a unity optimization article, but the difference is not noticeable in casual usage of the game at the moment.
  • For whatever reason, in Unity 2018.2 our forcefield shader likes to compile over and over again in our prep project, to the point that after we click out and then back in it would have to be force-killed by task manager. This didn't actually affect the execution of the game, but it made editing models or shaders an exercise in extreme pain.
    • Well, on the plus side, we were really tired of that shader anyhow and thought it was ugly. So that accelerated the pace of us replacing it, using an adapted shader originally by Oranged Keys.
  • Fixed a not-new issue where we were not clamping or capping our lerping in HeadingToInterceptTargetAcrossLastFewFrames, which was leading to shots accelerating off to negative infinity location and then causing issues.
    • This issue wasn't new, definitely, but how exactly this wasn't happening before isn't clear. The lack of clamping was a problem no matter what, but the code seemed to be catching it before it could get to full negative infinity before. Somehow.
  • Fix a bug with autobuild where it was counting dead engineers/rebuilders (so it would say "Oh, you have 2 remains rebuilders, don't build more even if those units are dead")
  • For Dark Spire Locus, include "how close to transforming into a Vengeance Generator this is" in the description.
  • Add a 'Spawn Player Ships' button in the debug menu. It will spawn 8K strength of ships at the player's home command station (ignoring the Energy limits)
  • The XorshiftRand has been doing a remarkable job of literally doing this (https://xkcd.com/221/) in too many test cases, so we're switching back to using Mersenne Twister in all cases. The MT algorithm has a higher seed reset time, but not much, and the quality of randomness is vastly better. This shouldn't actually be remotely a bottleneck anyhow, unlike what some of our profiling seemed to indicate previously.
    • While we were at it, we improved the seed initialization for a number of things during mapgen so that planet defenses and whatnot will be better randomized between games based on the map seed and not just the planet index.

Multiple Marauder Factions with Customizable Allegiances

  • Allow for multiple independent Marauder factions. You can set the starting Allegiance for each one independently.
    • So you could potentially have a 'Hostile To All' marauder faction with intensity 5 and two 'Friendly To Player' marauder factions at intensity 10
    • Friendly-To-Player marauders will kill Command Stations and Warp Gates, which will drive up the AIP.
    • Friendly-To-AI marauders will not colonize AI planets, because that would be OP

The Road To DrawMeshInstanced

  • Thanks to the folks at Amplify, we've now got a purely on-GPU rotational version of our main shader that we use for ships. This allows us to have rotational animation of vertices, with proper normals recalculation, on the GPU itself. This solves a number of issues for us.
    • Firstly, it's substantially more efficient than our old way of doing rotation of ship parts (such as the space docks or AI Overlords), which involved C# code that rotated the transformation matrix on the CPU. This required a lot of on-CPU math that then got transferred to PhysX, among other inefficiencies.
    • Secondly, this lets us combine ALL of our ships into single-meshes-per-ship like we were already doing with the non-animated versions. Each different material is applied simply to a submesh, but the overall transformation matrix is the same for all of them. This is a lot more efficient in the object hierarchy, and results in fewer matrix calculations when multi-material ships are moved around. We already did that before with the non-animated ships, but couldn't do it with the animated ones.
    • Lastly, this lets us get rid of our ArcenShip class (or will let us do so soon), and instead use the much simpler ArcenSolomeshShip class. In turn, this is vastly more simple and unified of a way to handle the drawing of ships, whether they have multiple submeshes or not, since they only have a single mesh in all cases. This was one of the biggest things that kept us from going ahead and implementing the DrawMeshInstanced code, because it was so darn complicated when you started having to account for a bunch of meshes instead of one. So this removes that last barrier.
    • If you're interested in the sample shader code provided by the folks at Amplify: https://forum.unity.com/threads/best-tool-asset-store-award-amplify-shader-editor-node-based-shader-creation-tool.430959/page-71#post-3560946
  • A number of calls to Time.unscaledDeltaTime have been replaced with a new Engine_Universal.UnscaledDeltaTime, which is more efficient.
  • Fixed the materials for a bunch of shots visuals that were accidentally missing their instancing flag being on -- leading to a waste of draw calls and degradation in performance.
  • We now import unity's version of System.Numerics into our internal and external vis dlls so that we can use the more-efficient SIMD vector/matrix math in there for some of our vis-layer processing.
    • This new dll is now in the ReliableDLLStorage folder and has been added to the build scripts for those projects.
  • Our ArcenPoint class is now able to convert to both the UnityEngine Vector3s as well as the System.Numerics kind.
  • Added extender class and method for efficiently converting Numerics Vector3s to Unity Vector3s, and the same with the two types of Quaternions.
  • Created a new CyclicalArrayPool data structure that is explicitly for dealing with the unknown number of arrays of max size 1023 that we have for the DrawMeshInstanced usage.
    • Efficiently handling this with as few operations per frame as possible was one of the bigger things we had to figure out, although the general refactoring was a bear, too.

DrawMeshInstanced For Shots

  • Refactored shots so that they are now using DrawMeshInstanced to draw more efficiently, and using System.Numerics to calculate their positions more efficiently.
    • This is the first of the graphics to get this improvement, but we'll be handling ships this way sooner than later and that will be another gigantic performance improvement (even more than this one).
    • There are various areas that this improves:
      • Firstly, it saves a bunch of CPU logic for figuring out how to instance batch these shots, because we're now handling that ourselves, way more efficiently.
      • It also saves frustum culling cost on the CPU, which is a big positive. Though more on that in a minute in the downsides.
      • And then the biggest one is that this no longer requires us to use GameObjects and MeshRenderers. The movement of GO transforms was a huge expense because it triggers a lot of different domains that we don't care about (like PhysX), and in general has a huge amount of overhead that we didn't need. The MeshRenderers were something we had to disable and enable in order to turn on and off the shots, and we had to set the values on the MRs and MeshFilters to match new shots as we pooled them. Now we don't have to do any of that logic, again saving substantial CPU time.
    • The downside of all this, however, is that we do lose frustum culling, z sorting for minimum overdraw, and some other things that cut down on the GPU load.
      • This leads to higher overdraw, as well as the drawing of some elements outside the view. As you might expect, this will hit GPUs a bit harder, although it shouldn't be too bad.
      • This is something that we'll be able to improve in the future by adapting some logic from a clever unity asset store asset that sets up calculations for frustum culling on the GPU (using compute shaders), and then allows for drawing via DrawMeshInstancedIndirect. That will take us some time to adapt into our purposes, but the code has been enlightening. For now it doesn't seem to be an optimization that is needed, but it's nice to have the ability to include that later.
        • Though it IS interesting that using the frame debugger we can see that it does not submit any instanced draw calls of this sort if they are entirely out of the view frustum. Not sure if this is done on the GPU or the CPU, but it seems to be all-or-nothing from the batch submitted (which makes sense).
  • The settings for how many shots to move per second and per frame have been removed for now. At the moment it just allows for 1 million shot movements per second as a maximum, which is way above anything that is likely to happen. The performance hit of the movements is now so vastly much lower (several orders of magnitude) that this limitation was giving a choppy feel to large battles but not actually helping the framerate appreciably.
  • No matter how you cut it, doing LookRotation calls are expensive. The best form of optimization is to simply do fewer of them. We're doing a first one on shots as soon as they move 0.01 unity units, to get their bearings straight. But now instead of doing it again every 0.01 unity units after that first one, we fall back to instead only doing it every 30 unity units moved. Shots rarely change direction, being fired in a straight line generally, so this has no visible effect but cuts down the number of LookRotation calls a ton. If we ever have shots that are curving around a bunch or retargeting frequently, then we can easily override this distance limiter for their specific cases.

Multithreading Improvements!

  • Our newly open-sourced ArcenThread class has been improved by BearPerson in a variety of ways:
    • ManualResetEventSlim is now used instead of bool for FromCallerToThread_YouShouldStart, and its Wait() and Reset() are now used instead of the dreaded Thread.Sleep().
    • FromThreadToCaller_IHaveFinished is now a volatile bool.
    • FromThreadToCaller_IHaveStarted is removed as unneeded.
    • A clever new ThreadFriendlyLogging class has been added and is now used for _reliable_ timing dump information, which revealed a lot about our timings that we were not seeing in profilers properly.
  • Now clearing the game-speed tracker (bottom left under the time counter) when switching from into or out of the galaxy map view, to keep that more accurate as you switch between lower-load and higher-load screens.

Version 0.749 Release The Hounds

(Released July 11th, 2018)

  • Bigger Teeth: Buff Macrophages further so the Harvesters don't die so easily. Give them some lifesteal too
    • Thanks to Ovalcircle for the recommendation
  • Fixed an issue that could lead the UI to not be able to get strength counts during certain frame intervals. This has been a minor bugbear for a while, but is fixed up now.
  • Warp Gates and Wormhole Guardians are now destroyed automatically when a Command Station dies
    • Thanks to DevoutHaruhiist for noticing this
  • Prevent the Devourer from being killed by Ion Cannons
    • Thanks to Ovalcircle for the bug report
  • Plasma Turrets could still be researched though they are not in the game. This was causing weird artifacts in the Tech menu. Remove those entries from the Tech Menu.
    • Thanks to dv for the bug report
  • Add back in some code paths for voice effects, though those effects aren't in the game yet.
  • Don't allow an Ion cannon to appear on the planet where the Nanocaust spawn, since it can just one shot nanocaust ships
    • Thanks to Ovalcircle for pointing this out
  • Add the Nanocaustation and Zombification mechanics back in
  • More Marauder Raider buffs.
  • Mercenary Outposts will come with some Turrets for extra "We're trying to conquer the Galaxy here". Also give them more generic defensive ships.
    • Thanks to zeusalmighty on discord for the suggestion (bonus thanks to Draco, Mac and OvalCircle)
  • Make Mercenary Spawning multiplayer safe
    • This adds a GameCommand that can be used by modders going forward. If a modder wants to make a faction that interacts with the UI directly (like "Hit a button on the UI and cause an effect on a minor faction") then it needs to use a GameCommand in order to be multiplayer-safe. This Modder GameCommand will allow for modders to define arbitrary GameCommands.
  • Replace tooltip mentions of "Fuel" with "Energy"
    • Thanks to DevoutHaruhiist for the bug report
  • Remove a message from the hovertext for command centers; it was left over from testing.
    • Thanks to DevoutHaruhiist for reporting
  • Fix a bug where AI Waves were capped at 100 units. The AI is very excited by actually getting to spend all of its Wave Budget now.
  • In the settings menu, under Game, add support for auto building units. Currently supported: EnergyCollectors, RemainsRebuilders and Mark1 Engineers.
    • Note that this is allowed to be in the settings menu (which is local-machine-only) because this runs in non-sim logic for the local player and then sends proper GameCommands into the sim queue just like you had clicked the buttons yourself. Very handy!
  • Fixed a bug where engineers have not been placeable since the addition of mercenary engineers, since they had a sharedcap that they both used together and engineers thought that mercenary engineers were an upgraded version of themselves.
  • Put in a variety of debugging code that will yell at you with an error message if unexpected things prevent you from creating a new unit. If you see those popups, we apologize, but just let us know since it's probably a bug anyhow.

Salvage/Reprisal Mechanics

  • Add the Player Salvage and AI Reprisal Mechanics (as seen in AI War Classic).
  • When units die on non-AI planets they generate Player Salvage. Build a Command Station there to turn the Salvage into bonus metal. The hovertext of the Metal on the resource bar will show which planets are current generating Salvage and how much of it.
  • When player units die on AI planets they generate AI Salvage, used by the AI to launch Reprisal waves. Reprisal waves will only happen if no new AI salvage has been collected for the past minute (this time is defined in the XML). The higher the AI Salvage the stronger the next reprisal wave is. Reprisal wave strength is capped at X*CurrentBaseWaveStrength, where X is a per-AI-Difficulty constant between 2 (Difficult 1) and 10 (Difficulty 10); these constants are subject to change based on balance feedback.
    • There are per-Difficulty and per-AI type multipliers for the amount of metal required for a Reprisal Wave/bonus strength for a reprisal wave, as well as master Per-Player and Per-AI Salvage gained per ship death multipliers.
  • Add a new Salvage Master AI type who gets a bonus to reprisal waves.

Golems

  • Golems can be enabled in the Game Lobby. When enabled, some derelict golems will be seeded on the map, and you can control how many golems are added (Low/Med/High). There's also a Debug flag which seeds a ton of golems including some right next to you; this is for test purposes only
    • Currently available golems: Artillery, Armored, Cursed, Regenerator, Botnet
    • Known issues: Regenerator Golem doesn't have visuals. Golems are always auto-claimed despite them costing AIP, Golem Difficulty doesn't do anything yet (but it will next version!)

Unity 2018.2 and .NET 4.6 Upgrades

  • Upgraded all of the projects of the game to be Unity 2018.2f1 (release candidate 1) instead of 2017.3.
    • This gives us access to a few new tools and tricks and bugfixes, although for the most part the improvements in these newer versions are not relevant to us.
    • This should stop the double-keystroke-entry issue that folks were seeing on certain flavors of Linux in 2017.x.
  • Upgraded all of the projects of the game to use .NET 4.6 (no longer experimental in the latest versions of Unity!) instead of .NET 3.5.
    • This is a huge improvement for us in terms of flexibility, particularly in terms of multithreading, compared to the decade-old prior version.
    • This is the largest thing that the upgrade to the newer version of Unity allows for us.
    • Interestingly, our calculations of fixed-int square root have doubled in speed just from doing this upgrade, which is notable all on its own.
    • Also interestingly, our sim speed got a 50% speed boost just from doing this upgrade, too.
  • Rebuilt all of our asset bundles, and executables, in the newer 2018.2 format.
    • Made a laundry list of small script adjustments for compatibility with the new unity version.
  • Fixed an issue caused by Type.GetNestedType() in the .NET 4.6 mono implementation that Unity uses where base classes were not being properly checked. This was preventing some of our sidebars from loading in correctly in the GUI.
  • Updated MeshBaker and Amplify Bloom.
  • The bloom settings in the main game view seem to be wrong in the latest version, likely because of a shift in HDR formats on the screen buffer. We're going to have to adjust a lot of materials manually, most likely.
  • Fixed a queue/list size issue in our BattlefieldVisualSingleton class, where basically we were using generic collections that started small and then would have to grow rapidly any time a fight started that was substantially larger than a previous fight during that run of the game application. That was causing some slowness and jitters during fights, and could even lead to an exception in rare circumstances (maybe less rare in the new .NET runtime, for whatever reason).
  • The post processing stack on the main menu have been updated to use the V2 version instead of the older one. This is kind of a test case for being able to do the same thing with the actual game, and potentially gain some performance out of it. This also now uses Temporal AntiAliasing (TAA) instead of FXAA, so the stars don't flicker like they used to (although they are also now more faint).
  • We have now thoroughly investigated the Lightweight Rendering Pipeline in Unity 2018.2: https://blogs.unity3d.com/2018/02/21/the-lightweight-render-pipeline-optimizing-real-time-performance/
    • There's a lot to love there, and we were able to convert most of our shaders over to that with some elbow grease, but there were some dealbreakers in the end.
    • The way that normal maps are used in this pipeline is just absolutely underwhelming, leading to incredibly flat-looking surfaces no matter what we tried.
    • The general ability for geometry to pick up the bit of global reflection in the forward-rendering style isn't there, which again makes things look really cheap and flat.
    • The ability to completely turn off specular highlights as we were accustomed to in forward rendering isn't there, leading to bloom hotspots.
    • Some of the depth sorting seems a bit wonky with specialized shaders such as the ones we use for wormholes. There were also some issues with the nature of our forcefield shaders after porting those over.
    • The complete lack of motion vectors, which thus makes TAA impossible to use, was a surprisingly big blow to the visual quality. TAA seems cheaper than SMAA, although we're not positive which we'll be going with (and that's somewhat hardware-dependent, potentially).
    • Overall it was a good experiment and something to try for sure, but for our purposes we just need to start using DrawMeshInstanced like we've been talking about doing for 2+ years now.

Multithreading Revision Explorations

  • Somewhat as a test case, implemented a parallel loop based on https://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/how-to-write-a-parallel-for-loop-with-thread-local-variables to calculate all the FInt square root arrays across all your cores rather than just on your main core. On a mult-core machine, this will generally yield roughly 0.9x of a speed bonus for each core beyond the first, conservatively. On a quad core with hyperthreading, this cut the computational cost to between a quarter and a third of its prior expense. This leads to faster loading times by about 1-2 seconds, depending on your machine.
    • This is using some of the new syntax and available functions in threading and linq inside the new version of mono/.net that we just upgraded to.
    • Big thanks to José Salavert Torres for turning us onto this methodology. We could definitely see this being useful in some other locations in the sim itself!
  • The entire sim loop, multithreading and all, has been moved to the open-source external ai war 2 code. This allows for a few things. Firstly, if someone ever wanted to entirely replace the sim loop for some crazy reason, they could do so in a mod. This seems unlikely, but it's now possible. Secondly, and more importantly, it allows any modder to look at our sim code and contribute any sort of tweaks, improvements, extensions, etc, that they might be interest in. Lastly, as a minor bonus, it actually makes the time to test in-game after a tweak to the code faster since the unity editor doesn't reload the external file the same way.
    • Chris has spent a fair bit of time trying to improve the multithreading model that the game uses at this point, thanks to the insight and advice and code examples and explanations from folks who came here (https://docs.google.com/document/d/18uFxUOnlPf5-hoS0wQToPeBuFxdQ1hqpVVSP6XZ0RUM/) after the last kickstarter update asking for a hand with this.
      • Unfortunately, this has not yielded positive results yet. Switching to the ThreadPool has thus far still yielded identical performance to the Thread.Sleep(1) method, which really shouldn't be the case. In both cases, cores beyond the first were frustratingly idle. Switching to using locks in the manner described by BearPerson in his FrameSync class example led to things being about 20x slower than our current implementation, BUT all cores being pegged. This isn't a problem with BearPerson's code example, but something architectural in our sim framework design itself.
      • In general that's the conclusion that we have at the moment: something in our sim architecture is holding back the threads from realizing their true potential and using all the processors as fully as possible. With that in mind, this open-sourcing of the sim architecture code will hopefully allow some of the better experts to come in and help us out more directly. Them not being able to see the code was a big barrier before. In the meantime, this will let us focus our own dev hours on some other areas that are more to our specific expertise.
  • A bunch of comments have been added to the sim/multithreading code files to make them far easier for someone else to untangle in terms of what they are supposed to be doing.

Version 0.748 Macrophage Teeth

(Released July 5th, 2018)

  • The click hitboxes on the galaxy map planets are now much larger, making them easier to click. They're also now properly spherical rather than being an inset rectangle.
    • Thanks to DevoutHaruhiist for reporting.
  • Updated the non-viewed planets on the galaxy map to just be small spheres instead of those strange cubes. The cubes looked extremely tacky.
  • Fixed a bug with the Dyson and Nanocaust behaviour when patrolling on a planet.
  • A number of Marauder changes. Tweak the message when Marauders capture a planet. Fix a bug where the Raiders weren't choosing sane targets. Buff the Raider ships. Allow the Marauder Intensity to change the Raider spawn interval. Fix a bug where new outposts weren't spawning correctly.
    • Big thanks to Ovalcircle for the report and save game
  • Pausing the game no longer causes the background worker threads to suicide after 10ish seconds.
    • This has no material effect on the game, performance-wise or functionality-wise, but it avoids cluttering up the logs with useless and scary-looking messages.
  • Fix a bug where the Macrophage weren't actually doing damage
    • Thanks to Ovalcircle for the bug report
  • Fix a typo in Hunter Fleet description
    • Thanks to Ovalcircle for the bug report
  • No longer compiling against Theraot.Core.dll, since it includes some of the System.Threading classes duplicated.
  • Fixed an issue in the last version or two of the game where the metal amount shown in the header was acting like it was 1000x smaller than it really was.
    • Also made it so that the metal now shows a decimal place and two significant digits after it if it is drawing into the millions.
    • Thanks to Badger for reporting.

Simulation-Side Performance

  • Updated the game to prefer the XorshiftRand in almost all cases instead of MersenneTwister. The former is vastly faster, and overall good quality of random results. For things like map generation which have obvious visual patterns, we're still using MersenneTwister. But for things like AI decision-making and declumping of unit overlaps, etc, we're now using the faster random. This leads to a nontrivial increase in the speed of background thread execution.
  • The way that the selected state of units is tracked now uses a local variable that is kept in sync with the global hashes, thus removing the need for expensive hash checks and other sweep-and-pass loops. These were extremely expensive CPU drains on the main thread, in excess of 10% of the entire sim CPU bottleneck in one particular performance savegame we looked into.
  • For a lot of parts of our spatial code in the sim, the ability to quickly calculate a square root is a limiting factor. This is particularly bad since we need it to be deterministic between machines (for multiplayer), so we have to use fixed-int math on the processor and not something accelerated like SIMD or other hardware-accelerated solutions (sqrt is a common bugbear even outside of games).
    • We now have a tiered version of precalculated fixed-int squareroots, where it calculates all of the values up to 400 with full game-specific fixed-int precision (12 bits in our case), and then from 400 to 400,000 it precalcuates it at integer-level precision (which is plenty good enough for those scale of numbers. Above those numbers, which happen fairly rarely in our code just given the nature of the game, it continues to use the iterative approach that it's been using up until now. During gameplay we're not actually seeing it hit this case at the moment, though.
    • This costs an extra 2-3 seconds of CPU time on loading the game, but then shaves off a ton of time, particularly on the background threads, while the game is running. For practical purposes, this savings is something that gets larger and larger the more ships there are at once on a planet.
  • Made some improvements to finding out who the owning and local player factions are on planets, and finding the planet controller, such that the workload of our OnUpdate method -- which was our previously most expensive method on the main thread of the CPU -- has dropped to 40% of its prior bulk. Some of the secondary threads also get a bit of benefit.
  • Commented out a bunch of unity-profiler instrumentation that was seemingly slowing down the game when it's run really fast and under extremely heavy load, at least according to JetBrains DotTrace, which has been pretty reliable so far.
    • Extremely heavy load, in this case, refers to a simulation of 27000 enemy ships (2500 squads) versus 272 player ships (35 squads), run at +7 simulation speed. At regular simulation speed, this runs at 75% gametime speed at the moment, but at +7 sim speed it runs at 10% gametime speed. So this is pretty good as a punishing new sim-side test case.
    • Prior to now, the testing has been done with a simulation of 12000 ships versus 100 ships in a +1.25 simulation speed. Same savegame, but just prior to spawning in some extra waves using debugging tools. From here down, we're using the more intense save.
  • Adjusted the main loop's queue of game commands to be more of a swizzle set now; it has two lists that it flips between, sorting unused items into the backup list and then switching which list is active. This saves us a ton of CPU time when there are many game commands going through at once, since previously it was having to continuously pull items out from low in the list and then shuffle the other items down.
  • Switching in bitshifting in place of some multiplication and division in order to get a bit of math speed boost in some areas.
    • In a few areas, like collision checking, this saves about 25% of the CPU processing requirements. In other areas it is less, but still an easy way to get a bit more performance in various nooks and crannies.
  • Split out the "GetCanHit" method into several variants that are each optimized for specific use cases. We're not using variables in one method on this in order to shave the absolute maximum time off of them. This method is the third-most-hit method in our codebase during large battles, being hit over 10 million times in 18 seconds of battle. So absolutely every bit of savings we can get here, including the usually-too-miniscule-to-matter bits, are done.
    • Now we're also doing a few other things like caching the count of items in the systems list so that we don't have to check that every loop iteration, etc. That's almost never a worthwhile code addition, but here it is.
  • Fixed up the World_AIW2.Instance object so that it's now a static member variable instead of a static property. This normally is not the best plan for idiot-proofing's sake, but in our case this property was getting hit 29 million times in 18 seconds of combat, so here again it was a case of pulling off the safety covers to get the absolute best speed. Go to space in a convertible!
  • Slight improvement to how the GameDeltaTime is checked throughout the application. Despite it only being called by a few lines of code, it wound up being hit 9 million times in 18 seconds of gameplay. This isn't a huge boost or anything, but it was a quickie.
  • The way in which the thread manager checked its threads for if it should kill them has been updated to use DeltaTime rather than TimeSpans from DataTimes. This actually saves a surprisingly huge amount of time -- it was previously eating 2% of our total execution time because it gets called 40 million freaking times in 18 seconds of gameplay. This was our most-called method in our code (List<>.Count is higher at 105 million, and List<>.getItem at 75 million, but nothing else comes close).
  • Now we only check for auto-killing threads 5 times per second rather than every frame, to avoid having so very much overhead from doing this excessively.
  • Now we only check for network socket updates 20 times per second rather than every frame, to avoid having so very much overhead from doing this excessively. Even in single player this was a thing!
  • Finally figured out a way for us to be able to profile into the "external" dlls using our unit tester tool. This works with dotTrace and ANTS. At the moment there is next to nothing of importance in there performance-bogdown-wise, but we had no way of knowing that until now (and that likely wasn't always true, Badger made some improvements a while ago). It's also something that will help us improve the performance of MapGen code, later, which is definitely always in the external code (and of course, if we later have a spike in some part of the external code, we'll see it now, versus before we may or may not have).
  • The ability for our unit tester to profile map generation has been added.
  • Put in some improvements for speed with getting and transporting the lists of orders for the long-term planning thread. These get hit about 3.2 million times over 18 seconds, and were a minor hotspot for performance on some background threads, so it was a nice spot for a bit of a bump.
  • Added some minor performance improvements to our tracing code that reduce a few math operations to just a bool check.
  • Another minor improvement, this time with the speed of checking what the status of the networking socket is. This helps equally in multiplayer and singleplayer, although it's a slight help. The main thing is that it gets checked 19 million times in 18 seconds, so even small improvements help here.
  • Checking for secondary thread death is now done only every 0.4 seconds, since it involves several calls that we want to avoid hitting. Normally threads should not be dying, but instead say they are complete, anyway -- so mostly this only matters for when exceptions happen.
  • In our unit testing program, we now have the ability to specify our simulated framerate (expressed via GameDeltaTime). An interesting discovery from this is that when the delta time is higher, the background threads actually run notably slower. This doesn't have anything to do with competition between the threads for resources, since the work the main thread does in this case is identical in both cases; we're going to further investigate that finding.
  • In ArcenTime, we now have a float TimeSinceStartF, which works like Time.time rather than DateTime.Now (which is what ArcenTime.Now is).
  • Previously, we found that repeated DateTime.Now calls were a major source of slowness in our application, so we implemented our own custom incremental counter using a stopwatch and a starting DateTime.Now time. This largely solved the performance problems, but now we've taken this even further.
    • Instead of using a DateTime.Now at all, or even keeping track of time at all in the global sense, we're now just keeping track of a float-based seconds since the application was started, with the numbers here being based on accumulated GameDeltaTime.
      • This saves a substantial amount of processing in various places where we were adding or subtracting DateTimes, or switching to TimeSpans to check TotalMilliseconds or TotalSeconds or similar. Now it's just a single float subtraction or addition in all those cases, and to compare against seconds we just compare against a number like 2 for 2 seconds. For comparing against milliseconds, we compare to 0.4f instead of 400.
      • There are a few UI-related places where we need to actually use a real DateTime, and ArcenUI maintains a DateTime on it that is a cache of DateTime.Now. This one doesn't have any drift and should be cheaper to get once per frame than the stopwatch and timespan math. This has been left on ArcenUI instead of being moved to ArcenTime in order to emphasize that this is for display only and that ArcenTime.TimeSinceStartF should be the primary thing used now.
    • Among benefits to performance in various places -- the network NAT traversal included -- this is a more precise form of time tracking than our previous method, which makes the framerate counter a lot more accurate, for example.

Version 0.747 Improper Handling Of Forcefields

(Released July 2nd, 2018)

  • Fixed a bug where special seeding logic (for capturables, among other things) would always put a unit at the dead-center of the planet if that spot was safe for placement.
  • Add some missing XML for Risk Analyzers
    • Thanks to OvalCircle for reporting
  • Fix a bug where the Marauders weren't correctly checking a planet's defenses when deciding who to attack. Also some buffs.
    • Thanks to OvalCircle for reporting
  • Add information about the faction sending the wave to a PlannedWave object for use in notifications
  • Fix null reference exception when mousing over the notification for a CPA
    • Thanks to dv for reporting
  • Tweak Rally-To-Group to allow units rallying to the group to take on the existing orders of the group if the group has orders already.
  • The various threads that were previously only living for 10 seconds at most now live for 30 seconds at most -- at least for now. This may cause hangs to happen in the game if something is really long-running, but ideally this will let us know a bit more about what something is doing and why, and potentially find the hangups that are taking so long.
  • The error messages for commands that are trying to be executed on a different frame now say more about the command, such as what type it is. Most likely the problem isn't directly with these commands anyhow, but a thread that stalled before it or ran overlong, but it's worth having the extra info just in case.
  • When you are in ship placement mode, it no longer exits ship placement mode when you place one ship. Instead it stays in there until you press escape or right-click. Previously you had to hold down shift for this to work this way.
    • Thanks to Cyborg for suggesting.
  • Pressing the "Switch to tech tab" button (T) now selects any science labs you have on the current planet (convenience!)
  • Pressing the "Switch to build tab" button (B) now selects any and all builders of any type you have on the current planet.
  • If you have ONLY builders selected (such as by hitting B), and at least one of them is immobile (aka not only mobile builders selected), then right-clicking will set the rally points for any queue-based builders.
    • This is a big time-saver, but is set up this way so that builders don't get accidental queue-set commands when in mixed selection company, and so that mobile builders don't become unable to get movement orders thanks to the right-click override.
    • Thanks to Badger for suggesting.
  • Put in some code throughout the map generation and AI sections that should defend against possible infinite loops. No idea if those areas actually did run into infinite loops previously, but it doesn't hurt to code defensively in these areas since some of the background threads may be stalling out at times.
  • On the tooltip for the AI Progress icon/number in the header, it now shows you what your AI difficulty level is (or range if it's multiple), and it tells you the thresholds at which new things unlock (at this point in time it's just the AIP per ship unlock, and the AIP at which the hunter waves unlock).
    • Thanks to elcommendante for suggesting.
  • Because of some changes in the overlay camera hierarchy a while ago, the "You lose text" now shows above the GUI, which is what we've desired for a while.
    • Thanks to this, we no longer have to hide the GUI after a game loss; the GUI should never be completely hidden using the methods that we were using at the time, because it leads to "hovertext crashes," among other crashes. The in-game hide GUI button never had this problem.
  • Visually, the game now treats strength as if it were 1/1000th of what it is under the hood. Thus anything that previously had a "k" at the end now has nothing at the end, making it a lot easier to read. Anything that had an "m" at the end now has a "k" instead. Anything that was previously written out as hundreds or less is now written out as a decimal, to one significant digit (old 100 = 0.1). All of this makes it way easier to read strengths at a glance throughout the UI.
    • Thanks to dv = i ln(w0 / wf) and BadgerBadger for suggesting.
  • Colony ships, scouts, science labs, mobile builders, and mobile space docks no longer die to remains.
    • Engineers and remains rebuilders DO, because presumably you want these to automatically come back online after being killed if at all possible.
    • We can obviously adjust this further as needed in the future.
    • Thanks to Badger for suggesting.
  • Fixed a longstanding bug where forcefields could visually appear on squads that don't actually have forcefields. This had no gameplay effect, but was confusing as heck from a visual feedback standpoint.
    • The bug with sometimes the wrong units getting mixed in with squads is still there, but we'll get to that soon.
    • Thanks to Ovalcircle for reporting that this was still going on.

Wave 3 of 5 of the Pivot (Part 2)

  • Added the Advanced Factory and Advanced Starship Constructor back in, with AIWC-like mechanics.
  • Added the Zenith Power Generator, with AIWC-like mechanics.
  • Added the Mobile Builder, with AIWC-like mechanics.
  • Added the Mobile Space Dock, with AIWC-like mechanics.
    • Caveat: only repairs one thing at a time right now; later the repair mechanic will need to be replumbed to allow for multiple repair targets at once.
    • Caveat: the builder menu currently doesn't reasonably handle multiple constructors of the same type, or many constructors on the same planet in general. Probably it needs to just handle all mobile space docks on the same planet as one group.

Return of the Nanocaust

  • The Nanocaust was removed to make Keith's life easier during the pivot, and it now makes its terrifying return
    • There are a few post-pivot bugs, but its mostly functional

Version 0.746 Disposing of the Invisible Man

(Released June 29th, 2018)

  • A few tweaks to prevent nullrefs in hovertext over ships, and to make them work properly in build and tech modes, as well.
  • Further protection against some data garbling that could happen on worker threads, which led to things like AOE attacks striking ships on other planets from the current one.
  • Fixed an issue where newly-created ships that were rallying into a control group could rally to themselves if they were suddenly the strongest ship in the control group.
  • Fixed an issue with Infrastructure being spelled wrong.
    • Thanks to Ovalcircle for reporting.
  • Put in a variety of protections against exceptions that could happen due to units no longer existing or being removed from any planet (aka the game) but having orders queued up for them and executed later.
    • Thanks to Ovalcircle and BadgerBadger.
  • Fixed a bug with 8 of the skyboxes that were causing nothing to render on their planets except wormholes. Uh... whoops!
    • Thanks to Ovalcircle and Badger.
  • Updated one of the really dark and pretty ugly skyboxes to instead be more white cloudy so that it's still faded out, but you can see more of what is going on.
  • Fixed the middle-mouse pan controls so that they act as expected; they were reversed as of the first pivot release.
  • Fixed an issue where if you upgraded a ship type (such as Fighter 1) to a higher mark (Fighter 2), it wouldn't keep the new level of fighters in all your queues. Now it immediately starts cranking out Fighter 2s instead of Fighter 1s after that upgrade.
    • Thanks to Badger for reporting.
  • There is now a brighter version of the colors that always shows when the game is writing text using a team color. This keeps text actually legible, while still giving the general feel of the player color in question.
  • Rather than showing the generic yellow strength color on the wave warnings, it now shows the color of the first AI faction in the game (waves are not attached to factions directly, apparently).
    • Ditto the colors now used on the attacking-my-planets warnings, except in this case it uses the color of the first-found attacking faction. Before it was using yellow for players and purple for AIs, but now it uses the colors that are more specific.
    • Same for the CPA notices now, actually -- instead of showing red text, it shows whatever the first AI color is, like the waves (by default this is actually red anyway). The actual icon portion is of course still red and white, since that's an icon.
    • Same also for on the galaxy map when you're viewing colors of unit counts on planets. For the threat color, if there is a hostile count AND threat count (aka on enemy planets), it draws the border color instead of the center color.
  • Fixed an issue with the text colors in the galaxy map over planets, as well as on the planet view over wormholes. They were being translated from gamma color space to linear color space incorrectly, and we're now using Color.linear to fix that manually on our end. Now the colors there match the colors on the UI parts of the interface.
  • The wormhole names now show all the time by default (like they did pre-pivot), since that's pretty helpful data.
    • If you prefer the more recent way of having those off unless you hold Ctrl, there is a new settings option you can disable.
    • Thanks to dv = i ln(w0 / wf) for suggesting.
  • Scout starships now provide some decloaking abilities around themselves, as in the first game.
    • Unlike in the first game, they are now unlocked by default from the start of the game. This way the players have some way to deal with cloaked ships on enemy planets.
    • Thanks to dv = i ln(w0 / wf) for suggesting.
  • Player tachyon arrays now have the same icon as AI tachyon sentinels.
    • Thanks to dv = i ln(w0 / wf) for suggesting.

Wave 3 of 5 of the Pivot (Part 1)

  • Added Ion Cannons back into the game, with the old AIWC-like ion mechanic of simply insta-killing anything of a low-enough mark level (in this case it's actually mark level <= the cannon's, instead of strictly less-than, and the cannons are Mark 1 through 5 instead of 2 through 6).
  • Added the "Bulletproof Fighter" bonus ship type. Basically just a fighter that's immune to ion cannons.

Attack Move And Group Move!

  • Added keybind "Group Move" (default G)
    • Normally when you give units an order to move, attack, or enter a wormhole they go as fast as they can. Hold this button down to make them go at the speed of the slowest (mobile) unit to whom the order applies. Ignores speed debuffs like engine-damage, tractors, gravity, or paralysis.
  • Added keybind "Attack Move" (default X)
    • Normally when you give units an order to move, attack, or enter a wormhole they pursue the target point/object without regard to (other) enemies. Hold this button down to make them stop to fight anything they run across (more specifically, any time they're reloading).

Version 0.745 A Pivot And A Leap Forward

(Released June 27th, 2018)

  • This is the first release of "The Pivot," which you can read full details of on Kickstarter: Pivoting AI War 2: Bring The Fun!.
    • The short description is that we're dropping back from what was considered a beta status, and instead proceeding with a revised design on our existing engine in order to make sure that this sequel fully lives up to the legacy of its predecessor.
  • As part of this, basically all of the game content that was pre-existing has been removed, and we're adding new content in a fashion as described below.
    • The interface and such from before has been retained, and then greatly expanded as part of this release.
    • The underlying engine and whatnot that we built has also obviously been retained, and we've also expanded that where needed in order to support the new content.
  • Existing savegames are all broken now. With the game basically being redone from the ground up in terms of units and content, this seems pretty reasonable. Older savegames would have been incredibly strange in the new version, anyway.

Wave 1 of 5 of the Pivot

  • Wave 1 of 5 of The Pivot is now complete.
    • Note that this obliterates a lot of the game that was previously known as AI War 2, and we're going to be adding back to this rapidly.
    • Please also note that a lot of the graphics for the post-pivot stuff is still inwork, which includes both icons and actual ship graphics. We have a lot to do!
    • Lastly, please note that this is putting a variety of kinks in our current GUI, so there is work incoming on that, too. We're basically making a mess at the moment, so please excuse our sawdust.
    • The overall goal of Wave 1 of the pivot was to get an end-to-end playable version of the game. By that, we mean the MINIMUM possible possible playable stuff, to be clear.
    • Main things that were thus included:
      • Removing all the ships that previously existed, and then adding as new:
      • Command station mechanics, and home command stations.
      • AIWC-style mechanics for the AI home command station.
      • Upgradeable mechanics for other command stations (so we can do econ, military, etc).
      • AIWC-style metal harvesters, the seeding of them, and all that.
      • Ditching power and fuel, and going back to the AIWC-style Energy mechanic, and adding energy collectors.
      • Going back to AIWC-style mechanics for the space docks.
      • Fighters, Bombers, and Missile Corvettes; and with that, a framework for applying the old AIWC balance numbers on top of our newer xml balance framework (until the framework and the numbers can be made to meet in the middle)
      • Warp Gates for the AI, those were already pretty much the same between games.
      • Engineers, and all the AIWC-style mechanics associated with them.
      • A variety of turrets from the first game.
      • Tractor turrets, but this time switching to the older AIWC-style mechanics for how those work.
      • Scouts, and the AIWC-style scouting mechanics.
      • AI Tachyon Guardians, which are simply a new unit, although possibly this included a shift to the AIWC-style cloaking mechanics? Not sure on that one bit.
      • Science Labs, and the AIWC-style knowledge-gathering mechancis.
      • Colony ships, and the AIWC style of those working.
      • Mine layers, and the rebuilder mechanics that go along with those.
      • Guard posts for the AI, and the mechanics that go with that.
      • Some of the AI guardians, and the AIWC style of guardian mechanics (AIW2 was previously wrapping guard posts and guardians into one thing, but now that's more split)
      • Force field generators, and a return to the AIWC style mechanic (with those now being present at all in general, too.
      • Starship constructors, nothing major different here between the two games.
      • Some of the basic starships.
  • For the time being, in the xml and underlying data structures, we still have global fuel and per-planet power.
    • However, everything is just using the global fuel now, to be more AIWC-like.
    • On the interface, we are now referring to this global fuel as being Energy again, as with AIWC.
    • We'll see how this continues to evolve, but for now that was the simplest thing.

Wave 2 of 5 of the Pivot

  • Wave 2 of 5 of The Pivot is now complete.
    • Now we're building back up a bit more in terms of having the game more recognizable, but there's still a lot to clean up before we even release it to you.
    • New ships, with their attendant mechanics, added:
    • Scout Starship mk1-4, Stealth Starship mk1-4, Shield Starship mk1-4, Siege Starship mk1-4, Sniper Starship mk1-4, Carrier Starship mk1-4.
    • Arachnid Guard Post mk1-5, Missile Guard Post mk1-5, MLRS Guard Post mk1-5, Laser Guard Post mk1-5, Shield Guard Post mk1-5, Stealth Guard Post mk1-5.
    • Tachyon Guardian is now Tachyon Sentinel. Added Wormhole Sentinel, Data Center, Advanced Research Station.
    • Matter Converter, Mercenary Space Dock (and mercenary versions of relevant ships), Home Human Settlement, Human Cryogenic Pod.
    • Multi-Needler Corvette mk1-5, Eyebot mk1-5, Armor Ship mk1-5, Autocannon Minipod mk1-5, Lightning Corvette mk1-5, Grenade Launcher mk1-5, Infiltrator mk1-5, Laser Gatling mk1-5, MLRS mk1-5, Raider mk1-5, Raptor mk1-5, Sentinel Frigate mk1-5, Sniper mk1-5, Space Plane mk1-5, Space Tank mk1-5, Spider mk1-5, Vampire Claw mk1-5, Vorticular Cutlass mk1-5, Tachyon MicroFighter mk1-5,
    • Flak Turret mk1-5, Laser Turret mk1-5, Lightning Turret mk1-5, Missile Turret mk1-5, MLRS Turret mk1-5, Sniper Turret mk1-5, Spider Turret mk1-5, Beam Cannon mk1-5,
    • Tachyon Array, Stealth Tachyon Array, Focused Gravity Generator mk1-5.
    • Laser Guardian mk1-5 as a rename from Needler Guardian, Stealth Guardian mk1-5, Sniper Guardian mk1-5, Missile Guardian mk1-5, Widow Guardian mk1-5, Tractor Guardian mk1-5, Lightning Guardian mk1-5, Flak Guardian mk1-5,

New Faction: Astro Trains (Thanks, Badger!)

  • Add new faction 'Astro Trains'.
    • When enabled, a bunch of Astro Train Stations are seeded on the map. Every so often the AI will create a Depot, then begin to spawn trains that head to the Depot. Trains will travel between the Stations, then eventually to the Depot.
    • For some depots, a train will be required to go "near" a player if possible so that you always have a chance to kill them. Whether trains are required to go near the player is tunable on a per-Depot basis.
    • There will be a number of different types of Depots. Some produce an effect whenever a train arrives ("Increase the next CPA's strength", "Spawn some ships for the Warden Fleet", etc), others produce an effect after a certain number of trains ("If 4 trains arrive then spawn a Golem"). Depots are defined entirely in XML so it's easy to add new ones or change their balance
    • There will also be a number of types of Trains based on the defenses they have. At the moment there is only 1 (and it's misnamed, Keith hasn't added its weapon system back into the Pivot yet)
    • Eventually I'd like to have the Trains give you metal when killed, but that mechanic isn't added yet.
    • This faction intended to be a More Interactive and Fun version of AIWC's astro trains, which I always found rather frustrating.
    • For other modders, this faction is a great example to look to since it defines a new table in the XML, which allows for very complex behaviour.

New Faction: Macrophage (Thanks, Badger!)

  • Add new faction 'Macrophage'
    • This faction is an invasion of giant organic Macrophage. They prey on Metal, devouring ships and structures they come across, and in particular they prey on the AI (since you haven't encountered them yet).
    • Macrophage live in colonies called Telium, which are hidden from the AI. A Telium sends out Macrophage to harvest metal by destroying human or AI ships. When a Colony has been fed enough metal it will create cloaked and harmless Spores which wander the galaxy. When spores encounter spores from other Telium they can reproduce to spawn a new Telium.
    • They are hostile to humans and AI alike, but not very intelligent.
    • If a Telium produces enough Macrophage, some of the Macrophage will be transformed into an Aggressive form and then go try to kill the human player. If a Telium is destroyed, all of the Macrophages associated with it will attack the player.
    • This faction is a bit like reimagining the Devourer Golem as a part of an ecosystem.

Dyson Rework (Thanks, Badger!)

  • The Dyson Sphere now uses a "Metal income per second" mechanic to spawn units instead of just arbitrarily creating things at a time interval. This makes it much much easier to balance.
    • Changing the intensity of a Dyson Sphere changes the income per second; the balance numbers for a given intensity are now in the XML.
  • Multiple Dyson Spheres can be enabled at a time, and each can have a different colour and intensity. Enabling X dyson spheres divides the income of a given sphere by X so multiple Dysons won't be able to just crush the Galaxy.
  • Dyson Spheres can be Antagonized, like AIWC. If a Dyson Antagonizer exists, all the Dyson Spheres drop what they are doing and start sending units to attack you. Previously created Dyson Sphere ships will keep their previous alignment (so if they were friendly before, they will fight Antagonized ships)
    • Antagonizers are not currently created by anything yet, so don't worry about them showing up yet. I imagine one of the Astro Train Depots will create antagonizers eventually, but there may be other mechanisms worth exploring.
  • Each Dyson Sphere now has a max Strength Allowed based on the current AIP; the higher the AIP the stronger the Dyson can get. The tuning for this is in the XML

New Faction: Mercenaries (Thanks -- yet again -- Badger!)

  • Add new faction for Mercenaries. The Mercenaries are a much fancier version of the AIWC mercenaries (which are rebranded as "Auxiliaries").
  • Mercenaries are groups of units defined in the XML that can be hired to come fight for you temporarily using metal or hacking points. We may define other costs for them as appropriate going forward. A small set of mercenaries are defined right now with no attempt for balance, just to illustrate the various options that exist. Each group has a name and backstory and different behaviour. Some only defend one planet, others patrol nearby worlds (and will go help any of your planets if they are attacked), others will kamikaze at the AI. Some groups consist only of turrets and engineers. One group is a large cloaked unit that can be summoned on an AI world which will hopefully distract the Warden fleet, but that's untested.
  • Options for mercenary groups that can be specified in the XML
    • On Spawn behaviour: Fight all enemies on a current planet, then warp out. Defend this planet. Patrol nearby friendly planets (they will detect attacks on nearby planets and go help). Kamikaze into the AI.
    • Planet summoning restrictions: Can only be summoned on a Friendly planet, an AI planet, a planet not owned by the AI, or anywhere
    • Seconds allowed to exist: mercenaries will only stick around for a certain amount of time (in seconds)
    • Times allowed to summon: If the Primary unit of the mercenary group survives to the end of its "Seconds allowed to exist" then you can summon these mercs again, up to a certain number of times.
    • Cost: Metal, hacking points or both
    • Spawn Delay: the mercenary group in question will appear after this many seconds
    • Primary/Secondary/Tertiary units: A mercenary group can have up to 3 unit classes. You set these classes with the "[primary|secondary|tertiary]_unit_tag" field in the XML. Note that a tag can be on multiple types of units, and it will choose randomly among them. For example, we might have multiple units tagged with "MercenaryFleetship", and specifying that as one of the unit tags will pick among those at random. You can specify either a specific number of units with that tag, a strength of units, or both. So for example, one might say primary_unit_tag="MercenaryFlagship" primary_number_to_spawn="1" primary_strength_to_spawn="2000". If the Mercenary Flagship units all have 900 strength then this will summon 1 + 3 (we round up when calculating how many units for the strength) = 4 flagships.
    • Class: Defense/Offense/Utility. This is future proofing, we don't do anything with it yet.
  • At the beginning of the game, a number of Mercenary Communicators (I am open to a more flavorful name) are seeded on the map. Each Communicator grants access to some unique mercenary groups. If you are holding a planet with a Mercenary Communicator then you can summon those mercenaries.
  • The two key advantages of mercenaries over regular ships are that they don't cost energy and they can be summoned more quickly. Also some may do other fancier things later (like the warden fleet distractor). There is nothing preventing someone from tweaking the XML to allow you to hire the Devourer, for example, as a fun alternate win condition.
  • How quickly the Mercs appear is tunable on a per Group basis (so we could have identical groups, one that spawns in 60 seconds and costs X metal, another that spawns in 5 seconds and costs 5X metal).
  • AIWC style mercenaries are rebranded as "Auxiliaries"

Marauders Expansionism

  • When the Marauders capture a planet, if they get up to Mark III outposts then they will begin spawning Raiders, powerful starships that will attack weakly defended nearby worlds. So if you give the Marauders and inch they will expand rapidly (the ideal case is "You've cleared out a bunch of planets but haven't captured them, and the Marauders will build an empire there if you don't watch out").
  • Make Marauders hostile to everyone. This means that neutral planets or weakly defended AI planets are eligible to be captured by the Marauders. Remember that the Marauders capturing a planet will permanently strengthen the faction.
    • Thanks to Ovalcircle for the suggestion

Misc Bugfixes

  • Fixed an oversight in some of the recent versions where the Dyson Sphere was missing its cage. It now has a shiny (literally) new material on it.
  • Slight rework of the Autosave code. You now can specify the interval for autosaves and the number of previous autosaves to keep. So if I want to take autosaves every 10 minutes and keep the last 6 then I'll be able to easily jump back to the game up to an hour before. The goal is to make it easy to savescum efficiently and effectively ;-)
  • Provide a workaround for the problem where people who had last used a no-longer-extant map type would hit a crash when they start the game. Those deprecated map types are now defined (so it won't cause a crash anymore), but hidden by default so they can't be selected.
    • This was reported by numerous people, including Valeroth, Clasmir, zeusalmighty and probably others
  • Fixed a since-forever bug where ships fast ships that wind up needing to move to not overlap something would start bouncing around like they needed to go to the little starship's room.
  • Fixed the scales and collision radii of the assault starships.
  • For now at least, the bobbing of ships within squads has been turned off. As steam user Bucketsmith pointed out, it looked too much like ships on the ocean. It was meant to give a sense of life to the ships, but after he pointed this out to us, we couldn't stop seeing it, either...
  • The game now has proper settings on all the ship renderers for dynamic occlusion, motion vectors, shadows, etc. This should lead to a slight performance bump.
    • The editor has also now been set up to detect incorrect settings for these.
  • We had some extra uv2 and color and so forth channels on about 510 of our meshes, and we've now removed those. The amount of data was small, but it was useless info to be sending to the GPU since our shaders don't read from those. Every little bit of data shaved off when you're pushing millions of polygons on a millisecond scale is a win, not that it was causing problems in our testing thus far.
  • Fixed a bug where the single-ship-in-a-squad units were not being properly scaled down location-wise.
  • There was previously a bug in the profile screen where it was reversing what your body and trim color selections were on the box-based examples.
    • The icon-based examples were fine, but now the boxes have been corrected to match the icons.
  • Fixed a likely-longstanding bug where the scale of ships would drift smaller and smaller the longer you played, depending on how many times pooled ship visual instances of that type were reused due to deaths or due to switching in and out of the galaxy map view or between planets. Some went extremely fast, such as the recently added AI command stations. We suspect this is also what was going on previously with the warp gates.
  • Previously, the icon scales could sometimes be incorrect when tabbing back from the galaxy map, until you scrolled the camera around a bit. Fixed.
  • The placement mode icons were never scaled up or down to match the size they would be once placement was complete. Fixed.
  • Fixed a since-forever bug where the colors of icons in the main view were lighter than those in the sidebar. Turns out it was not color grading being applied, but rather that we were passing in our Color type parameters as Vector4s. This worked, sort of, but the typo wound up transposing the data slightly for some reason. Why it didn't just function correctly or fail completely is a solid mystery, to be honest.
  • Fixed an issue where opening savegames that were originally saved in a different campaign name but have been manually moved to a new folder were using the old campaign name instead of the new one as far as "continue last save" was considered.
  • Previously, if continue last save was not able to load the last save because it couldn't find the file, it was not showing any error. Now it tells you what the issue is.
  • In the game setup screen on the galaxy map, it no longer shows the colors of any factions other than player planet names (since in games with a lot of factions that actually gives away info).
  • In the game setup screen on the galaxy map, it now shows the player names under each planet name controlled by one.
  • Once into the game, it no longer shows the color of the faction on the other side of a wormhole if you've never scouted that planet at all.
  • Fixed an issue with the little bottom-left menus where the mouseover of elements behind them could sometimes happen because there were cracks between the buttons. Now there's a backplate behind the entire windows in those locations.
  • The underlying flag under the queue pause button was not actually implemented (it may have previously been the loop flag), so it didn't work; now it's implemented and works to pause that queue. Incidentally this does not disable any other functions of the building unit, unlike in AIWC where it was done through the general "disable everything" mode
  • Removed requirement that you have had units on a planet before you can send units there on the galaxy map (leftover from the sensor-scrambler scouting model)
  • Fixed a bug where the game was still trying to seed design-template-servers when the AI unlocked something new, despite those not currently being defined in the game, and thus throwing errors
  • Fixed a bug where AI ships freed by a minor faction still just went after the humans

Misc Improvements And Additions

  • Added a new IGameEntityDescriptionAppender, which can be linked up using the new xml tags description_appender_dll and description_appender_type.
    • One example is presently in place with the human home command station and a test class called AnyUnitExampleAppender.
    • This is something that can be used for adding arbitrary unit-specific or class-specific dynamic text to the description of any unit or unit type. This is likely to be widely useful as we build out the UI later on, because we can put in context-specific warnings and commentary, for instance.
  • If a ship has been shot to death into remains, it now says REMAINS in red after the name of the ship in the mouseover, and it tells you what the remains means and that you need a remains rebuilder in the description text. Otherwise this was absolutely mystifying as to what was going on!
  • When ships are under construction directly on the battlefield, it now shows the health bar to show the progress that they are making towards completion. Holy cow did things feel incomplete without that.
  • Hey, does the scale of the grav wells on planets feel too small to you? Here's how you can tune the numbers. For example, at the moment we've doubled the size of the grav wells, and we'll see how that feels. To do the doubling, since that's simple math, here are the changes:
    • GameData/Configuration/ExternalConstants/KDL_VanillaConstants.xml
      • distance_scale_gravwell_radius 13000 to 26000 (This makes the sim-level grav well twice as large, but if you just change this then visually things will draw very wrong. Must be an integer.)
      • asset_base_unit_radius from 100 to 200 (This makes the units draw half as large as they previously were. It has to be an integer).
    • GameData/Configuration/ExternalVisualConstants/CMP_VisualConstants.xml
      • combat_visual_scale_divisor from 10 to 20 (This makes the position of units, and the size of their selection radius, all make sense visually. Whatever multiplier you apply to distance_scale_gravwell_radius, apply the same one here).
      • forcefield_visual_scale_divisor from 5 to 10 (Same deal, forcefields will look the wrong size if this isn't adjusted).
    • There actually may be a few other settings that we overlooked, but hopefully this is a comprehensive guide. If not, we'll update this in the future if we discover a hole.
  • Selecting a constructor unit (like the Space Dock or Starship Constructor) will automatically open the Build Tab on the sidebar. It was really annoying to click on a constructor, then realize you need to also click on the Build Tab. Note that hitting "B" is more efficient than clicking on a constructor anyway.
  • Dark Spire: Different factions produce different amounts of Energy when their units kill or are killed. These values are tunable in the XML. The AI or players units produce more energy than minor factions like the Macrophage, Devourer or Nanocaust.
  • In the planet view, linked planet names are no longer shown over wormholes unless you are holding down the ctrl key. Thus you can easily see the names, still, but they aren't cluttering up your view all the time (and making the gravity well feel smaller in the process). This also has the benefit of making it really obvious when you can click to send your ships or camera through the wormholes.
  • Now that warheads are no longer a resource that should be shown on the top bar, we're bringing back the attack warning/numbers up there. This shifted around several elements on the top bar, spatially, but put the new attack warning in the bottom right of that bar.
    • Slightly different from the first game, the new attack indicator shows the number of hostile enemy ships on ANY player planets, not just those you own. That seems relevant. It has three states: a greyed-out "nothing's here" safe shield with checkmark, a yellow and orange "things are here, but not on your personal home planet," and then a red and white warning "there are at least some of these guys on YOUR home planet."
    • Undoubtedly we'll adjust this some over time. One oddity you'll notice is that the frequency of the flashing of the text in this field is inconsistent. That's unfortunate, but a side effect of the way that unity dirties its GUIs rather than drawing every frame, along with the multithreaded queued approach we take on top of that.
    • The tooltip will list all your planets that are under attack sorted by the strength of the attack
  • The quick start button now actually works, although it goes to the same location as the custom start. A tooltip notes that the quick start variant is coming soon. However, some folks were confused and not thinking to go to the custom start, so here we are.
  • On the galaxy map and in the planet view, the icons for ships now are rotated to billboard toward the camera on the GPU instead of on the CPU. This saves an enormous amount of processing when there are many icons, and means that we can update the scale of icons more rapidly even when there are many many icons on screen -- getting rid of that delay in rotation/scale that was seen in prior versions of the game. There still IS a delay built in, just in case you absolutely flood your screen with icons, but it shouldn't be hit in normal gameplay (or if it is, we'll adjust this further based on profiling of said savegames). Additionally, since the rotation is run on the GPU, that means that CAN'T happen any way other than instantly, which is nice.
  • The color picker UI has seen a number of updates:
    • The individual color cells are now far smaller, letting you see tons more of them at once, and feeling more like traditional color pickers.
    • The selected color cells no longer blink their main color, but instead blink a little border around them. It's a lot more obvious what is going on now, and no longer seems like a bug. The flashing is still needed because the borders get lost in the riot of colors, otherwise. Hazard of having so many options.
    • There is now a section of preset options (combos of body and trim colors) down at the bottom of the screen. These give attractive options that also don't conflict with any of the NPC factions. This is one of those things that makes the game infinitely more usable.
      • There are eight of these right now, but it's possible to define more via xml.
  • The in-game tooltips for planets and units/objects now shows in the bottom left, as it previously did in AIWC.
  • The selected ships notice now also shows up down at the bottom of the screen, where the tooltips do. It only shows if a tooltip (or the escape menu) is not showing. This saves important space in general, and also paves the way for the notifications bar up at the top to finally have room.
  • Scouts have a much higher movespeed than anything in the game, so the approximation for lerping squad movement was much higher than anything else. This caused scout movement to feel very jerky. Instead we put a cap on the fastest possible visual movespeed for a squad.
  • Fixed a bug deep in the bowels of our UI code that was leading to a lot of higher-level bugs with things being positioned incorrectly, etc. The most recent manifestation of this, in the working versions of the pivot build, were un-owned metal desposit spots showing up half off the sidebar.
  • Added a new "Owned by Nobody" section on the ships section of the sidebar, since that's a legitimate fourth category. Golems that nobody controls yet, un-owned metal spots, etc, etc.
    • Also new, the items in this category can be seen on the sidebar if you've ever been to the planet before, even if you don't have vision of the planet right now. This is pretty handy.
  • Engineer and Rebuilder FRD now works (though their prioritization leaves something to be desired)
  • AI planets directly adjacent to a human homeworld no longer seed guardians or sentinels, to match AIWC (AIWC had wormhole guard posts, now known as wormhole sentinels, but their omission is not significant)
  • Guardian counts have generally been significant reduced, and are now proportional to planet mark level as well as number of guard posts
  • A bonus ship type can now be selected for each human faction (currently you have to click "more" to get to this, since the space is already taken by the two color dropdowns and the Ark dropdown)
  • You now start with 10k science, and all weapon turrets (except beam), to parallel AIWC
  • Your command stations will now automatically claim metal spots, to better resemble what happened after capturing a planet in AIWC.
  • Made the planet view cursor code moddable and open source.
  • Constructors can now be set to rally units they build to either an already existing control group or to a point chosen by the player.

Keyboard/Mouse Input Overhaul

  • Previously we were using some middleware called Rewired, which was bulky and inflexible in a variety of ways. It's super useful if you want to handle a bunch of gamepads and in particular if you want to have design-time-defined controls. Our use case was diverging enough that all it added was bloat, though, because we had to write our own runtime-control-definition layer, poll the list of all our controls while it polled all the keys under the hood, and other messy things like that. So Rewired is out.
  • We brought in what started as EasyInput from ootii as replacement middleware, then pared that down to just the keyboard and mouse bits. We then basically rewrote the entire thing so that it's more efficient, uses no dictionary lookups during the game loop, and is compatible with all the things we want it to do for this game. So ultimately we wound up just kind of creating our own.
  • The new input system has a lot of performance benefits, but one of the biggest things it will do is make it easier for us to define all of the keybinds in xml, no matter how many we have. All of the keybinds that were previously hardcoded have now been moved to xml.
    • It was previously somewhat difficult for us to check if something was just pressed, just released, being held, etc, in an efficient and automated way. This is now something that can be directly specified in our xml definitions for the keybinds.
    • We also have a new Custom type of key check, which basically skips the whole Handler reflection-linking process and instead just lets classes elsewhere in the code get an object reference to that key and then check it as needed. This is very useful for modifier keys of any sort, and for all of the camera controls.
  • Work has also been done to prep this for an actual interface for viewing and editing keybinds in game. We'll get that in place prior to Early Access, but for now we have a few other fish to fry.
  • A variety of bugs relating to keys that could be triggered on the main menu that were only supposed to be in-game have been fixed.

Galaxy Map Improvements

  • The galaxy map is now using a purely top-down camera with the ability to pan and zoom but no ability to tilt or rotate the view. There have been a number of valid issues brought up with the existing galaxy map, and we're starting to work through those now. Lots more to come, but here are some of the first bits.
  • Players can now see the entire galaxy map structure -- meaning the actual planets and their wormhole links and lines -- from the start of the game.
    • This is the same data you see in the lobby, so it was always strange that we took it away after the game started in Classic and this game.
    • This does NOT grant you any actual visibility on the planets as to their contents, owners, resources, ships present, or anything else.
      • Aka, this is not a reduction of fog of war, it's just the ability to see the shape of the battlefield, same as you already could in the lobby.
  • Previously, on the galaxy map it would take you into the planet view as soon as you clicked a planet, unless you held Alt. This was not helpful for a variety of reasons, so based on user feedback it now by default just switches which planet is selected but doesn't change the view unless you hold Ctrl.
  • When you are on the galaxy map, it now only shows the name of the planet you are currently viewing unless you hold down the ctrl key. This is a lot more like the first game, and is way less cluttered.
    • In the lobby, it shows the names for all human planets, with their colors on there.
  • You can no longer zoom the galaxy map so far in, you start further zoomed out, and you can zoom out further.
  • On the galaxy map, the visuals for the planet are now 4x larger, making them easier to see at farther zoom ranges. This is essentially the same as making the planets "closer together," so to speak, in its effect on how you view the map.
  • Rather than drawing the literal visual of the planet on the galaxy map, which turned out to be fairly pointless, we now draw icon-like 3D models in place of them.
    • These show the color of the owning party for the planet, if there is one, and they show a different icon for unscouted (ever), regular, and homeworld planets.
    • The regular-planet icons are a bit different for marks 1-5 of regular planets, incidentally (anything over mark v shows the mark 5 graphic for the planet itself). These help give you an indicator of the strength of planets when they are in the hands of the AI.
      • After you capture a planet, it still retains its graphical styling for what mark level it used to be, which is a subtle but cool way of showing your progress in the past.
  • On the galaxy map, the selection ring is now fancier, easier to see from a distance, and it rotates to make it even more obvious where it is.
  • The "king unit" no longer shows up next to home planets on the galaxy map. Instead, now the planet itself is showing up looking different. It's a lot easier to tell what the heck is going on, now!
  • The text on the galaxy map that shows the strength at planets is now a lot more clear, and more useful in general. Before it just showed the amount of threat at any given planet, period.
    • Now it shows a yellow row with a strength icon for any allied + self units that are on that planet (or omits the line if that total is zero).
    • In the same fashion, it shows a purple row for any threat on the planet IF you currently have vision there. Or omits the line if none.
    • And also in that same fashion, again if you have vision there, it shows a red row for the total of hostile strength on that planet that is NOT threat.
    • Now you can actually see what sort of dangers there are to your planets, which planets of yours are outnumbered, and all sorts of other useful things like that!
    • It actually shows the strongest forces (allied or enemy) on the top or bottom. It doesn't sort the threat vs not threat, but moves those as a bloc.
  • Also adjusted the placement of the "lower text" on the galaxy map to be centered right below the planet name, rather than down and to the side. Previously it often looked like the threat counts were located at some other planet instead of the planet they were actually on.

Camera Improvements

  • The camera in the planet view has been something of a bugbear for a little while, because there were a variety of things that could go wrong with it. But even more than that, it was using a TON of keys on the keyboard: WASD and the arrow keys for movement, Q and E for rotation, and R and F for tilt. Time for revisions!
  • One of the new things that was most interesting was the idea of a "tilt and rotate" mode, rather like what happens if you hold the right mouse button in Planet Coaster. We can't really use the right mouse button that way, and the middle mouse button makes more sense as the existing "grab and pan" functionality, so we've defined the mode modifier for that as Q now, or Mouse4 if you have a 4+ button mouse (those are awesome, incidentally).
    • Along with this change, the default bindings for rotation and tilt are simply set to nothing. If you want to bring back the Q and E and R and F the way they were, that ability didn't go away, but we're claiming those keys for other things instead (Q is already the tilt and rotate mode, whereas the others are unbound at the moment).
  • Along with this, zooming out could potentially put you out of bounds previously, if you had the camera tilted sideways a lot. Now when you zoom out, it un-tilts your camera to avoid this happening. Most other games do this same thing; technically it wasn't zooming out before, but just backing up laterally, anyway, if your angle was shallow enough. Now it actually always zooms out.
  • Previously it was possible for sometimes the mouse wheel to give way too much input in one frame, and send you shooting forward. Probably this was happening directly during a long Garbage Collector frame, although we're not sure. We've put in some safeguards to prevent this from happening, although if it is caused by something other than what we guessed then it will still happen and we'll have to add more safeguards elsewhere.
  • There's a new setting for the tilt/rotate mode that lets you set the sensitivity of that.
  • The "free look camera" stuff has all been commented out for now. We could in theory bring that back, but it felt awkward and was not really needed, ultimately. This removal also helps the settings menus be a little less overwhelming when it comes to camera options.

Notifications Bar Added!

  • The wave and CPA warnings are back! Actually, they never were quite in the game in this fashion showing a proper countdown. They show a little icon and number box in the upper left of the screen, which you can hover over for more info.
    • Clicking on them takes you to the planet that is involved, if it's a specific planet.
    • For waves, it shows you the planet it is headed to, and it strength, on the notification badge itself. For CPAs, it just tells you a CPA is coming and when.
    • For these, it has a tooltip for each of them that tells you what a CPA is if you don't know, or what the composition of the incoming wave is if it's a wave.
  • The notification bar now includes entries for planets of yours that are under attack, and shows the total strength counts for those ships that are aggressing and those that are defending.
    • These are color-coded, and whichever is on top is stronger, so you can tell at a glance if you should be winning this fight (on paper; positioning and tactics are important if the numbers are close, of course).
    • The icon for this is different if it's your home planet versus one of your other planets, so this is yet another source of visible warning when your home planet is under attack.
    • As with the wave warnings, you can click these to immediately go to the planet in question.
    • The tooltips for these show the name of the planet that is being attacked, who the attackers are, who the defenders are, what small ships, large ships, non-combatants, and strength each participant has, and what critical infrastructure is located here for the defenders.
      • Big thanks to Eric for designing all of these things (as with almost all of the GUI now, but this in particular is super cool).
  • There is now a general-purpose framework where developers and modders can add items to the notification bar from any faction.
    • This is useful for a variety of things, ranging from alerting you that a trader is visiting a planet and wanting to trade, to telling you marauders are after you, to other things of that nature.
      • Note that we're not using it for any of those purposes yet, but the capability is now there -- and the first proof of concept is actually the planet under attack notices.
  • We now have the concept of critical infrastructure, which are simply items that you get warned about in the tooltip when they are on planets of yours that are under attack.

Visual, Audio, and Workflow Improvements

  • The icons for ships are now just stored once in the game, at a single size, rather than twice at two different sizes. This makes it a lot faster for us to update the icons, and uses a bit less disk space.
  • Added a new visuals_scale_multiplier xml entry for GameEntities that lets us scale up or down entities as we wish for whatever purposes.
    • One of the biggest uses is so that we can have fewer prefabs that we have to initialize and keep in memory for ships that grow in size but nothing else during mark-level changes.
    • This is now in use on the AssaultStarship and the NeedlerGuardian, which are the only two ships re-implemented at this point for which this is relevant.
  • The tractor turrets look so cool that we've made them a bit larger and made it so that there is only one per "squad" on them. They look like they individually mean business as it is.
  • The visuals, icons, and scales for engineers, rebuilders, and human cryogenic pods are all now in place.
    • Note that only engineers and rebuilders are actually in the game yet.
  • Adjusted gimbal_base_scale from 2 to 2.5 in GameData/Configuration/ExternalVisualConstants/CMP_VisualConstants.xml so that the gimbal icons aren't so darn tiny. This seems to feel more like AIWC, now.
  • Human scouts and AI tachyon sentinels now have their graphics in place.
  • Added a new y_offset_of_ship_in_formation xml tag, which allows us to raise and lower ships from a squad as a group. This is useful for really tall structures, for instance.
  • Added the visuals for all of the command stations (AI, basic human, economic, logistical, military, warp jammer, human home, human home core).
    • This was quite a task to pull off in a satisfying yet recognizable way, but we finally have it. Basically these needed to be larger and more epic, yet stand out and not have too many polygons, etc.
  • All of the icons for the new command stations and such are now in place, and the icons for command stations show larger than other icons on the planet. The icons for the king units now show even larger. There are also different icons for each type of command station, in such a way that you can easily tell something is a command station, but also that it is some other kind of command station beyond the basic sort.
  • The voice_group xml tag that specifies what voice is used for ships is now required. For non-human-controllable ships, just using Silent is preferred, although it doesn't really matter since these voices only happen when a human player gives orders to the ship in question.
    • Previously these were partly defined on the weapon types, but this was far too broad a way of doing it (and had stopped working on our internal versions as part of the Pivot anyhow).
  • Visuals have been created for the energy collector, matter converter, science lab 1 and 2 (though only mk1 is in the game), raid starships mk1-4, metal harvester (and empty version), tractor guardians mk1-5, scout starships mk1-4, home human settlements, and hackers (though hackers are not in the game yet).
  • The visuals for the colony ship are now in place.
  • There are a lot more Arcen-based header menus in unity now for us to speed up repetitive tasks. Also ones for opening folders, and in general letting us work faster and with fewer clicks to get things done.
  • The icon definitions no longer need a _border entry in xml. They still need the actual files, but the game can find them just based off the original icon entry. Yay less typing and chances for typos.
  • Wormhole scaling-up has been removed, and will be replaced by a far-zoom icon like ships/squads get.
  • "GenericObjects" can now have a list of AlternativeMaterials specified.
    • This is used for the wormholes in particular so that they can change colors and cubemaps in order to represent different things, or even being hovered.
      • On the wormholes, if you look into them, you'll see a distorted view of actual images from the ESA/Hubble, used with attribution. It's a neat little detail, and you have to get extremely close in to see it.
  • The wormhole visuals have been completely redone AGAIN, probably for the last time this time. We're using something called Scingularity, heavily modified for our purposes.
    • The wormholes are drawn using a single untextured quad, which then does a ton of math and uses a cubemap for the center of the singularity, and then a pixel shader to do the outer swirl. Because of this, it looks fantastic at any zoom level. And amazingly, it performs well. You don't need any special hardware.
    • In our case, we're using those EA/Hubble images noted above for the center of the wormholes, and then different normal maps for swirl patterns on each color of wormhole, and different colorizations on the wormhole swirls to indicate different things.
    • Greenish ones go to enemy planets, darker blue ones go to your planets, lighter blue ones go to allied planets, red/orange ones have a wave incoming, pale green ones go to allied or neutral NPC factions, and white goes to unowned planets.
    • When you are hovering over the wormhole -- which requires you to be holding ctrl down, incidentally, so that you can send either the camea or units through it -- then it glows at a much brighter temperature. Makes it far easier to know if you're actually hovering over it.
  • At long last, your choice of colors in the profile menu actually means something! Whatever you select on your profile for your body and trim colors are now used next time you go into the lobby.
    • The lobby is still the outdated style with the dropdown for colors, but now it has two colors there for your choosing, too. Using it that way is not ideal, but we'll get to that in the next few weeks.
    • For now, it's a very happy thing that we finally have two-color player colors in the game!
      • For each place text is using the colors, it just uses the body color right now.
      • There are presently be some issues with the icons in the main not matching the colors exactly, which is probably due to color-correction post-processing. We're going to be shifting those icons into the GUI camera soon anyhow, so that should solve that when we do. Until then, everything looks washed out in the main icon view.
      • When it comes to showing that a unit is hovered-over, it now goes darker or lighter depending on whether its average color is greater than or less than half brightness; this is instead of the
      • When it comes to showing that a unit is selected, it now adds a border around the mark level icon itself, and brightens the border of the unit color.
    • As an aside, when you change the colors and hit OK in the color picker in the player profile screen, it writes to the underlying log what the color selections are called. You can then use this in xml defaults if you're doing modding. Otherwise this doesn't affect you.
    • For all of the special factions, AI factions and subfactions, humans, and so forth, there are now default colors! With the two-tone colors we were able to do a lot more theming and nuance.
      • Player colors are going to need to include some defaults for people to choose from, since it can be time-consuming to do so otherwise and you don't know if you're potentially selecting something similar to another faction's defaults. Providing some quick-pick attractive defaults is on our list prior to EA; we already have 8 sets of colors, but the interface isn't updated for that yet.
  • The icons for all ships have been improved, with more darkness and light on them, and more layers of borders and sub-borders, to make things really have contrast and stand out so that they are more legible.
  • Put in a fix to our spritesheet for the ship icons so that now there is substantially more padding in them, fixing some bleed-over between sprites (causing line artifacts, etc) at smaller mipmap levels (when an icon is shrunk a lot).
  • The game finally has "burning and dying" effects on the ship icons as they are killed. Thanks to Badger for continuously pushing for this, as well as for implementing the timing code portion of this. This really helps make the battles both more dramatic from the far zoom view, as well as frankly clearer what is going on.
    • We implemented this in completely open-source code between the C# and shader bits, so it can be tuned by other folks if desired. We though about using a ramp texture, but wound up going with a series of lerps between vector4s instead.
  • The font for the mark level numbers has been changed again, and looks much better now.
  • On the sidebar, the strength number is now shown abbreviated instead of written all the way out -- we're trying to standardize on that everywhere, as it's the easiest to read.
    • This also now applies to the resource bar at the top of the screen.
  • Fixed a variety of places that were incorrectly using the strength per subsquad instead of the strength per squad -- including in some of the targeting logic for ships.
  • Fixed a bug with the ships tab of the sidebar where it was including the strength of noncombatants in the total strength for the planet, which was not remotely useful. Now it just shows the strength of combatants, like everywhere else, which gives you a much more valid picture of the battlefield. Defensive strength of noncombatants is kind of incidental to that.
  • At a few places in the game, we were showing "Human Remnant" as the faction name instead the name of the player in question. Now we show the player name.

Version 0.743 Music Blooms

(Released May 2nd, 2018)

  • The second half of the AI War 2 soundtrack is now in place! These pieces, as specified in the kickstarter, are all remixed/remastered versions of tracks from AI War Classic. In there we have the Defeat and Victory tracks from the first game, Nomad Sunrise from DoW, Intro and Midnight from the base game, Night Light from LOTS, Rising Up from VOTM, and Voyage to Zenith from TZR.
    • With this, we're now also distributing the full soundtrack (plus a variety of bonuses!) to all those backers who signed up for it. You should have an email with that link, and/or be able to see it in your backerkit profile page: https://aiwar2.backerkit.com/
  • The game now actually plays defeat music when you lose.
  • When you win, the game first plays the For The Fallen vocal track, and then goes into the from-Classic Victory track, then goes on to play regular music from the in-game rotation.
    • When you lose, the game plays the defeat track, then also goes back to the regular in-game rotation.
    • These two changes are aimed at people who want to keep playing after a victory or loss, which are a not-insubstantial number of people.
    • We actually have not tested this bit at all, so, uh, if it doesn't work properly like this then please do let us know and give us a savegame. We're kinda busy on a lot of fronts right now! Normally we unit-test things, though.
  • We're now internally using the Asset Bundle Browser to help us find trouble spots with overlarge pieces of data in our asset bundles that we're building for the game. This helps with load speed, runtime efficiency, and asset bundle build speed.
  • Slightly improved the efficiency/size of the effects asset bundle.
  • Reworked the bloom effects to use the Natural Amplify Bloom effect rather than the Realistic one. This, plus a couple of other tweaks in that area, lead to something that still has bloom, but is a lot more subtle than before. Some folks were complaining about that with the teaser trailer, and we can see their point.

Version 0.742 Hotfix

(Released May 1st, 2018)

  • Fixed a bug where the total seconds to load was only being reported in output.log, and not in the ArcenDebugLog.
  • On the main menu, it now shows how long it took to load the game, and you can hover over that to get details if you want. The "logged in as Steam user" info is right below that, and both are a bit smaller now.
  • The loading feedback on the sound effect items and graphics items are now more coarse, leading to faster overall loading times compared to the last internal versions.
  • The method for tracking how much time has passed has been adjusted to use DateTime.Now instead of the Stopwatch class, since we had some questions about accuracy.

Version 0.742 Darkly Loading Spire

(Released May 1st, 2018)

  • Rather than looking like the application is hung when it starts, the game now shows the loading progress in the form of what it's doing at the bottom. It doesn't show a loading bar, but it does show a counter of how long has elapsed, and how long specific long-running bits are taking.
    • This is useful both for us to know in terms of telling when something is overly slow to load, and it also gives players something to look at and a cue that there's not just a frozen application in front of them.
  • Surprisingly, the sound effects loading is taking twice as long as the loading of the graphical data right now (9.6s versus 4.4s on Chris's machine), so this is already an example of where we can optimize our loading speeds a bit, which saves everybody a lot of grief and saves the devs here time staring at the screen when it's time to test each item.
  • Additionally, now if the game has an error during load, it won't show a mishmash of all the gui windows all overlapping themselves in an insane and obviously-glitchy way. There is no functional difference between before and now, but it seems a lot less terrifying now if you're seeing it for the first time.
  • The loading log for how the game starts up is now more informative than ever, and on the long-running sections it actually shows a progress count rather than just hanging on those sub-parts. Sometimes those sub-parts can take 30 seconds or more on first run (though usually 4 seconds or so on subsequent runs), so having this feedback is pretty vital to this not feeling like maybe it locked up.
  • The alpha channel has been removed from a ton of images that didn't need it, letting the compression format be smaller on disk, in RAM, and in VRAM, as well as loading faster. This will definitely be kept, as it was useless data.
  • The max texture size for some of the non-diffuse texture channels for the ships are now cut way down from what they were before, to reflect the distances you typically see these from. This saves 300MB of RAM, disk space, and also lowers the VRAM requirements and makes rendering faster. It also makes loading vastly faster. This is definitely a quality/compression tradeoff, and we do still have the originals, so we may wind up making this an option or something in the future if it seems ugly to folks this new way. At a fairly casual glance by those who worked on the ship graphics, we can't really tell the difference, though; in side-by-side shots you would notice it, but that's about it unless we are mistaken.
  • The compression style for weapons effects and other sound effects has been changed to ADPCM instead of Vorbis, and these are now set to load on a background thread rather than the main thread. This makes loading vastly faster for the sound effects, although it does use something like 20MB of extra disk space. The amount of space used in RAM is identical, since we always decompress on load, anyway.
  • The voice acting clips are now set to stream in like the music does, as well as load on a background thread, rather than being preloaded or decompressed early. This actually saves quite a bit of RAM, and doesn't affect disk space, and saves an enormous amount of loading time. The downside is that it can cause a sub-second delay in playback of voice clips, but given the nature of a voice clip that is both imperceptible and irrelevant.
    • Different types of sounds have different characteristics and need different settings, and we've optimized these, in short.
  • Speaking of optimization, we're no longer doing full error-checks on load for each ship visual that is loaded in. That was time-consuming and pointless. In the ship designer windows it shows errors, and if someone commits a ship with errors that's something that is a goof on their part and not something we need every player machine checking for every time the game starts. So that saves another batch of time.
  • We're also doing another experimental thing, where with the solomesh ships we're directly using the asset bundle copies of the ships to get their meshes and materials, rather than instantiating a copy first.
    • Generally this is not advised, since it can cause a bunch of extra disk reads and other general slowness when accessing that data. However, in this particular case, since we're not actually accessing anything more than the data on these objects (we're not making copies of the object), we think it's not hitting the disk like that. We don't see any evidence of it in the profiler now, anyway, and we were in the past.
    • This speeds things up yet again, and so far so good on that front, but we may have to back this one out later.
  • Overall the loading speed of the game has more than doubled, in typical test cases thus far, and it actually is responsive while loading as well, which is an important first impression piece.
  • Fix a bug where the Nanocaust was never losing influence over a planet even after the constructor was destroyed
    • Thanks to OvalCircle for reporting
  • Change the default colour of the Risk Analyzers
  • When the Human Marauders put Marauder Outposts on a planet, give them Influence over the planet (so it will be shown on the Galaxy map)
  • Initial commit of Dark Spire. Like in AIWC, it spawns ships based on energy it gains when ships die on a planet with a Vengeance Generator (VG).
    • Energy is tracked per VG. When VG energy > threshold it either shares energy with the VG with lowest energy or it spawns ships to attack. There's a Conversion Ratio when turning energy into ships; it starts out not very efficient (maybe 50% of the energy becomes ships), but every time a VG spawns new ships it becomes more efficient.
    • AI Overlords start with a Dark Spire Ward structure on their planets which prevents Dark Spire ships from going there. If a player destroys the Ward then the Dark Spire will be able to attack the AI overlord, thus giving you a new win condition.
    • Every so often the Dark Spire will attempt to spawn a Vengeance Generator Locus. The Locus will transform into a full Vengeance Generator in 5 minutes. If you don't kill the Locus in that time period then it turns into a Vengeance Generator. Planets are eligible for a Locus to spawn if they have no Human or AI ships on them, and they are adjacent to a Vengeance Generator without any human or AI ships on it.

Version 0.741 Music Part 1 Of 2

(Released April 29th, 2018)

  • The first half of the new tracks for the AI War 2 soundtrack are now in place: Abandoned Ship, Absolute Zero, Bouncing Lights, Event Horizon, Light Year, and Supercluster.
    • All by Pablo Vega, mastered by Dio, and all fantastic.
  • Update to Human Marauders behaviour. If they destroy all your forces on a planet then they will begin to construct Marauder Outposts which will spawn Marauder new units. This will make it harder to recapture planets. Every so often a new MarauderOutpost will be added, and existing MarauderOutposts will upgrade themselves to make stronger units. Note also that when the Marauders capture a planet they get a permanent boost to their MaxBudget, making them more dangerous.
    • If you allow the Marauders to get Mark 3 outposts then they will start getting Budget faster.
    • The balance levers are in XML for ease of use
  • The default game volume is now quieter in the hope of not deafening new players
    • Thanks to Flavin for the report
  • Improved the performance of music loading at the start of the game and during the game.
  • Fixed a regression in the prior version of the game where the first time any camera loaded a "traditional skybox" type of background, it would be solid black instead.
  • Fixed an issue where the construction part of the sidebar could show some stale data when switching from a planet with a builder to one without a builder.
    • Thanks to hawk for reporting.
  • Fixed a bug that nobody had reported yet with lightning attacks being very strange-looking and not like lightning bolts anymore.
  • Fixed a bug with the various type of geometry-based explosions (flak, lightning, etc) so that they now render additively in the transparent queue rather than the overlay queue, and so that they read from the zbuffer but no longer write to it.
    • This changes the effects a fair bit so that they no longer do things like eat into one another or the ship icons around them.
    • These will need further tuning to not be over-bright in huge battles, and they're on our list for further improvements visually anyway, but for now it's a good enough start.
  • Risk Analyzers: code tidying, also track the total and net AIP generated by Risk Analyzers. Eventually this is going to turn into 'When X AIP is generated by Risk Analyzers, do something unpleasant to the player', probably an exo wave, once exo waves are added
  • Map Types: Add a new planet placement mechanism for Simple and Realistic, and tweak one of the previous placement algorithms for Simple and Realistic
  • Fix some bugs with Marauders, where outposts weren't upgrading properly.

Version 0.740 Clean Up That Nebula, Young Man!

(Released April 26th, 2018)

  • Fix some dumb bugs in the HumanMarauders faction that was preventing the marauders from correctly analyzing your planets to see which they should attack
    • Thanks to OvalCircle for reporting
  • Fixed a bug where the Vis layer was not correctly setting the Shot location when we tabbed into a planet with the shot in flight; it was assuming the shots should be at the middle of the planet, which is manifestly incorrect
    • Thanks to OvalCircle for reporting
  • Fix a bug where where if a non-Nanocaust faction killed a unit that had taken Nanocaust damage, the killing faction would get the new zombie ship instead of the Nanocaust.
    • Thanks to OvalCircle for reporting
  • A new and frightening visual look for Usurpers has been added. These will be absent for a while until we get past the "Fun point" once Keith gets his first wave in place, but then we expect these to come back pretty darn fast, so we want them to look nice and scary). (These are the AI ships that recapture planets)
  • The infrequently-changed space backgrounds, and planet graphics, have all been moved into a new internal AIW2Scenery unity project, which saves us a _ton_ of time when actually building the gui asset bundles, or ship asset bundles, for the game.
  • The sound effects and voice acting files have all been moved out of the platform-specific projects, and out of the modding and gui project in general.
    • These are now in the GlobalBundles folder, which saves some disk space if you've got multiple OSes of the game installed at once. It also saves us time when pushing new versions of the game, and has less of a footprint on the system for everybody thanks to the modding unity project now being much smaller without all those files.
    • This does make some of the sound stuff a bit harder to mod, but we'll just throw that stuff up on github or google drive or something when the time comes. It's not worth inconveniencing everyone over putting it directly in the build.
  • There were a variety of old "space boxes" that were from back in the kickstarter days that were just... underwhelming. They were nicely colorful, but had kind of gross large stars in them, and in some cases just junky colors in general. These have either had their gross big stars patched out, or they've been removed.
    • Overall these have mostly been removed except for the best couple of them (which now have color variants!).
    • This saves about 200mb of RAM for something that wasn't looking so hot in general, and makes the game load faster, too.
  • Our middle-style "nebula sphere" type of backgrounds previously had a really bad problem with distortion on the starfields. This was just embarrassing, and led to some perfectly-fine spaceboxes looking really gross depending on the angle of view, instead. These have all been fixed up with a revised shader for handling those starfields as simple tiling rather than triplanar reading.
  • Our most recent, and best-lookg style of space backgrounds, which are based on traditional skyboxes, were absolutely HUGE, taking up more than 450mb on disk, and in RAM. Each one was 12MB of VRAM to render, as well, although that's unavoidable to keep the starfields crisp using a non-tiling cubemap like that.
    • We've now split these out so that the stars themselves are in a separate cubemap which is the larger size, and then the nebula parts are able to be a quarter of the size (half the side length) without any drop in quality. This adds 3MB of VRAM usage per draw (of which there is exactly one per frame), but saves over 300mb of disk space and system RAM during runtime, as well as making the game, once again, load faster.
  • 49 new space backgrounds have been added, based on 8 source cubemaps, to replace the ones that were taken away (though this actually adds back more than were taken).
    • The new skyboxes are way higher quality than the ones that were removed, is the main point, anyhow.
  • The starfield backgrounds on the galaxy map are now much more neutral, with mostly black and a little bit of white. Easier to see foreground objects on them, now.
  • Fixed a bug where once you viewed an old-style spacebox background, it wasn't letting you view any "traditional skybox" backgrounds, which explained the over-prevalence of the former.
  • The settings option for "background style" has been removed, as that's no longer really relevant to anything.

Prior Release Notes

AI War 2: Final Pre-Beta Checks