Hey traveler! Alex here, transmitting live from our Story Simulation Center on the moon (the low gravity is great for tossing around weighty narrative concepts). Most of the work we do up here is still under wraps, but today we're going to take a small peek into how we build and test the underlying mysteries of  Outer Wilds.

It might have all the trappings of a space game, but I like to think of Outer Wilds as a narrative adventure game that just happens to take place inside a (miniature) astrophysics simulation. As players explore each planet, they discover pieces of embedded narrative that reveal the history of the solar system and the ancient race that used to inhabit it. These pieces also act as clues that point to each other and to special hidden locations, or "Curiosities", where players can find answers to the game's biggest questions (i.e. what's really going on).

Considering the scope and complexity of our narrative structure, it's pretty important that we test whether or not players can understand the clues, find the Curiosities, and piece everything together into a coherent story. Which brings us back to the bit about all of this taking place inside an astrophysics simulation. Testing for narrative comprehension is extraordinarily time-consuming when players can't even access most of your content without (among other things) learning to fly a spaceship. We needed a way for players to test the game's entire narrative structure in a fraction of the time it would take during a normal playthrough.

Our solution was to make a paper prototype that completely abstracted away the space travel and focused on what we wanted to test: the underlying narrative structure.

Major locations on each planet were represented by note cards, and players were given a limited number of turns to move between them each round (if you've played the alpha you can probably guess why). Players could also spend a turn to explore a location, which occasionally meant flipping over the card to reveal hidden information, and more often involved me just describing what they found there.

Overall the prototype worked surprisingly well. It gave us valuable insight into how players were interpreting the clues and understanding the story, and by essentially DMing each session I had a lot of flexibility to adjust content on the fly. We noticed that all of our playtesters quickly resorted to jotting down their discoveries on a notepad, which pretty much confirms that the onboard ship computer should keep track of your discoveries.

The next step, which was both totally unnecessary and absolutely worth it, was to recreate the paper prototype in an open source Java library called Processing.

Between these two narrative prototypes we now have a much better idea of what the game feels like when all of the pieces are put together. Our next big challenge is to translate the descriptions from the text adventure into fully realized 3D spaces. We've got a lot of content to make, but it's nice to know that all of it is  probably going to make sense.

Onwards!

Greetings from Outer Wilds Ventures! One of the big questions campers have had is how our previous titles relate to Outer Wilds, so we thought we’d gather y’all ‘round the fire for a good story about the games we make at Mobius Digital.

Our motto is “We make games wild and wonderful. Come explore with us.” We believe this rings through all our design: giving players only part of the map and asking them to discover what’s out there in the wild. That’s certainly true for the mobile game we’re just finishing, Beacon 38. The first core pillar of the game was “At its heart, this is a game of EXPLORATION.” 

Beacon 38 puts players in an unseen alien dimension where they must use sonar pings to expose the flora and fauna of the world around them, but the underlying principle is "To Observe is to Influence." The world is constantly moving around the player, and they need to figure out what's going on rather than rushing head-on into danger, a mantra that works well for making it through the tightly constructed chaos of Outer Wilds.

Greetings from Outer Wilds Ventures!  In this first episode from our Head Music Counselor, Andrew, he discusses the evolution of the main theme for Outer Wilds and plays some of the stripped down space campfire tunes that he wrote as a basis for the score!

Greetings from Outer Wilds Ventures! Our latest transmission comes from Kelsey in the Narrative Department, who is making sure you'll have the most wonderful story to tell after your amazing stay in Outer Wilds!

Three guesses which games are major inspirations for Outer Wilds’ narrative and in-game text! If you guessed offhandedly snarky titles like Grim Fandango or Curse of Monkey Island, then you win bonus points, because the easy answer is “pretty much any Zelda game.”

Weirdly, I have not played much of Majora’s Mask, which is obvious OW design influence; I was a latecomer to consoles, so my first experience with the Legend of Zelda was on the Game Boy Color, and the charmingly bizarre characters and races in Oracle of Seasons and Oracle of Ages made a big impression on me. In Oracle of Ages you have the Tokay, friendly giant lizards obsessed with meat that steal your items when you land on their island and go around saying off-kilter things like, “There’s a winding maze beneath this island. Maybe.” Oracle of Seasons has the subterranean-dwelling Subrosians, a secretive be-robed species who are really into digging for ore chunks and dancing. That’s also where you’ll find the Subrosian Smithy, one of my favorite places in the Zelda multiverse, where your choice of dialogue when requesting a job is between “Make it fine!” or “Do whatever.”

The point I’m trying to make is this: my favorite games have always been the ones full of interesting characters and unique races, because that’s what really sucks me into a story and makes me feel like part of the world. What would Ocarina of Time be without the Gerudo and Gorons and Kokiri and Zoras?

So we finally tried updating the Outer Wilds project to Unity 5 this week! After several thrilling hours of tweaking the entire code base to work with the new (admittedly much-improved) Unity API, the last compile error finally vanished and I eagerly pressed the play button.

This is what I saw.

Those who have played Outer Wilds before know that the game begins with the player character looking up at the sky. This is technically a screenshot of that scene, albeit with a few notable discrepancies. Let's ignore all of the weird graphical artifacts for a moment (those are to be expected when upgrading a project) and focus on the fact that the player character has fallen through the ground and is well on her way to the planet's core. If you haven't played Outer Wilds, I should note that this is not how the game typically starts.

A cursory glance at the error output window revealed the source of the issue.

The console contained 999+ identical errors reading "Non-convex MeshCollider with non-kinematic Rigidbody is no longer supported in Unity 5". Non-convex (or concave) refers to geometry featuring negative topology (valleys, caves, tunnels, etc), and non-kinematic rigidbodies are objects that can be moved by physical forces. This error essentially means that dynamic physics objects can no longer have negatively-curved geometry in Unity 5.

In most games this isn't a problem. The most common use for convex colliders is level/terrain geometry, which by definition is usually static. Objects that need to be simulated with physics tend to be simple enough that their shapes can be approximated by one or more convex colliders.

In Outer Wilds, literally everything in the game is moving at very high speeds due to real-time physical forces. Each planet is a non-kinematic rigidbody that is actually rotating about its axis as it zooms around the sun. Every planet also features a  terrain that relies on a non-convex mesh collider to prevent smaller physical objects (like the player) from falling through it. Likewise, your ship is a dynamic rigidbody that needs a non-convex collider so that the player can walk around inside the cabin while it's in-flight (fun fact: we have to apply a counter-force to the ship at its point of contact with the player, otherwise the player's weight would cause it to spin ever so slightly).

