Overland Newsletter — April 2017
Hello readers! I have many, many updates for you. This newsletter is long overdue and is due to run over and long accordingly. I’ll run through The News as fast as I can and then show you some of the art and tech that we’ve been working on that is allowing us to flesh out the second half of Overland finally.
The News Part 1: Overland Build 223 is Out Now
Even though it took 3 months longer than I hoped (see the rest of The News below, and this month’s deep dive into our new tech) Build 223 is up on First Access finally.
There’s an entire new biome, The East Coast, where the adventure properly starts. The Woodlands, Grasslands, and Mountains have all been remixed to balance out and work the way they’re supposed to accordingly. The Mountains has some new dangers as well. I was going to call this patch a “game-changer” but Rebekah threatened me with violences so.
My point is if it’s been a while since you played, and you’re curious about what we’ve been up to, this is a pretty fun build to explore, especially if you haven’t seen the new UI, the night-time levels, etc!
The News Part 2: Night in the Woods
We did it. We actually got it out. Not only that, technically no one at Finji or Infinite Fall perished. Also as far as we can tell, folks are way into it.
We even got that Arby’s tweet!
At least emotionally it’s been very overwhelming, to get the game out and then to have it connect with people on the level and in the way that we hoped it would… I mean emotional in a good way, but overwhelming is overwhelming still. It’s been a commercial success also, which doesn’t hurt.
Marketing guy voice: also it’s available now on PS4, PC, Mac, and Linux for just $19.99 and probably will mess up your emotions!!
The News Part 3: Shows and Whatever
So in the midst of actually releasing Night in the Woods, we also mentored Train Jam attendees, met everyone up at GDC, and then took Overland and NITW to PAX East.
It’s always rewarding to connect with our players (old and new) in meatspace, and PAX East is no exception obviously. Most of the team did get the flu though, which we all have mixed feelings about. Actually that’s not true at all, we hate the flu with a vehemence usually reserved for fascist oligarchies taking over plural democratic republics backed only by a narrow white supremacist minority!
The News Part 4: A New Chris Joined Your Party
PR & marketing expert Chris Dwyer has officially joined our crazy quest full-time. He’s been a huge help for Overland specifically, and for helping get us through the Night in the Woods launch, so you’ll be seeing a lot more of him around here whether you like it or not!
Anyways give him a hearty wave, high five, or hug next time you see him at the Finji booth. And of course welcome to the family Chris!
Ok But Back To Overland Though
So yeah one thing we mentioned earlier is that Build 223, or at least the contents of it, are things that we’d hoped to ship by the end of 2016, not Q2 2017. The most obvious thing that happened in there is of course that Night in the Woods became a huge priority for us. It’s a project we’ve been nurturing for a long time, and the last thing we wanted was to under-attend to its launch. We didn’t go into this blind or anything either, we knew that launching it well meant Overland would be slowing down for a while. I don’t think we understood beforehand quite how much! That’s shipping games through I guess.
The good news is we have our momentum back and it’s a huge relief. Overland means just as much to us, if not more, obviously, and it feels great to finally share some of the new stuff we’ve been working on, and to dig in to the next set of features and content right away.
For this newsletter’s kind of behind-the-scenes part I wanted to talk a little bit about some new tech we’ve been developing to help us make some of our new environments. Specifically, environments like this:
See how the buildings and the terrain all sit together nicely as one contiguous piece of the diorama? Pretty nifty right. Not rocket science though — you just model the ground, model the building, stick em together, make sure the cutaway is UVed properly etc. Except that Overland has procedurally generated encounters and environments — we want each area of the city you stop in to look and feel a little different. We want to be able to shuffle up the order of the buildings and so on.
But we want the edges to still look totally seamless, be lit appropriately, not interfere with existing edge-oriented UI elements, be performative, hopefully not require any technology features that are platform-specific, not mess with existing shader effects like heat waves, etc etc.
Ultimately we decided to break this up into two problems. One easy, one not so much (at least for us and our complete lack of experience building 3D games).
The Easy One: Clipping
So by clipping we just mean “don’t draw stuff that is outside of the diorama’s bounding cube.” Before we started on this feature I wasn’t sure what was involved to accomplish this, but fortunately shaders make this very, very easy to do. For example, here’s the Overland standard material shader layout in Shader Forge:
See that little code box down there with all the “return O;” calls? That’s just saying hey, if you’re trying to draw a pixel and it’s out of bounds, just don’t. Here’s what the scene in the last screenshot looks like in the Scene editor window in Unity thanks to that simple bounding box check:
That’s about all there is to it. In our case there was a bit more work involved, as a lot of Overland stuff was still using the Unity Standard Shader. So we had to update some materials etc. But this was overall a really cheap and easy and effective first step.
But wait, there’s more!
The Not So Easy One: The Cross-Section Effect
Boy that was fun and easy. Except now your game looks like this:
Which it turns out maybe your art director feels like looks pretty bad and is pretty upset that you even proposed that this might be an acceptable solution. So now you just draw the edges where you chopped things off, so easy.
Ok so the main thing is that everything in every video game is a bunch of smoke and mirrors and very very gentle lies. Things that look and feel solid in games are really more like papercraft models. If you cut away some of the pieces, there’s no nice foamy interior there to see. It’s all very thin and very hollow. So, because it’s video games, the solution is even more smoke and mirrors and gentle lies.
There’s a few different roads you can take at this point. Probably even more that we never even thought of but these were the ones that came to mind:
Physically slice away unused geometry, and reconstruct new geometry along the cut planes. Possibly as a vertex shader, possibly as a load time process. Would work well for static geometry, maybe not so well for objects moving dynamically across the boundaries. Potential for weird glitches, bad cuts, etc.
Use a screen-space shader effect to fill in the empty areas by doing some kind of special effect where we only draw unobscured backfaces. Essentially, we’d be drawing only the insides of things, and only the parts you can actually see, last. Like on top of everything else. Easy to set up, works great with static and dynamic geometry.
Because of cars driving in and out of levels and some other things, we thought the shader option would give us a lot more flexibility. Running it as a screen-space post-effect meant it would be relatively unobtrusive too, which was nice.
Unfortunately, it completely didn’t work at all like we hoped. The two main problems were A) intersecting geometry and B) obscured world-space UI elements.
Intersecting geometry is a weird idea at first, and the papercraft metaphor starts to break down here, but imagine the papercraft is instead like… holograms, basically. They can overlap and intersect in totally arbitrary ways. You can make a papercraft duck and a papercraft boat and just mash them together and they’ll overlap in 3D space without complaining at all.
So which is fine and great, computers use a thing called a “depth test” to decide which parts of the duck to draw and which parts of the boat to draw. But now imagine, because we’re doing cutaways, that we’ve used scissors to cut off parts of the duck and the boat. And now we’re asking the computer to still draw everything correctly. But now you can see part of the boat steering wheel inside the duck. Do we draw that? Do we hide that?
On top of that, running it as a post-effect had the unintended consequence of completely obscuring some world-space UI elements that we rely on heavily, like the big arrows that let you drive out of the level. And on top of that, we were still loathe to physically slice away the elements and try to perfectly reconstruct and triangulate the 3D cross-sections. Games have done this before (see Metal Gear Rising) but lordy it was an unappealing option.
Crud
This was admittedly a pretty demoralizing crossroads. It really seemed like an achievable thing, but it also felt like something that could be done without needing a PhD in computer science or whatever. Like there had to be a more approachable, simpler method. Finally we figured out a weird new idea that seemed promising: shadow puppets. Basically anyways.
So I mean forgive me the obvious storytelling thing here right, I mean there are screenshots up there that have a relatively convincing cross-section effect and I already told you we already figured it out so like this isn’t exactly a twist ending but. The solution we ended up with is pretty simple and pretty effective and I’m excited to show you how it works! Thus the buildup here. Anything to legitimize the pain it took to discover it haha.
Ok so the idea is basically this. What if the insides of the cutaway meshes essentially cast shadows against invisible screens on each side of the diorama?
And it goes a little something like this (hit it):
Now, this wasn’t by any means the … this wasn’t quite the elegant simple stroke of absolute unfettered genius that it might seem. In respect of everyone’s time I’ll stick to summarizing some of the remaining problems rather than dedicating them whole like chapters.
One problem was that our asset pipeline involves a lot of intersecting meshes, which are still a problem in this approach. By splitting our geometry up into static and dynamic layers, we were able to render the static layers up front and composite them into a single image. This allowed us to have a lot of overlapping static geometry, and to have the dynamic geo overlap that too. We ended up having to handle this on the submesh level too, to keep the pipeline light and manageable on the Maya side, but it’s a couple of loops or whatever, nbd.
Another problem was that Unity’s basic lighting system uses rendered pixels to draw shadows, so cutaway buildings were casting WEIRD shadows. However, because these screens have rendered pixels on them, they can fix the shadow casting problem! However, you actually have to have screens on the two sides of the diorama where they don’t really seem necessary to sort of box those sides in for the lighting engine.
Another small issue was that the shader I was using to “cast” the “shadows” against the screen relied on a semantic fragment shader variable that has WAY less stable support across APIs than I thought. Which is a very fancy way of saying the “shadow caster” I wrote just effed up super randomly on all Windows machines. I rewrote our double-sided shader to be a simple two-pass shader and that fixed that.
Another small very small problem is that on Windows, if you turn off a camera that is drawing to a render texture in Unity, Unity might randomly sort of assign it to another camera’s buffer, making the game completely unplayable on its primary platform during the whole weekend after your big patch came out.
Anyways, at the end of the day, we’ve ended up with a super robust system with very good performance that achieves all our goals, and can even handle dynamic geometry pretty elegantly:
Anyways, the main thing this lets us do is achieve the look and feel that we’ve already established, but keep our asset pipeline pretty loose and flexible. Overlapping meshes? No problem. Big ol dioramas with lots of variety and we only show a small slice? Easy. Mega-obstacles like buildings and large rock formations that might extend outside the diorama? Pssshhh what could be easier. A few weeks of painful programming has produced an environment in which our small team can create much more interesting environments with a lot more variety without a ton of special case stuff.
Onward
Anyways, thanks for reading. Hopefully if you had questions about what was taking us so long to hit our next content milestone this has provided some insight there. Night in the Woods was a huge part of this obviously, but taking the time to build this new tech, which we’re using in every biome to make every level look better without crushing our art director’s spirit, and which we’ll be using even more in the upcoming areas, was a harsh but necessary sacrifice. I always have these mixed feelings about whether showing how the sausage gets made takes away some of the magic, but idk, sometimes the way we make the sausage uses a lot of magic too.
The easiest place to follow dev right now, in between these beefy newsletters, is on the official Overland twitter. We’ll be keeping a relatively low profile for the next few months while we build to our next big milestone, but patches and release notes should be pretty steady over the next few months if that’s your jam.
Thanks again, and as always, safe travels ❤
