AI War 2:Earlier Than Early Alpha

From Arcen Wiki
Jump to navigation Jump to search

Next Release Notes

AI War 2: Making Alpha Fun

Version 0.300 Welcome Early Access Kickstarter Backers!

(Released May 29th, 2017)

New Graphics

  • The Usurper now has visuals for it (all five marks, although only one mark is actually used in the game right now).
  • The Spider Turrets, Lightning Turrets, Beam Cannons, Sniper Turrets, and Focused Gravity Generator now have real graphics.
  • Yet another version of the wormhole has been added, this time completely shader-based with no physical rotation component. This is something that we still need to work on, though, because it just STILL doesn't look good enough.
  • Design template server now has its proper graphics.
  • The various types of warheads now have their proper graphics.
    • Same with the silos for them.
  • Fixed the stealth starships having no graphics on them past mark 1.
    • Also sniper starships and assault starships.
  • Fixed the shield starships using the laser guardian graphics.
    • Thanks to BadgerBadger for reporting.
  • The various warheads now have their proper icons and flairs.
    • Same with implosion drones.
  • Rather than using solid objects visually as projectiles, we're now using trail renderers. This gives much smoother visual updates regardless of how many shots are on the screen, since their stretching is framerate-independent.
    • We may switch to using some other similar system if we think we can get it to look as good, but for now this is the best-performing and by far best-looking thing we've got.
  • Some updated buttons and fonts for the game. (Much) more work still needed on them, but it's starting to feel a bit more thematic.

New Nebula Backdrops System

  • The game now uses a completely different space background creation process.
    • This is something that we created ourselves from the ground up, based on what we learned using the systems of other people and then expanding (greatly) upon that, so consqeuently we are able to make this open source and something that players can actually make their own variants with.
    • We've completely replaced all of the existing space boxes, although we don't have quite as much variety in the new ones just because we haven't had a chance to create them just yet.
    • We'll also do a video in the next couple of days showing how to author these, since it's not a super-duper simple thing.
    • These spaceboxes are, on average, much darker than the old ones. With the lower amount of contrast and backlighting, it should be easier to see the hud and ships coming up, and lead to less eyestrain. But frankly the system can be configured in any manner to have bright, dark, middling, or whatever backdrops.
      • Thanks in particular to Cyborg and BadgerBadger for pushing the over-brightness issue.
    • Older savegames automatically upgrade to randomly assign new backdrops. They'll do that at random every time you load the savegame until it is saved again in the new version.

Performance Optimizations

  • The great "performance slaughter," as Keith called it, is complete. Basically a massive performance gain in the simulation side of the game when a lot of battle is happening.
    • This is an absolutely massive upgrade, the scale of which can't really be overstated. Further bottlenecks are on the visual side at the moment.
  • Improved the warming/prototype-loading process for all the various kinds of objects in the game, to keep from having jitters as much when new objects have to be cloned into existence for visual purposes.
  • Chris created a specialized new SwizzleList data structure, which is highly specialized for dealing with list of objects that need to be iterated rapidly and also have arbitrary additions and removals at any point in them.
    • There really wasn't a general-purpose list for this sort of thing, and one of the sacrifices this makes is the inability to garbage-collect anything you ever put into the list (or at least it's unlikely to garbage collect). So this is really the most useful for cases when you are pairing this with a pool of reused objects.
    • The other limitation put in on this was having a fixed maximum count of objects, but it can be absurdly high without issues on a modern computer for big pools where this would even be needed.
  • The SwizzleList is now used for our list of active visual shots in a scene, with a maximum cap of half a million shots. That many shots would kill the scene in many other ways, performance-wise, so this is not a big limitation. And it could easily be increased later if needed.
    • This change leads to the following results:
      • Regular List<> samples:
        • 0.57ms baseline with 3171 shots active, 47ms spikes every few seconds with certain Remove() calls (mostly those earlier in the list).
        • 0.60ms baseline with 2860 shots active, 89.51ms spikes on occasion.
        • 0.58ms baseline with 3008 shots active, 10ms spikes sometimes multiple times per second in addition to the larger spikes.
    • Translation: owwwwww.
    • New SwizzleList<> samples:
      • First of all there, are no spikes at all, as there's a constant cost to removal and addition. So the only thing to measure is a baseline.
      • 0.63ms baseline at 3301 shots active. So we've lost a tad of performance on the baseline, but it's only about 30 NANOseconds difference in exchange for no spikes.
      • 1.38ms baseline at 6184 shots active. So we see that the cost of the baseline scales pretty linearly, with minor fluctuations, which is really good to see.
  • Fixed a variety of cases where the recent profiling additions were leading to some string concatenations even when the profiler was off. Oops.
  • Fixed a teeny tiny little typo that was causing huge performance degradation for creation of pooled objects in general, as well as a memory leak every time an object was pulled from the pool.
    • Thanks to BadgerBadger for reporting the leak.
  • Made a variety of internal changes to have ship, shot, squad, and so forth movement more efficient.
  • There are now settings options that let individual players throttle the update rates for shots and shot removal checks. These things have no effect on gameplay, so it's something that can be tuned per-computer as needed, and of course increased with time as computer technology continues to mature and/or unity performance improves in future versions. This is a CPU-side issue.
  • Thanks to Keith's wonderful system of having balance stuff all determined relative to one another, we were able to adjust two central multipliers to affect the following changes:
    • Ships now fire on average half as many shots.
    • Shots now move 3x faster than before.
    • Result: battles still feel extremely active, but now we're usually having something like 1.3k shots in a situation where we might have 4k to 6k shots before. The travel time aspect of this really cuts down on the number of shots that are just in transit in the air as a battle heats up. This also makes the shots feel a lot more active and threatening. Overall effect on balance should be zero.
    • Yes this is somewhat "cheating" in terms of performance improvements. But we basically want to have it so that we're not getting into performance-issues territory anywhere close to our current test cases.
  • Fixed a bug where weapon systems with multiple-shot salvos were firing salvos much more rapidly than the balance model intended.
    • The erroneous formula was:
      • SecondsPerSalvo = Constants.SecondsPerShot / system.RateOfFireMultiplier
    • The corrected formula is:
      • SecondsPerSalvo = ( Constants.SecondsPerShot * system.ShotsPerSalvo ) / system.RateOfFireMultiplier
    • Where system.RateOfFireMultiplier is, for example, 1 for normal needlers like a fighter's, 4 for fusion rockets like an MLRS's, and 0.125 for fusion bombs like a bomber's
    • The upshot (no pun intended) is that MLRS units (which have 16 shots per salvo) now actually fire "salvos" of rockets instead of being "rocket hoses".

Coming Soon: Post-Processing Visual Stack Upgrades

  • NOTE!! The below statements are now all outdated, but we'll leave them for now. We're pretty sure we can get an excellent HDR visual style going now, but we didn't have time to do it this version. We needed to have the nebula backgrounds stable in their styling before we could fully start redoing the emission values and tonemapping and all that. So these are something that will be next version, and until then the backgrounds probably look a bit drab compared to what they will. But we need a certain level of non-saturation to differentiate them from the ships pre-tonemapping.
  • Did quite a bit of experimenting with our post-processing stack to see if we could make it any more efficient or any higher-quality. Short answer: not at this time.
    • Now that MSAA works in conjunction with HDR (thanks to recent Unity updates), we looked into using HDR cameras. Normally we'd be doing this already, and we already use the linear color space. But we wanted MSAA, and so on this game chose not to do HDR.
      • The resulting visual effects and shaders that we've built up actually somewhat simulate HDR-like effects in an LDR color range, most notably because we're really abusing the concept of "PBR lighting" in our highly-exaggerated shaders.
      • What this winds up meaning is that any sort of switch to HDR causes any sort of bloom effect to absolutely blow out the lighting, and in general we have such delicate little emissive lights all over the place we have temporal flickering issues with most styles of bloom to begin with.
        • Our usage of Amplify Bloom is already really highly tuned to use only 4 mips and specific weights that really play well with their temporal stabilization without having such a high value that we run into any ghosting. No amount of experimenting with other pipelines has yielded anything remotely so good for this specific use case.
    • In general this is a bit of an unusual use case in general, because we have a lot of highly emissive and specular objects of wildly varying size under a single directional light at really extreme range variances. Traditional PBR approaches really aren't designed to handle that well, because typically objects past a certain distance simply stop doing so much emission, etc.
    • So the long answer is that we've already optimized the heck out of this, and we've got a super-specific workflow that goes all the way into our custom shaders and then comes out into how our post-processing pipeline is set up. We're able to achieve an HDR-like look in an LDR camera flow (since we had no choice at first), and we're able to achieve stable bloom on very detailed and distant objects. Despite Chris continually wanting to "be a little more normal" with the post processing stack he made, now that HDR MSAA is available, there's just not a way to do that. Not using an HDR camera feels kind of dirty for some reason, but in the end we get to the same place in a more efficient way that also achieves a unique look. :)

Misc

  • Upgraded Amplify Shader Editor to the new version v0.7.2.006, which includes direct support for HSV to RGB nodes (and vice-versa), as well as better custom expressions.
    • Yay saving time having to manually edit our HSV shaders!
  • Our existing sprite HSV shaders have been updated to use the new Amplify Shader Editor conversion nodes rather than our manually-handled shader code. The result is great!
  • The squad formations have been moved into the AIW2ModdingAndGUI project, thus making them a lot easier to mod. They are also now in their own asset bundle called aiw2squads.
    • Also fixed up an issue with a number of the larger existing ones where scales were being handled at the wrong level of the transform hierarchy, leading to some of the ships overlapping one another in an unfortunate fashion.
    • We may solict player help in setting up a variety of squad designs that people like. These simply consist of arranging some cubes relative to one another, so it's easy enough from a technical standpoint -- it's mainly about creativity and taking the time to make sure it looks good.
  • Fixed a bug where the "starved metal flow line" was rendering as pink. Went ahead and improved the visuals of it while we were at it.
  • Improved the handling of the intra-salvo delays for weapons firing from squads of multiple ships and/or multiple shots coming from an individual ship. Previously if a shot's delay "expired" during any of the fairly-coarse sim-frames it would get the full movement rate for that frame. Now it gets a prorated amount based on how much of the frame was "spent waiting" for the delay to elapse. This allows for tighter, more coherent salvos without the shots "clumping" as much in odd ways.
  • Fixed up a lot of the objects that we load from external sources so that their correctness-checks now happen on application start (and are thus easier to find) instead of happening the first time they are encountered in the game.

Version 0.201 Bugfixes and Optimizations

(Released May 19th, 2017)

  • Reworked a ton of our instrumentation for profiling, so that we can get a much better picture of what exactly is costing us in performance on the CPU side without the instrumentation itself (ala deep profiling) throwing off the results so much on long stack traces.
  • Improved the performance a slight bit on the movement of squads in the visual layer.
  • Upgraded Unity from version 5.6.0p2 to 5.6.1p1.
    • This improves the performance of the particle systems, fixes a GUI memory leak, and has a variety of other fixes.
  • Troop Accelerators, Black Hole Machines, Raid Engines, Alarm Posts, Planetary Cloakers, Attrition Emitters, Magnifiers, and Super Terminals now all show icons on the galaxy map view, to be more consistent with other entities of their types.
    • Thanks to BadgerBadger for reporting.
  • Apparently it was possible for ships to lose engine health without even having engine health, and then they would start showing up as not having any engine health.
    • Fixed the display issue, although the issue of engine health going down when no max engine health is untouched. Not really sure from the code how that could possibly happen.
    • Thanks to BadgerBadger for reporting.
  • We never could exactly replicate the issue, but there were definitely circumstances in which players were seeing ships being the wrong color at various times (theirs and enemies). The code for this has been heavily reworked, and _should_ work fine now. But if anyone sees it again, please do let us know!
    • Thanks to BadgerBadger and RabidSanity for reporting.
  • Fixed a caching issue with the galaxy map where ownership of various entities (like ARS units) was not being reflected on the map until you quit and restarted the game (but was showing properly in the planet view).
    • Thanks to BadgerBadger for reporting.
  • Fixed a regression in the prior build that was causing planet names to never appear on the galaxy map.
    • Thanks to BadgerBadger for reporting.
  • Put in some extra logic that more efficiently detects when a squad is at full health.
  • Fixed a regression from the prior version where health bars were not disappearing when squads were at full health if the health had ever been lower than full on the gimbal in question (not that squad specifically for sure). At any rate, it works now. ;)
    • Thanks to BadgerBadger for reporting.
  • Fixed a couple of issues relating to testing if the player is in the "test chamber" that could cause exceptions if there was difficulty parsing the map type out of the savegame (but otherwise things were fine in the savegame).
    • This also makes things a tad more efficient in that area.
  • At least temporarily, but we'll see about long-term, the flame-trail contrails have been disabled for ships. This causes a 30fps jump in speed from 60 to 90fps in a 5000-ship scene, and as ships move the benefit gets much larger.
    • It's possible that some nesting issues with transforms are what are causing the issues, and so we might be able to get them working more efficiently that way. It's also possible that we might be able to do a more GPU-centric type of trail generation, or have these simply throttle by distance. We'll see what makes the most sense within our time budget. For now they're simply off.

