Working notes, and a bit of a tutorial of sorts (as well as a request for help) for Keith. Also includes essentially some working notes for Blue, our artist. And there’s some technical tidbits that an avid modder could pick up here, if they’re so inclined.
New version! Release notes are here.
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!
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.
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!
Notes for Blue (or modders), given that we’ve switched to a completely new GUI system (the unity built-in one) for this project, and there are some hidden settings that are easy to overlook.
Internal notes between developers on how we’re handling some of the text stuff in version 0.302 and great. Figured others would also be interested!
As of two days ago, actually. Please see our latest kickstarter update for all the news on what’s going on at the moment. Cheers!
A how-to guide for modders or other players who want to create nebula backgrounds for either their own use, or to send in for official inclusion in the game. This requires version 0.302 or greater of the game.
For the various folks that work on one or both of the games, showing how to get both of them compiled and ready for people to use. AI War 2 is waaaaay more complicated, which is pretty interesting to see.
Please see our latest update on Kickstarter for all the details.
What’s The TLDR?
1. We’re going to delay the actual Early Access launch on Steam until something like late June or early July. Previously it was intended to be May 29th.
2. BUT, for all the “Early Access” level backers from Kickstarter and BackerKit, we’re going to give you your keys on May 29th anyway, as promised.
Seriously, there’s a lot of details there, and if you have any questions please let us know. Thank you so much for your continued support as we take this game to bigger and better places than we had anticipated. Speaking of, we just dropped a massive new release an hour or so ago. 🙂
This release has… just absolute tons of stuff in it. First of all, it has the 5th batch (out of 7) of pre-Early-Access ships. Lots of goodies in there.
Secondly, it has an enormous overhaul of the visuals, which you can see in video format in this post from last week. This does indeed affect the minimum system requirements for the game, which you can read about in both of those links.
The gains we get from those changes are absolutely staggering, though. On my GTX 1070 and latest-gen i7, there was one particular savegame (with 5000 ships in it) in which I was getting about 30fps even when paused. And it was a ragged 30fps. Now I get more like 90 to 100fps when paused in that same scene, thanks to all the improvements made here.
When it comes to actually unpausing and having ships move around, there is a dip in performance again back into the 60s fps on that hardware, but that’s largely to some half-measures that are in place right now optimization-wise. Some of that has to do with frustum culling and other optimizable things on my end, and others of it has to do with some optimizable and/or better-multithreadable stuff in the simulation on Keith’s end.
On this particular savegame I am referring to, it’s possible to send those 5000 ships through the wormhole to its neighbor. Once you do that, the performance absolutely tanks on my machine, even with all the improvements that have been made thus far. I get a ragged 5 to 25 fps.
Some of that is related to things I still need to optimize better in the graphics code (the frustum culling itself is 30-40% of the CPU-side graphics load right now, which is ludicrous and something I intend to work around).
Other bits of that are simply bits of the simulation code that need some looking-into by Keith. I don’t dare really speculate on that, since it’s not my part of the code, but it’s the sort of thing that he notes will take a few hours of investigation at least, so we didn’t want to delay this release over that.
Smaller-scale battles are running better than ever, after all.
But there’s always more to be done, and I’m hoping that we can get those battles of that scale up to a buttery-smooth 60fps or higher. Seems doable, but we’ll see — in AI War Classic, those were hard-locked to 20fps most of the time, and would run extra slowly under the load, too. So we’re already pulling ahead, and we haven’t done remotely a full optimization pass on the simulation code.
I’ve had time to do that sort of thing on the graphics code because it’s a lot more limited in scope, despite being super intricate; so I’ve been able to focus on iterations over and over again, while Keith has been splitting his time between improvements and additions, since the simulation is so much larger.
Oh: also, right now the battles are throwing out metric tons of particle effects, which will largely be going away. I have fancier things I can do without all that wasted CPU/GPU time. 🙂 People talking about “ships breaking apart” being a neat thing got some ideas into my head. Giant things will still do explosions, but we’ll make those look more epic, too. And since they will be comparably more rare, they’ll stand out better as well as not adversely impacting performance.
Anyhow, that’s another big big area that will really improve things during battles, performance-wise. Just haven’t had time for that bit yet, on my end.
There’s a lot of other goodness in this release, too. Things like more ship models, way more ship icons and flair, and so on.
The sidebar is temporarily semi-busted because I just frankly ran out of time and will get to that tomorrow. It works, but it’s not colored properly and doesn’t have the proper flairs on the ship icons. And its icons likely still don’t show up on linux right, although they will once I’m done with that bit.
Coming Soon: Sound!
Craig (Pepisolo) has been taking on the process of getting the sound effects going for battles, and I’m going to start actually integrating that soon. I’m really excited to finally start hearing these battles, rather than just seeing them.
Going along with that, at the suggestion of a number of players I’ve started working with a variety of voice actors to do human-side voice responses to commands that you issue. More on that soon, but I’ve got the first four sets back and I’m really pleased. I’ll be integrating those soon as well, and then tuning them with your feedback.
Onwards and Upwards!
Thanks for reading. 🙂
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!