Starward Rogue v1.750 released: two new mechs!

Hey everybody,

Exciting news! You may have heard of the upcoming paid expansion for Starward Rogue, AuGMENTED. Well, we’ve decided to push the free content part of that a month earlier, as in… today!

Merry Christmas! 🙂

So, in today’s update, as well as containing a bunch of improvements and fixes we are also introducing two new mechs created in collaboration with community modder Logorouge: Penumbra and Alpha.

One is a glass cannon ninja (or Glassassin if you like) and the other is a roulette mech with completely randomized perks. Both mechs provide a vastly different play experience. Playing as the Penumbra (shown above) can be challenging but very rewarding. With high damage output and a variety of special abilities at its disposal, it’s actually possible to feel like a ninja as you use the evasion unit to dash through dangers, and smoke bombs to hide when things get too hectic.

The Alpha (shown below) is the ultimate RNG mech where you could get a level 15 perk at level 1… or vice versa! Both mechs come with completely new weapons such as the Shuriken Shot and the Alpha Slugger.

Other improvements include an extended tutorial, a new condemned boss, extra particle work on weapons (smoke effects, muzzle flashes, bullet death particles), lots of balance work, improvements to perks (plus one entirely new perk), big performance boosts, and more. This build also contains an important fix for certain achievements that was preventing a 100% clear, many apologies for anyone previously frustrated by that problem.

As for AuGMENTED, we’re pleased to announce the launch date for that is January 24th. You can watch the trailer for that over on the store page. If you want to be informed when the expansion is available, you can add it to your wishlist so that once it launches you will receive a notification.

We’d encourage anyone considering purchasing Starward Rogue to hold off until our next discount period later this month (*cough cough*). Thanks for your support, and Merry Christmas from the whole Starward Rogue team. 🙂

Goodbye, Alloy, But Thanks For Teaching Us A Lot

As of our upcoming version 0.610, we’re removing the Alloy Shader framework.

The above is a tutorial for Blue, our artist, though if any modders who are creating custom models are also using substance painter, this shows you how to set up your setup, too. You can also infer pretty easily how to do combinations manually using Photoshop channels to create packed maps, too.

Anyhow, we’re moving away from the Alloy Shader Framework to instead use custom shaders that give us an equivalent look with a vastly reduced workload and with definite compatibility with future unity versions, and this tutorial covers Blue’s side of what needs to change.

The above is a tutorial for Cinth, but this also is useful for any modders who are creating custom graphics for the game.

As noted in this video, this saves us a ton of manual work. A ton.

Also in this video I randomly stumbled across a visual improvement to the custom player ark Rorqual Hegira, so you can see how that evolved a bit thanks to the extra flexibility of this new shader set.

 

Some screenshots of newly-painted PBR ships.

These ships are painted by Blue using Substance painter — well, overpainted by Blue.  These were ships that she had previously painted in photoshop directly in a cel-shaded fashion, and which now she’s overpainting to give it a mixed realistic look.

It’s worth bearing in mind a couple of things:

  • These are screenshots from Substance Painter, so it will look a bit different in Unity.   See my recent videos on that subject.
  • These have emissive parts on them, but that REALLY doesn’t show up properly in the substance painter view, so you’ll have to imagine that part for now. 😉

Autocannon Minipod

Old:

First revisions:

My main note on that was that it didn’t feel beat-up enough, although beyond that I really love it.  And, um… what a difference, right??

Newest:

Aww yiss, now we’re talking.

Fighter

Old (although with some improvements that were overdue on the cel-shaded part):

New:

I just love the fighter, with how metal and beat-up it looks now.  It should do particularly well in the in-game lighting and with the lightmaps on. 🙂

Armor Ship

Old:

New:

I also really love the metalness here, and the added details.  I’ve asked about adding a variety of scorch marks on that, though.  We could do a variety of smart masks and then make them black with a very high roughness and potentially low metalness and that effect happens easily.

Bomber

Old:

New:

Overall I really like the bomber, although it feels a bit too gleamy-shiny in some ways.  Maybe having it a bit more worn of a metal as a base there is something we’ll do — or just introducing layers of wear.  I love the scratches we have going on.

Eyebot

Old:

New:

The eyebot is perfect, I love that glassy look it has and how perfect it seems in a lot of ways.  Really a different form of character to it, which is fantastic. 🙂

That’s all for now!

Just thought I’d share a bit of the progress that is being made.  Now I guess that our main problem is that these ships are drawn so bloody small in the battlefield — relative to the camera — that all that awesome detail is lost…

We’ll figure it out.  Someone on kickstarter was mentioning the same thing.  Maybe the answer is smaller squads of larger ships, or using more verticality to fit larger ships in the same radius, or who knows.  I don’t want to shrink the feeling of scale of the game, but at the same time we want to be able to see more than just the icon-fest, at least when zoomed in.

 

More AI War 2 art-related videos!