Version 0.200 Decisive Battle

(Released May 18th, 2017)

New Ships: Batch 5 of 7

  • Warheads:
    • The Ark starts with a certain number of certain types of these, and can get more by hacking AI Missile Silos (which destroys the silo and gives you more warheads).
    • An important change from AIWC is that these don't cost AIP to use. Instead they're simply a limited resource, with a starting stockpile you're expected to use (at some point) and others you can obtain in exchange for hacking points.
    • You launch these from a menu under Commands, similar to the Hacking menu. The Ark has to be present, obviously, but the warhead can move independently after launch, even through wormholes.
    • Nuclear
      • Triggers on death. Hits everything on the planet, including friendlies and resource spots. Things which normally revert-to-neutral on death just permanently die (except Controllers). Nothing is immune, though some things like the Ark have an extremely high resistance. Does a finite, but extremely high amount of damage spread across all targets. It's possible to have enough stuff on the planet that not all of it dies, and the Ark can generally survive if it's got full hull health when the blast hits.
    • EMP Warhead
      • Triggers on death. Hits everything on the planet, stripping away all shields and doing some damage to all targets. Most significantly, it applies a huge amount of paralysis damage to all targets. Paralyzed targets eventually recover, but not if some other fleet comes through and arranges an accident.
    • Lightning Warhead
      • Basically a nuke except:
        • 1/100th as much total yield.
        • Only hits a limited area (similar to the Ark's full shield radius).
        • Only hits hostile targets.
  • AI Structures:
    • Warhead Silos
      • Seeded randomly kind of like Data Centers. But instead of destroying to decrease AIP, you hack these to increase your warhead stockpile. E.g. a Nuclear Warhead Silo gives you one "destroy pretty much everything in sight for free" card.
    • Magnifier
      • Seeded like Black Hole Machines, etc. Doubles attack power of all allied (i.e. AI) units on planet.
    • Super Terminal
      • Similar to how it was in AIWC (one in the galaxy, can hack it to steadily reduce AIP in exchange for steadily more insane responses), though the responses are much simpler until later implementation. Also, it explodes at 200 AIP reduction from the hack, but realistically you shouldn't be able to survive that long anyway.
      • Related: AIP Floor is now simply the initial AIP at the start of the game, rather than total / 5.
    • Ion Cannon
      • Seeded randomly like Black Hole Machines, etc. Similar to AIWC (insta-kills lower-mark stuff), but instead of just one-shot-killing stuff it instead gets x10 damage for each mark it has over the target's mark. So x10 for hitting something one mark lower, x100 for something two marks lower, etc.
      • Unlike AIWC, stuff is not made immune by simple size (though stuff that is "markless" takes no extra damage from Ion), but starships and guardians are effectively two marks higher for the purposes of resisting the ion bonus.
    • Orbital Mass Driver
      • Seeds like Ion Cannons, etc. Similar to AIWC, but instead of "what ships can this shoot at?" being set per-type, now it can only shoot at types where an individual unit is at least 5% of a cap. That could be a normal-strength type with a ship-cap of 20 (or less) or it could be a higher-cap unit that's intentionally balanced as more powerful than normal types.
    • Warhead Suppressors
      • Unlike AIWC's Warhead Interceptors, these don't try to shoot down warheads, instead they reduce the output of any detonated warheads by 50%, stacking. So 2 or more suppressors mean warheads do no damage on that planet. The AI homeworld has 4 suppressors and each Mk4+ planet has 2. Supressors can be destroyed normally, so basically this just means you have to do some kind of raid first before you can nuke it from orbit.
  • Dire Guardians:
    • Dire Implosion Guardian
      • Uses Implosion weaponry (similar to AIWC, but multiplied by target "strength" instead of target HP) and spawning drones which use shorter-range versions of the same.
    • Dire Heavy Beam Guardian
    • Dire Widow Guardian
      • This and the non-dire version are just big engine-wrecking things right now; mobile tractors are for later.
    • Dire Magnifier Guardian
      • Like the structure of the same name, doubles attack power of its allies on the planet.
  • Guardians:
    • EMP Guardian
      • Periodically emits blasts like an EMP warhead would, except weaker (and obviously not-destroying-itself).
    • Self-Destruction Guardian
      • A lot like a Lightning Warhead.

Graphics And Performance Updates

System Requirements Change!

  • Support for DirectX9 on windows, and Metal on OSX, have both been removed.
    • Neither of these platforms support GPU instancing, and if we want to have lots of ships doing lots of things at once we need those instancing capabilities.
    • This will also raise the minimum system requirements to OpenGL 4.1 (or DirectX11) for all platforms.
      • This is something that really lets us make VASTLY more efficient use of the hardware you almost certainly already have. There are a few cases where someone might now be unable to run the game, and we can do refunds if needed in those cases.
        • However, based on hardware surveys that's probably a vanishingly small number of people that actually play our games. The Steam hardware survey in general reports 87% of all steam users have DX11 capable hardware, which is automatically also capable of OpenGL 4.1 (their feature sets are equivalent).
        • Yes, potentially more people have played our games historically because of very low system requirements, but we're actually a bit more forgiving (in terms of age of valid hardware) with the launch of AI War 2 in 2017 compared to the launch of AI War Classic in 2009.
      • Basically hardware support for this means: Nvidia GeForce 400 series and newer, AMD Radeon HD 5000 Series and newer, Intel HD Graphics in Intel Ivy Bridge processors and newer.
      • That in turn means that your system needs to date from roughly 2010 or 2011 at the oldest. There's a solid chance that stuff that old or older would not handle the AI well anyway, so the people we're excluding are probably dropping even further.
      • Finally it's worth noting that while we are targeting systems that are 6-7 years old at most as of 2017, this will let us do a much better job of future-proofing the game. Larger battles, better performance during them, and so on.
        • Changing the system requirements NOW, pre-launch, is vastly preferable to changing them after people buy the game on a storefront, to put it another way. Hopefully Kickstarter backers have a certain amount of understanding on this (and most of them, if not all, likely posses plenty-capable machines anyhow), but once it's on the open market we'd be saddled with the last-mile customers on DX9 or OpenGL 3.x or 4.0 for as many years as the game is getting updates. We would have really regretted that in a few years, even if we didn't need the performance boost from GPU instancing now.

Now The Good Stuff

  • Created a new shader for our ships to use via Amplify Shader Editor instead of Shader Forge. This new one is more efficient, uses a few more modern features, and looks waaay better. Just getting started with this one.
  • Using GPU instancing now instead of dynamic batching in most cases. This leads to substantially better performance when viewing giant ship battles.
  • Forcefields have had a LOT of visual work done on them. We just weren't happy with how they were looking -- most notably, how they looked when stacked up or very frequent on a planet.
    • The forcefields are now darker, and they don't show anything when your view is down inside them. (This provides a clearer view out during that mode).
    • The strength of the fresnel effect around the edges is stronger, though.
    • Additionally, these now only use a single mesh to draw, rather than two, and they use GPU instancing and so only use one draw call for any number of forcefields rather than two draw calls per forcefield. (Big difference in performance there, too!).
  • Shots now use instance batching, making them vastly more efficient compared to dynamic batching where the CPU had to do a bunch of geometry combining before routing them to the GPU.
    • Created a new shader that even allows us to instance batch together shots of different colors, which is handy.
    • This new shader is a lot more efficient than the unity standard shader, too, since this one is unlit and based around glows and turns off a lot of unneeded features.
    • The ArcenVisualShot object is now able to use instance material property setters in a really efficient and flexible way, allowing for easy setup.
  • Huge numbers of ships have been converted to the new shader style, which has an even more dramatic effect on their appearance than we expected. Things are now a lot more modern and metallic feeling rather than matte.
  • The shot graphics (for the basic bullet shots) have been updated to use more complex geometry. It uses very few more verts/tris (about double, and it was small to begin with), but looks far more interesting and shot-like.
  • For a variety of types of text that are shown over ships and similar, the game is now able to cache their meshes so that there is far more reuse of these.
    • This cuts down on initialization time for these gimbals, it cuts down on the RAM used by them, and it allows for the possibility of instance batching.
  • Fairly extensive updates have been made in creating a new shader in order to make it so that our sprite text now uses GPU Instancing rather than dynamic batching.
    • When there's large amounts of different text, this is far less efficient. That's now what we're using this for, however, and we still have another shader that works perfectly fine with dynamic batching if we find we need it to.
    • When there's repeated copies of the same text, the new approach is vastly superior in terms of CPU performance in particular, but also GPU performance.
    • In our "slow battle" test, this got another 5-10fps onto Chris's machine since there were a ton of ships with temporary text graphics above them in that scene.
  • To keep the outline-sidebar from exploding the game in big battles, it now automatically changes scale to try to show no more than about 50 icons (it can wind up showing more if there are lots of distinct types of units). So if there would normally show 100, it instead shows one icon per 2 squads of the same type/side. If it would normally show 200, it shows one icon per 4 squads, etc. The scale is currently not shown, but will be later.
  • Sprites now use GPU Instancing, taking them from hundreds of draw calls and lots of CPU-side expensive dynamic batching to just a couple of draw calls (depending on circumstances), and most of that work offloaded to the GPU, which laughs at it.
    • In a performance-intensive scene, this increased framerate from the 80s into the low 90s, or thereabouts.
  • Introduced some throttling on ship and squad LOD and gimbal updates, to prevent slowdowns related to that in large battles.
    • In a savegame where Chris was getting 90fps with something like 5k ships, this managed to squeak him up to 95 to 100fps, bouncing around in that realm.
  • All of the ship flair for the game is now in place, bringing us up to a total of 86 items.
  • All of the ships in the game now have proper icons and flairs implemented.
    • It's entirely likely that we made a mistake somewhere, so if something seems off please let us know!
  • Flak Turrets and Advanced Factories now have actual ship graphics implemented.

Known Issue: Sidebar Is Mostly Busted Until Next Version

  • Fixed the sidebar performance problems, but the sidebar still doesn't show up correctly. It's all default-colored and on linux likely doesn't draw at all. And missing the flair, etc.
    • More on this needs to be done, but we didn't want to hold up this build.
    • It's also possible that this will introduce some index out of exception errors based on race conditions, but we'll need reports of those (just stack traces is fine) in order to finish with those pieces.

Misc

  • On both the galaxy map and the main planet view, the game now recognizes when you're hovering over GUI elements and prevents things like the cursor and ship hovering and whatnot from happening.
    • This also means that things like using the scroll wheel in dropdowns doesn't also zoom the view, and other things of that nature.
  • The console window no longer has horizontal scrolling, instead wrapping the text inside it.
    • It also now uses better formatting with colors on the help command results in particular.
  • Some handy new things under the hood:
    • Engine_Universal.IsAnyTextboxFocused lets us know if there's a textbox/text-area currently focused, and thus not do keyboard controls:
    • Engine_Universal.IsMouseOverGUI lets us know if the mouse cursor is over any GUI element.
  • Fixed up an internal TODO item where now the raycast that determines what point on the playing field your mouse cursor over now only collides with the playfield itself, and not any ships or whatever else that is in the way.
  • When your shields are at zero, the hover for the shields now shows that text for them in red.
  • The game now shows the engine health for hovered squads IF the engine health is less than max. It shows in red if it's zero.
    • Previously you could not see your engine health at all.
    • Additionally, any ship is immobilized by having no engine health, its mark level icon styling adjusts to a new format to indicate that at a glance.
    • Thanks to BadgerBadger for reporting.
  • There is a new AIWarExternalVisualizationCode project that is open source and that players can use for modding of various visual aspects of the game.
    • We can basically move code there as-needed in order to let programming-oriented people tune things in ways that they want, or try out changes that they then suggest to us.
    • The first thing that is in here is the zoom code, which lets people mess with the zoom-to-cursor logic.
  • There was an issue previously with higher-mark-level ships of a variety of types not using the proper graphics, flairs, or icons. Fixed all those.
  • The game no longer shows any planet names during the lobby setup phase, since the planet names all change during actual galaxy generation, anyway.
    • Thanks to BadgerBadger for suggesting.

Version 0.123 Ship Batch 4 of 7, And A Metric Ton of Improvements

(Released May 9th, 2017)

  • Moved most of the mapgen logic for populating the galaxy with units into the external mapgen code.
    • This adds a few methods to IMapGenerator, meaning that if you've implemented IMapGenerator with your own classes before you'll need to add those methods for that class to load properly. A standard implementation is provided in Mapgen_Base.
  • The AI no longer starts with all fleet ship types and all guardian types.
    • The AI's available "unlock points" equal the current effective AIP minus the total unlock points spent thus far. So if it gets up to AIP 100 and spends 100 points, then you knock it down to AIP 20 it won't start getting new unlock points until it gets back up to AIP 101.
    • It can currently spend 10 unlock points to unlock a new bonus fleet ship type. This is configurable in the difficulty xml data.
    • It now starts with the fleet-ship triangle (fighter, bomber, missile corvette), and immediately spends its first 10 unlock points on a one bonus fleet ship of its (random) choice.
      • The logic for choosing the unlock is in external code (AI/Budgeting.cs, for an example).
    • It also starts with a basic set of guardians and currently doesn't add to that during the game.
  • Added a "Test Chamber" map type to the lobby. This is mostly just for our purposes, but it will probably also be very useful to modders and testers as it allows creating a very specific situation without trying to create it through the normal game.
    • For now it just creates a single planet, and spawns absolutely nothing on it except what's defined in GameData/Configuration/TestChamber/Example.xml (if you put more xml in that file or that directory it will only use the first encountered chamber record, for now).
  • Fixed up a variety of third party components that may have been unwittingly causing some GUI spikes, particularly in the most recent unity versions.
    • This may have only been present in the Unity Editor anyhow, but it's better safe than sorry and it doesn't hurt anything.
  • One of the most CPU-expensive aspects of the visual display of combat is now vastly more efficient: the spawning and despawning of shots.
    • SetActive on GameObjects is a pretty expensive call to be doing a lot (when there is a ton of bullet spam in particular), but there wasn't an obvious way around that. We are pooling shots in order to avoid garbage collector allocations and also save CPU there, but still -- turning on and off shots from the pool had a nontrivial cost.
    • Well -- no more! Turning them on and off is now pretty close to "free" in terms of CPU use.
      • We realized that since these shots have no colliders on them, nor rigidbodies, nor MonoBehaviours with Update methods directly on them (we already call those from a central tree to save yet more CPU there), basically the only cost to having a shot active was the drawing of it or making changes to it via our central tree.
      • Given that, we only have to not-change-them-via-calls-through-our-central-tree, which of course we were already doing, and we have to turn their MeshRenderer(s) off, which is insanely cheap on the CPU to do.
      • And thus: voila. Super cheap shot pooling. Any other Unity 3D games that are using shots that use raycasting methods rather than rigidbodie and colliders (and most games do, incidentally) could just as easily make use of this technique to get a potentially notable performance boost, too.
  • Actual graphics for the AI Master Controller are now in place!
  • Tweaked the shaders on a variety of ships to better bring out the IBL qualities in them. Main the AI Data ships, and then also the fuel generators.
  • Added Design Template Backups, similar to what was there in AIWC:
    • Whenever the AI unlocks a new bonus ship type (including the initial pick at the beginning of the game) it spanws a backup server on one of its planets.
    • You can hack that server one of two ways:
      • Download design. Works like hacking a fabricator or advanced factory: you get that ship type.
      • Corrupt design. Prevents the AI from ever producing more of that ship type.
        • Note: the response to this particular hack includes scads and scads of the ship you're trying to get rid of.
  • Cloaked squads now lose 5% of their current "cloak health" when firing a salvo
    • So this will never decloak them by itself (since it's a % of current, not of max) but if you've got a big pile of cloaked things attacking you, you will find your tachyon emitters decloaking the attackers faster and faster as the fight goes on.
  • A new batch of planet names has been added to the game.
  • The AI's "reconquest" mechanic has been implemented:
    • It puts roughly 10% of its strength budget into the reconquest fund (you can adjust that in external code AI/Budgeting if you're curious, and it can vary based on what the AIP is, time of the game, etc, but for now it's just 10% all the time).
    • It periodically considers all non-AI planets (player or neutral) which border AI planets, and looks at the balance of AI vs human strength on them.
    • If the balance on such a planet is such that the strength in the reconquest budget is deemed sufficient to let the AI conquer that planet, it spends that budget (up to some maximum based on the human strength present) to deploy a "Usurper" and various other attack ships in a wave-like fashion to attack that planet.
    • If the Usurper is present on a planet (having survived the battle), and the controller is neutral, and the AI has massive strength superiority on the planet, the Usurper is consumed to spawn a new set of defending guardians, fleet ships, turrets, etc and the controller is flipped back to the AI's side (completing the reconquest).
      • If you reconquer that planet for yourself, you don't gain additional AIP from the controller's death.
      • Further, the usurper can't spawn anything that causes AIP-on-death, like warp gates.
  • Dire Guardians:
    • These function in much the same roles as the ones in AIWC, but the category will also include the equivalents of the Core Guard Posts from AIWC. These four are some of the relatively tame ones, though once balanced they'll have the stats to kick in a whole lot of teeth.
    • Dire Lightning Guardian
    • Dire Missile Guardian
    • Dire Plasma Guardian
    • Dire Shield Guardian
  • Special AI Structures:
    • Roughly half of the AI's planets each get one of these, picked at random.
    • Troop Accelerator
      • Whenever the AI spends reinforcement budget on this planet, it gets twice as much strength worth of ships as normal.
    • Black Hole Machine
      • Like a really powerful gravity generator, and if the enemy ships are slowed to 25% speed or lower they can't leave through a wormhole.
    • Raid Engine
      • If you alert this for 20 seconds, it causes a big wave. It does so again every 60 seconds, if still alive and alerted.
    • Alarm Post
      • If you bring overwhelming force to this planet, all AI guards on this planet and its neighbors are freed as threat.
    • Planetary Cloaker
      • Makes all AI units on the planet act as if they have a normal strength cloak. They can be decloaked as normal.
    • Attrition Emitter
      • Damages all your ships on the planet every second or so.
  • Fixed the issues with ships sometimes being absent from squads they are a part of.
    • It's possible that there may still be an issue with certain ships that disappear for about 1 second before being recreated. This would only be noticeable with large single ships; please let us know if this is observed in this or future builds.
    • Basically the system works better now in general, and is self-correcting now, but there's a 1-second gap before the self-correction.
    • Thanks to BadgerBadger for reporting.
  • Fixed an issue with squads often having way more visual ships than they were supposed to. Evidently it was fully populating some of the squads with 25 ships when they should have had 20, or it was populating them with even more than that and having them double-up on their locations.
    • As you can imagine, this wasn't exactly kind to the CPU or GPU, making it waste resources on visual duplicates on identical locations. So this helps with visual correctness as well as performance.
  • A new game console now is available by pressing F3 (and F3 hides it again).
    • You can type "help" to get a list of commands from it, of which there are a number of cheats available, which are helpful for debugging.
      • The main cheats thus far are: destroy_selected, toggle_invincible, set_shields, set_hull, revenge, and exterminate.
    • This log also shows the history of any errors or warnings that were sent to the unity log, which is helpful.
    • This also has an autocomplete function, which you can use by hitting Tab.
    • There are a variety of improvements we need to make here in terms of being able to resize the window, and making it not give commands to the underlying game when you are over this window, etc, but it's a start for now.
  • The game now (by default, and this can be changed in the settings) zooms in on your mouse cursor, mostly like AI War Classic (rather than zooming in on the center of your screen).
    • There is still a bit of wonkiness in this in terms of the accuracy not being quite as strong as we'd like, but it's very close. We're going to move this code into the open-source part of the game libraries soon, so perhaps some other folks can tinker with it can see what they come up with that might be better than our present approach.
    • But either way, this does seem better in the main.
    • Thanks to jerith for suggesting.
  • The zoom angle curves are different for the cameras on the main view and galaxy map view now.
    • Rather than gradually tilting forward, it now zooms more straight in almost all the way, then tilts at the last second.
    • This is something that was pretty much required for the "zoom to mouse cursor" code to work with any accuracy.
  • Fixed a bug where sometimes the incorrect selection state would be set on ships when loading a new planet, or when ships were spawned, etc.
    • Thanks to gavin144 and jerith for reporting.
  • Fixed a cluster of issues with objects visually existing when they should not, either permanently on a planet or by flashing past when entering a new planet.
    • If any similar issues are seen again, please let us know.
    • Thanks to BadgerBadger and treyra for reporting.

Version 0.122 Ship Batch 3 of 7: 14 Ships!

(Released May 3rd, 2017)

  • ExternalConstants now supports the testing_techs_to_start_with attribute, which allows testers/modders to specify a list of techs that all players will start with. Useful when testing a new fleet ship or whatever.
  • Added support for "strength_portion_to_allocate" attribute on entity system nodes. This is used for multi-system entities (like the Fortress with multiple weapon systems, or something like the Raptor with a cloak and a weapon) to keep the overall entity balanced according to its strength.
    • So the Raptor "spends" only 10% of its strength on its cloak effectiveness, and 90% on its weapon. A unit with the same strength but a 50/50 allocation would be much less powerful, but much harder to decloak.
  • New Units:
    • Beam Cannon
    • Heavy Beam Guardian
    • Fortress
      • Human-only for now, these are very powerful and very expensive units with Needler, Laser, MLRS, Missile, and Beam weapons in addition to a fairly wide-area shield. Barely mobile, and cannot go through wormholes.
    • Minefield
    • Capturables
      • Advanced Factory
      • Advanced Starship Constructor
      • Experimental Fabricator
      • Experimental Turret Controller
    • Econ/planet-customization structures
      • Mass Converter
        • Metal => Power
      • Auxiliary Reactor
        • Fuel => Power
      • Metal Synthesizer
        • Fuel => Metal
      • Auxiliary Mine
        • Power => Metal
      • Fuel Synthesizer
        • Metal => Fuel
      • Auxiliary Refinery
        • Power => Fuel
      • Each reduces multiplies that planet's production of the "input" resource by 0.5 and the planet's production of the "output" resource by 1.5. Only one of each can be placed on each planet, but you can have (for example) a Mass Converter and an Auxiliary Reactor on the same planet if you only care about power output there.
  • Added the actual ability to do design-download hacks on Advanced Factories, Advanced Starship Constructors, Experimental Fabricators, and Experimental Turret Controllers
    • The AI's response is fairly basic for now, just some waves periodically launched from the thing being hacked. With an extra-special one at the end, of course.
  • New visuals for the following ships:
    • Data Center, Coprocessor, Advanced Research Station, Sensor Scrambler, Experimental Turret Controller, MLRS MKI, MultiNeedler Corvette MK I, Laser Gatling MK I, Raider MK I, Autocannon Minipod MK I, Eyebot MK I, Lightning Corvette MK I, Spider MK I, Starship Constructor, Sensor Array MK I, Tachyon Array, Fuel Generator, Assault Starship MK I, Sniper Starship MK I, Stealth Starship MK I, and Tractor Turret MK I
      • Sensor Scrambler, Sensor Array MK I, and the Tachyon Array use the Tachyon Array model
      • Fuel Generator does not have a flair assigned, though all other models have Icons and Flairs.
  • Put in a fix to an issue that was losing the locations of the formation styles and a few other things like that when a secondary file did a partial assignment to a ship type.
  • Fixed a TON of issues with multiple files partially contributing to the graphics of a ship.
    • These were leading to lots of things like the wrong graphics appearing, or wrong icons, or whatever.
    • This would have affected mods for the visuals or icons of the ships, although prior to this release it probably didn't affect the game itself.

Version 0.121 Ship Batch 2 of 7: 16 Ships!

(Released April 26th, 2017)

  • This is a good example of the metric tons of underlying work that Keith was doing mostly-invisibly over the past few weeks now paying off big time in terms of lots of content very fast. :)
  • New Units:
    • Ruined Network Node
      • It's like a science-gathering point, but for hacking points. Not present on every planet.
    • Coprocessor
    • Carrier Starship
    • Focused Gravity Generator
      • I.e. Grav Turret
    • Bonus Ship Types
      • Lightning Corvette
      • Spider
      • Grenade Launchers
      • Sentinel Frigates
    • Turrets
      • Flak Turret
      • Lightning Turret
      • Spider Turret
    • Guardians
      • Widow Guardian
      • Lightning Guardian
      • Flak Guardian
      • Gravity Guardian
      • Carrier Guardian

Version 0.120 Bugfixes

(Released April 25th, 2017)

  • Improved the outline's sorting when there are multiple sides of a given type (specifically, multiple Player sides) present, so it doesn't start putting lots of stuff on its own line for no good reason.
    • Thanks to BadgerBadger for reporting.
  • Fixed an issue where the game would not give an intelligible error when trying to load a save where subsequent changes to configuration data had removed or renamed a record referred to in that save.
  • Fixed a null-reference exception in the UI code.
    • Thanks to BadgerBadger for reporting.
  • Fixed a bug where some structures like starship constructors had no collision priority defined and thus a single ship could stack on top of them and make selection difficult.
    • Thanks to BadgerBadger for reporting.
  • Fixed a null exception in the targeting logic.
    • Thanks to BadgerBadger for reporting.

Version 0.119 Ship Batch 1 of 7: 24 Ships!

(Released April 24th, 2017)

  • Believe it or not, still more metric tons of mechanics implemented by Keith under the hood.
    • We've said that a couple of releases in a row, but one thing to remember is that AI War 2 is something based around a huge amount of prior knowledge we have from Classic. The mechanics he's adding are things that were in Classic in some form in the overwhelming majority of cases, so getting all those things done before then testing them more as a group and on ships that come out in rapid succession is something we've viewed as the most efficient path to a robust Early Access build.
    • Thanks for your patience, given all that! We know it looks unnervingly quiet on the surface lately. :)
  • Laser guardian shaders/materials updated to be more attractive.
    • MLRS and Needler guardians have also had their updates, now.
  • Fixed a bug where you essentially could not generate power.
  • New Units:
    • Turrets:
      • Missile Turret
      • Tractor Turret
        • Some notes on the tractor mechanic:
          • In AIWC a tractor could stop N units in range that were not tractor immune, and most things that were not small were immune. Units under forcefields (shields) were also immune.
          • In AIW2 a tractor can stop N strength worth of units in range, and nothing is immune (regardless of shields) though it's possible for a unit to have higher-than-usual resistance (and thus "cost" more tractor points to stop than another unit of the same strength). If a tractor doesn't have enough remaining strength to stop something, it is proportionately slowed down.
            • Tractor auto-targeting prioritizes the things that are easiest to stop, and fully stopping them rather than slowing them down.
      • Sniper Turret
    • Guardians:
      • Shield Guardian
      • Stealth Guardian
        • Some notes on the cloaking/tachyon mechanic:
          • In AIWC a tachyon emitter could decloak any number of units in range, though if something was cloak-boosted by another unit it was more complex.
          • In AIW2 a tachyon emitter does N "damage" per second to the "next" enemy cloak on the planet, and when a cloak hits zero the unit becomes visible and the emitter moves on to breaking the "next" cloak (cloaks can recharge, but only in the complete absence of enemy tachyon). The Ark has a tachyon emitter, and flagships and controllers will probably also gain some tachyon capacity. There are also the standalone tachyon arrays you can build.
            • Tachyon auto-targeting prioritizes the things that will be decloaked the fastest. In case of ties it prefers the things that have been on-planet longest.
          • In AIWC a cloaked unit that fired would be decloaked for a certain period of time.
          • In AIW2 firing does nothing to affect the cloak.
          • In short it's much harder to sustain a long-term cloaked presence on an enemy planet, but lacking sufficient tachyon coverage on a planet can leave that side unable to destroy cloaked ships attacking it. So cloaking isn't nearly as good at trolling, but it's much better at actually being dangerous.
            • In the future AOE weapons will probably hit cloaked units in range, and point-blank aoe weapons like lightning turrets will "know" to start firing even if only cloaked ships are in range... we'll see.
      • Sniper Guardian
      • Missile Guardian
    • Starships:
      • Assault Starship
        • Armored, with short-range cannon (anti-armor).
      • Siege Starship
        • Unarmored, very fragile, with long-range plasma torpedo (anti-shield).
      • Sniper Starship
        • Unarmored, moderately fragile, with planet-wide-range weapon.
      • Stealth Starship
        • Unarmored, cloaked, with short-range plasma bolt (anti-shield).
    • Bonus Ship Types:
      • Multi-Needler Corvette
        • Large-ish armored fleet ship with multiple needlers (anti-armor).
      • Laser Gatling
        • Evasive very-high-cap ships with rapid-fire lasers (anti-evasion).
      • Raider
        • Fast, evasive ships with plasma bolts (anti-shield).
      • Autocannon Minipod
        • Fast, cloaked, mildly fragile, high-cap, evasive ships with rapid-fire cannon (anti-armor).
      • Raptor
        • Very fast, cloaked, mildly fragile, evasive ships with rapid-fire lasers (anti-evasion).
      • Eyebot
        • Cloaked, mildly fragile, unarmored ships with plasma bolts (anti-shield).
      • Sniper
        • Unarmored low-cap ships with planet-wide-range railguns (anti-structure).
      • Space Tank
        • Slow, armored, moderately tanky and moderately low-cap ships with short-range cannons (anti-armor).
      • Infiltrator
        • Fast, cloaked, moderately fragile and moderately low-cap, unarmored ships with short-range fusion bombs (anti-structure).
      • Space Plane
        • Fast, cloaked, evasive ships with medium-range fusion rockets (anti-structure).
      • Armor Ship
        • Slow, armored, tanky and moderately low-cap ships with short-range cannons (anti-armor).
        • Not much to distinguish these from Space Tanks right now, will change when engine damage is added.
    • Other stuff:
      • Tachyon Array
      • Starship Constructor
        • Allows building MkI Starships of the available types (the flagships you've been finding before this version are just the MkV versions of the Shield variety), and MkII and MkIII of the same if you research them.
  • Fixed a bug where errors on some of the farmed-out threads were not being reported at all.
  • Updated the unity engine from version 5.5.2p2 to version 5.6.0p2.
    • This is a substantial upgrade that includes some various performance updates under the hood, and which allows us to use the new instancing pipeline in vulkan and directx 11 if we decide to.
    • As part of this upgrade, we've also upgraded the following components that we use: Amplify Bloom, Curvy, Shader Forge, Mesh Simplify, Vertex Tools Pro,
    • A variety of other scripts have been automatically updated based on method deprecations by Unity.
    • As part of the various upgrades, they fixed a (minor, but still) memory leak in their UI system, among many many other fixes and tweaks.
  • Fixed up the AIW2ModdingAndGUI project to have the most modern versions of the example ships and similar scripts on it. That way they actually function as suitable examples!
    • This included adding some of the new IBL shaders over to that project, and the cubemap used there, too.

Version 0.118 Of Shots And Hidden Mechanics

(Released April 13th, 2017)

  • More metric tons of mechanics implemented by Keith under the hood, waiting to rear their head visibly in an upcoming release.
  • Outline sidebar icons now:
    • Respect aspect ratio of the ship icon. For some reason the missile corvette (and to a lesser extent) the fighter have icons offset slightly too far to the right, but for now it will do.
    • Have a faint border around their "box".
    • Are grouped by human/AI.
    • Now puts your Ark/Flagships on lines of their own.
    • Handle left-click (selects and centers on, if your unit; otherwise just centers on).
  • Shielding no longer forces healthbar display for small ships with 100% health, since their shielded status is evident on the outline. This greatly reduces visual clutter.
  • Shots now do linear interpolation (lerping) between individual ships in the squad they are coming from, and individual target ships in the other side.
    • This is likely to have some bugs or other issues at first, since this is a huge amount of code. However, we're at a point where it seems more solid than what we had before in terms of providing a pleasing visual experience.
  • Debug_DrawTrueLocationOfShotsInsteadOfLerps has been added as a game setting to turn off the new shot-lerping code and just show the raw under-the-hood positional values like has been shown up until now. This is mostly useful for testing, but it's good to be able to see those underlying pieces if need be.
  • Removed the "shots with dead targets reacquire some other target" mechanic.
    • Thanks to Cyborg for observing how erratic the current implementation looked.
  • Added a new Debug_DrawShotDebuggingData flag into the settings file, which lets a variety of lines and circles show up to help understand what shots think they are doing and why. Telemetry, basically.
  • Fixed the bug where the outline sidebar boxes could permanently turn into white bricks.
    • Thanks to BadgerBadger, Insignus, and others for reporting.
  • The game now has different colored shots for the enemy and the player, to give a general idea of who is firing. It's not based on team color, so we'll see if we keep this, but anyhow the capability has been there for a while and now we're using it.
  • Updated the basic shot graphics to not just be a big ball anymore. ;)
  • Shots now rotate properly toward their target, which looks a lot better. It's a bit lazy on updating for new locations at the moment, but we're trying not to hammer to the LookAt command on transforms, since that can be heavy and there are a ton of shots already.
  • Known issues with shots (please let us know if you find circumstances to reliably repro!):
    • Sometimes the shots will mysteriously slow down and then speed back up again.
    • Sometimes the shots will all of a sudden, in a giant chain, go running off to another location in a really jarring and obvious way.
    • We do know that ships are still exploding before shots are hitting them, and that's next on our list.
      • This one we don't need any repro steps for, as it's just incomplete work.
    • Also we know that sometimes there will be a squad with no visible ships in it that is still firing somehow.
      • Is this one new, or have you seen that before? It's more common now, either way. Steps to repro would be helpful.
      • Tabbing to the galaxy map and back fixes it. We have a suspicion what this one is, but will have to investigate it tomorrow.

