Heaven's Vault updates

Heaven's Vault is an archaeological science fiction adventure from inkle, developers of 80 Days and Sorcery! Follow this blog for updates on how the game's development is progressing.

[heavens-vault-game]

Building rivers (again!)

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.

This is a pretty common approach for racing game track editors, but our game has some things that make it special. Like a roller coaster, our tracks can be rotated to any angle (although ours aren’t trying to make you throw up)

...or twisted around.

The other thing we have that racing games don’t is velocity. Our rivers have a direction and speed. Some rivers are slow and graceful; others fast and dangerous. In most cases speed is directly linked to the width of the river, so to save time we only need to set one variable, cutting our workload in half!

The color gives us an indication of the speed

Points can be created and deleted with keyboard shortcuts, automatically setting new points at a position that creates some fun gameplay so we have something fun right away.

They can also be subdivided, which is handy when we set the start and end points of the river, and then fill in the straight line with some nice curves.

Lastly, our rivers snap together! We can use this to create branches, or simply to bind two rivers together. We point that connects always inherits the properties of the river point it’s attached to.

We then automatically generate our pathfinder network from the connected rivers, which is how “satnav” works.

There’s some other neat thing we do to save time, but I’ll save those for next time, when I’ll post some screenshots of finished levels so you can see what we’ve been able to build!

[heavens-vault-game]

CUT!

As the year winds down, it’s a good moment to look back on the distance travelled, and try not to stare ahead at the list of things still to be done before the game is ready...

Damn, too late. 

It’s no secret that Heaven’s Vault is our most complex game to date. Real-time, non-linear, always-reacting storytelling in a fully explorable 3D world isn’t something you just stumble on. It’s also our most beautiful game yet; and a huge part of that are the environments. We’ve shared a little peek of the forest moon of Maersi already...

... but there are desert digs, overgrown palaces, ancient covered markets, towns, cities... there’s a lot of stuff. And somehow we have to build it all before we can release the game.

Luckily, we recently wrote the ending. We now know exactly how and where the game will stop. That means we know which bits of the middle really matter, and which just seemed like interesting ideas at the time. We know which bits are foreshadowing, and which bits are fluff. So now’s the time to cut. 

Cutting is hard, right up until you do it. Everything, especially in a game this tightly bound, seems like it absolutely needs to be there - until you take it away, and realise it only had the appearance of real content. 

Cutting is also expensive: we’ve thrown away weeks worth of work, in greyboxing, writing, scripting, camera design, play-testing... The hope is all of that work has been distilled down somehow and that’s what left is richer and juicier than it would otherwise have been, but it’s impossible to know for sure. 

But not cutting is even more expensive. Greybox levels take weeks to finalise - to fill with props and colour, to light, and of course there’s additional writing, scripting, and all the other things that take a decent level and make it great. As a rule we try not to cut anything that’s past the greybox stage - there’s always freedom in what you cut and how. (We have in one instance cut a section of an existing level and used it to make a new level.)

So far in the last two weeks we’ve cut two entire levels, mixing what content we can around the other sites. Those places have got richer, and the need to pad out the weaker location has gone away.

With our previous games we never needed to cut like this - we cut lines and words, sure, but whole cities, whole towns - never. The key advice in creating 80 Days was “Just write everything”: if you can think of something, write it; we’ll need it somewhere. For instance, take a look at this screenshot of the 80 Days content prototype, from about halfway through development:

That’s about 60% of the final game.

For Heaven’s Vault that approach has gotten us this far - to a terrifying scope problem - but it’ll take us no further. But, it has given us a great opportunity. We’ve got a large stockpile of raw ideas, of moments and concepts. We’ve got a huge old pile of veg to turn into stock here: with the right cuts, we can make this game nothing-but-good. 

And every cut is real progress - it increases the percentage of the game that’s complete. A day when we cut a level is our most productive day. (Although when our AI overlords start applying this kind of logic, we’re all in big trouble.)

So cutting is hard, but vital; and we think we’ve made some brilliant cuts. You’re going to love the bits you don’t get to see. 

[heavens-vault-game]

Ink tip: stable shuffling for choice text

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.

[heavens-vault-game]

Rocking Out

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!

[heavens-vault-game]

