AI War 2 v0.607 Released! “Don’t Die Harder, Die Smarter”

Release notes here!

Don’t Die Harder, Die Smarter

This one goes a long way towards making AIW2’s units much more enthusiastic about their jobs.

AI Waves (and Threat in general) now behave in a much more intelligent fashion. Well, except for the enforce-stupid-refusal-to-retreat-for-30-seconds change, which just makes it less annoying. Less annoying to you. Very annoying to the AI.

All ships (not just AI) benefit from the targeting changes that greatly reduce lost efficiency from overkill, and from the pathfinding changes to prefer less dangerous routes where it’s still efficient.

Not many interface improvements this time around, but I know many of you will be happy to see range rings when placing turrets. (You’ll also be able to place more turrets, thanks to the power balance change)

Tachyon units now take their job seriously, and can actually reveal cloaked enemy ships in a reasonable period of time. At least if it’s a reasonable quantity of them. Otherwise you’re still going to be target practice for a bit, but at least you’ll have something to shoot back at.

Even the simulation itself is working smarter, thanks to zealous application of the Ostrich Algorithm for planets with no opposing forces.

And there’s a few other things in there, like a new AI type that loves cloaked units.

Enjoy!
Keith

AI War 2 v0.606 Released! “Input-astrophe”

Release notes here!

This one is about input.

Camera input. Chris redid the entire camera system, and now it’s much more configurable in the Settings window (and the code itself is massively moddable). The “Free Look” mode is a major new thing, but the default view is also very different, in response to player feedback about acceleration, etc.

Keyboard input. Each binding can now support more than one mapping, so both P and Pause/Break can trigger pause, etc. Several bugfixes and changes to make certain keys do what you would expect. Making the unit-commands context menu not open automatically to prevent conflicting with control group number input, and so on.

Mouse input. Added a much-requested feature from AIWC where bandbox selection ignores non-military ships unless they’re the only thing there. Made clicking planets in the galaxy view do what it did in AIWC (“go there” instead of “select this”; you can still select with alt+click). Fixed a key bug that was preventing mouse interaction with ship icons.

Saving you lots of input. The new “budget policy” concept allows you to give high-level commands about how your metal should be allocated, from the simple “suspend spending until we’ve saved up” to the amusingly complex battle-support policy that has multiple levels of prioritization and looks at whether a unit is on a contested planet, etc. This is fully moddable, so if you want to script your economy you can just about do so.

There’s a few other changes as well, including a helpful bit from community member BadgerBadger that reimplements AIWC’s model of waves being planned, announced, and then launched after a countdown instead of just immediately spawned (previously the timer was a projected estimate of when it will be). It’s great to see the modding tools put to good use 🙂 Thanks, Badger!

(if you’re wondering where 0.605 went, I think it had a run-in with the Devourer)

Enjoy!
Keith

AI War 2 v0.603 Released! “Banishment of the Bottom Bar”

Release notes here!

One resounding theme of recent UI feedback is “the upward-expanding pile of buttons at the bottom has got to go”. So for this release we told all the functions in that menu “you ain’t gotta go home, but you can’t stay here”.

The result is a general layout of:
1) Passive info on the top half of the screen
2) Interactable controls on the bottom half
3) Stuff pertaining to your selected units (if any) on the left
4) Stuff pertaining to your selected planet on the right

There was also a major switch in the graphics pipeline (now using Alloy since it recently became open-source and we could thus let modders have access to it) and a move of a ton of visualization code into the external-visualization project, which greatly expands what modders can impact.

Enjoy!
Keith

Some screenshots of newly-painted PBR ships.

These ships are painted by Blue using Substance painter — well, overpainted by Blue.  These were ships that she had previously painted in photoshop directly in a cel-shaded fashion, and which now she’s overpainting to give it a mixed realistic look.

It’s worth bearing in mind a couple of things:

  • These are screenshots from Substance Painter, so it will look a bit different in Unity.   See my recent videos on that subject.
  • These have emissive parts on them, but that REALLY doesn’t show up properly in the substance painter view, so you’ll have to imagine that part for now. 😉

Autocannon Minipod

Old:

First revisions:

My main note on that was that it didn’t feel beat-up enough, although beyond that I really love it.  And, um… what a difference, right??

Newest:

Aww yiss, now we’re talking.

Fighter

Old (although with some improvements that were overdue on the cel-shaded part):

New:

I just love the fighter, with how metal and beat-up it looks now.  It should do particularly well in the in-game lighting and with the lightmaps on. 🙂

Armor Ship

Old:

New:

I also really love the metalness here, and the added details.  I’ve asked about adding a variety of scorch marks on that, though.  We could do a variety of smart masks and then make them black with a very high roughness and potentially low metalness and that effect happens easily.

Bomber

Old:

New:

Overall I really like the bomber, although it feels a bit too gleamy-shiny in some ways.  Maybe having it a bit more worn of a metal as a base there is something we’ll do — or just introducing layers of wear.  I love the scratches we have going on.

Eyebot

Old:

New:

The eyebot is perfect, I love that glassy look it has and how perfect it seems in a lot of ways.  Really a different form of character to it, which is fantastic. 🙂

That’s all for now!

Just thought I’d share a bit of the progress that is being made.  Now I guess that our main problem is that these ships are drawn so bloody small in the battlefield — relative to the camera — that all that awesome detail is lost…

We’ll figure it out.  Someone on kickstarter was mentioning the same thing.  Maybe the answer is smaller squads of larger ships, or using more verticality to fit larger ships in the same radius, or who knows.  I don’t want to shrink the feeling of scale of the game, but at the same time we want to be able to see more than just the icon-fest, at least when zoomed in.

 

More AI War 2 art-related videos!

Figured I’d cross-post this new batch:

The above is a tutorial for Cinth on how to get things ready for Blue to do her painting in Substance Painter. It doesn’t handle the old-style of very-high LODs for us yet, but it gets all the rest of it.

The above is a video for Cinth on how we need to update our existing ship definitions to fit with our new “one material only” approach, which relies on mipmaps and GPU instancing for the bulk of its efficiency, rather than on baked vertex colors and dynamic batching.

The above takes a look at the newly-free alloy shader framework, which we’ve used in other projects, and looks at the difference in quality when we’re now integrating it into AI War 2.

Starting at 8:30 in there is a tutorial for Blue, and at about 23:00 in is a tutorial for Cinth.

https://assetstore.unity.com/packages/vfx/shaders/alloy-physical-shader-framework-11978

https://forum.unity.com/threads/alloy-physical-shader-framework-version-3-for-unity-5.305178/page-34#post-3278461

The above video is about three ships that I’d done with standard shaders previously, including the first backer’s custom Ark, and now they’re converted over to Alloy. Just a video of me working and chatting about it as I do. Why not.

AI War 2 v0.602 Released! “Nice Sidebar You’ve Got There”

Release notes here!

This one focuses on the UI, but there’s a lot of other stuff too.

On the UI front:

1) The “Let’s make a better sidebar” experiment has been abandoned, beaten unconscious, and fed to the Devourer Golem. In some order.
– Now we have a sidebar very much more like the original game’s, though with the extra feature of using each team’s color rather than a standard blue/orange/yellow for me/enemy/ally.

2) The main galaxy map display mode now shows way fewer units (just key units and sensor scramblers), since it was way too cluttered. You can use the other display modes to see the other categories, in turn.
– The planet names also no longer try to name the owner, and instead rely on text color to tell you that. Again, decluttering.

3) The game no longer automatically assigns a “Fighter, Bomber, Missile Corvette” build queue to your Ark. If you want that behavior, you can use the new “Build Policy” behavior menu to set your Ark to just build everything it can. The Build Policy framework is very powerful, and addresses one of the longer-standing UI requests from AIWC (build queue templates) but in a much more flexible way. This allows us or modders to write scripts that control what gets built and in what order, and can automatically adapt to changing conditions from battle losses, which builder is closest to the rally point, tech unlocks, etc.

On other fronts:

4) More updates to the Nanocaust faction from community member BadgerBadger. The very same Badger has also submitted a bunch of changes to the Zenith Dyson Sphere faction to bring its behavior more in line with AIWC. Thanks, Badger!

5) The ratio of ship-size to gravity-well-size has been altered so that more ships can fit into the same space. You can still zoom in to see them honkin’ huge, but one of the biggest balance changes from AIWC to AIW2 was actually that ratio, to an unintentionally huge degree. Made things feel kind of cramped. So this is a step in the right direction, and there’s now a handy lever to tweak it further (the “ship_size_scale” attribute in ExternalConstants, to be precise).

6) Several other things, including another huge chunk of AI code moved into moddable-territory, and fixes for a bunch of bugs, like the one from the last few versions that made the AI always start in “tutorial” mode unless you specifically selected an AI type.

Enjoy!
Keith

“Rorqual Hegira” Ark Painting Videos

No actual painting takes place in the first video.  Instead we go through mesh simplification, examining the mesh, sizing things up, and generally getting things prepared so that we can just sit down and paint in the next video.

The second video shows the first of the 11 custom Arks that kickstarter backers commissioned for the game. This will be one of the Arks that anyone who plays the game gets to choose between.

This Ark, dubbed the “Rorqual Hegira”, was the vessel for the cetacean flight from Sol. I can’t say any of those words. 😉

Anyway, this goes through the process of actually doing the painting to make the cel-shaded baseline turn into a PBR (Physically Based Rendering) style. Basically what that means is taking something that looks intentionally cartoony and adding on a layer of processing that makes it react to light more like real materials do.

As part of that I also wind up adding various procedural details, naturally, as Substance Painter is really excellent for that sort of thing. All those little scratches and splotches and so forth that humans just aren’t meant to paint by hand with any speed or lack of repetition.

This video took way longer than I expected, mainly because my first idea for how to handle the metal body didn’t work out (I had feared from the start it might not, but it was a fun one to try), and because handling the “glass with something down inside it” is an inherently super-tricky request, and something I wanted to do justice to rather than just slapping an emissive glow on it and calling it good. I’m quite happy with how the result came out, although we’ll see what the backer thinks once he sees this video.

Enjoy!
Chris

AI War 2 gains IBL (Image Based Lighting)

Recently I showed how the graphics have evolved in the game via switching the materials to be more PBR-based (overpainting our cel-shaded visuals to augment them via Substance Painter).

At any rate, one of the things that was bothering me was the drop in quality between Substance Painter’s view of things and the view of things in Unity.  It still looked great in Unity, but was a notable step down.

So, I thought about that a bit, and made some changes to the lighting in Unity.  More on that in a bit — but first I should note that this isn’t something that is costing any extra performance hit on your GPU.  Yeah, you heard me — these sort of visual improvements can be “free” in terms of performance cost.  It’s all in the techniques, and I’ve been learning a lot on that front as I’ve been working on my “secret side project.”

Anyhow, that’s been paying big dividends for AI War 2 that I wouldn’t have anticipated.

Where We Started

That’s purely a cel-shaded approach modeled in Maya by Blue, and painted in Photoshop.  There’s a lot to love there, particularly in most of the ships in the game, but this was probably the number one ship that bothered me because the asteroid doesn’t look at all like rock.  (Then again — do rocks in any cel-shaded game look like rocks??)

At any rate, her painting and models were being fed into some custom shaders I created, and then tuned to have custom reflection maps and specularity and rim lighting, etc.

One of the big things that I struggled with with my shader was making the ships look really dramatic — but also visible — on their dark sides versus their light sides.

Often this really caused issues with the normal maps (those images that make things look more bumpy than the actual underlying geometry is) either being too harsh or too subtle depending on how close you were to the ship or which side of it you were on.

Next Up: Substance Painter

In a video you can see me painting that mesh using Blue’s cel-shading as a base.  The end result — in Substance Painter — is this:

Now, there are a few things to bear in mind.

First of all, this is using different shaders than Unity has.  Ones that don’t have to render in realtime, and certainly not thousands of objects in realtime — Substance Painter would choke and die on that.  But that tool is equally useful for offline cinematics or feature films as it is for realtime game usage.

That said, it should translate pretty well — shockingly well, to be honest — to Unity.  When you’re using full lightmapping and calculated ambient occlusion and so on, the visuals get very very close between the platforms.

Problem, though: you’re not able to bake lightmapping in unity for dynamic scenes.  At least… mostly not.  There are a variety of complicated techniques, and even some simple ones.  But let’s just say for our purposes here that isn’t feasible in this particular case. 😉

At any rate, the second issue is that this is using IBL, or Image Based Lighting.  And in Unity I was not.

What Is IBL?

Basically that means a 360-degree image cubemap is “shining” on the model from all around it.  Imagine having a painted translucent box and putting the model in it, then shining light evenly through every side of the box at once.  The result is an IBL look.

Actually, you know what?  Just check out this video with someone showing off what Unity can do.  Video is worth a thousand words… squared?

Okay, So What This Looked Like Coming Into Unity

This is a huge improvement over what was in Unity previously, but it’s still… not my favorite.  The lighting is very stark and harsh, and the specular reflections feel wrong, making me have to tone down the smoothness of the metallic shaders.  All that combines with the flatness of the lighting in general to make it feel… like a blander version of what I had before.

Well, heck — I’ve worked with IBL plenty of times before.  Let’s see what I can do.

Upgrade One

Starting with this:

We then move to this:

In order to get that second look, I turned off the main directional light in the scene, and am using just a single IBL light source.  I have to “bake” that in a really broad sense for Realtime GI to work in unity, but my understanding is that it isn’t really using anything other than the original cubemap since there’s no true baked data (no lighting probes, etc) in the scene.

At any rate, this is with the ambient light coming from the (invisible) skybox, which is an HDRI cubemap.  And then no other light sources other than the emissive materials on actual ships.  Oh, and the global reflection cubemap has also been toned down a bit and switched over to use a compressed version of the HDRI skybox rather than the studio lighting look I was using before.

This approach is pretty cool, and certainly more vibrant… but it’s still missing something.  It’s a very flat look to it, and if you circle the asteroid the lighting is even on all sides.  There’s no real shadows happening.

Upgrade Two

Now we’re talking!  This tones down the ambient light a bit, and then adds back in the directional light — but tones that down to about 60% of what it previously was, too.  I also made the directional light warmer rather than a harsh white, so that it would match with the HDRI image I chose.  Incidentally, I went through a variety of HDRI maps before finding one that felt right.

The overall settings used in Unity for this are as follows, if you’re curious:

And That’s Where We Are Now!

In a non-procedural game, there’s all sorts of fancy and highly-performant things that can be done with lightmaps and reflection probes and so on, but this is not that game. 😉

For performance reasons I’m not using parallax mapping/heightmapping/tessellation or baked AO on these models, either.  Those don’t contribute enough to the scene to be worth the added GPU and RAM costs, and we want this game to be able to remain as huge as possible.  All of the changes thus far have been either GPU/RAM-neutral, or come with a performance savings.

I may move back into slightly custom shaders for this, mainly so that I can handle the death effects for ships via parameters on the ship itself “eating the ship away” as it dies.  But in general, beyond that, this is how the game looks now (or will look, once we paint all these models again — blending what came before with what we can do now).

Hopefully this was an informative/interesting read.  🙂 It’s obviously something I’m passionate about, and I think it contributes a lot both to the mood of the game and our ability to sell it to a wider audience.

Chris

AI War 2 v0.601 Released! “Grumpy Ark”

Release notes here!

This one is mostly cleaning up various issues that have been highlighted since we made Alpha 0.600 available to all backers (well, as many as we had steam-keys for, sorry about the delay while we get more from Valve).

But one very visible change is another revision to the art style to make it less “happy”, as Chris discusses in this Kickstarter update:

https://www.kickstarter.com/projects/arcengames/ai-war-ii-0/posts/2033119

We’ve made several attempts at unhappification-of-the-art since the beginning of the year, but stuff just hasn’t looked grumpy enough! Hopefully this is another step in the right direction.

Enjoy!
Keith

Updating the ship aesthetic in the game?

Chris here!  Wanted to run something by folks.

Hopefully you can click on that and get the fully zoomed-in full-quality version.  If not, here is a link to a version that will definitely be full size.

In case that (tiny, tiny) text at the bottom is hard to read, here’s what it says:

Note that this effect actually uses vastly less VRAM than the other approach — insanely — because we’re able to use compressed textures. The smooth, cel-shaded look shows imperfections in texture compression super fast, so we have to use higher-quality compression or even no compression. The PBR-based approach is inherently grungy and messy, which fits with the general vibe of a war-torn galaxy anyhow, and DXT5 compression doesn’t show any artifacts that aren’t just something your brain writes off as more grunge.

This overall aesthetic helps to make things look less “happy,” since that was a complaint withthe art before, but it also keeps the exact sameunderlying textures. However, we’ve overpainted those textures using procedural work in Substance Painter, giving a blend of hand-drawn and PBR styles that seems unique.

Thematically this seems more appropriate, and it’s also a lot (LOT) more efficient on your GPU, particularly if you’re on OSX or Linux (which can’t read BC7 compression. We’re talking a 4x to 10x reduction in VRAM, while getting added detail — just to be crystal clear. 4x on Windows, 10x on OSX and Linux.

We should also be able to make some of our LODs and asset-integration work a bit more efficient using this, too.

Any complaints?

Oh, Also — About The GUI

We’re having a lot of discussion about the GUI, and I’ve made a pair of videos on the topic.  Cyborg has been a huge help in focusing our attention in a positive way in this particular area.

Also, when it comes to the vibrance of the space backgrounds I’ve toned those down as of today, too — with the next build that comes out, 0.601, those will be much more muted.

And About Those Remaining Keys…

Still waiting on those from Valve.  So sorry about that!  I assume I’ll have the keys from Valve either this afternoon (PST) or tomorrow afternoon.  Otherwise I’ll get up with my contact there.

Cheers!

Chris