AI War 2:Making Alpha Fun

Starting State

Okay! We've extended the alpha period beyond what we had originally intended, but we're going ahead and giving out the Early Access keys to kickstarter backers on the date we originally specified. Meanwhile, we're pushing the date for early access back. That link explains a lot of the reasons.

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.

And here's what we've been doing for the last few months

Known Issues

• The sidebar on the left side of the screen, which should show your ship counts and so forth, is removed at the moment as we update it.

• The interface in general is horrible, and you need to go into the PlayerData folder and edit your settings file manually if you want to make settings changes.

• In very large battles, there are still some performance bottlenecks that we intend to address. All on the visuals/fluff side, not the core simulation, thankfully. We've gotten most of the heavy-hitters thus far, though.

• Various ships are implemented but don't have real graphics, so they just show a little "rock" instead where the ship graphic would be. You can still see the ship icon and whatnot just fine.

• All ship shot types use the same graphics right now.

• No sound effects yet, and only a couple of music tracks.

• Particle effects are also limited.

• Ships currently just sit there in their squads, rather than flying around within their squads.

• Not quite all of the baseline ships are implemented off our pre-Early-Access list, but we're pretty close!

• Various bugs on mantis: https://bugtracker.arcengames.com/view_all_bug_page.php

• Balance needs a lot of attention, with your help.

• There's no tutorial yet, and there's basically not much in the way of a lobby beyond map types and seed. You can't choose your player color yet, even.
  • Compared to the actual gameplay mechanics, we felt like these were ancillary things, but they are coming up in importance sooner than later.

What Is The Purpose Of This Phase?

Short Answer: To make the game fun, which it is not yet. Please don't fret on that!

Long Answer: There's still a lot to do on the game obviously, as stated in the last blog post. But there's a lot of good stuff here to tinker with now, and we're really looking forward to having more people bashing on it. It's not a "fun, balanced game that just needs some polish" yet, but it will be really useful for us to have more people finding the pain points both in the interface (which is currently atrocious) and the actual gameplay flow (which, from a macro standpoint, is still pretty immature).

The underlying technology and components for making a fun game are here, and that'd a very critical step towards it being a fun and balanced game, but that's not where we are just yet. In a lot of respects we kind of reordered things: the underlying tech is somewhat more advanced and more polished than we had anticipated at this point, and that is pretty important because it gives us a better idea of what we CAN do in the engine. It gives us a better bounding-box for setting up things so that we can build an interface around what is possible, and have the scale of battles reflect what is possible performance-wise, and so forth. On that front, I'm super happy with where we are.

But yeah, the next step is to finish implementing the last of the "before early access" ships, and then to actually make a GUI that isn't eye-gouging as well as a game flow that doesn't have any obvious deficiencies. Right now there are some notable concerns about parts of the game flow regarding how you don't really need to keep territory as much as in the first game, and certain other bits of the feel from a strategic standpoint are "off." Some of that is just because xyz AI feature maybe isn't in place yet, but other pieces are more about the design of certain ships or mechanics. These are things we want to iron out before we go full-Early-Access, and we need the help of folks like you to do so. We're trying to streamline certain aspects of the first game, but we don't want to do that at the expense of what made the original game cool.

The engine for this one is so flexible that we could just recreate most of what the first game was if we felt like it, but we'd really rather not for a variety of reasons that should be apparent to anyone who tried to get into the first game and bounced off it, or who played the first game for a huge number of hours but wanted certain fundamental improvements. Now that all the basic frameworks are getting in place here, we're at a point where we can start thinking about those things.

Version 0.402

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

Version 0.401 Ship Batch 6 of 7, And Gimbal Perfoooormance!

(Released June 12th, 2017)

• The game console has now been fully moved to the AIW2ModdingAndGUI project (source code aside), and has been re-skinned using our own graphics and text mesh pro.
  • This may not have seemed like a high-priority thing to do, and indeed it was not in and of itself, but it validates a particular GUI creation workflow that we now have, as well as providing a concrete example for that type of GUI.
    • Basically our existing GUI creation methodology is all based around xml creation of things and populating them certain ways.
    • But now we can also take an entire GUI canvas, create it in the WYSIWYG unity editor in the AIW2ModdingAndGUI project, and then wire it up in a completely traditional-for-UGUI fashion and after that let it be triggered from the dynamic GUI. These are even loaded using the existing "gui prefabs" logic that the xml-oriented GUI uses.
  • The end result is just as performant in both cases (and basically identical), and so mainly the question is of which approach is easier for a given piece of the GUI. There's no one right answer. Even the xml-oriented version is using prefabs that have a bunch of nested stuff, but this is just taking it to a completely other level of having the entire canvas/window populated.
    • At any rate, being able to do this now and having an example of how to do it was well worth the time in this particular build. It should open up options better for the upcoming GUI revisions.

