IBL in AI War 2!

Pics lower down. 🙂

The Problem I Wanted To Solve

One of the frustrations I’ve had with the ship graphics in AI War 2 is that it’s hard to make sure that they’re both vibrant AND nicely reactive to the environmental colors and similar while being so hugely restricted in terms of how many truly-PBR techniques we can use because of limitations caused by having SO many realtime objects to light in that sort of scenario.

I’ve gotten around that with a variety of tricks that have evolved over the last months, and it’s been working well with Blue’s cel-shaded clean ship albedo/diffuse coloring.  It wasn’t perfect, but I knew I’d have time to improve it later — the main issue I had was that specular highlights tended to trend to white on all models.

Part of the recent evolution in the look of ships was to give them more of a metallic-on-cel-shaded look, which allows for a lot more flexibility in the sort of visual effects we can then do.  My first approach to that was to think of PBR, and so that’s what we recently converted to — the Unity Standard shader, which is heavily PBR.

There were a variety of challenges with that, though — I couldn’t control the amount of specular whiteout as much as I wanted while still having a ton of metallic feel to it.  Cinth kind of set me on the path of chasing the metallic look to marry that to the cel-shaded look that Blue sent me chasing, and I really wanted to get those working together.

The New Approach!

Experimenting a bunch last night and then today, I’ve settled on an IBL approach that is using Blinn-Phong again, back to what my custom rim-lighting shader was doing before we went to the standard shader (sorry, no link on that one — it’s somewhere on the forums or kickstarter, though).

Anyhow, the big benefit of this approach is that I’m able to handle reflections via a cubemap that has nothing to do with the larger scene, and then tint the reflections as needed, along with using a fresnel effect on them.  Then beyond that I’m faking a metalness map in some cases (such as for the fighter and bomber) by additively using the inverse of that data in the diffuse channel.

It’s All About The Motion

Bear in mind that the result is a lot more dramatic in motion, because as ships move around you get a lot more of them shimmering and glinting in the light as a school of fish might.

Even so — in still screenshots I think that it looks a bit better now.  But in motion it’s night and day.

Also: Lighting

Also!  Bear in mind that based on the lighting of the planet in question, you’ll get pretty drastically different results from what I am about to show.  In one case I was frustrated because the serial number on the fighter wasn’t showing up properly… only to realize that in fact it was acting appropriately in the lower-direct-lighting environment it was in at the time.

The basic rule of thumb is that the ships wind up varying in appearance more from planet to planet in terms of the characteristics of light on them, which is a big part of the goal.


The above is what I had before, using the Standard shader and a metalness map.  I was particularly unhappy with that one.

Now a few shots of what the new one looks like from various angles:

You’ll notice that in the two different angles give a really different feel to the color, even within one lighting profile.  That has a lot to do with the fresnel effect and cubemap for the reflections, but also just the specular highlights based on the view angle toward the light, too.

In a couple of angles that makes it looked a little more washed out in the cool orange parts, but very metallic — and then in other angles it looks rich and deep like the original cel-shading work that Blue did.  I’m really pleased with how these feel like they’re a living and interesting part of the scene, rather than just a flat piece of junk that always looks the same no matter where you see it or from what angle.  Perish the thought. 😉


So the above is again the “before shot,” prior to today’s IBL work.  I was actually really happy with this one already.  Then here are a few angles of what it looks like now:

In some lighting angles, you can see that this one is really dark on some of the surfaces.  But there’s also a very metallic sheen to it.  From other angles the main color comes right back out, and from yet others there’s this kind of bluish shimmer that passes over it as the camera or the ship turns, either way.

I might need to make the cockpit a little brighter, I dunno.  Minor tweaks.

More To Come!

At any rate, the space dock and Ark and warp gate and planet controllers also really got a huge upgrade out of all this.  All the rest of the ships are still using the PBR approach, which looks similar-enough but not quite the same by any stretch.

This wasn’t really on my list of things to work on this week originally, but with Cinth having some major health issues and there also being some major health issues with a couple of my extended family members, it’s been a week where I wanted to focus on some things that were productive, but not quite as mentally taxing.  This was a tricky problem to solve, but not as tricky as some.

Anyway — enjoy!  Thanks for reading.


AI War 2 Alpha v0.112 “Plasma, Forcefields, and DirectX11” released!

