Just before we broke up for Christmas I finished up on the broad strokes for the level design of our open world. There’s about 100km, or 6 hours of rivers to travel down, all thanks to our improved tools!

A big time saver is automatically setting bezier control handles from the position and rotation (which is itself generated from positions of the points around it).

We set the control handles automatically from the position and the rotation or the point (the rotation is also set automatically in most cases). If you want to see what I mean, watch how the white points move.

Keep reading

Here’s a common thing to want to do in ink, that’s surprisingly annoying:

What we want is a knot we can thread in which simply inserts a generic “that’s enough for now” line. We’d like to vary that line so it’s not always the same, so we shuffle the text.

So what’s the problem? Well, the shuffle picks out a random choice…

… and when the choice is picked, the shuffle picks again….

… so what the character actually says isn’t the line you chose. This happens because choice content is re-evaluated when a choice is chosen. So how do we stop this from happening? 

The easiest fix is to use a temporary string variable: 

But a better solution is to break your shuffle into a multi-line list and embed the choices into it.  This can be really powerful, as it allows some lines to be longer than others, or contain extra data. (If you’re using voice-over via hashtags, for instance, you’d need  to do this.)

After the choice happens, the flow will move to the next available gather point and continue from there.

You can’t gather points into shuffle blocks this way, or more complex weave structures, but you can do single blocks of content; including diverts.

With a small art team and quite a few environments to cover, we’ve been looking into procedural techniques to help quickly generate detailed content. Procedural generation can mean quite a few different things, in this context we’re using procedural systems to quickly add detail to blocked out art assets. First up - rocks!

Quite a few of our environments have rocky surrounds. From lush steep-sided valleys to sand-carved deserts, we needed a way to hit the level of detail we wanted without requiring the usual AAA art team size. After a bit of R'n’D we’ve hit on a solution we’re pretty happy with. Onward to pictures!

This is a section of the cliffs surrounding one of our environments, it’s a big chunk of level and would take a good while for the art team to detail up by hand. The low detailed model is the original block-out, it’s not particularly exciting but it serves its purpose while the gameplay and layout are being tweaked. To make it more snazzy, we apply one (or more) basic rock-type procedural templates like these:

The template adds deformations at different scales to create large and small features, cracks and other details. From that basis, we can just tweak some settings to get the right look and scale, perhaps mixing in some other rock types to add more interest.

As these are generated at a super high resolution, we need to optimize the model for use in the actual game. However, having all that extra detail allows us to quickly generate the textures using the crags and crevices in the actual geometry (in this case, using Substance Designer). Check out all that lovely edge detail in the final model!

A model like this one now takes a couple of hours to produce, rather than several days. As we create more environments we can also expand our set of templates, allowing more variety without loads of extra work for the artists. Perfect!

Two powerful features of ink that we’re slowly starting to use all the time are threads (which let you bring choices and content from another knot into the current knot, potentially diverting the flow) and tunnels (which let you drop into another knot, and return when you’re done, like a classic function call). 

But one problem that starts to arise is how to thread in content that’s been written as a tunnel. Is it possible?

Well, yes it is. But it requires a slightly cunning bit of ink. 

=== tunnel_as_thread(-> tunnel, -> ret )
- (top)
   -> tunnel ->
   {TURNS_SINCE(-> top) == 0: -> DONE }  -> ret

This runs the tunnel and threads in any choices inside that tunnel. 

If the player doesn’t choose an option from inside that tunnel, this thread will die, and the last line is never hit. If they do choose an option from inside the tunnel, then when the tunnel finishes goes back to the given return point. 

The TURNS_SINCE check is almost unnecessary: it’s needed in case the tunnel contains no choices at all: the -> DONE ensures the thread stops safely, instead of continuing onto the return point. 

Here’s an example of this in action:

- (opts)
<- tunnel_as_thread(-> ask_about_urns, -> opts)
<- tunnel_as_thread(-> ask_about_coins, -> opts)
*  {ask_about_urns.done && ask_about_coins.done} [Finish talking]
   El:     Okay, we’re done!
-   -> END

== ask_about_urns ===
   *   El:    Are urns useful?
       Six:   Depends on what you want to put in them.
   -   (done) ->->

=== ask_about_coins ===
   *   El:     Do coins float?
       Six:    Depends on what they’re made from.
   -   (done) ->->

=== tunnel_as_thread(-> tunnel, -> ret )
- (top)
   -> tunnel ->
   {TURNS_SINCE(-> top) == 0: -> DONE }  -> ret