Version 0.117 New Planetary Sidebar

(Released April 7th, 2017)

  • Smooth rotation has been implemented for squads. No more jolting Arks turning, or fighters and such with little squiggly contrails from all the rapid turns!
  • The game no longer uses Steamworks.NET (which it wasn't really using anyway). That's ancient and deprecated by modern standards.
    • We've now shifted to using (again in the loosest sense thus far) Facepunch.Steamworks. https://www.assetstore.unity3d.com/en/#!/content/74349
    • This one is getting the job done without having OS-specific non-managed wrapper DLLs, which is a really welcome shift for us.
    • As to the details, we'll find out more of those later, but we only do a limited amount of things directly and they seem well supported here, so that's a win as far as we're concerned.
  • Went through the code and made sure that the music tracks were being played randomly.
    • They were, but we only have a couple of tracks at the moment, so it doesn't come off that random yet.
    • Even so, we made a variety of improvements to our code to make it more idiot-proof just in case.
    • Thanks for kasnavada for getting us to look into it.
  • Individual GUI elements can now choose from a variety of prefabs (that can be added to at will) to start visually styling them as well as adding extra functionality if need be.
    • The first super-basic pass at getting a themed GUI is in place with some of the buttons. Not it's still super temp-y.
  • Fixed a bug in the prior build that was causing players not to be able to interact with wormholes to send either ships or their view through them.
    • Thanks to BadgerBadger for reporting.
  • The old "planetary sidebar" placeholder on the right side of the screen has been removed. Instead, there is now an "outline sidebar" on the left side of the screen. Instead of names and numbers, it shows only the icons of the ships present
    • Plus little decal indicators for when those ships are in certain states:
      • Yellow marker in the top-left corner of the icon when firing on other stuff (literally: am I reloading?).
      • Orange marker just below that when being fired upon (literally: have I been damaged recently enough to not be repairable?)
      • Blue marker just below that when protected by a shield (one's own or another ship's shield)
      • Purple marker just below that (hits the bottom-left corner) if I'm cloaked (cloaking isn't available in the game yet, so you won't see this yet)
    • You can also mouseover each icon to get the tooltip you'd normally get if you mouseovered them in the game space. But no click handling, yet.
    • Please note that we have a looooooong way to go with getting this outline sidebar up to snuff; getting it looking not-awful, separating out friendlies and enemies (now they just sort in different parts), separating out capital ships, click handling, toggling 2x/5x/10x/etc scaling for when there's just tons of ships, highlighting in realspace the thing you're mousing over on the sidebar, etc, etc. But it was to the point that it was more useful than the old sidebar, so poof :)
    • Thanks very much to eRe4s3r, Wanderer, Toranth, Cyborg, treyra, Draco18s, Cinth, and others for inspiring this change.