Since the last blog post I made, we’ve done two intermediate versions, and this is the third.

In cases when I just don’t have time to update the blog for whatever reason, bear in mind that there are three places that always get updated:

  • Steam itself will auto-update you unless you’re on a specific locked-in “beta” branch for whatever reason.
  • Our official forums always gets a quick post, because that’s super fast.
  • The release notes page always gets a new entry, and the date logged for the build.

At any rate, apologies for not updating the blog on the last two builds.  It’s something I try to avoid doing, but I’d rather miss a blog post than a release.

So: what’s new lately?

  • Keith updated a ton of stuff with the modding capabilities in 0.110, which is a big deal for modders.  It really increases the power/flexibility of the modding system.
  • I upgraded the version of unity that the game runs on in that same build.
  • As part of 0.111, Keith fixed a bug that was causing crashes on linux and milder problems elsewhere.
  • This new 0.112 build includes three new units in the game.
  • This build also now includes DirectX11 support, to deal with an OpenGLCore crash bug on at least one windows install.
  • There are a variety of under the hood improvements in this new 0.112 build that are getting us a bit of extra performance and quality in a few areas, and which get us closer to getting into some of the GUI work.

Other stuff?

  • Blue has been pulling her hair out working on the new icon system for the game, and the results are coming along really well at this point.  It’s been a big task and the topic of much discussion with players; even after the direction was set late last week, that still left a lot of experimenting to get something that looks cohesive and clear while still being attractive.  Getting just the right amount of detail is a big deal.  We’ll be ready to show that off later this week, I think.
  • There is a backlog of 3D models and textures that are done and ready to get into the game, but unfortunately Cinth had a very serious medical emergency over the weekend and so will be out for a few weeks at bare minimum, and possibly more like months.  At the moment he’s still in the hospital.  Please share your well wishes for his recovery.  At any rate, a bunch of that stuff will drop all at once sometime soon once I have a chance to get to it.
  • In general, Keith has been looking at the GUI more now that I’ve gotten the unity project set up for him to be able to do that sort of thing.  So we’ll see what happens with that, in terms of what he does with it both with and without Blue at this point.  He can speak to that better than I can.
  • I’ve been working on a modified version of the sort of sprite batching system that I use in starward rogue for actually displaying the ship icons that Blue is creating.  That’s been a tricky thing, because they are pretty different systems, but after a lot of study I just don’t think there’s a more efficient way of handling it.  The actual GUI won’t use that system (that would be less efficient, not more), and of course the main game doesn’t either (same deal when it comes to large ships).  But for this particular case it should pan out well.
  • I was also working on some cool stuff relating to a new system for explosions of ships, although I’ve temporarily set that aside.  The general principle of it works and looks great and seems to perform well, so that’s enough for me for the very short term — I have bigger fish to fry before I finish that one up.

So that’s what’s going on with us.  Thanks for reading!


Sometimes you just gotta ignore the priority list.

One of the things that will become apparent for those in the alpha is that I don’t really work in a linear fashion. 😉

I have a todo list of things that is long, and there are things of relative priority in there even within priority categories.

One of the things that is funny about todo lists like that is that if you never take time off from the highest-priority category, often the lower-priority ones don’t get done at all.  The highest-priority one just fills up again and again, etc.

At any rate, the other comment I have is that typically you have to seize upon inspiration when it strikes.  Sometimes I look at a piece of code or other work and just think “oh man that’s going to be a slog,” but I’m excited about something else on the list.

In those circumstances, unless the house will burn down if I change items, I switch to the item that I’m excited about.  That gets that item off my list, and I’ll wind up doing it faster because I’m more excited about it.

Later I’ll revisit the thing that I had been dreading, and one or more of three things will now be true:

  • I’ll be excited about that now; or
  • I’ll have at least had an epiphany about it so it doesn’t feel so bad; or
  • I’ll feel so guilty for “slacking off” that the energy from that will propel me through.

Sometimes people comment on how darn fast Keith and I are at doing various things.  I don’t know what Keith’s methods are, but I tend to use various tricks to get myself to work harder than my natural inclinations.  “Slack off” by doing a lot of little things, then tackle the big thing out of guilt, etc.  It’s surprisingly effective at chewing through large todo lists.

The last couple of days I’ve felt particularly slack because there’s been so much OS-specific stuff that I haven’t been able to really focus much on my todo list at all.  I’ve gotten a few things done, maybe a dozen at most, but it’s not what I’d prefer.  A lot of the other things I got done never made it onto that todo list at all.

Today is another funky day for me, in that regard.  Cinth made some mockup derelict ships that look amazing, but are very metallic and thus PBR-lighting-model-based.  I told him I’d have to redo that of course, which he knew going in, but dang if we both didn’t really love the look.

Soooo… I thought about the performance gains that we’ve unexpectedly had with the game thus far, and started wondering about going with a PBR pipeline approach with the main game ships themselves.  It means throwing away my rim lighting shaders and a variety of other things, but it could be awesome, right?

Turns out: yes.

So I’ve been working on a hybrid style that gives those homeworld-2-looking flat shaded models a more modern metallic styling to go with them.  The approach actually works really well!

But it does make the ships a little bit darker, which fits with another issue I have in general, which is to do with the space backgrounds for the game.  It was way down on my list, but I had already noted I hate the backgrounds for the skyboxes, and wanted to change them.

So that’s also happening.  We’ll see where performance winds up, but this is all GPU-side stuff.  It’s possible that my Mac will have some sort of issue with this on the GPU side, but somehow I suspect not.  I have some more shader work to do with the lower LODs than 0, but I think that I can get some really interesting things going there.

Also of note, on windows in particular it was using DirectX9 in builds up until now, which means that the BC7 compression format was being uncompressed and then sent to your GPU in an uncompressed format, wasting a lot of bandwidth on the GPU bus as well as VRAM.  I’m switching over windows to primarily use OpenGLCore, since that can use BC7, near as I can tell.

I could just make it use DX11 on windows, but I have endless problems with the unity editor itself bugging out on me in DX11 for some reason.  On like 5 computers with fresh installs on 3 different windows versions (7, 8.1, 10), over multiple years, on many different unity versions (4.x to 5.x).  Curiously, almost nobody else has this problem, so I guess I just have some sort of strange DX11 Editor curse.  Actually running DX11 in the standalone player works fantastically.

Anyhow, that’s yet another aside.  But basically I’m now finding that I want to toy with a few more styles and options now that we have all these different machines with different performance coming back to us.  Almost all the machines are running at 60fps+, and I’m wondering if I can keep that happening while also sliding in a few more advanced bits.

I’m betting so, but we’ll see for sure when the next build comes out tonight.  That’s what I’m working on today, anyhow.


Rethinking the icons…

I already complained about the icons today, and there are a few things going on with them that are definitely moving in the right direction.  And I’ve figured out the math on how to handle them even better.

However, Blue and Cinth and I were talking today, and there may be a better, more attractive way for us to handle the icons in general.  We still need to do some mockups, but basically it would involve making the icons 2D and trying to keep them feeling like HUD elements that move around, tracking the squads, rather than elements in the 3D world.

For reference, the center of this screen is more or less the general style of GUI we’re going for:

Bear in mind, of course, that’s still incredibly early as a mock for the GUI.

In this new concept for squad icons, people will see those as basically being “part of the GUI,” kind of like how Iron Man would see targeting icons laid over top of real-world objects through his helmet, if that makes sense.  We’ll see if it works out visually or not, but in theory it might.

Load-wise, we can probably do it in a way that is approximately equal in cost to rendering the 3D icons the way we’re doing them right now.  In theory.

Luckily we have a ton of testers now, so we can easily do A:B testing on a wide array of hardware and OSes, right?  Such an awesome resource to have you folks. 🙂

Anyway, we’re going to do some prototypes of the bomber and fighter, and then see where that gets us.  Worst case, we keep with the existing style we’ve already established, minus being so crazy over-glowy.