Of course, if you don’t think you need to thread a tunnel, you probably don’t. It can be useful because tunnels are portable - when they finish, they don’t need to know where to go back to, they just return - and threads allow the player to choose content from lots of different places in the source.

We use threaded tunnels for our conversations: each one is a little packet of interaction, but there are hundreds of them, separated, and with their own conditions. Writing as tunnels means we can write them without caring about where they came from, and also inject them into the story if we want to; and using threads means they can be written independently from each other. 

Everything in archaeology is a jigsaw puzzle. From piecing together shattered pots, to piecing together the complex trade routes of Phoenician merchants, everything we know about the ancient world has been assembled from a hundred little details, turned and shifted and laid carefully into place. 

This is one of the core ideas behind Heaven’s Vault, and in particular behind its artefact system - the gameplay layer which drives the narrative layer, and sees the player collecting artefacts (“clues”) and tracing their origins to uncover new sites to explore.

But because Heaven’s Vault is also a massively branching game, we can’t even be sure what the player knows, or doesn’t know, at any point in the story. We can’t know in advance what they’ve discovered, and where they are languishing. We don’t want people to get stuck because they failed to open a particular door or look inside an anonymous box. 

So while we do have hand-authored game clues, many more are generated procedurally, as and when they’re required. Based on our model of how the Nebula worked, and how people moved from one place to another, we can simulate what artefacts might have been taken where, and fill out the world with things for the player to find which make narrative sense and also help push the player forward.

But what we’ve not done - before today - is close that loop: by feeding those procedurally generated artefacts directly back into the narrative. They’ve always just been outputs: attractively described objects, collected by the player and added into their gathering inventory. 

Playing yesterday, however, we realised those objects were enticing in their own right. An ancient brass compass; a charred map of the inner Spiral; a blunted knife from an abandoned mine; these are objects created by the game at run-time, but they sound like they should have stories attached. 

So here’s our “cupcake” approach. First we make the “sponge” - we take the location where the artefact is found and work out what kind of object might be found there, and where that object might have originated. We then generate an object of that type. The result is usually nice, but quite often, fairly generic.

But in case it isn’t, we pass the result back into the ink, to a function which looks for specific attributes and tries to kick off hand-authored content - “icing”. So if the system generates a burned star map, El can ponder why it might have been burned. If it produces an ancient book, Six can discover a dedication inked into the inner flap. If it finds a compass dating from the earliest days of the Nebula, they might notice it does not point to Iox as it should…

We can query as much or as little information about the automatic artefact as we want. There might be a response that only fires for coins dating from the the Holy Empire; or there might be a response appropriate to anything made of gold. Only tools from the mine where a bloody revolution occurred will blood-stained.

But because we robustly model the knowledge of the player at all times in the game, tracking every fact they’ve learned, we can push this even further, and have the player discover significant story information - contained in specific content attached to entirely procedurally-generated artefacts.

So how do we choose what content to write? Easy. We play the game - or rather, we run our automated player through the content - and then we pick out interesting-looking items from the log. A bone statuette? Let’s see what it’s a statue of. An ancient, chipped knife? Perhaps it’s nocked from a clash with a sword. A rolled-up scroll? Perhaps there’s something useful inscribed in the margin, that leads you to a corner of the Nebula you’ve not visited before…

Some of the content we’ve written will not be seen by you. Some, maybe, will never be seen by anyone. But everything that is seen will further uncover the past of the Nebula - even if it’s, at least partly, being made up as you go along.

By Joseph Humfrey

For a while at inkle, we’ve been keen about the idea of making an interactive comic - from our very first projects, we wondered whether our approach and philosophy could be made more graphical.

It hasn’t been until Heaven’s Vault when we’ve started to put some of our ideas into practice. The game was initially conceived as a pure series of static frames - we would use the 3d background art purely to allow the scene to be viewed from any angle, but the camera would never actually move or rotate.

We’ve shifted pretty far from that vision - we don’t really consider the game to be an interactive comic, and we now have a fully dynamic camera that can spin around the protagonist when you’re exploring environments. However, much of the original concept remains in the game, and we do have sections with fixed camera angles that play out a bit like a dynamic comic book.

Comic book artists are used to designing the composition of each panel to allow enough space for the dialogue bubbles - it’s a core part of the craft. On Heaven’s Vault though, we are having to find ways of doing this automatically, as the interactive narrative takes unexpected twists and turns.

Enter the Bubbleographer, a component of the game that’s responsible for finding the best arrangement for the given set of visible dialogue bubbles. It’s happiest when it has a lot of space to play with, and when it doesn’t, it does the best it can.

