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!
The release notes are here, and huge.
I’ve been neglecting to update the blogs, instead just posting to the forums and the kickstarter comments section when the last few releases went up. Honestly? Finding a picture for each release was taking too much time, so I’m skipping that here.
Anyway, Keith has been in process adding all of the for-start-of-early-access ships, and this is batch 4 out of his 7 for that. There are more ships for 1.0, but those will be in batches coming after May.
This build also has a huge number of things that I’ve wanted to do for a while, ranging from a cheats console to bugfixes with errant ships and ship selection statuses, to better zoom. Some of these were thanks to Keith helping me out whittle down my list.
Meanwhile Keith has also added a bunch of new AI capabilities, and so things continue to develop on that front. Things like the black hole generator you’ll also notice are very similar to how they were in Classic, but improved to be a bit more graceful in how they work with the game.
Things are going well! Cinth and Blue and myself are also busy on art things, and a wide variety of pieces are coming together all at once for the Early Access launch later this month. Still quite a ways to go in terms of the feel of polish (which is presently utterly absent), but we’re getting there. 😀
April 25th, 2017 – Notes for Cinth on how to use Mesh Baker Pro to do our atlasing instead of Pro Draw Call Optimizer. Pros and cons and troubleshooting galore, although it all works out in the end. Good tool, bad interface, great results. Translation: long tutorial.
We’ve had several releases since I last did a blog post announcing one, and that was mostly due to me simply not having time at the end of a long day each time.
What We’ve Been Up To
That said, the prior versions were not really fully reflective of how much work is going on lately, even so. The new planetary sidebar is an awesome thing (even in a somewhat early state), and the new shot lerping and smooth rotation of ships helps to improve the visual polish a great deal. There’s still a lot more visual polish things for me to do (and some visual performance ones) prior to the Early Access launch about a month from now, but it’s proceeding on a good pace.
Less visibly, behind the scenes Blue has been cranking out new ship designs with great gusto, and Cinth has been wiring them up so that they can be used. Keith has been doing massive amounts of underlying code work to support the various systems that all sorts of ships need in order to function. These things were frustratingly invisible, but now they’re starting to bear visible fruit.
Version 0.119, which is now out, is the first of seven ship batches that Keith has planned for during alpha. Overall there are 24 new ships in this one, so I believe that about triples the number of ships the game previously had. There are about 70 overall types of ships planned for during the pre-Early-Access alpha. After that, there’s another 60ish ships planned prior to 1.0.
Art For Ships vs Logic For Ships
Progress is happening well on all of that, although when it comes to actually having ships in game (playable) versus art-is-done (looking like the actual ship) is a mishmash. Some of the ships are in the game without having graphics completed (or wired-up) yet, and those just show with their name and little rock-shapes.
Some actually do have their art done, but they’ve been left as rock-shapes because Keith was in a hurry I think. Others have their art done, but the actual logic for those ships won’t be ready until another few ship batches from now.
From the look of things, we should have all of the alpha ships done in the next month (visually speaking), so that should coincide well with the Early Access date. For the post-alpha stuff, I don’t have an estimate on how long that will precisely take, but I’m guessing 3+ months after EA starts.
Backer Art Commisions
And then lastly, there’s 21 specific art variants that high-level backers commissioned; 10 custom arks, 1 ark or flagship (up to the backer), 2 derelict fortresses, 4 flagships, and and 4 gold-merc-backer-level merc ship paint jobs. These are things that we’ll start discussing with those backers once all of the other ship art is in, so that they can see what is there already when they’re trying to decide what they want to ask Blue to cook up. 🙂
All in all? Things seem to be on schedule. We’re behind in some areas (I had planned on doing sound effects before now), but ahead in others (some of the modding and balance capabilities are more advanced than I’d expected at this point).
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.
Oy, I’m tired. So I’ll mostly let the release notes speak for themselves. 😉 Also, here’s a screenshot: