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!
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!
Looking good Chris! I was worried about performance when you decided to go to Unity but it seems like things are going well. Really can’t wait to try this out.
Thanks! And yep, we’ve been using Unity since 2010 or so (before that we were on a custom DirectX9 engine I made myself), so this isn’t new territory to us. 🙂
I was worried about nothing 🙂 I love how open and honest you are in your work. Very frank and humble when things don’t go to plan and always communicating what works and what doesn’t.
I’ve not funded AI War 2 yet but I will be as soon as beta starts or very soon after. I really loved the original and i’m looking forward to getting on at the ground floor this time. Through hopefully many expansions if we are lucky.
Thanks for making interesting games Chris 🙂 I really want AIW2 to be a success because you guys deserve it.
I really appreciate it. 🙂 In this day and age, I feel like honesty is something that many people place shockingly low value on, so I’m always happy when that matters to people.
Hopefully we hit that beta point late this month, although I guess it really depends on how quickly the interface evolves. A lot of the barriers to that evolving are gone now, and Keith just finished up batch 6 of the 7 needed for the beta, so fingers crossed. 🙂