The poor Bubbleographer has a lot more to contend with than the average comic book artist though. The camera can move around to look at different things on the whim of the player, so the composition of the screen can change very quickly, potentially leaving the dialogue bubbles in awkward positions. The player also has to be given the chance to read the text of the bubbles of course, so it tries to move them as little as possible, or it would be distracting.

And how does the Bubbleographer decide on the best place on screen for a particular bubble? It divides the screen into a grid and calculates a score for every position on that grid based on a number of things - would the bubble overlap anything it shouldn’t? Is it near the character that owns it? Is this bubble positioned nicely right below the previous one? Is it leaving enough space for the next bubbles? Finally, if it really can’t find a good enough position, it will tell the game to allow the existing bubbles to finish before allowing the new one to transition in.

The image at the top of this post is a picture of what’s going on in the Bubbleographer’s head - the debug view. It’s managed to position El’s bubble right above her head, but left space for the villager’s incoming bubble next to him. The numbers drawn underneath represent the constituent parts of how the positions have been scored.

This has been one of the hardest parts of code that we’ve had to write for Heaven’s Vault. As with many things in both code and design, if the Bubbleographer does its job perfectly, you shouldn’t notice it at all!

by Jon Ingold

We were asked on Twitter last week “will Heaven’s Vault include any romance?” We wanted to answer, yes, beautiful, glorious, subtle ones - like Vitti or Goland in 80 Days, like Flanker (if you went there) in Sorcery!…

… but the truth is, right now, we don’t know for sure.

In most games, “romance” is a codeword for “achievement”. How romantic! A platter of persons is served for your delectation and desire; and so long as you lob enough attention their way, you’ll get the sloppy ending you were promised.

Our romances aren’t like that. They tend to emerge more cautiously, a part of the writing process. A remark here, a charming aside there, a meaningful glance, that grows into something more…

(Goland was only “romanceable” because I fell in love with one of Meg’s incidental characters while editing, so much so that I wrote in the extra path. Vitti was Meg’s revenge, balancing out the genders. And Flanker was never intended to be a lover at all, but enough players speculated that we gave it a spin. The “true” run-through of Sorcery! is now, of course, the one that sees you dancing with Flanker right before your love overcomes the mind-altering powers of the Crown of Kings, but don’t tell anyone who read the books that.)

With its 3D art and hand-drawn characters, Heaven’s Vault can’t afford to be quite so fast and loose with its affections - but with the ink script underneath, a cinematographer system above, and no voice acting, we still have the crucial ability to go off on interesting tangents at the last minute.

So waiting in the wings are several potential romances. The unfortunate librarian, the untrustworthy bartender, the mechanicist, the thief. All are tentative right now, waiting to be invited to step a little closer. Some may never be called up. Some may be beautiful. Some merely advantageous. Some may prove to be quite unwise.

One thing that fascinates me as an interactive writer is the way that, although the protagonist might be naive, the player never is. The player has a freedom to be fickle that is never afforded to those who meet-cute on Hollywood screens. 

At any moment, you might spin that bad romance to your benefit - you might run Flanker through and take the Crown for yourself. You might be cruel and play your admirer for a fool. Or less cynically, you might commit to following your heart across the Steppes at the cost of Fogg’s paltry bet. 

Unlike two characters trapped in a rom-com, whatever you choose, you choose. Something is gained and something is lost - so perhaps you really meant what you said.

There’s so much to explore here. Hopefully El won’t be too busy digging up broken pots to notice.

by Jon Ingold

When we began designing and prototyping Heaven’s Vault, one of our primary goals was to make an adventure game-like; something which took the best parts of adventure games - the dialogue, the settings, the plots, the sense of progression - but discarded the bits that fought against those good bits - in particular, the farming of every possible action in every possible location, the backtracking, the rule that nothing changes until you push things forward.

This isn’t an easy goal! The normal adventure game template is an easter-egg hunt: the designer hides gold coins, and the player turns over every stone until they’e found them all again, and when they have, the game is done.

We wanted a game where players would find some, but not others. A game where looking under every stone simply wasn’t allowed. We’ve done this before, in Sorcery! and 80 Days and the usual trick is to give every scene some kind of external pressure - a collapsing ceiling or a soon-to-be-returning gentleman - which gives you enough time to do something, but not everything.

But in moving to a graphical environment, these things become much more complex to do - and a lot more obvious. When every building you explore has to have a collapsing animation, they start to become repetitive. (Ahem Uncharted ahem).

