Plans and Status Updates for AI War 2

(Crossposted from kickstarter.)

Chris and Keith here! Apologies for not having made any kickstarter updates since June, good grief. We’ve had daily or weekly interactions and updates on our forumsblogyoutube dev diary, and release notes pages for anyone who wanted the full firehose info dump, but that’s no excuse.

Schedule Slippage – Overview

Let’s get to the toughest topic first. We had originally planned to have an Early Access release on Steam in May, and then a 1.0 release of the game this month, October. As you are no doubt guessing, a 1.0 release this month is not in the cards.

With the Early Access launch-pushback in May, we went ahead and gave out the keys to all of the early access backers at that time, even though the game wasn’t available for purchase on Steam yet. We’re going to do the same thing with the “launch” backers: we’ll have your keys to you later this month, even though the game isn’t in a launch state and won’t be launch on Steam just yet.

In both cases, you’re still getting your key when we said… but, well, the game is not in the state that you would want just yet. So at best that’s a half-kept promise. Obviously schedule slippage is not exactly uncommon with kickstarters or game development in general, but we are still very sorry about that.

Where We Are Right Now

Code:  

  • All of the core code for the game is done.
  • Multiplayer is currently broken for some reason, but should be quick to fix.
  • Massive amounts of work on frameworks for a flexible UI and extra modding capabilities have been put in place.
  • There are actually a number of extra goodies in there, like multi-squad formations and some other surprises.

Gameplay and Interface:

  • Balance leaves a lot to be desired.
  • In a general sense, the “feel” of the first game isn’t quite there yet.
  • There’s no tutorial, which makes starting to play quite hard.
  • The lobby interface is very sparse.
  • The overall GUI is ugly, but becoming increasingly usable through iterations. Our goal is for it to be better than the first game in terms of incorporating a lot of the longstanding requests people had for that game.
  • The Spire, Nemesis, and Interplanetary Weapons stretch goals are delayed, possibly until after launch.
  • Unexpectedly, we have a whole new minor faction in the form of The Nanocaust, created as the first mod for the game by BadgerBadger and integrated into the official builds by us.

Art: 

  • All of the ship models and textures — all two hundred and six of them — are complete as of last week.
  • The actual integration of those ship models and textures is only about halfway complete, give or take.
  • The ship model and texture work includes all of the Spire, Nemesis, and Interplanetary Weapons stretch goals stuff — so the art for those are already done, at least.
  • The far zoom icons are done, although we will probably change some of the “flair” parts of them as we get closer to release.
  • We have done a number of pieces of concept work for the GUI in terms of figuring out a style, but none of that is integrated into the game yet (no point until the actual underlying elements stop shifting around so much), and there’s still more concepting work to do in general.
  • The visual post-processing stack is still evolving at this point, to give the game a more sophisticated look and avoid the “circus lights in abundance” feel that sometimes hits right now.
  • The visuals for different shot types are still on the todo list.
  • The visuals for how ships die are also still on our todo list. There’s a balance there between performance of particle systems and the frequency (read: very high) at which ships die that we have to work out.
  • We’re still working on inside-one-squad formations that look awesome, although some of those are already in place. Basically making them look more like actual naval or air force military formations rather than just grids of ships. This has been pretty cool to see evolve.
  • The “ships flying around inside one squad with flame trails everywhere” approach has just turned out not to be feasible on modern hardware without impacting our ability to have really large-scale battles, unfortunately. There are some special tricks we could do to still make this happen, but that would get into some budget that we don’t have. This is a real shame, because this was something we showed off a lot in the kickstarter videos, but in pretty much every other respect our art is exceeding what was shown in the KS videos, so this has been a pretty decent tradeoff — and something we can return to in the future.