I already have plans on changing up how squad selection visually looks, so this might fit well with that.  The actual visuals for the ships themselves are already nicely set and we’re cranking through them, but there are various other areas of the game that aren’t nearly so far along.

  • Obviously the GUI itself is just completely test junk right now in the actual game.
  • I had thought the icons were pretty final, but we think we might be able to do better.
  • The planets are pretty final, but I’m less happy with the background spaceboxes at this point and want to redo those if possible.
  • I’m not really happy with the shot graphics at all, but that’s not really a crisis because it’s just the first one anyhow.  That’s right up my alley in terms of making a lot of that stuff look amazing.
  • The wormholes I created are something I hate, and both Cinth and I have been poking at ways to do a replacement.
  • The ship contrails are reasonably final unless we think of something better as a way to handle that, although I’d had concerns about performance.
  • The particle effects for ships exploding and similar are nice, but I don’t see those as being final anymore.  I had thought they were, except needing to be scaled better for the types of ships in question… but now I want something more dramatic, and have a good idea of how to do it.

Overall I’ve been getting a much better idea even since just yesterday of how much room I have in which to play with visuals before it starts making some hardware unable to be used.  I’m really pleased with early results, since so far I have a bit more room to play than I thought.

Anyhow, apologies for not having the next release ready today.  I will definitely have that out tomorrow.  Thanks also for the torrent of early feedback, it’s been really useful!

Okay… what!? OSX not only works, the performance is ridiculous so far.

Last time I fired up AI War 2 on my Mac, which is a pretty outdated machine with a really really bad GPU, the results were pretty bad.  I wasn’t really surprised, because I was running it with all the settings turned up, and the music was throwing errors a bunch, and I knew it could get a lot better with some polish.  An old intel 4000 integrated GPU is not exactly at the middle end of the market anymore, even.

Just retested the latest build, which has the music swapped over to a different playback system, and which has a metric ton of performance optimizations from myself and mainly from Keith (the entire game simulation runs on a secondary thread, now).

Results? 300-some odd ships in the very opening battle, with all the settings turned up to maximum still, and it was buttery-smooth.  I have no idea what the framerate was, but I feel confident saying it was north of 60.

I just… whaaat?  That’s… not what I expected.  It’s fantastic, but it’s also a big surprise.

I’m not going to run out immediately and lower the minimum stated system requirements expectations, but that is certainly super duper positive as an indication thus far.

Reminds Me Of Something…

As kind of a fun aside, back when I was coding AI War Classic in the early days I was hoping to get 10k ships in a game, and was pretty sure I could do it.  The maximum any other RTS had at the time was about 1000, and it was super choppy and laggy with that many units in the other titles.  I felt like I could bump that up by a 10x partly thanks to going 2D, and partly just due to coding practices.

By the time the first public builds were around for AI War Classic, the typically number of units in the game was more like 30k, and it would start to chug around 45k units.  Within a year after that, 50k was more typical and it would start to chug at 75k units.

More Generalized Thoughts on Optimization

Sometimes it’s just really surprising how things can go when you throw everything and the kitchen sink at optimization.  It’s kinda-sorta working, it’s getting along okay, and then suddenly you pass this critical mass and whoosh the performance jumps by an order of magnitude.

I’m not remotely ready to say that’s happened here, yet, though.  The simulation is not remotely finished for the game, as there’s still a lot more AI to build out, and lots more ship functions.  The largest battles still have only involved just a few thousand ships at a time for me, whereas in classic sometimes north of 10k ships in one fight would happen.

So I want to see what happens with all those things.  Right now early indications are ridiculously, surprisingly good; but some monkey wrench could still very well appear between now and early access that makes me say “yeah, the minimum system requirements for a truly pleasant experience should still be more than a lousy intel 4000.”  Then again — maybe not. 🙂

Oh, One Last Thing

In AI War Classic, the simulation speed was locked to the framerate on the slowest computer in a multiplayer game, or to your framerate in solo play.  Kinda common for RTS titles, though not all of them.

In AI War 2, your visible framerate is completely unrelated to simulation speed.  We’re actually running the simulation speed at 10 cycles per second no matter what, which gives us a lot of muscle per cycle on a secondary group of threads.  It doesn’t need to be any more fine-grained than that.

Then for input and actual visual display, of course it can run at much higher framerates, basically up to whatever your hardware can handle.  If you’re running at a buttery-smooth 200fps and everything is just peachy, and I’m having more trouble on my machine at a hard-won 30fps or something, the simulation won’t slow down for either of us.

I’m a pretty happy guy about now. 🙂

A fantastic conversation.

Just general forum humor.

BadgerBadger: What does “lerping shots out of ships” mean? I know larping, not lerping.

Keith: Please, please don’t let the shots larp.

Cyborg: The AI will now say, “Lightning bolt!” before each attack.

Chris: “I’m attacking the darkness!”

Keith: 20,000 MkV Gazebo Guardians to Murdoch in 0:32…

Chris:  My favorite version of that skit: https://www.youtube.com/watch?v=zng5kRle4FA

Hey, do you remember the Gazebo monster we put into Valley 1 as a bit of an easter egg? Most of the Gazebos were harmless, but a tiny minority were absolutely deadly murder machines.

I completely forgot about that. 🙂

Definitely having to prioritize my time.

If you’ve looked at my todo list, you’ll see why.  There are so many things that I want do do, where I just think “oh, but I could get that done in just a couple of hours at most!”

And it’s true in each instance, but there’s a very real additive cost to all that.

I know that I can make the background starfields, which I’m growing tired of already from a visual sense, look a lot better and more stylized.  But is that more important than bugfixes?  No… sigh.

I want to get MasterAudio set up so that I can go ahead and have music ducking and so forth in place when I get to that point… but is that more important than just getting uAudio out and thus the game working on OSX properly, and then back to those bugfixes?  Again… no… sigh.

And so it goes.  Things move fast with Arcen, but there’s still just never enough hours in a day.  I’ve had a very unhealthy work/life balance for years, and in the last year or so I’ve been trying to get that more under control.

So… priorities.  Making sure I can load music in a cross-platform way and play it efficiently.  We’ll worry about audio ducking later when we’d even be doing that at all.

Among other things that will just have to wait.  At least with the todo list, you alpha folks can see where my head is at and what I am valuing over what in the short and middle term.

Hopefully everything on that entire list is done within the next month, knock on wood.  I have three in which to do it, but I’d rather be done in one.

RIP My Linux Install

Okay, so… “funny” story?

I’ve been mostly running ubuntu in a Parallels VM on my Macbook.  It’s worked well for the last number of years.  However, now… well, it’s a combination of drivers and just other accumulated issues.

Basically, the short of it is that my linux install still works, kinda-sorta, but it’s buggy as all get out and randomly crashes and is constantly reporting errors in itself, steam, and various random programs.

This VM was perfectly capable of running Release Raptor, at least at a low framerate with a lot of quality settings off.  It also ran a much earlier build of AI War 2.

However, now it literally gives a blue screen in the window that unity pops up when I try to start AI War 2.  I think that this is because my VM is so hosed in general, and also because it’s running an older version of ubuntu than unity now supports… and which I can’t upgrade from due to lack of virtual disk space.

All of which is to say, while we DO have “day one alpha” linux support in the game, as promised, I am not presently sure if it works at all.  I’m tired of VMs, and I work pretty much exclusively on laptops these days, so what I’ve decided to do is order a new Oryx Pro from system76, with ubuntu natively installed.

All my other machines are MSI, Asus, or Alienware at present, aside from my mac and a trio of old desktop machines in my attic.  I don’t have room to run a bunch of desktop towers in my office, though, which is why I went the VM route in the first place.

I looked into getting ubuntu on my existing laptops, but it’s just one of those things that is so fraught because of lack of driver support from those vendors in a lot of cases (shakes fist).  Trying to test the game on those would involve hours of actually setting up the ubuntu install, possibly corrupting my master boot records (thanks, Windows 10), and possibly still having a steaming mess of unsupported hardware.

I figured I should Do This Right, instead.  The bad news?  It may be another two weeks before that new linux machine actually reaches me.  So if linux works out of the gate for you during alpha, then I’ll be overjoyed and that’s a relief.  If there are problems, I can try to use your error messages to figure out what is up, but most likely I’ll need to have my own linux box before I can really get into it if it’s something complicated.

Hopefully it just works.  But you know how that sort of thing can go.

I apologize for not being more on top of the linux build from the start, but it WAS working and it hadn’t occurred to me to test it lately and find that it was suddenly not.  The way it dies instantly pretty much guarantees that it’s missing something in my particular install, and not our code doing something that breaks linux.  My worry is more that if you get past the first issue on your machine (having a non-broken install and all that), that you’ll instead run into something that’s broken in my part of the code.

Anyway, teething pains.  Apologies again if it doesn’t work day 1, and fingers crossed that it will.