Figured I’d cross-post this new batch:

The above is a tutorial for Cinth on how to get things ready for Blue to do her painting in Substance Painter. It doesn’t handle the old-style of very-high LODs for us yet, but it gets all the rest of it.

The above is a video for Cinth on how we need to update our existing ship definitions to fit with our new “one material only” approach, which relies on mipmaps and GPU instancing for the bulk of its efficiency, rather than on baked vertex colors and dynamic batching.

The above takes a look at the newly-free alloy shader framework, which we’ve used in other projects, and looks at the difference in quality when we’re now integrating it into AI War 2.

Starting at 8:30 in there is a tutorial for Blue, and at about 23:00 in is a tutorial for Cinth.

https://assetstore.unity.com/packages/vfx/shaders/alloy-physical-shader-framework-11978

https://forum.unity.com/threads/alloy-physical-shader-framework-version-3-for-unity-5.305178/page-34#post-3278461

The above video is about three ships that I’d done with standard shaders previously, including the first backer’s custom Ark, and now they’re converted over to Alloy. Just a video of me working and chatting about it as I do. Why not.

“Rorqual Hegira” Ark Painting Videos

No actual painting takes place in the first video.  Instead we go through mesh simplification, examining the mesh, sizing things up, and generally getting things prepared so that we can just sit down and paint in the next video.

The second video shows the first of the 11 custom Arks that kickstarter backers commissioned for the game. This will be one of the Arks that anyone who plays the game gets to choose between.

This Ark, dubbed the “Rorqual Hegira”, was the vessel for the cetacean flight from Sol. I can’t say any of those words. 😉

Anyway, this goes through the process of actually doing the painting to make the cel-shaded baseline turn into a PBR (Physically Based Rendering) style. Basically what that means is taking something that looks intentionally cartoony and adding on a layer of processing that makes it react to light more like real materials do.

As part of that I also wind up adding various procedural details, naturally, as Substance Painter is really excellent for that sort of thing. All those little scratches and splotches and so forth that humans just aren’t meant to paint by hand with any speed or lack of repetition.

This video took way longer than I expected, mainly because my first idea for how to handle the metal body didn’t work out (I had feared from the start it might not, but it was a fun one to try), and because handling the “glass with something down inside it” is an inherently super-tricky request, and something I wanted to do justice to rather than just slapping an emissive glow on it and calling it good. I’m quite happy with how the result came out, although we’ll see what the backer thinks once he sees this video.

Enjoy!
Chris

AI War 2 gains IBL (Image Based Lighting)

Recently I showed how the graphics have evolved in the game via switching the materials to be more PBR-based (overpainting our cel-shaded visuals to augment them via Substance Painter).

At any rate, one of the things that was bothering me was the drop in quality between Substance Painter’s view of things and the view of things in Unity.  It still looked great in Unity, but was a notable step down.

So, I thought about that a bit, and made some changes to the lighting in Unity.  More on that in a bit — but first I should note that this isn’t something that is costing any extra performance hit on your GPU.  Yeah, you heard me — these sort of visual improvements can be “free” in terms of performance cost.  It’s all in the techniques, and I’ve been learning a lot on that front as I’ve been working on my “secret side project.”

Anyhow, that’s been paying big dividends for AI War 2 that I wouldn’t have anticipated.

Where We Started

That’s purely a cel-shaded approach modeled in Maya by Blue, and painted in Photoshop.  There’s a lot to love there, particularly in most of the ships in the game, but this was probably the number one ship that bothered me because the asteroid doesn’t look at all like rock.  (Then again — do rocks in any cel-shaded game look like rocks??)

At any rate, her painting and models were being fed into some custom shaders I created, and then tuned to have custom reflection maps and specularity and rim lighting, etc.

One of the big things that I struggled with with my shader was making the ships look really dramatic — but also visible — on their dark sides versus their light sides.

Often this really caused issues with the normal maps (those images that make things look more bumpy than the actual underlying geometry is) either being too harsh or too subtle depending on how close you were to the ship or which side of it you were on.

Next Up: Substance Painter

In a video you can see me painting that mesh using Blue’s cel-shading as a base.  The end result — in Substance Painter — is this:

Now, there are a few things to bear in mind.

First of all, this is using different shaders than Unity has.  Ones that don’t have to render in realtime, and certainly not thousands of objects in realtime — Substance Painter would choke and die on that.  But that tool is equally useful for offline cinematics or feature films as it is for realtime game usage.

That said, it should translate pretty well — shockingly well, to be honest — to Unity.  When you’re using full lightmapping and calculated ambient occlusion and so on, the visuals get very very close between the platforms.

Problem, though: you’re not able to bake lightmapping in unity for dynamic scenes.  At least… mostly not.  There are a variety of complicated techniques, and even some simple ones.  But let’s just say for our purposes here that isn’t feasible in this particular case. 😉

At any rate, the second issue is that this is using IBL, or Image Based Lighting.  And in Unity I was not.