Audio: 

  • A lot of the sound effects for different shot types have been selected and set up, but are not integrated into the game yet. So the battles don’t sound as variegated yet as they will later.
  • Another bonus that we’ve chosen to explore thanks to the urging of backers is extra voiceovers for human ships when you give them orders and when there are various alerts. We’ve done about 30% of the recording with a variety of voice actors for this, and we’ve integrated maybe 5% of that into the game so far. It’s something that brings more of a feeling of commanding actual humans rather than just lifeless ships, and it’s something you’ll be able to disable. It’s also something that we’ve got a system for making sure it doesn’t over-saturate you with the same voice cues over and over again, too.
  • As far as AI taunts or human taunts that you can give back, we have not yet started recording any of those yet.
  • The music is partly in place, but overall only a few tracks thus far. Pablo tends to work in a massively parallel fashion, and so a lot of his tracks are at various stages of completion rather than him finishing one piece fully and then pushing it out and repeating. Bear in mind he has to compose them and then perform them and then do all the audio engineering and mastering on them, so this process gains a lot of efficiency.

(The GUI is being gradually blocked out and iterated-on in that fashion before being made pretty.)

Upcoming Schedule: October through November

During the next two months, more or less through December 6th, there’s going to be a flurry of extra work going on to try to get the game to a point where all of the AI War Classic enthusiasts are able to come to the new game and feel both somewhat at-home as well as like they’re in the next era of the game.

Exactly what that means is a bit unclear at this point, but we know it focuses on usability, balance, the interface, and possibly tutorials. The reason for the lack of clarity is that there’s a big back-and-forth between us and you in this section — this is a huge game, and so we need feedback on things that are unclear or break balance, and then we’ll respond to those items, and repeat.

There are a number of things we already have planned to work on through the early part of October prior to us releasing the “launch” Steam keys, and then after that point we hope we’ll see an uptick in the number of people who are giving us feedback.

Upcoming Schedule: December

After the December 6th date, or thereabouts, we hope to have things in a state where a LOT more people are comfortable jumping onboard and testing and giving us feedback.

Right now feedback has been really limited to only coming from a few people, largely because the game has been too unapproachable and too unbalanced. So that’s on us.

But we just absolutely cannot go to launch, or even to giving out press previews, with that little feedback. Our goal is to get our side of things to where we can start getting your feedback — from more and more of you — while at the same time seeing more and more of you enjoying simply playing the game without having major complaints.

Upcoming Schedule: January

Once the new year rolls around and we’re into 2018, hopefully we’re pretty close to where things are so polished that we can start handing out keys to the press and getting some previews. We don’t know if that will be at the start of January, or later into that month, but either way the goal is sometime in this time period.

At this point in time, when we start sending out press keys we plan to disable our backerkit preorders store and our paypal preorders. This is also likely when the “Coming Soon” page on Steam will go live, although we might conceivably do that in December.

Upcoming Schedule: February

This period might start sometime in January, if things are going really well, but either way it bleeds into February. Basically this is the “press review period.”

During this time we’re not taking any new sales for the game, and press are able to play and review the game. We hope that you folks are also playing the game and enjoying it and giving us feedback on how to make it better during this time so that we can apply some final polish to it prior to launch.

This time period is pretty critical for a number of reasons. Firstly, it gives press a chance to have reviews ready for launch, which can help a lot with purchase decisions. Secondly, it gives the game time to “settle” and hopefully have a lot fewer changes required despite a lot of backers playing it.

Thirdly, it gives a period of exclusivity where only backers and the press are able to actually get the game. People have an increased desire for things that they cannot have, and the press prefers writing about things that the general public cannot yet have, so we wind up with this funky period because human psychology is what it is. Hopefully this doesn’t feel manipulative to you, but we’re being upfront about why we’re doing this — basically it will increase the strength of our launch week (which is critical) and the number of reviewers who will play it during this month (also critical).

Upcoming Schedule: March

Obviously these dates get less certain as time goes out further, but the idea is that about a month after the press gets their hands on the game, we launch the 1.0 on Steam.

The exact day will partly be determined by what is going on with other game releases by other developers, what conferences and conventions are in that time period, what store-wide sales might stomp our launch, and so on. We won’t have visibility on what the exact ideal release date is until probably 6 weeks prior to choosing the day; and even then we might need to shift the day forward or back a week or so because of something else in the market that comes up.