Threading tunnels

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. 

[heavens-vault-game]

Procedural narrative cupcakes

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.

[heavens-vault-game]

Dynamic comic-book composition

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!

[heavens-vault-game]

Love and Romance

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.

[heavens-vault-game]

Why isn’t El diabetic?

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.

[heavens-vault-game]

Getting things 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.)

[heavens-vault-game]

Using ink for rooms and objects

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. 

[heavens-vault-game]

Money!

One question we’ve been wrestling with since the beginning of the project is “what do we do for currency?" 

The easy answer is call it CREDITS and move on, but somehow that’s never felt right - after all, what does Aliya do to earn them anyway? Does the player get paid per excavation - that’s realistic but rather dry. She’s an academic, sure, but we don’t want to force the player to write out grant applications before they go exploring.

Most real-life archaeologists - by which we mean, from the exciting days of the 20s - had wealthy patrons, and those people paid for excavations in return for a pick of the loot. Which raised the question - can Aliya pilfer from dig sites herself? Should that be beyond the pale, or up to the player?

Obviously it should… but stealing ancient jewellery just to convert it to CREDITS is somehow even more prosaic - the thrill of a heist is the cold hard diamonds, not the bank balance after you’ve fenced them and moved on.

All of which means we’re considering not having any currency at all. We’re not fully decided on this, but the alternative is really interesting - an economy built on barter. Every transaction in the game is a swap-shop, and with different characters wanting different things.

A player selling an ancient Pharoah’s ring for the 2,500 CREDITS they need to buy a new sail for their ship is fine - but we think having them choose to swap the ring for a new sail is better. 

Especially since it limits your options: maybe you can find another ring somewhere - maybe you can swap something less important for a different ring - but you can’t ever grind the world for junk and amass enough CREDITS to simply pay your way. 

[heavens-vault-game]

Unity - Saving changes made in Play Mode!

Wait...that’s it?

If you’re a Unity dev, you’ve almost certainly made big, important changes to your scene before realizing that you’re in play mode and it’ll all be forgotten when you exit.

There are a few solutions out there, but they’re all geared towards saving data rather than GameObjects, which isn’t much use if you’re primarily looking to build out your scene.

Sound familiar? Well, good news! We’ve cooked up a solution called Save Play Mode Changes which you can grab here.

It works by mimicking the common trick of copy-pasting GameObjects/component data, except it’s totally automatic. All you need to do is attach a component to the root GameObject of the hierarchies you’d like saved, and it’ll retain all your changes to them! 

As you might imagine, this means you can easily end up with more being saved than you’d bargained for - instantiated objects and runtime component data - and unfortunately we don’t have a means of adding exceptions to what’s saved.

Still, we’ve been using Save Play Mode Changes for a few months now, and it’s saved us a lot of time! If you want to give it a go or help make it better, grab it now!

...

Ok, we’re definitely below the fold now. Want to know more, you sexy, sexy nerds? 

Ok, so how it works is: just before exiting play mode, we get all the GameObjects with our SavePlayModeChanges component, and we serialize the entire hierarchy (including components and fields) into a custom format using the dark arts of Reflection. We then use Unity’s recently added JSON serialization system to boiled that down to a nicely formatted string, which we store in EditorPrefs. When we’ve finished exiting play mode we can pull that string out, decompile it, and then reconstruct the GameObjects/etc! It’s just about as destructive as it sounds, but heck - a hack is a hack.

What’s super cool about this is that you can use the same code to serialize scene data for any other purpose - something we’ve not yet had a reason to do, but oh boy is this ripe for some serious hackery!

- Tom

[heavens-vault-game]

Inline ScriptableObject editing in Unity!

Do you make games in Unity? We’ve developed a new trick for editing ScriptableObjects, and it’s wayyy too good to keep to ourselves.

It lets you view and edit the fields of a ScriptableObject reference inline. Super handy for settings files that automatically get saved between play and edit mode, and those that contain visual information, like button state styles.

In the example below, we have settings for our simple close-up camera, which is positioned relative to a particular character’s face. We can tweak the settings while playing, and they get saved automatically outside of the scene.

Additionally, when you need to create a new ScriptableObject Asset, we provide a handy Create button.

We’ve posted the source up over here:

https://gist.github.com/tomkail/ba4136e6aa990f4dc94e0d39ec6a058c

[heavens-vault-game]

Prototypes

Heaven's Vault is about three years old now, though it hasn't been Heaven's Vault  for most of that time. For the first year it was something else completely (we might talk a bit about that in the future); and for the two years after that it was a strange collection of prototypes without a name.

We've prototyped everything . We never used to - on previous game, we just got on and built them, fixing things that didn't work as we went. (Well, we prototyped specific mechanics, like Sorcery!'s combat and dice games. But we didn't prototype, say, how you move around the map.)

So why the change? Maybe it's because Heaven's Vault is big and complicated. Maybe it's because we fancied a project that didn't veer from self-inflicted disaster to self-inflicted disaster. (80 Days was really not at all fun about a month before we released it.) Maybe it's because after lots of releases we wanted to just write some throwaway code for once.

So, for instance, the prototype pictured above is “the whole game”. It's got no art at all. That big orange box? That's the Nebula. That box top right? That's the script of the story. The way it ends mid-sentence? That's, ahem, the story bug that's next to fix...

It’s written in Javascript, which is great for throwing code around (and throwing it away); but its using the current ink script, thanks to ink-js , the port of the ink engine to Javascript created by @y_lohse. 

But a prototype isn’t just useful at the start of a project - we’re still maintaining it, but now as a testing tool. The original prototype let you click through the story; but we’ve now added the ability to auto-play at random, so we can find places where the narrative runs out or gets stuck in a loop. 

A random player doesn’t really tell you much about the experience of a real player - randomisers make terrible decisions and choose the choices no human ever would. They walk way from intriguing story-points and hurl insults at their friends. But they do show you the worst story your game affords, so you can bring that baseline up as high as possible.

Not all our prototypes are Javascript, however - the prototypes for movement, cameras, flying, characters have been all been done in Unity, and are gradually being folded into the main project. More on some of those later!

[heavens-vault-game]

Aliya “El” Elasra’s character design

Heaven’s Vault began as a project when we stumbled on the work of Dr Monica Hanna, an Egyptian archaeologist who has been leading attempts to protect the antiquities of her home country from increased looting since the 2011 uprising. 

Details of her life make for gripping reading - for instance, after sneaking into the mummification lab at the Egyptian national museum aged 14, a year later she was helping to repair the toes of Thutmose II. She’s been held at gunpoint by tomb-robbers, and named a Person of the Year by Egypt Today magazine. 

Heaven’s Vault is not her story, of course - but the idea of academics as defenders of national identity during times of political turmoil, and of antiquities as both economic and political currency, took root. So when we began working with the experienced concept artist Jeremy de la Garza to design the look of our protagonist, Aliya Elasra, we knew we didn’t want her to be a pulp-fiction Lara Croft type - but something closer to real life.

So our El is an academic, albeit a charismatic one with a stubborn edge. She wears sensible clothing and has a human’s body shape rather than an elf’s. As we iterated, we tried to push the design to be simpler, more grounded, eschewing overtly stylised clothing, and removing big straps or widgets or gadgets or what-have-you.

Now we’re in full production, our talented in-house illustrator Anastasia Wyatt is producing the full set of El and Six’s illustration frames, and designing the rest of the cast in Heaven’s Vault to fill in the universe in which Aliya lives.

And with that, we’ll leave you with a selection of the concepts that went into Jeremy’s design process for El - we hope you enjoy them as much as we enjoying the process that produced them!

[heavens-vault-game]

Unity asynchronous sprite loading - with code

Tom Kail

After talking about how we’ve implemented a system for loading sprites during scenes to reduce scene file sizes (and loading times!) we’ve had a few requests for the juicy details. For the other developers out there, here’s some more details and some example code. The backbone of the process uses Unity’s Resources library. There’s two functions that interest us here, Resources.Load and Resources.LoadAsync. There’s also Resources.UnloadAsset for unloading assets. 

Anything you need to load is passed in via a string path reference (relative to a “Resources” folder). Note that the reason you can’t load an asset by passing it directly is that if you’re using the asset, it’s probably already loaded!

We’re only loading sprites, but you can load any UnityEngine.Object types using these methods.

We’ve uploaded an example script here.