So we came up with the idea of an internal pressure, and one idea that stuck was that El could be diabetic. The balancing of glucose-levels and insulin would force El’s energy and exertion to be to be conserved and considered. If there were two mountains to climb, perhaps the player could only pick one.

It’s also something we’d never seen in a game before - the closest analogy we could think of was Jayden’s drug addiction in Heavy Rain, which was initially presented as a player-driven system, but quickly disappeared. So why not? Diabetes is common. It’s not scary. It’s extremely systematic, especially if you have the right gadgets for measuring your blood sugar.

From a narrative point of view, we liked it too - it’s much more interesting if our archaeologist isn’t a Croftian ass-kicking ninja-trained marksman (who can survive the rigours of archaeology with four broken limbs), but rather someone who is actively ill-suited to physical hardship, long hours and limited supplies (but who, nevertheless, is driven to her task).

So why isn’t El diabetic?

Because games are not great at telling stories through systems.

Wait! Isn’t that thing everyone says games are great at?

Games are good at demonstrating systems, and teaching them. Sure; if we’d made El diabetic, we could definitely have taught players how to manage their glucose levels. Depending on the balance of accuracy and abstraction, we might have given players real-life skills.

But systems that are learned become invisible, or tiresome. You either master them or they get boring. But stories aren’t built on routine and grind. They thrive on surprise and delight. And unlike in a film or a novel, where a character’s insulin injections can be assumed by viewer until the moment they become important, games have a hard time not to acting out every footstep the player takes.

So if El had been diabetic, the narrative effect would likely have been a minor annoyance, or a game-stopping irritation, with nothing in between.

Which is not to say it’s not possible to have a diabetic protagonist. There are definitely ways to solve the problem. You could push it all into the story; have El medicate herself and simply assert to the player that their choices are limited. Or you could craft a really well-balanced UI system that makes tracking and balancing insulin and glucose totally smooth.

But for our game - which has so much lifting to do to explain what and where and who and why - it felt like more than we could tackle.

The echo of the idea still lives on. There is a “stamina” concept of sorts, and a simple cost applied to some actions which are “tiring”.You still can’t farm all the actions in the game. El can’t run up and down mountains indefinitely. 

The result is functional, provides simple, obvious narrative impact, and it doesn’t do an existing condition wrong.

Something we’re trying to let the player do when translating the ancient script symbols in Heaven’s Vault is to Get It Wrong.

We started out thinking of the translations as puzzles, but puzzles have Right Answers, and before you find the Right Answer you don’t have any Wrong Answers. A puzzle is either unfinished or its right.

But the translations aren’t toys either; toys have no Right Answers; you can do what you want with a toy, and keep trying out new ideas. Our translations all, ultimately, mean something . They were put there by someone, they were written for a reason. They can be read - or they could have been.

So our translations are something in between - something you can get right, but that you can also get wrong. And you get them very wrong, you can get them wildly inaccurately wrong. That’s part of the storytelling, after all - reading an inscription that says beware of the dragon as enter wearing a princess costume is a good set up for an action sequence. (Editor’s note: this sequence does not  appear in our game.)

But the design part is hard. People don’t like Getting Things Wrong. They like to feel they’re getting things right. Surely puzzles - or things-like-puzzles - can’t let you get things wrong and just keep going?

Spoilers: this is not the word for port.

Well, here’s what we realised about that: Sudoku doesn’t like you getting things wrong. Get something wrong and your whole puzzle goes in the bin. But crosswords are all about getting things wrong. You see “Vegetable (6)” and write in CARROT, but a bit later you figure out the word going down that put a T where the C should be and you change it to TURNIP. You got it wrong, but it didn’t feel too bad, because you only found out you got it wrong at the moment you got it right. (Well, assuming the answer wasn’t TOMATO, that is.)

Heaven’s Vault is a bit different from our previous game, in that it uses ink - our narrative scripting language - to simulate what a “normal” adventure game would do, with rooms full of interactive props.

For any ink devs out there, here’s roughly how we’re doing it.

Each “room” is a knot. Inside the knot, we use threads for each of the props the player can interact with, so we can divide up the action into chunks of interactivity. In each thread, there’s a link back to the top of the location.

The great thing about this structure it’s very portable - if you have “background” objects that appear in multiple rooms, you simply thread them in and pass a parameter for where to return to. 

And if you have things that can happen in the room - say, a bit of dialogue for when you stand in a certain place - you can put that in the main “hub” of the location and it’ll always be tested for.

Heaven’s Vault gets a bit more complicated than this - because we also handle conversation, which can happen anywhere, at any time, from a separate contextual system. But that’s for another post maybe.