Launch Discount

Speaking of the importance of a good launch week, one of the things we’re going to need to do is have the traditional 10% launch discount for the first 7 days. This is potentially contentious, because that’s a $2 discount that all of our existing launch backers (early birds aside) are not getting.

If this is something that angers anybody to a huge degree, then Chris will refund the $2 discount to those individuals out of his own pocket. So please put away your pitchforks. 😉

That said, I think we all have the same vested interest in seeing this game do well and go on to have lots of post-launch support (which require sales to fund), and expansions, and so on. Basically we all want to see the same sort of arc that AI War Classic had, I think?

The market is a lot more hostile now than it was in 2009, however, and the launch weeks are more and more critical to having any sort of momentum. The more we’ve looked at the data and talked to other indies, the more it has become clear what a problem it would be to not have a good leadup to launch (that month with the press), or not have a launch week discount that buyers have come to expect.

The backers and preorder customers here are the customers who have made this game possible in the first place, and so the 10% launch discount can really stick in the craw of some people when situations like this occur. We’ve witnessed the backlash against certain other games and developers when a development like that comes up out of the blue, which is why we’re telling you now, way in advance, and offering that $2 refund to non-earlybird launch backers if anyone is angry enough to take us up on that.

THAT said, in general we’ve been taking the approach that Prison Architect did, where “you pay more if you buy earlier,” which is counterintuitive in a lot of ways, but something that we’ve talked about the mechanics of with backers for a year or so now. Obviously the alpha and early access tier backers paid a whole heck of a lot more than the launch folks did, and those backers both help to support this game getting made at all, as well as having the game earlier and being able to influence the game’s design from an earlier stage.

We could go on at length about this particular topic, and we feel guilty about that as well as about the general schedule slippage here, but hopefully you read our reasoning and it makes sense — particularly if you’ve been watching the PC market as a whole lately.

(The above image is a good example of us still needing to do some work on the post-processing pipeline, although it’s already much better than that as of today’s release of 0.522.)

Backer Rewards Status

There are a variety of backer rewards in a variety of states of completion right now. For practical reasons, it’s pretty much breaking down like this:

  • Now that we’ve finished all of the ship art for the base game, we’re starting in on fulfilling backer rewards that are ship-art related. We’re working first with the custom Arks, since those are the most numerous and most complicated of the backer rewards, and then we’ll be moving on to the others that are art-related.
  • For things that are design-related (custom AI types, ship stats, etc), we probably won’t get to those until December. It’s better if things are more stable and you can play the game more before you get into that sort of reward.
  • For the audio taunts and the text and lore bits, I’m expecting that probably January would be the timeframe, just to balance with our workloads.
  • As far as all of the digital rewards, other game keys, etc, those are available now and you should already have them. The wallpapers aside, which again will likely be January.
  • To reiterate, the last of the AI War 2 game keys (those for “launch” backers) will go out later this month, and anyone else at a different tier should already have theirs.

Wrapping Up

Hopefully that covers the questions of where we are, where we’re headed, and why. The blogs and dev diaries and release notes show where we’ve been recently. Again we apologize about the delay, but we’re doing our best to mitigate its impact on you, and are feeling good about how it will impact the project as a whole.

As always: any questions, please let us know!

Best,

Chris and Keith

AI War 2 v0.505 Released! “Tooltips And Build Menu”

Release notes here!

This is basically completely about the build menu being more usable, and tooltips being more useful and legible.  They still need a background to really be fully legible, but we got a lot of the other things with them.  The unity ui is still… a learning process, sometimes.

This time around, I made a quartet of videos rather than Keith making them:

I wrote: A lengthy look with me at how to set up new GUI prefabs and then use them in code.  This is shown while setting up the build menu to look better/clearer.

I wrote: A quick look with me at how to set up sound effects for buttons.  It’s not a complete tutorial with everything in-depth, but there are tooltips for the bits that might not be clear, and this shows the workflow with greater clarity thanks to not going over every detail.  At least that’s the goal!