What Is IBL?

Basically that means a 360-degree image cubemap is “shining” on the model from all around it.  Imagine having a painted translucent box and putting the model in it, then shining light evenly through every side of the box at once.  The result is an IBL look.

Actually, you know what?  Just check out this video with someone showing off what Unity can do.  Video is worth a thousand words… squared?

Okay, So What This Looked Like Coming Into Unity

This is a huge improvement over what was in Unity previously, but it’s still… not my favorite.  The lighting is very stark and harsh, and the specular reflections feel wrong, making me have to tone down the smoothness of the metallic shaders.  All that combines with the flatness of the lighting in general to make it feel… like a blander version of what I had before.

Well, heck — I’ve worked with IBL plenty of times before.  Let’s see what I can do.

Upgrade One

Starting with this:

We then move to this:

In order to get that second look, I turned off the main directional light in the scene, and am using just a single IBL light source.  I have to “bake” that in a really broad sense for Realtime GI to work in unity, but my understanding is that it isn’t really using anything other than the original cubemap since there’s no true baked data (no lighting probes, etc) in the scene.

At any rate, this is with the ambient light coming from the (invisible) skybox, which is an HDRI cubemap.  And then no other light sources other than the emissive materials on actual ships.  Oh, and the global reflection cubemap has also been toned down a bit and switched over to use a compressed version of the HDRI skybox rather than the studio lighting look I was using before.

This approach is pretty cool, and certainly more vibrant… but it’s still missing something.  It’s a very flat look to it, and if you circle the asteroid the lighting is even on all sides.  There’s no real shadows happening.

Upgrade Two

Now we’re talking!  This tones down the ambient light a bit, and then adds back in the directional light — but tones that down to about 60% of what it previously was, too.  I also made the directional light warmer rather than a harsh white, so that it would match with the HDRI image I chose.  Incidentally, I went through a variety of HDRI maps before finding one that felt right.

The overall settings used in Unity for this are as follows, if you’re curious:

And That’s Where We Are Now!

In a non-procedural game, there’s all sorts of fancy and highly-performant things that can be done with lightmaps and reflection probes and so on, but this is not that game. 😉

For performance reasons I’m not using parallax mapping/heightmapping/tessellation or baked AO on these models, either.  Those don’t contribute enough to the scene to be worth the added GPU and RAM costs, and we want this game to be able to remain as huge as possible.  All of the changes thus far have been either GPU/RAM-neutral, or come with a performance savings.

I may move back into slightly custom shaders for this, mainly so that I can handle the death effects for ships via parameters on the ship itself “eating the ship away” as it dies.  But in general, beyond that, this is how the game looks now (or will look, once we paint all these models again — blending what came before with what we can do now).

Hopefully this was an informative/interesting read.  🙂 It’s obviously something I’m passionate about, and I think it contributes a lot both to the mood of the game and our ability to sell it to a wider audience.

Chris

Updating the ship aesthetic in the game?

Chris here!  Wanted to run something by folks.

Hopefully you can click on that and get the fully zoomed-in full-quality version.  If not, here is a link to a version that will definitely be full size.

In case that (tiny, tiny) text at the bottom is hard to read, here’s what it says:

Note that this effect actually uses vastly less VRAM than the other approach — insanely — because we’re able to use compressed textures. The smooth, cel-shaded look shows imperfections in texture compression super fast, so we have to use higher-quality compression or even no compression. The PBR-based approach is inherently grungy and messy, which fits with the general vibe of a war-torn galaxy anyhow, and DXT5 compression doesn’t show any artifacts that aren’t just something your brain writes off as more grunge.

This overall aesthetic helps to make things look less “happy,” since that was a complaint withthe art before, but it also keeps the exact sameunderlying textures. However, we’ve overpainted those textures using procedural work in Substance Painter, giving a blend of hand-drawn and PBR styles that seems unique.

Thematically this seems more appropriate, and it’s also a lot (LOT) more efficient on your GPU, particularly if you’re on OSX or Linux (which can’t read BC7 compression. We’re talking a 4x to 10x reduction in VRAM, while getting added detail — just to be crystal clear. 4x on Windows, 10x on OSX and Linux.

We should also be able to make some of our LODs and asset-integration work a bit more efficient using this, too.

Any complaints?

Oh, Also — About The GUI

We’re having a lot of discussion about the GUI, and I’ve made a pair of videos on the topic.  Cyborg has been a huge help in focusing our attention in a positive way in this particular area.

Also, when it comes to the vibrance of the space backgrounds I’ve toned those down as of today, too — with the next build that comes out, 0.601, those will be much more muted.

And About Those Remaining Keys…

Still waiting on those from Valve.  So sorry about that!  I assume I’ll have the keys from Valve either this afternoon (PST) or tomorrow afternoon.  Otherwise I’ll get up with my contact there.

Cheers!

Chris

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