• A massively new way of drawing the "sprite gimbals" over squads in the game is finally complete.
  • We tried a variety of approaches, but for various reasons dynamic batching, instancing, and so forth all yielded subpar results when individual sprites were made up of often up to 6 sub-parts (main icon, border, flair, mark level, and health bar).
  • We're now baking the sprites into meshes prior to them ever being instanced, which cuts the graphics load of the gimbals to around a sixth of what they previously were.
  • That said, the sprites themselves still need to be instanced even after being baked, and to do that we need a single mesh for all the types for the most part. So we're hiding data in the uv2 and uv3 channels that let us know which instance properties to conditionally apply to which vertices, which in turn lets these things colorize themselves (via HSV shift) as needed. But since not everything needs to be colorized, our new ubershader for the baked group is now actually more efficient than before, making the savings more than a drop to 1/6th of the previous load from this source.
  • Performance improvements in this area might not seem like that big a deal, but on a GTX 1070 with 5k ships on the screen, the icons were approximately half of the visual load. Facepalm, right? So this has been a big priority.
  • The downside of the new approach would seemingly be that now these icons are harder to edit, though, if someone wants to mod. Bummer... except that it's just as easy as ever! :D
    • We've created editor tools in the AIW2ModdingAndGUI project that allowed us to merge meshes, set the uv2 and uv3 channels properly, and so on. You can re-bake the meshes as desired, and we can do so quite easily as well. You can't do it by xml anymore, but that's a pretty small thing.

• Fixed a bug in the prior build where the gimbal icons no longer reacted to player mouse hovering or clicking.
  • This was because of the changes in the hierarchy of pieces of squad parts in the last version.
  • Thanks to TheVampire100 for reporting.

• When you are placing ships/structures on the map, there's now a filled circle that shows the radius of the footprint that ship will take up. It then also shows the icon of the ship in white over where the footprint is.

• Fixed an issue where the missile turret was not assigned its flair properly.

• The game now automatically checks its models for missing materials, or materials not set up for instancing.
  • There were then a number of ships that we fixed that on so that they have instancing set up properly.

• The font_size property now actually works on the new text labels in the game (not buttons or anything else presently).

• The game now has icons for the various resources, which can be inserted into text with <sprite> tags from text mesh pro.
  • Unfortunately the process for getting those in there requires the creation of sprite dictionaries embedded in the main game Resources folder at the moment. We will likely alter that at a future time, but for now that's stuck.
  • The process for getting new sprites in there is pretty convoluted in general at the moment, to be honest, so that's again something we'll have to work on later. But it does work, and it does perform well!

• Fixed a bug where "dfgdfg" would show briefly as the planet name in the prior build.
  • Thanks to BadgerBadger for reporting.

• Updated to Amplify Shader Editor v1.0.005, which has a number of new features and some at least minor performance improvements.

• Fixed an issue with the AI Warp Gates not having their mechanical parts rotating properly.

• Put in some code to automatically tell us when our animators have messed up.

• The game now has a nice fade-in effect whenever you're switching planets or in and out of the galaxy map, making things feel more polished.

• Fixed a problem with the mod support where every dll had to define a type which implemented the IInitialSetupForDLL interface, and further required a specific naming convention for that type.
  • Now when loading a dll it looks at all types exported from it and runs the RunInitialSetup() of each IInitialSetupForDLL it finds.
  • If it doesn't find any, it won't mind.
  • Thanks to Draco18s for reporting.

• The very low end of the camera zoom now has a few more gradations where it shows more of a side-facing view, and then the very lowest zoom level actually looks back UP slightly, allowing you to see tall ships and structures better, and in general get a little more cinematic of a view. This has no effect on the higher zooms.
  • Thanks to BadgerBadger for inspiring this change.

New Ships

• Bonus Fleet Ships:
  • Vampire Claws
    • Cloaked melee ships that heal themselves when they do damage.
  • Vorticular Cutlasses
    • Melee ships that damage themselves when they do damage (when balanced, their dps will be much higher than vampire claws, for example).
  • EtherJet Tractors
    • Cloaked Jets with Tractors. What could go wrong?

• Dire Guardians:
  • Dire Warp Beacon Guardian
    • The AI can always send waves to the planet this guardian is on, and if it is on alert this is likely to happen.
    • Not to be confused with the Dire Warp Bacon Guardian (despite internal typos to the contrary), partner-in-crime to the Pancake Golem.
  • Dire Commander Guardian
    • Increases reinforcements sent to the planet it is on.
    • Triggers waves (like a raid engine) while this is on alert.
  • Dire Shredder Guardian
    • Internally constructs and launches shredder drones (vicious little melee ships).

• Guardians:
  • Vampire Guardian
    • Can be very hard to kill if you don't kill it quick, because of its ability to heal itself from doing damage.
  • Implosion Guardian
    • The Dire Implosion Guardian's little (and far more common) brother. They're a real pain in the rear if you're a golem...

• Golems:
  • Seeded like Flagships, you find these, clear their planets, and claim/repair them to gain control of them.
  • Unlike flagships, these are rarer, claiming them costs AIP, and they don't have the quasi-Ark functions for building/repairing/etc. Instead, they're considerably more beastly than Flagships and some have unique abilities.
  • Armored Golem
    • Short-range brawler.
  • Artillery Golem
    • Long-range sieger.
  • Black Widow Golem
    • Massive paralyzing-tractor capacity, and does engine damage with its shots.
    • The "if you move while tractoring something, it moves with you" logic has also been implemented.
  • Regenerator Golem
    • Regenerates ships you lose on its planet, at the cost of some of its own health.
  • Cursed Golem
    • Has powerful fast-firing railcannon, but damages itself in proportion to the damage done.
  • Hive Golem
    • Internally constructs hive drones, which it launches in large groups against any threat on the planet.

Version 0.400 Usability and the GUI Pipeline

(Released June 6th, 2017)

Usability Improvements

• Reorganized the bottom menu to better emphasize the function most people expect from the number keys in strategy games with real-time simulation. Namely: control groups.
  • So now the 1-9 buttons along the bottom of the screen are the control groups 1-9.
  • And the 10th button (button 0) is a "Menu" button that opens the master menu that used to be there.
    • Though that no longer has the "commands" sub-menu.
  • If you have a selection, the game shows the commands menu (as a bar instead of a stack) above the bottom bar, and the 0-9 keys map to that instead of control-groups/menu.
    • And backspace will cancel your selection (if you have no deeper foldouts), thus returning you to the bottom-bar context.
  • The upshot is that if you select your Ark, you'll see a "Build" button in the command bar at the bottom of the screen, among other things an Ark can do. Similar with other unit-producing things.

• The buttons in the command menu (now shown whenever you have a selection) now are only visible if they can be executed with the current selection:
  • FRD only shows if there's a mobile military ship.
  • Scrap only shows if there's a non-Ark.
  • Build only shows if there's exactly one type of builder unit.
  • Hacking and Warheads only shows if there's the Ark.

• Added some direct keybinds for the sake of near-term sanity:
  • P
    • Toggles pause.
  • B
    • Selects a builder unit on the planet and opens the build menu.
    • If a builder is already selected, selects the "next" builder, if any.
  • T
    • Opens the tech menu.
    • If tech menu is already open, closes all menus.
  • Escape
    • Opens the system menu (save/load).
    • If system menu is already open, closes all menus.
  • Space
    • Closes all menus.
  • You can change any of the above in your inputmappings file.

Visuals And Moddability

• TextMesh Pro has now been integrated into the game (version 1.0.55.56.0b9). We have the paid version, but we're using the free version so that we can include it with the ModdingAndGUI project.
  • This lets us do a lot more advanced text rendering at no extra performance cost, as well as giving us basic functionality like proper kerning.

• The first place we've set to using TMPro is the galaxy map, where now the text is both in a better font as well as a lot more readable.
  • The actual places where the fonts are set up for the galaxy map, and things are oriented around planets, is now also in the ModdingAndGUI project so that it can be edited by folks as desired.

• Darkened all of the new skyboxes to fit with the new HDR rendering.

• Made it far easier for people to edit skyboxes quickly, thanks to a new button in the header of the skybox editor.

• The ruined network nodes now have proper graphics.

• The advanced starship constructor now has proper graphics and animation now.

Misc

• Fixed a bug where saves triggered in the save menu could happen while some changes to gamestate were still ongoing, leading to the data being saved in an inconsistent (and sometimes non-loadable) fashion.
  • Also added a warning message that will show if this particular corruption happens again, though it shouldn't be able to.
  • Thanks to BadgerBadger for the report and save.

• Fixed a bug that could cause a hang in the mapgen logic.
  • Thanks to drspikes and BadgerBadger for reporting.

• Fixed a bug where various internal tech-groupings were showing as selectable menus (ironically named "Not Shown").
  • Thanks to BadgerBadger for reporting.

• When there is invalid data somewhere on trying to load a ship that does not exist, the game now does a better job telling you what the heck is happening. This would mainly be something helpful to modders and us devs.

• Put in massive numbers of performance improvements in how the GUI interfaces with unity.

• Put in a bunch of new error checking on the GUI side, so that if things are set up wrong at any point, it now yells instead of failing silently.

Version 0.301 The New HDR Visual Stack

(Released May 30th, 2017)

• Engine Damage Repair has been implemented.
  • Works similarly to hull/shield repair, but does not actually cost metal.

• Changed balance_seconds_per_fight to 15 from 20, and balance_seconds_per_shot to 2 from 4, massively speeding up the feeling of combat from what it felt like in the prior version. It's now much more like what it was in past versions, without having such bullet spam in giant battles that there's a bunch of slowdown.
  • Thanks to BadgerBadger for reporting.

• Fonts are now sharper in the GUI, although there's still room for improvement. Blurriness causing legibility problems is a definite issue to some extent still.
  • We've also updated the font on the small buttons at the bottom of the screen to be more readable, although we still want to update that even further in the future.
  • Thanks to Sounds and BadgerBadger for reporting.

• New backgrounds for dropdowns.

HDR Graphics!

• We had thought this wouldn't be possible with our visual style as recently as one version ago, but it turns out it is!
  • Also, prior to version 5.6 of unity, it literally wasn't possible at all, at least not without losing hardware MSAA support (which is the best sort of antialiasing available these days, and fastest).

• The game now uses HDR graphics for the main camera, allowing for a better color range and fancier lighting effects, etc.
  • One of the most obvious examples is the way the rings on the end of the laser turrets glow very bright blue now, whereas before they would white out fast and so we had to keep them pretty non-bright.

• We're using a new reflection cubemap against our scenes, and have tuned a ton of the materials to have better values to give themselves really high quality results without an over-blown specular highlight at certain angles to the main scene directional light.
  • Kinda related to this, we're doing new tonemapping now, which maps back down from HDR to the LDR range better, and helps give us a richer color without things having to be so darn glowy _everywhere_.

• The bloom effects have been completely replaced with another set, which is able to use a lot more precision in what it does.

• The game now uses the bloom and tonemapping from the relatively-new official unity postprocessing uber-stack.

Known Issues

• Thanks to the tonemapping, the backgrounds are presently too bright relative to the ships. We simply didn't have time to get to that, and didn't want to hold up the rest of this release over that.

AIW2ModdingAndGUI Capability Updates!

• Since this unity postprocessing uber-stack is freely available, and even open source at that, we're now able to show you actually what ships would really look like in the real game when you are working in the AIW2ModdingAndGUI project.
  • This is enormously important in particular for being able to reliably set up the space nebula backgrounds, which have their characteristics altered some by the post-processing stack and which you need to be able to see in order to properly create them.
  • As part of this, we're no longer using Amplify Bloom or Beautify.
  • Also as part of this general work, we've updated all the various shaders and ship models and materials in the examples folder there.

• To aid in background creation, as well as in general giving more examples of ships and how their shaders are used, there are a bunch of new ships that have been added to the example project: data center, lightning corvette, mlrs corvette, spider, and starship constructor.

Bugfixes

• Fixed a bug in the improvements to shot staggering that caused divide-by-zero errors when the game was paused (because it actually runs zero-length frames during that time so the game can still respond to you).
  • Thanks to BadgerBadger for reporting.

• Fixed a variety of errors that could happen with accidental extra calls to clean up objects (those extra calls are GOOD, since they often are coming from a few sources that need to double check things properly). This should also help performance minorly when objects are destroyed compared to pre-0.300 versions.
  • Thanks to BadgerBadger for reporting.

• Fixed some bugs that could prevent shield repair.
  • Thanks to BadgerBadger for the report and save.

• The sidebar is removed temporarily, since it was so busted anyway and overlapping things strangely.
  • Thanks to BadgerBadger for reporting some of the related issues it was having.

• Fixed some bugs that caused the build menu buttons to collapse into a pile in the bottom-left of the screen.
  • Thanks to BadgerBadger for reporting.

• Reworked the "Quit Game" button on the master menu to no longer be a "immediately chuck the gamestate into the grinder" function, but rather "tell the game that once it's done executing the current sim frame to close the gamestate". This avoids various race-condition null exceptions when quitting while the sim threads are going.
  • Thanks to BadgerBadger for reporting.

• Improved the inter-cluster connection logic of Clusters to be much less likely to draw long connections that overlap other clusters.
  • Thanks to BadgerBadger for reporting.

Prior Release Notes

AI War 2:Earlier Than Early Alpha