I wrote: For Cinth and for modders, this is how you create new formations for ships of various scales to use in the game.  I look forward to seeing a lot more creative and militaristic formations than my simple grids have been. 🙂

I wrote: Notes for Keith on how we’re using this component at the moment, with a variety of pros and cons to it. Referenced urls:
http://digitalnativestudios.com/textmeshpro/docs/sprites/
https://unity3d.com/unity/whats-new/unity-2017.1.0

All that said, as noted in the release notes, I think there’s a way for us to work around the <sprite> tags in general and not use them.  Even when those are working as well as possible, they still regularly show up improperly because we can’t control the exact relative scaling and offset per-font and per-font-settings.

Anyhow — major usability strides in this new build, although as always there’s yet more to do.  Also a number of bugfixes.

Cheers!

Chris

AI War 2 v0.500 Released: Major Milestone! Ship batch 7 of 7.

Still not time for “beta” status, or Early Access, just yet.  If you’re waiting for the smooth gameplay experience, there’s still a bit to go — but that’s now squarely the next thing on Keith’s plate (and the GUI is a big part of that, yes).

The release notes are here.

New Ships!

There are two dire guardians in this one (which are two of the most nasty ones), and then there are four big honkin’ Zenith golems.  This includes the Dyson Sphere, the Zenith Trader… and yeah, the Devourer. 🙂  Ho-lee smokes.

Bear in mind that these are the last of the ships until things are playing really well and the interface and whatnot have matured substantially.  Sometime during the Early Access period when things are running well, Keith will work on those interplanetary weapons (a stretch goal), the spire stuff (another stretch goal), the Nemesis (yep: stretch goal), and whatever other minor stuff might be left that I’ve overlooked.  I think basically everything else is in the game now, though.

Milestone!

Anyhow, so this is a very big milestone for us, because that means that Keith’s focus can stop being on content, and can shift instead to refinement, usability, and all that sort of thing.

I’m finally done with all my performance-chasing stuff as of a little while ago, and as of last release the sound system is in place (though not with all sound effects yet, of course), so cumulatively this makes for quite a satisfactory 0.500, I think.

Post-Processing Visual Stack AGAIN!?

I just finished redoing that, right!?  Well, it’s been redone yet again thanks to some issues that are detailed in the release notes.  The overall look is pretty similar to what it was before, except things are a little crisper and better antialiased, and there’s a very slight vignette effect.

The big difference is in the bloom effect, which is generally more subtle now, but also more diffuse and thus a bit more dramatic in how it blends things around.  Previously things were super intense in their bloom in a short range, but now they’re intense in their immediate area, then fade out more gradually.  Gives a more natural look.

Additionally, in order to deal with the flickering glimmering lights that could happen in some cases previously, the game now uses a much longer (about 3/4 of one second) temporal filter on the bloom, which can cause some really pleasing light trails that are purely a screen-space (and thus “free” in terms of performance) effect.

You can see that with:

  • The first shot in this post, which has the camera stationary and then the Ark moving away from it, leaving a bit of a ghosting trail from its engines.  That’s completely a screens-space effect.
  • The second shot in this post, which has the camera panning super fast to the right while the ships are stationary, and so you can see the glows being pulled to the left.  This looks less good, but is also a lot less common of a case and generally happens so fast you can’t see it unless you screenshot it while you’re in motion.  It does give a bit better sense of your own speed of movement, though, I’d say.
  • The third shot in this post (below) shows a stationary camera and both ships and shots that are moving, and how the glow trails help a bit with those.  This is more subtle since the shots themselves are trail renderers in a lot of the cases there.  It’s noticeable in a still shot, but during gameplay I wasn’t sure it was actually even happening.

If the temporal effect feels too strong to some folks, then I can easily make that a slider that folks can adjust in the settings, and we can debate what the best default setting would be if this is not it.  For the moment — and I’m too close to this at the moment to speak with any real confidence on the matter — I like how this is looking, though.

Coming Up!

Over the next half-week or so, Keith and I are going to be pretty quiet/absent, because of some other-life things that we need to take care of, respectively.  But then after that he’ll be working on the user experience and GUI and so forth, and I’m sure a bunch of mantis reports.  I’ll be working on mantis reports and more sound effects work, and getting the first voice acting in place, etc.

Enjoy!

Chris

AI War 2 v0.400 Released: “Usability and the GUI Pipeline”

New version!  Release notes are here.

There are also two new videos, one of which was for Keith, and the other of which is for Blue.  You might also find them interesting if you like the dev diary videos that we’ve been doing.

7 Days Between Releases Again?

Yeah, that bit isn’t my favorite.  But holy smokes this is a big one.  Hence the version upgrade to 0.400 instead of the 0.302 it was originally going to be called.  It warrants it!

Usability

So first off, this still has a long way to go, but there are some notable strides made in this area already.  There’s still a lot to do, but a lot of the things done in this version were aimed at making such updates easier in the future.

GUI Process Overhaul

This is one of those things that was designed to make things easier later, AND it also really improved our visual fidelity immediately and solved all our current GUI-related performance woes.  So… this was a big deal.

That said, embarking on this wasn’t really intended… yet, anyway.  As I noted to Keith in an email:

I was trying to fix that stupid sidebar, then realized several things couldn’t work the way I needed them to without some changes, then realized I could get a ton more efficiency out of better prefabs, then saw a bunch of other low hanging fruit, and suddenly I was waist deep in guts and there were tarps on the windows and I was trying to get rid of DNA evidence of what just happened. 😉

Wow that metaphor went off the rails fast. Accurate, though, to an extent.

The sidebar is indeed working again, by the way.  It is in need of severe TLC on the visual attractiveness and readability front, but that part is pretty straightforward now in terms of not letting the tech get in the way of the designers.

Amusingly, within the same minute that I sent the above note to Keith in a larger email, he was sending me a note back that included his own humorous analogy:

So I think that’s everything from my end on the UI circulatory-system-transplant. (“What kind of operation did you need?” … “A transplant.” … “A transplant of what?” … “Yes.”)

Again, quite accurate. 😉

Performance Of Those Darn Icons Over Squads

That’s a bugbear I’ve been chasing for the last week, and every approach I’ve tried has resulted in failure (although I have been able to shave the overall load from it down by about 20%, I’m aiming for a lot more than that and feel it’s reasonable).

GPU Instancing is something that is awesome and amazing for the ships that we have, but when you start getting to just tons and tons of icons (each individual icon is actually I think 8 icons on top of one another), then there come problems.  I had my own custom batching solution that I developed for either Starward Rogue or Stars Beyond Reach, can’t recall which, but those don’t work with complex MaterialPropertyBlocks, which I need for this batching.

Ironically, inefficient matrix math is the biggest thing holding back my specific use case.  I wrote a lengthy bug report to unity, with example code on how to fix it (I got a 120% or so performance boost with a trivial change on my end), so hopefully we see improvements there in a near-term version.

Longer-term, they’re expanding upon their ideas of CommandBuffers and open-sourcing the C# parts of their GPU pipeline, which will be wonderful for me on a number of fronts.  That said, that will be “sometime in 2017,” which to me means it could be after this year, frankly.

So I started thinking more and more about this, and was ruminating on a recent frustration of mine of not really being able to do much with vertex ids, since those are a bit on the limited side in terms of hardware support, and they just don’t quite do what I want, but ALMOST do.

As I was googling around the problem looking for some ideas on telling shaders about different surfaces, I came across an idea to just use the uv2 channel for sending custom per-vertex data.  Duh!  I felt a bit silly not having thought of that, because I’ve used various other tools that do exactly that sort of thing.  Anyway, using that general idea I can combine the 8 parts of a sprite for a squad into a single instanceable mesh, and then extend my existing shaders to handle that with a minimum of extra instanced variables.  I’m quite excited about that, because I know for a fact that works, and I’ve done that sort of general logic before.

There’s a slight chance that I might run into trouble with shader instruction counts, but I don’t think I will.  Thank goodness for the more recent shader models and their wide support on all platforms.

