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

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!

Chris

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.

Cheers!

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!