Version 0.116 Sprite Text / Forklift Full Of Design Work

(Released April 5th, 2017)

  • Several metric tons of under-the-hood sim-data-schema additions in preparation for... oh, I'm sure it's nothing.
  • The various sprite graphics are now using Trilinear filtering rather than Bilinear, and with an aniso level of 16 to make them super crisp at whatever angle.
    • They're all using unity mipmaps for the sake of efficiency and clarity, too.
  • Ported over the bitmap sprite text renderer from Starward Rogue (and other games going back to AVWW or so).
  • Previously, there were a variety of ships that don't yet have their permanent graphics in place that are using something called "namedsphere" as their model.
    • Those ships had a little sphere as their model (still do), and then some non-billboarding text that would show in appropriately through depth sorting (that's now gone).
    • Instead, those ships (and any ships, really) are able to have text show up over their gimbal icons, instead. These are sorted properly in terms of transparency, and they billboard to face you, and scale up like the rest of the gimbal icon stuff. Much better!
  • Rather than having the text for the wormholes be non-rotational and built into a plane below the wormhole, that now gimbals around like the text on the other ships.
    • This also fixes a sorting issue with them, and makes them easier to read in general.
    • Thanks to RabidSanity for suggesting this switch.
  • When you are hovering over a wormhole, it now actually shows the name of the wormhole changing color.
  • Fixed up some of the LOD code so that it is now running better; it was not culling things fast enough, even where values were there properly.
  • Fixed all the Scale 1 LOD values so that they are now a lot more conservative while still showing you good graphics. Before it was overly aggressive, which hurt batching quite a bit.
    • Same with Scale 2, to basically the same degree.
    • Same with Scale 4, but to a less severe degree.
    • A tad with Scale 8, but very little tweaks required. And then nothing beyond that needed tweaks.
    • Basically the problem was we were not getting to LODs 1, 2, or 3 fast enough (not nearly so) on the small units. But the values for LOD 4 (complete culling) were good all around.
  • Created new cutout variants of our various sprite and bitmap-font-text shaders, and implemented those.
    • This cuts our draw call vastly (by hundreds) by actually letting the various z-writing and sorting and all that happen properly. Previously it was winding up not being able to dynamic batch as much as you'd think because of partially-transparent pixels and thus an inability to do z-writes. Now it's all set!
  • Actually, scratch that about the cutout shaders except for in the instance of the text. That was causing z-fighting at far zoom levels because the lack of precision of the z buffer.
    • Yes there are solutions to that sort of thing, and for anyone interested in experimenting with that, the source code for the shaders is in the AIW2ModdingAndGUI folder along with all the other moddable things. If you get something working, please feel free to share with us -- or we'll revisit this later, if needed.
    • For the time being this only costs us something like 100 draw calls anyhow, and not really much of any setpass calls (the true killer), so it's not a crisis. On a 1070 running on a 4K monitor with all the settings maxed, this still gets 250+ fps in the early battles.

Version 0.115 Icon Refinement, And Shapes

(Released April 4th, 2017)

  • Extended the new modding structure to the external constants (and external visual constants) files, so that having partial records in XMLMods for those works properly.
  • Added a "Scrap" button to the master -> commands menu, since it had been unintentionally left out of the previous release. The Intergalactic Redundant Fleet Ship Union was in no way involved in that unintentional omission.
    • Thanks to lagomorph129 for reporting.
  • The master menu commands for "select X group" and "scrap units" now close all open expansions to the master menu so that you can move on without having to use backspace. So currently "toggle FRD on everything" is 8-1-1-5-1, rather than 8-1-1-backspace-backspace-5-1.
  • Removed 7 different external dlls that we've been using in all our games since AI War Classic. These were used in support of compression and excel export, but we have better ways of working around those problems now. This shouldn't affect much in the way of helping performance, but hey a little bit less to load is good.
  • Updated the icons so that they have more definition to them, including some of the flairs at this point.
  • Got rid of the concept of mipmapping the sprites, because we only ever use the larger size anyway.
    • However for the things like the numerals, health bars, etc, we're retaining a smaller version for things like the sidebar, since those have more details in them.
  • When under a forcefield or similar, the roman numerals no longer get a border. Instead the health bar does.
    • If the health bar would normally not be shown in this instance (because the ship is at full health), then it shows a blue non-segmented "perfect health" indicator bar instead.
  • The borders for the stealth, shielded, etc statuses on the health bars are now built into variants within the texture itself. This lets us make nicer-looking versions of them, as well as ones that play nicer with antialiasing, as well as that have slightly less overdraw.
  • Squads now use a smaller health bar than before, unless they are important. Important ships right now are set to be:
    • Player Arks, and the AI Master Controller.
    • Warp Gates and planet controllers.
    • AI Guardians.
    • Mark V Starships (aka Flagships) of the players or AI.
  • Whenever a border was previously not being drawn around a sprite for a squad, now it draws a black border instead. This definitely helps out with the sense of tone and definition for the sprites, and gives them a more defined look when they're all in a group.
  • Solely for the health bars, flair, and numerals, we are now using truecolor (no compression), and unity's mipmaps, as well as trilinear filtering. These wind up getting shown at various small scales and oblique angles, and there was a pretty wicked flicker between very disparate colors even in one sprite.
    • Aka if something had black and white near each other, it would flicker between the two of them because of the angle of view being slightly different as either the unit or the camera moved.
    • For the other icons themselves, this is less of an issue because they don't have such sharp color contrasts. But if that were introduced for some reason, then a modder could adjust the import for their textures as they see fit.
  • There is a new DisableMarkLevelsOnShipIcons option in the settings file which lets you turn off the mark level indicators in icons if you like.
    • Also there's a DisableFlairOnShipIcons one for disabling flair -- however, it only applies to the in-game graphics and not the galaxy map. At least for now.
  • If there is no flair or mark level drawn for a ship, then the health bar now moves upwards.
  • There are now 12 available shapes (for now -- we can add more as requested) that are available to be used as alternative icons for the ships.
    • Right now we've just gone with a proof of concept more or less, and we'd be happy to have feedback on what sort of shapes people want, and on what ships. It's just Blue creating a tiny bit of art and us updating some xml files, now.
    • To turn these on, set the new setting UseShapesInsteadOfShipIcons option in your settings file to true.
      • This does not automatically turn off mark levels or flair, so there's a good chance you want to turn off one or both of those in this case, too.
    • Bear in mind that right now it's kind of just semi-arbitrary how specific shapes were assigned by function. There is a rhyme and reason to it, but it's not a very good system in the main at the moment. Again: proof of concept, and now it's a data issue that needs discussion.
    • Another cool thing to note is that this only affects the in-game graphics, not the galaxy map. The galaxy map is useful for finding rare buildings, so the icons for them staying the same is helpful.
    • Even more helpful is that you can selectively use this, which we have chosen to do so far. The King units and certain other really important units we left using their regular icon. All the fleet ships, turrets, and so on use the shapes. It doesn't have to be done this way, but it makes a certain amount of sense and winds up looking neat.
    • For all of this stuff, obviously this can be moddd. But the goal for us is for us to provide you with two options such that you can choose one or the other and be happy without the need to go mod. If a giant number of people feel the need to use a mod just to play the basic game, then we're probably missing a setting, etc. So here's that setting, or at least the start of it.
    • Thanks to a lot of players, but most notably (recently) eRe4s3r for suggesting and pushing this option.
  • Investigated using both FXPro and the Unity PostProcessing Stack, and found both to be really unsatisfactory for our bloom needs, unfortunately. For now staying with Amplify Bloom.
  • Amplify Bloom has been configured to only use 4 mip levels rather than 6, and now uses half-scale rendertextures rather than full-scale, and has temporal filtering on as well as different blur levels per mip level.
    • The overall effect is now something that is more efficient to run, a bit softer in terms of the end effect, and which should be more compatible (on the rendertexture front in particular) with more graphics cards.
    • Thanks to tykinruoka for inspiring this change, even though they're running a 980Ti that should laugh at this. It might be a linux driver issue, we're not sure.
  • Adjusted the visuals on the wormholes yet again. Among other things, slowed down the effect some and made it once again less neon.
    • Thanks to Cyborg for suggesting.

Version 0.114 Major GUI And Icons Overhaul

(Released March 31st, 2017 -- FINALLY!)

  • The wormhole graphics have been substantially slowed down in their rotation so as not to be so distracting.
    • Thanks to gavin144 and BadgerBadger for suggesting.
  • Worked out new way of scaling text within UI elements that isn't nearly as CPU-demanding as Unity's built-in approach but still gives decent results at a wide range of resolutions.
  • Fixed a bug where opening the save or load window twice in a given run of the application would result in most of the buttons disappearing (in reality, they were all stacked on top of each other).
    • Thanks to BadgerBadger for reporting.
  • Rolled a lot of the in-game UI up into a menu along the bottom edge of the screen, where clicking an item opens the next level of stuff above that. All the debug and timing controls that were cluttering up the left side of the screen, for example, are all down there now.
    • This also allows access to the Tech and Planet functions regardless of whether you have a selection or are in galaxy-map view or planet view.
    • The buttons of the menu and most of the sub menus now also respond to the 0-9 alpha-row keys, and are labelled accordingly. Backspace backs you up one step. The Tech and Build menus don't support these (yet, at least) because the mapping isn't obvious and attempting it would probably be confusing.
  • The mechanism for drawing the cursor for the player on the game board is now completely different. It's now a bit more accurate, easier to see at all zooms, less jittery, and just generally more attractive.
  • Put in some more code that lets us do some initialization in external DLLs when they are first loaded, for purposes of setting things up initially. This should be pretty useful for modding in general.
  • A new flag check_for_continuously_held has been added for input bindings, so that keybinds that are based on holding down something rather than just pressing a button now are possible to dynamically define.
  • Added keybinds for showing the orders of your ships (hold shift), showing the ranges of your selected ships (hold Z), the ship you are hovering over (also hold Z), and showing the ranges of all ships (hold Shift+Z).
    • If other default keybind key assignments turn out to be more desirable, then we can easily change that sort of thing in the xml.
    • In general we're not trying to completely mimic what AI War Classic did, though, because already we have things like WASD in the way of that in the default binding set, and that's a really good setup for anyone not using edge scrolling.
  • Put in some code that now gives better error messages when there's a missing window definition for the GUI from code.
  • In playmode on the main game and in the prep project, the game now does an efficient job of checking for errors on visual squad definitions.
  • Fixed several bugs with specific ship model definitions, and with a couple of pieces of code related to them.
  • Added LOD "Simple Cullers" for helping out with things like the missile turret.
  • We now have batch files for automated building of the actual standalone copies of the game. This turns out to be faster than the way we had previously been doing it, and it also doesn't require opening the unity editor, which is nice. Downside is that you cannot build from the unity editor directly for all OSes anymore, and we have to close the unity editor (just that one project, anyway) to let this run.
    • Good news is that if we need to build just for our local OS, we can just do that using the normal unity build menu itself.
  • Updated our Steam copy scripts so that they first clear existing files, which will hopefully result in us being able to delete files without having to just blank their contents out. This next release is an experiment in if that works on the actual Steam side. But now it's automated on our end so that if that does work, we'll be taking advantage of it without Keith having to poke Chris about it at any time, etc.
  • Fixed issues with the LODs not always triggering off the proper camera, most likely due to some scene hierarchy changes we made in 0.107.
    • At any rate it's fixed now, and we've gone back to our general stance of "Camera.main is evil and dangerous." Consider us chastened. ;)
  • Updated the build process, once again, so that we can now control it via the Arcen menu in the unity editor (yay!), or via batch script. Now this lets us have some extra flexibility in terms of how we compile, and in this case now we can use the development build like we want (but could not do with pure command-line-only code).
  • Fixed a minor issue with building for OSX and Linux where it was having a managed dll clash over Steamworks.NET. No biggie, just housecleaning.
  • Added the "Objectives" window to the master menu at the bottom of the screen.
    • The general idea (as in AIWC) is that this is the place to go when you're wondering what your next steps could be.
    • Clicking on one of the objectives will generally either center on the planet/entity mentioned (if any, and you know where it is) or open the related menu (for instance, to research a suggested ship).
    • This is defined entirely in external code, so if you want to add other objectives that make more sense to you (or your non-programmer friends), it's straightforward to do so.
  • The wormhole graphics have been updated again, this time with work done to further customize their shader as well as cut their geometry in half.
    • This literally more than halves the amount of work the game does to render each wormhole, and the effect looks fancier as well.
    • Additionally, this no longer relies on being so darn neon -- thanks to Cyborg for particularly pointing this bit out.
    • Wormholes are also, yet again, a bit larger.
    • Oh, and they no longer are additive, which means they go in the opaque buffer, which is more efficient and also no longer makes them adjust their look so much based on their background.
  • The AI warp gate graphic has also been updated to match, and now has more of a green component in its color so that it's clearer that it is functionally related to the wormholes.
  • Replaced the existing bullet effect (which was always pretty temp) with a new one. This new one isn't incredi-final either, but it is a big step up in a variety of ways.
    • For one, it's able to be in the opaque geometry rendering path, so it requires a lot less complex depth sorting and doesn't result in overdraw to the same degree, etc, etc.
    • Also, interestingly enough, these were made spherical and yet there's still an illusion of stretching with them when they are moving quickly.
  • Code has been added to the Amplify Bloom scripts to catch errors that it might encounter when trying to create render textures or blit.
    • Previously on certain graphics cards+driver combinations (so far just one on linux), we could run into issues with it saying that the render texture was too large to create.
    • This seems like some sort of driver error given the caps of the card and what is being requested, but either way we've put in code to prevent that from keeping the entire game from working, as well as to give us better output about what texture size was actually being requested (in case there is something unseen causing that to be unreasonably large).
    • This is all third-party code and we may switch over to Unity's own new integrated post-processing stack, but for now this is a good start.
    • Thanks to tykinruoka for reporting.
  • There is now a DisableCameraBloom option in the settings file, which allows players to turn off the bloom effects if they would like to (or if the effects give them trouble).
  • We're now using TexturePacker in order to generate much-more-efficient sprite atlases for use for the little indicators (previously "gimbals") for ships.
    • The free version of the program is available here: https://www.codeandweb.com/texturepacker
    • We're using the pro version in order to use the MaxRects algorithm. If you're heavily into modding the game, doing that or not is your call, but the data format that is generated is a png and an xml file. The latter can be generated by any program, or by hand.
    • We're storing these xml and png files -- of which there are VERY few (one at present) in GameData/ExternalIcons rather than putting them into an asset bundle. The performance difference is negligible (on loading) and zero (during play), and this is simpler.
    • Note that we're also including the .tps project with the appropriate settings in there, as well as a subfolder with all of our original icons, so that it's easy to rebuild the official sprite sheets if you ever wish to.
      • Settings of most importance if you're building a spritesheet:
        • PNG32/RGBA8888
        • Size constraints: POT (Power Of Two). Some graphics cards, mainly very old ones, will otherwise resize it and cause issues.
        • Allow rotation OFF. (Our sprite handling system won't support this).
        • Trim mode: Trim. (Or Off, but no other version)
      • Optional settings if you're building a spritesheet:
        • Clear transparent pixels (it will run faster).
        • Algorithm: MaxRects (but you need to have pro -- and that does run faster).
        • Detect identical sprites (why not -- hurts nothing)
        • Border padding: 2 (otherwise may have problems
        • Shape padding: 2 (otherwise may have problems
  • UI text now does a better job of downsizing to fit the available area, without also trying to upsize if the area is larger than it needs.
  • Put in a fix that sets the internal culture to en-US, like our other games do, to prevent xml parsing issues and so forth.
    • The alternative is doing the following for the launch options, but shouldn't be needed after this: LANG='en_US.UTF-8' %command%
    • Thanks to tykinruoka for reporting.
  • Created a couple of new shaders for rendering the new sprites in as efficient a fashion as possible while still doing the hue shifts and so on as needed.
  • Completely redefined the team colors, since those are now based around icons rather than the 3D model gimbals.
    • The text color hex for all of them is not yet sensibly set, and the flame trail materials also need to be changed in some cases.
    • If you were using a team color in a prior savegame and that color no longer exists by name, then I'm not sure what will happen with that.
    • The root definitions of all of these are now all in the public ArcenModdingAndGUI project in order to make it as easy as possible for people to make new colors.
    • These are set to go into a new asset bundle called arcencolors.
  • In order to better control the import settings and get the best quality possible, the actual final icon sprite sheets are now placed into the asset bundle after all. The raw icons are not, though.
  • Fixed a bug that could lead to unhelpful error messages when string type values were missing from xml files.
  • Added white, cyan, and yellow flame trails to go with the various team colors.
  • Drag-selection of units based on their actual models (as opposed to their gimbals) is now properly working.
  • Additionally, for the first time now drag-selection properly works with additive and subtractive selection.
  • Finally fixed an issue where directly clicking individual ships within a squad would not always select them properly. It would for the Ark and other giant ships, but not for the smaller ones.
  • All of the ships so far defined, plus a variety that have not been put into xml yet, now have their icons and/or flair in the new system.
    • Bear in mind that the icon/flair system isn't fully polished yet and in a lot of circumstances will see the art being swapped out as things evolve. This is PASS ONE, it's important to note. ;)
    • From a technical standpoint we have enough to evaluate this approach and know that it's definitely viable.
    • From a configuration standpoint, we have enough to make it so that players can turn off a few things if they need/want to in the future.
    • From a design standpoint, we have enough to know that we CAN make enough variance that you can actually tell things apart, etc. This is super useful data for us, hence us doing a lot of the art even if a lot of it eventually winds up being redone or whatnot anyway.
    • At the moment we have 30 different flairs, and 23 different icons. Overall the idea is that we'd have more growth in flairs than icons as things progress, but also reuse of flairs between different icons (so the laser flair would be on both a turret icon and a starship icon, probably, which helps you to know what all of those things are a lot easier).
    • Anyhow, this is round one of the new approach, so please don't freak out if there are things that aesthetically you don't like, or conceptually or whatever. This is why we have you folks in early in the process!
  • There's now a difference in the color of a ship you've got selected and are hovering over, versus one that is not selected that you're hovering over. Now when you click something to select it, that means instant visual feedback in the selection ring.
  • Added a new hotkey that allows you to just reload the ExternalVisualConstants and Language xml files, which are two that are very common to want to load over and over again if you're making small tweaks. This combo is Alt+F10 instead of the usual Ctrl+F10 to reload everything.
    • This shouldn't be in anyone's way, and is a handy little shortcut for us.
  • Split out ExternalConstants to also have an ExternalVisualConstants variant so that it can be triggered on a reload without triggering the central constants as well. This prevents some issues with things with the sim dying if you're/we're just making tweaks to external visually-oriented constants with Alt+F10 reloads in there.
  • All those various icon scaling constants are now in ExternalConstants, making it so that if you don't like how things are set up, you can adjust it yourself.
  • The scale of icons is now far more sane in general, so that you're not being blinded by a massive clutter of them when you're zoomed out OR zoomed in.
  • Rather than showing their selection or hover status with a ring, the main body of the icons for the squads now shows a border around itself with a color that matches that of the ring around the underlying squad.
    • Flair, health, mark level, and similar don't get this border around them. That would be too cluttered.
    • Overall this minimizes the amount of space taken up by selection status on the icons, which is really nice.
  • Depending on the action status of the squad, its mark-level numeral takes on a certain color from the central dictionary.
    • This kind of takes the place of the colored borders from AI War Classic, but it's a bit less intrusive to the main colors of the larger icon itself.
    • The colors used here are different from in the original game, though, for the sake of clarity (for people coming to this fresh) and attractiveness.
      • Free-Roaming Defender mode is now red, rather than purple.
      • Group-move mode is now green rather than cyan (though this isn't yet available from Keith's sim).
      • Attack-Move modeis still yellow (though this isn't yet available from Keith's sim).
    • Additionally, we're retaining the ability to show certain things about the AIs by using these sorts of colors. What exactly we show, and the extent of what you are allowed to know about the AI, has yet to be determined. But it's something we did a little bit of in the prior game.
      • In general, the AIs now show a somewhat dimmer version of the numerals if they are a guardian in a guard stationary or patrol mode. This may need to be more obvious, not sure.
      • If the AIs are in their equivalent of FRD mode, then they show up with a different shade of red,
      • Really this is just kind of an example, and is something we should handle a lot better in the future with better-thought-out statuses for the AI that we want to indicate, if any.
        • But basically knowing what is threat and what is not is useful, for instance. For new players, getting near some ships that are guarding and then seeing their icons turn red as they become threat could be both exciting as well as really clarifying at an intuitive level about when you're seen versus when you're not.
        • Not really sure what we'll do with that long-term, but this is an initial prototype of the general concept.
  • Ships that are protected by a forcefield other than themselves now show up with an extra border around their mark level icon.
    • In Classic, we had a bubble appear around the icon, but that was a bit clutter-y. This is vastly more subtle, but still gets across the info.
      • We'd originally thought to do a little shield bar, but that again gets pretty clutter-y fast.
    • The border around the mark level is very white, but with a bluish tint. You can adjust this in CMP_VisualConstants.xml if you would like to experiment with other colors. Then just hit Alt+F10 in the game, and mouseover the ships in question, or select them, to get them to update their status.
    • When cloaked (not available yet), these will show a purple border here instead. When shielded and cloaked, it's more of a purple-blue. We'll see how that looks later, when cloaking is in place.
  • Health bars now appear for any ships that are damaged, right underneath the mark level.
  • The galaxy map now properly shows the icons of ships of importance, and the king units, as it did in past versions.
  • The size of the text for galaxy map planets can now be set via the visual config file. Also, the size is different for the planet you are at versus the rest, making things far less cluttered and again one better way of telling your current planet.
  • You can now see very well what mark level planets are on the galaxy map. They have a suffix of their mark level, which is nice and sci-fi-themed anyhow, and that helps keep things less cluttered as well as more in one plane of text. The colors get progressively more bright and threatening as you go up in mark level on the numerals there, again making the galaxy map easier to parse visually at a glance.
  • When the players control a planet, it just shows the "internal name" of their player color in parentheticals after the planet name, instead. That's tacky and temporary. We need to figure out something better there. If someone wants to post a savegame with a lot of planets controlled by them, that would be awesome.
    • When a planet is claimed by nobody, it just says "Unclaimed" in parentheses after that. Whether or not that's a good thing is also debatable -- it's probably not. Ideas welcome on how to denote that in a clear but unobtrusive way.

Version 0.113 The One Thanks To Cinth

(Released March 17th, 2017)

  • Converted the map type "spinner" in game-setup to a dropdown.
  • Converted the map seed "spinner" to an input field that allows you to type in a seed.
    • And a button that actually uses that seed to generate a map (as opposed to it regenerating with every digit you type).
    • And a button that picks a random seed and regenerates the map (basically what the spinner used to do, but without also showing the seed itself).
  • Completely new wormhole graphics!
    • Cinth started out this work by creating a really interesting torus shape, which we previously showed off.
    • The original version was more of a distortion and something based around a visual refraction along the lines of what you see in Interstellar. While that looks fantastic, it's extremely hard to see and thus fairly impractical in practice.
    • We thus took this further in the direction of the green swirling wormhole graphics from the first game. Based on the force field shaders by Ciconia Studio, plus a couple of spins, we came up with a two-tier additive animation set that is really easy to see.
    • These wormholes are also MUCH larger than before. This makes them far easier to see from very far zoom, and it feels more appropriate when so many of the ships can get so large.
      • Thanks to jerith for suggesting the size increase on them.
    • The names of the planets are also now far larger, and no longer billboard. This way you can always tell "which way is north," so to speak, which can be useful for orientating yourself. Overall the names of the planets are now 3x larger than they were before, and are now set underneath the playing field so that they shouldn't be blocking anything.
      • Thanks to BadgerBadger for suggesting this size increase.
  • Added a few new planet names that are pronounceable but more alien-seeming. At the same time, also took out or modified some of the more recognizable human last names (the original planet name set was all scientist names). We're going to be growing and changing this list anyhow, not least of which with the names from kickstarter backers, but overall Chris at least is trying to avoid some of the more common and obvious last names that somehow just don't feel like place names. If there are more, please feel free to point those out.
  • debug_non_playable_suppress_normal_multithreading removed from the external constants, and DebugNonPlayable_SuppressNormalMultithreading added to the game settings instead. This way it can be toggled in player settings rather than being a global override.
  • The wonderful IMDraw by Harvey C is now in use for drawing circles on an as-needed basis in a very high-performance fashion.
  • Added a new Debug_DrawAllRadiiAtAllTimes, which causes all of the squads to always draw their collision radii. This is super useful for purposes of seeing if the graphics are actually well set up in terms of how big the radius is versus the space the ships take up.
    • Prior to now the values were all guess-and-check, and mostly not even that checkable, because we simply hadn't gotten to this yet.
  • Started fixing a variety of ship and object radii.
  • The scale of the AI Warp Gates has been increased from 8 to 54, visually. This is a massive jump up, but it makes them way easier to find and also makes them a lot more in keeping with the regular wormholes now.
    • Alongside this, they've had their materials updated a ton based on some ideas from Cinth, and they also now use the torus-style underlying warp animations.
  • A new metallic PBR-style shader with IBL reflections has been introduced, and is now used with the planet controllers so that they now look in keeping with the other upgraded ships in the game.
  • The space dock and Ark have both had more updates to their visuals to use the IBL reflections and similar.
  • Fixed an issue where apparently dynamic batching was disabled when we upgraded to the newer unity version -- best guess as to how and when that got turned off, anyhow. So that should see a substantial performance bump on some machines.
    • Note that the number of SetPass calls was already nice and low thanks to material reuse, so this being disabled didn't have as big a negative impact as it otherwise would (which is in itself awesome, as an aside). But on some machines, depending on what the limiting factor is in their hardware pipeline, this could make a notable difference.
  • Fixed an issue with the missile corvettes not having quite the right emissive properties.
  • Corvette further improved with the IBL shader.
  • Bomber and fighter have now been upgraded to use the new IBL shader, with a metal map added.
  • Apparently the derelict and human planet controllers weren't showing their graphics properly. Fixed!
  • The first of the science "derelicts" is now in place. It's large, rotates, and uses fancy new shaders and so on.
    • Largely this is thanks to Cinth, in terms of inspiring it and getting us to use this particular style, etc.
    • Eventually there will be more than this one model, but this one is a good start.
  • Fixed a bug in the rotation animations for ships, where after a while it would get stuck and stop rotating due to a quasi-bug (or at least oddity) in how quaternions get translated to euler angles and back in unity. It's probably not a bug, but it is odd; and it only happens with really precise numbers, such as when the rotations are happing during a super fast framerate (200fps or more).
  • When you hover over squads/ships/etc, you now get a yellow circle showing its radius, and that also is indicating that this is the squad that the tooltip is for.
  • When you have squads selected, they now show white circles around them showing their radius, and indicating that they're selected in addition to the gimbal ring.

Version 0.112 Plasma, Forcefields, and DirectX11

(Released March 14th, 2017)

  • Added the immobile Shield Generator units, for both human and AI use.
  • Added Plasma Guardians and Plasma Turrets, which are the main counters to heavily shielded formations. Later, with other starships, will be the Siege Starship, which also uses plasma weaponry.
    • For now these use the MLRS Guardian/Turret graphics.
  • Shader Forge updated to v1.35 from v1.32.
    • All of the shaders created by Chris with Shader Forge have been recompiled in the latest version.
  • Beautify upgraded to v4.4 from v4.1.2.
    • The performance of this (on the GPU) has been improved in several ways through this upgrade as well as its new features, without having any visual impact on the game.
    • This performance gain will really only be noticeable on fairly old GPUs, it's worth noting.
  • Upgraded other internal tools of ours to the latest versions. This corrects a few should-be-harmless issues in our build chain, and in general cleans a few things up that got messy with the upgrade to the latest versions of Unity 5.5.
  • DirectX11 is now supported on the windows builds of the game, and is the default on that platform instead of OpenGLCore.
    • This should help for some people's systems that can run DX9 just fine, but which run into problems with OpenGL.
    • Thanks to treyra for reporting.

Version 0.111

(Released March 13th, 2017)

  • Fixed a race-condition bug when regenerating maps.
    • Thanks to BadgerBadger for reporting
  • Put in some error catching code to hopefully prevent unhandled exceptions on secondary threads, which may have been causing the linux build to die prematurely in some cases.

Version 0.110 Modding Overhaul And Unity Upgrade

(Released March 13th, 2017)

  • Overhauled XML mod support: instead of having each xml data directory support an "Override" subdirectory, now:
    • In the base game directory there is an XMLMods subdirectory.
      • In XMLMods there's an ExampleMod subdirectory.
      • In ExampleMod there's a GameEntity subdirectory, just like GameData/Configuration/GameEntity.
      • In that GameEntity there's an ExampleFile.xml file.
      • In ExampleFile.xml there's a single record, with the same name as the Ark, using the new is_partial_record flag, and only setting one value (speed tier).
    • In PlayerData there is a XMLLoadingOrder.txt file (you'll need to run the game once for that to be created). When loading the xml data the game will look at each line in this file:
      • "_Vanilla" (without the quotes) tells it to load the vanilla data from GameData/Configuration/
      • Any line composed entirely of whitespace, or whose first two non-whitespace characters are // (a common symbol in code for "commented out"), is ignored.
      • Any line containing any character other than a letter, a digit, the space, the underscore, and the minus sign is rejected with an error message, to avoid clever folks using this to read from files in some remote part of the filesystem. If you want more characters whitelisted, please let us know.
      • Any other line causes the game to trim off any leading or trailing whitespace and then to try to load the data from "XMLMods/" + that line + "/GameEntity/*.xml" (for GameEntity data; similar for other types)
    • So to create your own xml mod, just create a sibling copy of ExampleMod, add the name of that copy as a line at the end of XMLLoadingOrder.txt, and include whatever partial records (or just normal records, for stuff you're adding from scratch) you want in the copy's directory.
  • The version of unity in use has been upgraded from 5.5.0p3 to 5.5.2p2.
    • This has a variety of internal bugfixes to the engine, and may in particular fix -- or at least shed some light on -- a crash bug we're having on linux in certain circumstances at the moment.
    • We'll only be on this build for a few weeks, most likely, before shifting up to 5.6. The first non-beta build of that unity version is scheduled for March 31st, last we heard.
    • Note for staff/contractors: be sure to update your MonoBuild_MachineSpecificSetup.bat to the new location for the new version of unity, presuming that you're installing it alongside the current build of unity.
    • This would typically mean something like changing SET unityPath=D:\Program Files\Unity550p3\ to SET unityPath=D:\Program Files\Unity552p2\

Version 0.109 Special Forces And Modding

(Released March 9th, 2017)

  • The Special Forces Have Arrived.
    • The composition and target-planet selection are defined in AIWarExternalCode/src/AI/SpecialForces.cs , if you want to meddle. There are also a few new relevant constants at the bottom of GameData/Configuration/ExternalConstants/KDL_VanillaConstants.xml .
  • Now if you use the Scout All debug button you have vision on all planets until you quit that game.
  • Waves can no longer pick high mark ships from the very beginning; highest available mark is roughly 1 + (AIP/150).
  • The external modder/gui project is now ready for players to use, and we're also going to be doing our own gui images through that project, too.

Version 0.108

(Released March 9th, 2017)

  • The default launch of the windows build of the game is now back to being OpenGLCore. Since it doesn't have to decompress the BC7 textures on load, it's incredibly faster to load than DirectX9.
    • The problem with DX9 not working properly as an override in 0.106 was a misconfiguration in the steam launcher settings on 64bit windows, which we've now corrected. Now it can actually run either build, but unless overridden it will use OpenGLCore.

Version 0.107

(Released March 8th, 2017)

  • The basic fighter model has had some heavy visual work to get its emissive maps looking better, to tone down its normal maps, and to add an attractive metal map.
  • Now when a claim/repair operation is being slowed due to lack of metal, the line draws kind of orange.
  • Fixed a race-condition index-out-of-bounds bug in the visual layer stuff working with ship-to-ship lines.
  • Created a new PBL-based LOD2 shader that is now in effect, which keeps more consistency with the LOD0 and LOD1 values that are presently there.
    • LOD3 remains vertex-colored only, given it is so very far away and thus would have no point.
  • Removed the highlighting that happens on ships in a squad when the squad is selected. That just didn't look right.
  • All of the ship models now use the PBR rendering path rather than the rim-lit one.
    • Some will require a bit further hand-tuning, and in general there are still a few bits we're working on here. But in general, things already feel more lively.
  • A great deal more information is now shown about the current platform in the output.log startup log when the game starts. This will help us with debugging.
    • Thanks to Dar SelLa for inspiring this change.
  • The game no longer tries to do script debugging connections, which previously it was doing (as of 0.104).
  • A bunch of check code has been added for looking at the ship models and their setup, and finding and fixing any issues that would cause problems with them being selected or hovered-over or whatever other circumstance. It also helps to automatically correct a variety of other issues that might be found.
  • The game now has the furthest-in zoom at 11 meters lower than before, which lets you really see the ships up close and personal.
  • The windows build of the game is now once again DirectX9 by default, since it causes crashes for some folks when it's anything else.
    • We'll have it run in OpenGLCore mode as the secondary run mode that steam can invoke, rather than the other way around.
    • Thanks to Dar SelLa for reporting.

Version 0.106

(Released March 6th, 2017)

  • Fixed a potential render-texture-too-large error in the "there was an error" window.
    • Thanks to BadgerBadger for reporting.
  • The planet tooltip resource listing is now in a consistent order, rather than sorted from highest to lowest.
    • Thanks to BadgerBadger for suggesting.
  • Fixed the broken serialization issue that Keith noted in the prior version. Chris had meant to ask how to handle that for one particular line of code, but forgot, so that had broken saves. Hotfix is thus releaed.

Version 0.105

(Released March 6th, 2017)

  • In multiplayer each player is now issued a separate ark, and can only select (and therefore control) their own units.
  • Thanks to Unity actually now having support for detecting lost/gained focus (woohoo!) the game now suppresses input events like edge scrolling when the game window does not have focus.
    • Thanks to daktaklakpak for suggesting.
  • Patrolling enemy guardians no longer bum-rush you from across the planet. Instead you have to get within their patrol range (currently 1/4 the system diameter) or damage them in some way. Similarly, they won't deploy their internal ships until these things happen.
    • On the minus side, from your perspective, when you antagonize these patrol ships in this way they won't just come after you, they're _freed_ as threat and will devote the remainder of their existence to your demise. Isn't that sweet of them?
    • Note: as before, if you come in with a whole ton of force it may free all guardians on the planet. If you really overdo it, those guardians may just retreat to rain on your parade later.
  • The "give orders to units produced by me" toggle had tons of bugs and in general it's a very difficult concept to communicate correctly with the terribad placeholder UI, so it's been temporarily removed from the interface.
  • Planetary resources are now shown in the galaxy map tooltip for planets.
  • The AI's initial defense budget is now spent more on guardians and less on fleet ships and turrets.
  • Fixed a null-exception bug.
    • Thanks to BadgerBadger for reporting.
  • Reworked the revisions to planet mark levels, specifically for the surroundings of the human and ai homeworlds. Now some of their neighbors will be markI and markV again (respectively), and the next layer around that set (homeworld + I/Vs) is markII and markIV, respectively, and the next layer around that is a mix of roughly half-and-half 3s and 2s/4s (respectively).
  • Reworked initial AI defense population to be based on a number of guardians, caps of fleet ships, and caps of turrets. Before, with the non-linear growth in guardian strength but linear growth in fleet-ship/turret-strength it was very difficult to achieve the desired density of each.
  • Added Seed button to the game setup meu, so you can regenerate a different random map of the same type quickly.
  • It is now no longer possible to scrap the Ark.
    • Thanks to BadgerBadger for reporting.
  • Fixed an issue preventing the build queue from updating when a non-looping queue finished an item (so the item would just keep showing on the interface, despite being completed and thus removed).
    • Thanks to BadgerBadger for reporting.
  • Fixed an issue causing a "cannot build this now" situation to remove non-looping queue items; for instance if you hit the cap it would just remove the item even if it wasn't complete. The item should not continue producing in that case, obviously, but it should stick around to be fulfilled if/when there's room in the cap.
    • Thanks to BadgerBadger for reporting.
  • Reworked how button-set elements in the UI (like on the build menu) work so that they don't flicker as much and don't let mouse-clicks "through" if you click right as they're updating in response to you queuing something new, etc.
  • Fixed a bug where selecting a different planet and then starting the game would lead to your ark not having the pre-built build queue.
    • Thanks to Burnstreet and BadgerBadger for reporting.
  • Fixed a bug where pausing a unit like the Ark would stop all its resource production in addition to its unit construction.
    • Thanks to Dragondraikk for reporting.
  • Fixed an arithmetic underflow bug that was leading to the repairs of very expensive units taking inordinately long below certain health levels.
    • Thanks to gavin144 for the report and save.
  • Fixed a race-condition index-out-of-bounds bug in the UI.
    • Thanks to Toranth for reporting.
  • On windows, the game now uses OpenGLCore as the default rather than DirectX9. We'll see if we need to make any adjustments to that, and you can still override that to get DX9 using command line arguments if this new approach doesn't wrok.
    • Interestingly, this gives the same result of wormholes being a ring that we were seeing on Linux -- so apparently, that was an OpenGL/DirectX issue rather than a platform-specific issue.
    • This switch may result in better or worse performance -- we're not sure at the moment, and thought it would be interesting to experiment.
    • Either way, we've now also put in options in Steam that allow for you to select either mode directly from within Steam at launch.
  • ALL of the old starfields have been completely stripped out and replaced.
    • The new approach is using actual skyboxes (cubemaps), which uses more VRAM than before, but gives a higher-quality result.
    • However, it's also a bit more efficient in a few other ways, and uses 100MB less of disk space for all the color variants we now have, as well as using less general system RAM.
    • This is something we wanted to do simply for stylistic/quality reasons -- making the game look better.
  • Created a custom variant of the unity 6-sided skybox shader that allows for rotation in all three axes rather than just one axis, and that allows for HSV shifts, and that doesn't bother with exposure multipliers.
    • This allows for us to have a simple set of four overall skyboxes for starfields, and then recolor them in realtime on the GPU as needed.
    • Given the efficiency of even a kinda-okay modern-ish GPU, this is not a giant trouble for it. However, it (again) allows for a better result without a ton more system RAM usage.
  • The planet in the game view has been shifted to now be a part of the "space background" camera, so it will never intersect with anything in the game field anymore (not the Ark, not wormholes, nothing).
    • Thanks to gavin144 for reporting.
  • Adjusted the glow post-processing effects fairly substantially to work better with the new space skyboxes. The new glow processing is a bit more intensive, but it shouldn't make too big of a difference even on weaker GPUs.
    • If it does, then we can introduce options to take this back down to 3 mip levels instead of 6, and to use a lower-quality detection for glowing elements. This just doesn't seem to be enough of the typical load to warrant those options at the moment, though.
    • Overall this leads to a very different look for certain elements in terms of how they glow. The squad icons are most notable in this respect, but those are in the process of being reworked anyhow, so they're considered temporary at this point.
  • A couple of the ships -- fighter (kinda), bomber (fully), forcefield generator (fully), and space dock (fully) have been adjusted to use PBR lighting rather than custom rim lighting.
    • This is something we're experimenting with still, and it's basically a WIP on all fronts there. We likely won't have anything definitive in this area until Thursday at the earliest.
    • Overall this is letting us do a bit more with visual fidelity, but we're still experimenting on that.
  • The raycast distance has been increased for when you're trying to click things in the galaxy map or the main view, so that something is never too far away for you to hover over it.
    • Additionally, the clickable/hoverable area of planets on the galaxy map has been increased so that they are easier to click in general.
    • Thanks to BadgerBadger for reporting.
  • In the default control scheme (which later can be remapped anyhow), the arrow keys now work for controlling the cameras just as well as the WASD keys do.
    • Thanks to dfinlay, jerith, and BadgerBadger for suggesting.

Version 0.104

(Released March 3rd, 2017)

  • Fixed a null reference bug with the build queue buttons that could cause the buttons to go blank.
    • Thanks to dfinlay for reporting.
  • Fixed a bug where units like space docks still in the process of self-building could themselves repair other units, etc.
  • Fixed an issue where possibly some of the DLLs were out of date on the linux build, or something of that nature -- at any rate, everything is synced up now.
    • Thanks to BadgerBadger, RabidSanity, and gavin144 for reporting.

Version 0.103

(Released March 2nd, 2017)

  • Fixed a bug where squads were being prematurely killed if their current ship count was zero but a replacement ship was on its way. This could lead to invisible squads until you tab out and back into a planet.
    • Fixed a related issue where a nullref exception could happen if the replacement ship got there and the squad was already removed.
    • Thanks to BadgerBadger for reporting.
  • Planet mark level assignment now mostly avoids planets being more than one mark away from any of its neighbors.
  • Fixed a bug where ships scrapped while under shields would damage the shield rather than die (though the squad would be reduced to one due to another part of the logic).
    • Thanks to Zogheen for reporting
  • Fixed a bug where loading a save would not actually try to do any visual updates of units, so you'd just not see them at all even though you had vision and the game was running, etc.
    • Thanks to BadgerBadger, treyra, Toranth, and bladeravinger for reporting.
  • Reimplemented the pause feature as literally "the game keeps running, but instead of each sim frame being 10% of a game second, it's 0% of a game second" with a few small bits of code excluded from running at all (like "try to fire the guns").
    • This avoids a whole class of problems like placeing or scrapping stuff while paused not updating your net power, etc.
    • Thanks to Zogheen for inspiring this change.
  • Actually implemented the logic for "click on a planet in the lobby and that becomes your new starting place"
    • Note that this involves regenerating the map, so you don't start on a MkIV or whatever.
    • Thanks to BadgerBadger for badgering us about this function.
  • Reworked the X map type since the old one was doing weird things with many planets being placed on the same spot, etc.
    • Thanks to gavin144 for reporting.
  • Added a button to the game-setup phase for exiting back to the main menu.
    • Thanks to dfinlay for suggesting.
  • Now during game setup the planets no longer show their marks and what key units are there.
  • Fixed a few bugs that could cause the game to go bonkers if you switched through map types really rapidly in setup.
    • It will still be a bit weird because clicking the button means "switch to the map type after the one that generated last" and so if you mash it three times really fast it will wind up at the same one as if you'd only pressed it once. This will be fixed when we add a proper dropdown for this, rather than relying on a primitive spinner-type button.
  • A number of internal scripts were added that makes it much faster for Chris to push builds. Down from 5-15 minutes depending on the nature of the build, to instead 30 seconds to 2 minutes depending on the nature of the build.

Bleeding Edge Graphics Test (Linux In Particular Please Try!)

Basically, if you look inside your game folder you will now see a BleedingEdgeTest subfolder. If you go in there, there are a few executables. Please run the one that is for your OS, and let us know what happens.

From the whatisthis.txt file inside that folder:

  • You may notice that this isn't AI War 2 at all, in this folder. This is just a simple little scene that you open and look at, and it does nothing. HOWEVER -- it's running on a newer version of Unity than the game itself (5.6), and it's using Vulkan on windows and linux where possible.
  • The idea is to use this as a simple benchmarking tool to say "can this even run?" on various machine configurations, particularly on Linux. This has no bearing on performance or anything of that nature; it's just a matter of "will this launch and actually show the screen without barfing out a blue screen on linux."

Version 0.102

(Released March 1st, 2017)

  • Added some internal code that helps Cinth do live-testing for LODs, which thus lets us get better results from them. Right now our initial LODs were way too cut off, which was one thing that was leading to such unexpectedly good performance most likely.
  • LOD adjustments on smaller scaled models to make them more visible and attractive at standard game zooms and sizes.
  • Team color brightness adjustments, pattern change on red.
  • Adjusted the size on the numerals to help with flickering at ultra far zoom.
  • Updated the game to no longer allow for drag-resizing the window, since that can wind up really confusing things when you're trying to click near the edge of a window.
    • Thanks to Thalone for reporting.
  • New lower poly gimbals for the Fighter, Bomber, Missile Corvette, Laser Turret, MLRS Turret, and Needler Turret.
  • Completely redid the gimbal shaders from the ground up so that they are now more efficient, view-direction independent, and less neon-blinding-you.
    • No fresnel effect is used at all anymore, and normals/uvs are completely ignored, with it instead using part of the tangent data as the uv channels and then feeding that into a two-color emission blend mixed with an underlying diffuse texture that is mostly used for value (but also a bit for hue).
    • TLDR: Much nicer results, less work on the GPU (not that it was expensive before, terribly), and also easier to configure.
  • 13 New Team Colors
    • Cinth made these to look more flat
  • Fixed a bug where resizing the game window during runtime would not properly reinitialize the UI.
    • Thanks to daktaklakpak and others for reporting.
  • Game now shows the current version in the upper-right corner under the hide/show gui toggle.
  • Changed the behavior of the "Try to Capture" toggle to not prevent _direct_ attack orders on an enemy controller or warp gate.
    • Thanks to many of you for inspiring this change.
  • The game no longer uses unity-style "performance profiles," but instead uses our own settings under the hood for the following, which you can now edit in your settings.dat file:
    • IsFullscreen (actually used now!)
    • FullscreenWidth and FullscreenHeight (actually used now -- when in fullscreen mode only!)
    • WindowWidth and WindowHeight (actually used now -- when in windowed mode only!)
    • VSyncCount (valid values of 0, 1, or 2 -- please, please use 0 for the sake of performance).
    • UseSoftParticles (valid values of false or true, default false; doesn't make a big difference either way; last build this was true, though).
    • BillboardsFaceCameraPosition (valid values of false or true, default false, was true last build, doesn't make a big difference either).
    • AnisotropicMode (valid values of Disable, Enable, or ForceEnable; default is ForceEnable, same as last version).
    • AntialiasingMode (valid values of Off, x2, x4, or x8; default is x2, down from x8 last build).
    • TextureQuality (valid values of Full, Half, or Quarter -- this will make things look absolutely terrible if reduced from Full, but can be useful for truly ancient GPUs; probably nobody should use this).
  • Whenever the graphics settings are updated, it now writes to your output log to say what it did. It does them all in one batch whenever the game flags there as having been changes, which helps keep things efficient.
  • Fixed a bug during game setup where regenerating a map (from changing the map type) could lead to the game trying to re-draw the map before generation was done, leading to chaos.
    • Thanks to Dominus Arbitrationis, daktaklakpak, and Jeremiah921 for reporting.
  • Fixed a bug in some map types (notably Wheel) where the mapgen would fail due to not being able to find a planet X hops away from the human starting point and Y hops away from the AI homeworld.
  • Fixed a bug where doing multiple map generations would not properly remove the remains of the previous generations and would try to draw them when you started the game (i.e. Ghost Arks).
    • Thanks to Zogheen for reporting.
  • Tightened up the time between giving a move order and it taking effect. The main difference will come in tightening up the visualization layer to react more quickly, but this should help in the meantime.
    • Thanks to Cyborg, Zogheen, and many others for bringing this up.
  • Added an Exit Game button to the in-game "escape" menu (opened from the upper-right "Menu" button) that dismantles the game and puts you back at the main menu.
  • Added an Exit Game button to the main menu that closes the application.
  • Fixed a bug where switching between various build menus, etc, would not properly clear the previous menu's buttons out.
  • Now when an error occurs in the game, it shows it to you clearly with three options: open the log file, ignore the error, or ignore the error and prevent this window from opening again during this run of the application.
    • Previously you didn't know there were errors unless something obviously bugged out or you checked the log file. No wonder players thought the game was so stable! (just kidding... mostly)
  • Fixed a bug where trying to connect to a remote host, and then trying to start your own game, would throw errors because the game had not switched out of MP-client mode.
    • Thanks to Cyborg and waylon531 for reporting.
  • Now when a ship dies or enters a wormhole, any shots it had already fired but were visually delayed (so that you could tell there was more than one shot) skip the rest of their visual delay so you don't see a continuing stream of shots from the now empty space in cases of stuff like MLRS with very high rate of fire.
    • Thanks to Zogheen for reporting.
  • Now when the game ends (i.e., you lose) you now get vision and intel on all planets (previously it would look like everything despawns when you die).
    • Thanks to Cyborg for inspiring this change.
  • Removed several old debugging keybinds, including some that could break the game if you pressed the wrong key.
    • Thanks to Cyborg and Zogheen for reporting.
  • Replaced the Snake map type (which was generating maps that filled way too much space) with the Spiral map type; looks different but has exactly the same topology.
    • Thanks to Dominus Arbitrationis and Lakshata for inspiring this change.
  • Improved several map types to be way less likely to have two neighbors at the same "angle" such that the wormholes to those two neighbors exactly overlap.
  • Added a new DisableShipFlameTrails settings option that lets you turn off flame trails on ships if you wish. For the super low end hardware, this may be a big deal, we'll see. The batching is really good on them, but for the lowest-end hardware it might make a notable difference just beause of how many pixels can get drawn.
  • Added the ability for windows machines to use OpenGLCore if needed, instead of being forced into DirectX9.
  • A ton of new settings have been added for letting you control the speed and responsiveness of both the galaxy map camera and main game camera. All of this is still just in the xml at the moment.
  • Mouse edge scrolling can now be turned on or off, and is on by default.
  • Expanded ship tooltips, both in the information shown and in the space used.
  • Added tooltips to build buttons for ships.
  • Fixed a bug that was making the UI update much less often than intended (was supposed to be every 333ms, and was closer to every 700ms), and since that still felt a bit sluggish in testing it now updates roughly every 100ms.
  • The game is now properly using dev builds that allow us to get proper stack tracks from you. That means it will be saying "DEVELOPMENT BUILD" down in the lower right corner in an annoying way we can't control, but it greatly speeds development.
  • The default window state of the game is now windowed, with the window size being 3/4 the size of whatever your screen is. You can change this in settings, but it makes for a pretty pleasing first size for most people, most likely.
    • It won't go any smaller than 1024px wide or 768px high in terms of the initial default, by the way -- but you can set it lower than either if you feel you must. ;)

Starting State (as of v0.100)

Okay! So the title of this document is somewhat-facetious, but it gets at the intent behind this first phase. This earliest phase of the alpha is not about being able to play end to end and thumb your nose at all the suckers who are waiting for a later build for no particular reason.

"Earlier than early alpha," in this case, means that we're getting you in place to see what is going on absolutely ASAP. There are some folks who will relish this opportunity, and who have specifically requested it -- they then get to help shape the balance and details of our implementation of the game from the earliest days.

Ever hear developers say "well it's too late in the process for us to change that now" and feel frustrated that you weren't consulted earlier? This is us consulting you super early. Nothing is too late in the process, because this is "earlier than early."

To someone coming to this first build without that context, they may go "holy cow, what hot mess is this." This is not your typical alpha. We'll be to that point in a month or two. If you want the typical alpha experience, then feel free to register your steam key now and just wait around for the go-ahead from either other alpha players or Arcen staff to get a more typical experience.

On the other hand, if you want to be in there from minute one... well... welcome! We're sure glad to have you, and excited to show you what we've been up to. :)

If you're one of the many who struggle with playing the game such an incomplete state, check out the instructions

We also have a blog at https://blog.arcengames.com for dev diaries and other fun topics.

Also, here's Chris's todo list

Retrieved from "https://wiki.arcengames.com/index.php?title=AI_War_2:Earlier_Than_Early_Alpha&oldid=33491"