Enough Rambling

Anyhow, there’s a variety of other things in this new version, too.  Tractor beams are no longer so darn strong, and there’s some new ship graphics in a few areas, etc.  Performance in general is up yet again in a ton of areas, and there are some bugfixes.

Hopefully the next version comes sooner than 7 days from now!

Enjoy!

Chris

Taking a look at some AI War 2 ships during late alpha.

Chris here! This is just a video looking at a variety of the ships in AI War 2, or at least the graphics for them. These are in the version 0.124, which will come out early next week. It’s presently late alpha for the game (in the pre-Early-Access sense), and so these are coming up to a much more polished status now.

As part of our testing thus far, one thing that we’ve discovered is the need to use GPU Instancing. That was something that I hadn’t been sure if we’d need or not, and I’ve mentioned it since our first kickstarter for the game. I wanted to try to get away with dynamic batching, which is compatible with OpenGL 3.x and DirectX 9 and DirectX 10. However, the performance just wasn’t good enough, even in battles with only something like 5000 ships versus maybe 2000.

A few passing bugs aside, the performance was still better than AI War Classic with that scale of battle on the simulation side in particular, but GPU instancing became a clear need. So now the game is going to use that, which requires DirectX 11 or OpenGL 4.1, and basically hardware from 2010 or 2011, depending on your exact hardware and OS.

Realistically you needed hardware from that era at the oldest anyway in order to handle the CPU processing, so this really should be a moot point, but it was a bridge I hadn’t wanted to cross unless it really became clear it was needed. Well — now it’s clear. 🙂

A bug in the GUI sidebar aside, I was getting about 30fps in the aforementioned battle using dynamic batching. This is on a latest-gen i7 with a GTX 1070. Now with most of the stuff working with GPU Instancing, I get around 80 fps. There are still thousands of wasted draw calls because of some of how I’m handling my custom sprite system at the moment, and I expect to get my machine running that same scene at 120 or 140 fps by sometime next week. Knock on wood. 🙂 But it definitely seems like that will be what happens on my rig, based on all my tests thus far.

Anyway, so we get to the question of how big battles will be able to be, and to that I still have the answer: I really don’t know. For a variety of reasons, we can do larger battles than AI War Classic if you’re running them on modern machines. On a machine past a certain age (maybe from 2012 or before?), then the battles of Classic might be larger in terms of what your machine can handle. I’m not sure. The newer your machine gets, though, and that’s looking to the future as well, AI War 2 starts pulling further and further ahead. This switching to GPU Instancing is a huge amount of future-proofing in and of itself.

Overall we just have a ton of performance optimizations and multithreading in the game already, and it’s built around a variety of design concepts that lend themselves to larger battles than the original. We still do hit the occasional hiccup, like the sidebar thing, though, which makes performance absolutely grind to a halt for a bit. That’s one reason why we do the alpha, though; so we can fix things like that, and they never last long. 🙂

All in all, we’re looking good! I’m excited about the recent changes, even if I am apprehensive about any potential backlash by someone angry about the system requirements change.

Thanks for watching!

Chris

AI War 2 Video – Debugging Shot Lerping With Chris

Just thought that this was a fun video to do, since a bug in the shot lerping made this an ideal case to show what the shot lerping IS and how it makes a difference in the final visuals of the game.

The video came out longer than I had intended, but it’s a neat look into some of the math challenges behind having a “liar liar” 3D battlefield representation above an underlying coarser 2D simulation.

None of these are intractable problems, by the way, but if I waited to take a video after I fixed the problems, it would be a lot harder to see the innards of how this works. 🙂

As a reminder, we have a video playlist for our AI War 2 dev diary, which includes a variety of videos that are marked as unlisted on our main channel video listing.

AI War 2 Alpha v0.114 “Major GUI And Icons Overhaul” FINALLY released!

Chris here.  This is the largest single release we’ve done since starting the alpha with folks, and by a fair margin.  The release notes are nuts, but worth a read.

That said, right off the bat: “seriously Chris??  TWO WEEKS since the last build for the game?”  Don’t worry, that’s not something we’re going to turn into a habit.  In addition to simply packing this one with stuff, we also had that recent hacking attempt against us which slowed us down a tad, and some personal life things outside of our control.  But the biggest slowdown, by far, was the new icon system kicking my butt again and again.

Movie poster: “And then his butt… kicked back.”

(Wait, that’s not right.)

Icons!

At any rate, the icon system that is now in place is an in-progress version that has resulted from a lot of experimentation on my own part, along with experimentation by Blue, as well as lots and lots of discussion from players.

Note that I’m locking the original topic about icons, and I’d like to have a new discussion that starts from the common baseline of what is in 0.114.  I’m reasonably pleased with what is here, although the flair in particularly could look a little more visually polished.

Overall there are some polish things that need to happen with several areas of the icons, but in a generalized sense I think the core goals of showing clarity and yet not being cluttered is working well?  Before we get into polishing things like the flair too much, we want to make sure that we’re on the right path here.

The good news is that if we want to shift around what pieces of icon are where, it’s now something that I can do with some trivial code (or in some cases just xml).

The short explanation of these:

  • You can now see what a ship is via a combination of a central player-color icon and (sometimes) a non-player-color “flair” under it.
  • You can see the health for squads under them.
  • The mark level is still shown below them, but is done in a sprite fashion now.  And the color of the mark level on the squad shows its action status (Free Roaming Defender, etc).
  • If it’s under a forcefield or cloaked, then the mark level gets an additional glow around it to show that.  It’s subtle, but helpful.
  • If the squad is selected or mouseovered, then the main player-colored-icon part gets a border.

GUI!

Keith has been doing a ton of work on the GUI, adding in new menus and generally making things more-sane.  It’s still all temp graphics and so on, but the idea is to get the usability higher, which I think is very much happening there.

Another big thing that he has been working on with this is an Objectives window, which is inwork still (naturally), but is something I believe he wants to have a pretty major role in the game later on.  A lack of direction was something that was the biggest stumper for new players in Classic, even those that got through the tutorials.

The idea is to help solve that via the Objectives window, as well as making that useful for veteran players to check some intel (via what objectives are available for them).  At least, that’s my understanding — don’t hold us to that.  Keith can explain it better, as it’s his brainchild and I’m probably misrepresenting that bit by accident. 😉

Other Stuff

Oh man, it’s been so long I can’t believe some of the stuff that is in this build.  These were forever ago, but they’re just coming out now.  In no particular order:

  • Keith fixed a bunch of bugs, and I fixed a few.
  • We did a lot of internal work on our release process, to make releases easier and more reliable.  AND to make it so that hopefully we can remove files from the steam builds, which is useful for the external modding project that comes with the game.  (Keith, don’t forget to check that worked for you).
  • Some more work has been done to improve functionality in the custom LODs that I created for the game.  Although there’s a central problem with it right now that is causing them to not calculate their distances properly.  So it’s putting a lot of extra load on the GPU now compared to what it will next build.
  • The wormhole graphics have gone through like four more iterations, heh.  They’re a lot less neon now, and more attractive and more efficient.
  • If you’re playing on a non-US-English OS (linux or otherwise), the game should now work properly for you.
  • You can hold Z to see the range of ships, or shift to show the orders your ships have.  I’m already aware of an error in the display of your ships’ orders when they’re headed for a wormhole.
  • The cursor on the gamefield plane is now a lot more attractive and clear.

It’s been a really stressful couple of weeks for me, but I’m really happy with the end result.  Expect much more rapid releases coming up next week — although for now I’m off for the weekend, heh.  Looking forward to relaxing a bit.

Just in case there’s some major issue in this build that prevents you from playing, there’s a new beta branch in Steam for the older 0.113 build of the game.  You can revert to that if you want to play it for whatever reason, anyhow — hopefully the new build is far preferable on all fronts, though.  Knock on wood! 🙂

Cheers,

Chris

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.

Bomber

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. 😉

Fighter

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.

Chris