A quick google search revealed that the ability to marry non-convex mesh colliders with non-kinematic rigidbodies was discontinued by the physics engine itself. Unity 5 uses the latest version of Nvidia PhysX, which apparently no longer supports that feature (probably for performance reasons). In short, it's not something that's going to be fixed anytime soon.

That leaves us with a few options:

1. Replace every non-convex mesh collider in the game with a bunch of convex mesh colliders. This is almost definitely a terrible idea (imagine trying to create a tunnel out of convex shapes).
2. Secretly make every planet static...it only looks like they're moving. This is problematic because we'd lose all of the cool side-effects of actually simulating planetary motion (try jumping straight up on the moon and notice how you drift across the surface depending on your distance from the equator). Theoretically you wouldn't notice a difference if we correctly simulated Coriolis forces, but that is a massive "if".
3. Make every planet a kinematic rigidbody (instead of non-kinematic). Kinematic rigidbodies can still be moved manually, but they are not affected by forces. We'd have to write our own physics simulation to achieve planetary motion and crazier stuff like the islands on Giant's Deep. We'd also need to choose an integration method that closely approximates the one used by PhysX (the internet says it's probably this one: https://en.wikipedia.org/wiki/Semi-implicit_Euler_method).
4. Keep using Unity 4.
   

We're still weighing these options against each other, but right now we're leaning towards either 3 or 4. It just goes to show that when you make a game that blatantly ignores how its game engine is intended to be used, these types of problems simply come with the territory.

Then again, I suppose we wouldn't want it any other way.

--Alex