In our first two weeks back on the game side of the project, we’ve made some good progress. First among those is getting to some of the improvements and suggestions that have been on the back burner since the Early Explorer release and our time showing the game at IndieCade, IGF, and SxSW.
We’ve planned out some changes to the introductory levels, to better control pacing and give the player more control over how and when KRIS learns certain vital pieces of information about himself.
We’ve implemented a number of small technical changes that the later levels need: for instance, now activating a socket can reveal hidden sockets that depend on the parent socket to make sense. (This feature has long been planned for the 5th and 6th levels.)
We completed the design and layout of the complex 6th level (“the maze”), leaving only the final level of the game to be implemented: this is one of our priorities in the coming week. The content for these levels still needs to be written also, which will also be ongoing over the next few weeks.
We’re in the midst finishing up the written content for the 3rd (Aaron) and 4th (Jacob) levels, which was started way back before the Kickstarter but is now being dusted off and completed.
We’ve updated the music engine to the latest idea of how it’s going to work, and added all the hooks for UI sounds. Our composer is working over the next week to fully build out the sounds for one level.
We’ve also invited our Kickstarter backers at the “Author” and “Legendary Author” levels to help us with some special pieces of content. (If you were a backer at these levels and haven’t received these instructions, please let us know at [email protected].) We’re looking forward to seeing what people come up with!
Compendium Update: the printers have been analyzing all eighty pages of the book with a fine-tooth comb, and have sent a few back with questions or concerns. (For instance, we have some images that are deliberately low-res or pixelated for artistic effect; when they quite rightly brought these to our attention, we had to assure them this was in fact deliberate!)
We’re about ready to move on to the next phase, which will be getting a few physical proofs.
Another chance to see us gab: We’ll be talking Ice-Bound and interactive story this weekend at Indie Revolution Expo, a free online indie game convention happening now and continuing through the weekend. Check out our panel “The Future of Truly Interactive Story,” streaming tomorrow (Saturday July 18th) at 12 noon EST.
[In case you haven’t been following the Kickstarter updates, you can see the last few posts here, here, and here. We’ll try to cross-post all future updates both here and to Kickstarter.]
Greetings, backers!
We’re happy to report, at long last, that the final Ice-Bound Compendium files have been delivered to our printer!
Here’s a look at the final cover and back cover:
After extensive testing to make sure each page could be recognized by our AR engine (and several iterations of redesign and retesting for some of the more difficult pages), as well as the usual rounds of copy-editing, and our project-specific demands of cross-referencing with our game (whew), the full 80-page book is finally ready to become a reality. Our book printer, Regent Publishing Services, now has the files and is starting to move them into their production pipeline.
The whole process (from proofs through test runs through the printing and final delivery) will take several months. While that’s happening, we’re eagerly turning our attention back to the other half of the project: the game.
Despite being radio silent for a while (we really wanted to get the book out the door before sending an update!) progress has been ongoing on a number of fronts.
The Game’s Title
In part because of another game called Icebound that’s coming to Steam, and also to more clearly distinguish the book from the game, we’re happy to announce here for the first time that the game’s official title will be The Ice-Bound Concordance. Along with The Ice-Bound Compendium (the book) the two halves together will make up the the full Ice-Bound experience.
Music
Now that the book’s finalized, we’ve been meeting again with our wonderful game composer,NJ Apostol. An ongoing challenge as NJ’s been developing material is figuring out where the musical core of our multi-layered story lies. Is it with KRIS, the AI you’re conversing with? Is it in the stories you’re reshaping? How should the player’s nonlinear changes to the state of both of these layers affect the music? We have a new strategy we’ll be trying out in the next couple of weeks that we feel good about. Keep your ears open, because we hope to be sharing some sample tracks in the next couple of weeks, too.
What’s Next?
We’re doing the last of the coding for the game this week and next– mostly some custom code for a few of the special levels you get to later in the story. We also need to build the final UI for the game’s climactic level, which exists in a functional but ugly form right now, and there’s a stack of (mostly UI-related) bug fixes we’ve been putting off addressing until the book was finished.
Writing the remaining content will be the next major task after the code-jockeying is finished up. The second half of the story will be moving from sketches to drafts to its final, polished form. Here’s some text written this week, the introduction to a character from one of the weirder, deeper levels:
***
Ice had consumed his ship, warped by pressure into funhouse distortions, or shattered to spar and timber. He’d put it back together over the years, but in new forms: forcing back the entombing ice with reclaimed nails and boards, building a womb of wood. It was a sort of patchwork home now, only much bigger, somehow, than his ship had ever been in life.
He was well aware he should be long dead.
***
We also have about half the AR overlay content still to create (the images you see when you show pages from the book to the game), and some revisions to the intro levels based on early feedback.
Beta testing will also be happening more formally at some point. For those who indicated they might be interested in participating in their Backerkit surveys, you’ll hear from us later this summer.
What does this mean for Ice-Bound? We’re hoping that as long as we release before December, the tech in the game will keep working– that is, Apple won’t remotely disable Metaio licenses or anything underhanded like that. We’ve been in touch with Metaio and they can’t yet 100% confirm their licenses will keep working after December, which is distressing to say the least. We’re obviously hoping the eventual answer will be yes. In case it isn’t, we’d have to find a different AR library and re-code a bunch of things from scratch, which would be a grim but not fatal blow to the project– it would definitely delay the game’s release even more, and require some creative solutions on our part.
We’ll keep you posted if we hear any news on this. For now, fingers crossed we’ll be able to keep using our existing Metaio license.
Logistics
If your address has changed since the Kickstarter, you can update it through BackerKit at any time (https://ice-bound.backerkit.com/). When we’re getting ready to ship (hopefully in early fall), we’ll post an update reminding people to double-check their address.
High-tier backers, you’ll be hearing from us shortly to talk about your creative rewards.
Thanks!
Thanks for sticking with us– and we’ll try to keep the news rolling at a quicker clip from here on out.
“I sometimes remember what never was, and my memories of the countryside where I really lived can’t begin to compare, in sharpness and nostalgia, to my memories that inhabit– floorboard by creaking floorboard– the vast rooms of yesteryear that I never inhabited. …I’ve become so entirely the fiction of myself that any natural feeling I may have is immediately transformed, as soon as it’s born, into an imaginary feeling.”
We’ve had a pretty incredible start to the year. Ice-Bound‘s been honored with nominations at two prestigious indie game events: the Independent Games Festival at GDC, with a nomination for “Excellence in Narrative” (and an Honorable Mention for the Nuovo Award, to boot), as well as the South by Southwest “Gamer’s Voice” award. In both cases, we share a nomination with some pretty incredible games. We’re amazed at the love, and looking forward to attending both events!
Work continues on two major fronts right now: putting the finishing touches on the Early Explorer for PC version of the game, and finalizing the pages of the Ice-Bound Compendium before we deliver them to our printer. A few days ago we printed out all the pages at 1/2 size, spread them over a table, and discussed the arrangement, the thematic tagging, and what should fill the last few pages to be designed. Assembling the Compendium is a more delicate operation than it might appear: since the book pages drive the game’s story, the two parts of Ice-Boundhave to stay roughly in sync. One of several positive results of our tabletop exercise was realizing there are a few thematic threads on the digital side that don’t yet have enough analog pages referencing them, which hampers players’ ability to bring those elements into their own versions of the story.
The only bad news is that we’ve had to push our schedule back by about six weeks. There are three major reasons for this:
* The PC port continues to take more time than we’d budgeted for. It’s one of those things where the last 10% is taking 90% of the time: something that works on one setup will crash the webcam on another machine, or not reliably pass information back and forth between the interactive narrative and AR parts of the app on another. There are also more extensive UI changes than we’d anticipated to handle the context change from “camera as window” on the iPad, to “camera as mirror” on the desktop. It’s been a long and sometimes frustrating process, and we’ve been “almost there” for a while now, but the experience is still not quite solid enough for us to sign off on. But we’re getting there! Early Explorers, please bear with us for another few weeks…
* The festival nominations (while amazing) necessitate a week of our time each, for travel and exhibition, assembling the requested press materials, preparing a demo build appropriate for a show floor, and so on. That’s two fewer weeks between now and release to actually work on the game itself.
* Rather than rushing the printed Compendium into production, we’ve decided to take our time to make sure every page is exactly how we want it first. Nothing like getting ready to pull the trigger on printing a couple thousand books to make you double-check everything…
So our revised plan is now for the game and books to come out in early June. We’ll keep you posted with our latest info once we get that more locked down. And in the next month or so, we’ll start contacting our Author Explorers to chat with you about the collaborative parts of your backer reward (which after six weeks of code slogging, we’re really looking forward to!)
Hope your 2015’s off to a great start. Stay warm and keep in touch!
We’ve covered most of Ice-Bound‘s narrative system so far in our three-part post, ranging from how we make flexible story fragments to the combinatorial system that drives the sculptural quality of the narrative. Here are links, in case you’re just now coming across this:
For the last part of this “under the hood” overview, we wanted to talk about how we troubleshoot the narrative possibility space.
The Setup
As a refresher, each level in Ice-Bound has several symbols which can be activated and de-activated by the player, triggering a cascade of events and/or endings. That’s what we mean when we say Ice-Bound is a combinatorial narrative. Ideally, when the maximum number of symbols is active we want to see 3-5 events and 2-3 endings. That’s our self-defined “good amount of content”. It’s not so much text that the string of events run the risk of degenerating into narrative incoherence or overwhelm the UI, and not so low that it can’t make a story (or afford the player the ability to choose between endings).
But how, when designing a level and writing for it, do we make sure that any possible combination of active symbols makes a “good amount of content”? It’s a tough problem, both logically and as a visualization. We can’t just run a complicated data viz and call it quits–if it takes too long to immediately grasp the situation, it will bog down the authoring process. We need something we can use as we’re authoring, which means it needs to show the state of the possibility space in a fast and intuitive manner. We ended up developing two linked visualization tools to address this problem. First up: visualizing the possible combinations in a built level.
For a Given Build of a Level…
Each time you visit a new level in Ice-Bound, the system builds a new story, based in part on the way you resolved prior stories. This means each level has a large number of possible “builds.” Each build, in turn, has a number of possible states as the player explores it, based on all possible combinations of active/inactive symbols. To visualize the possibility space for a single level build, we use a graph like this:
There’s a lot of information condensed into this, so let’s break it down:
Each vertical bar represents one combination of active symbols.
The top of a bar (the lighter bit) shows the number of endings activated by this combination. The bottom of the bar shows events.
If the combination for a bar fails one of the “good amount of content” rules, it’s yellow. If it fails both, it’s red.
All possible symbols, events, and endings for this particular build are shown below the graph
The %s next to events and endings tells us what percentage of this build’s combinations involve those texts.
If you hover over a symbol, event or ending, it lights up the bars involving that text, showing all possible configurations of symbols in which that element is present.
Conversely, if you hover on a bar (like in the picture) it lights up the texts active for that particular symbol combination.
If you click on a text, the graph re-sorts so that all bars involving that text move to the left, allowing you to see if that text in general needs to be associated with more combinations, or if that symbol doesn’t have enough triggered events and endings for it.
That’s a lot, right? What it boils down to, though, is that by just clicking around a bit, we can quickly answer questions like “do most combinations have enough content?” or “if I’m adding content, where’s the best place to add new content?” or “is that thing I just added getting used enough?”.
But there’s more…
There’s a problem, though. Because you can build an Ice-Bound level many different ways, we author more symbols for a level than there are “sockets” to put them in. That’s how we ensure levels can adapt based on what stories the player has built in the past. But this adds to the number of possible per-level builds.
It gets worse, too. For maximum flexibility, we also have a large pool of what we call “global symbols”, which can go in any level. They’re really tricky to write, but are at the center of what makes Ice-Bound deeply responsive to player input, so they’re also super-important. But because of them, there are even more possible per-level builds.
How many are there? Depends. Currently, one level with eight sockets and a three-symbol activation limit has ~5,000. Another level with nine sockets and a four-symbol limit, though, has ~50,000 possible builds. You could hit refresh and re-load that bar graph, but the graphs differ widely depending on the symbols involved, and pressing a button 50,000 times is considered in general a bad workflow.
Browsing Problematic Builds
To tackle this problem, we came up with a second visualization tool. We started with the idea that of all possible builds, the ones we’re most concerned with are those with “red bars”, which have at least one combination of active symbols that doesn’t produce enough events and endings.
Since this generally happens because a certain symbol isn’t connected to enough events/endings, we categorize these problem builds by symbol, using a bubble graph:
A viz display for a well-authored, balanced level.
There’s a couple things going on here:
The black labels are the symbol names
The number / size of the bubble is how many “problem builds” the symbol is involved in
The color reveals what percentage of all possible builds involving that symbol are problematic…traffic light style. Green = good, red = bad. If a symbol doesn’t trigger enough events and endings, it will be redder, indicating it needs to be a trigger for more content (or more content should be written that involves it).
That’s pretty good, but what if I want to get more specific? 73 combinations involving “Romantic” doesn’t tell me much. Fortunately, this viz is also interactive. Clicking on any bubble rearranges the graph to show only the distribution if the symbol you clicked stays active. So drilling down looks something like this:
This helps you explore a pretty complicated space of possibility by using two criteria: shoot for big bubbles, and shoot for red bubbles.
You might need a bit more info though. So there’s also a panel:
This tells us that:
A: we’re looking at all combinations involving these three symbols
B: there are 13 total combos with these symbols, 3 of which need content. So if you’re adding content with these three symbols as triggers, it’s 23% effective (because you’re also adding content to things that have enough content, which we’d like to avoid if possible)
C: here let’s make that a pie chart so you don’t have to read numbers all the time
D: let’s keep it in perspective too, so how much of the total combos needing content are we hitting if we author stuff for these?
So for the picture I gave, you could look pretty quickly and think “huh…looks like I should maybe de-select one of these symbols and see if I can find a combination with a higher ratio, so the content I author is more effective”.
That’s…complicated.
Yes. But the feedback is fast and rather immediate. Crucially, these two visualizations are linked together, so clicking on a specific build in the second viz loads the first viz with that build, so you can move from a generic “problem build” to teasing out the exact cause of the problem. Essentially this lets us have a troubleshooting workflow like this:
Hey “Lonely” is a big bubble. Is it a little more yellow than the others? *Click*
Huh, yeah. Oh look…”dogId” is bigger than these others! *Click*
Cool. Let’s try “shaft” *Click*
Nooope. All the circles are tiny now. *Click to de-select*
Eh…that’s pretty good I guess. Ratio’s pretty high. Let’s look at a sample level build with that combo *Click*
[bar graph viz loads] Yeah, I should totally write two events with “Lonely” and “dogId”…maybe with a “not iceAx” so I don’t hit these others, since they look pretty good
So that catches everything?
Not everything…but short of more complicated, involved visualizations, it does the job pretty good! Tools like this help us navigate the “combinatorial wilderness”, and make sure we have enough content to cover all our bases, without requiring that we write a thousand novels of text.
Thanks for reading! If you want to read a more technical write-up, you can check out our paper on the viz tools from the 2014 Foundations of Digital Games. We also want to give a shout-out to Melanie Dickinson, who worked with us in summer ’13 and was instrumental in getting the viz tools off the ground!
In part one and part two of this series on the combinatorial narrative system behind Ice-Bound, we gave an overview of how stories are constructed from narrative fragments, and how the player uses the printed book to communicate to the AI KRIS which themes are most important. In this installment, we’re going to dive into the actual story text itself: how we make hand-authored prose that’s still responsive to a changing narrative context.
While most of the reader’s interaction takes place in the map view, by rotating the iPad (or clicking the appropriate icon in the PC version), you’re taken to the page view, a mode where each story fragment you’ve assembled turns into a paragraph of text: “excerpts” from Kris Holmquist’s novel in its current configuration. While this text looks static, it actually can vary in both obvious and subtle ways, based on the player’s interaction with it, and how the pieces are reconfigured in the other view.
Most of these fragments are not written for a specific story, but for a global pool of content available when the system builds a “level” of Carina Station. This means the system must be able to “cast” a fragment with a particular story’s characters, and use appropriate names and pronouns throughout. The system uses the casting call to reject fragments inappropriate for a certain story: for instance, discarding a fragment requiring three characters in a story that has only two. We can also request a character who appeared in an earlier fragment or type of fragment. For example, a scene might require a character who was previously in a fragment where something tagged as “unsettling” happened.
Once the cast has been determined, we need to make sure names and pronouns appear correctly throughout the text. You don’t quite realize how often we use pronouns in English, and how many subtle variants there are, until you need to hand annotate each one! Not only is this prone to mistakes (do you mean his/her as in “her book,” or him/her as in “give it to her”?) but an awkward syntax makes it nearly impossible to write creatively: constantly having to interrupt the prose to call a function or insert curly braces can be a real cognitive drain that makes it hard to stay in a creative zone. We devised an authoring syntax that tries to minimize mental overhead. For instance, when you reference a character you tag which alphabetical “cast position” it’s referring to, but subsequent pronouns will assume you’re still talking about the same character unless you say otherwise, simplifying the syntax:
_name/a/ tried and tried to get to sleep. _They rolled over and clasped _their pillow over _their ears, hummed lullabies to _them~self.
(Why “they” and not “he” or “she”? It’s because third person plural is the one of the few pronoun forms in English that has a distinct word for each possible pronoun. We also have tags like _himher, but found the “they” form more natural once we got used to it.)
But slotting characters interchangeably into stories doesn’t do much to make those stories feel personalized. We also have more complex replacements triggered via additional underscore-prefixed keywords. One example is “mix-ins,” a technique borrowed from Aaron’s work authoring stories for the game Prom Week. By giving each character a word or phrase that they’d use in a particular context, such as saying hello or in a moment of shock, you can personalize dialog written for any character. So for instance:
…might produce “Thanks, comrade” from one character, or “Thank you, my dear” from another. While this technique seems simple, it’s a remarkably effective injection of a particular character’s sensibilities into a narrative moment, and makes the rest of the scene seem written just for them.
These replacements can get rather complex. The underlying system is actually a full contextual expansion grammar, meaning a replacement can expand to a more complex form containing additional replacements, ad infinitum, and that each replacement can execute code referencing the full state of the system to decide what text to produce. (Aaron actually used Ice-Bound’s system to write a procedurally generated novel in a couple of hours for NaNoGenMo last year.) Some of the other tricks this system enables include using different text based on how many other characters are present, using specific language for specific time periods (such as changing an “email” to a “letter” or a “telegram”), or even changing text based on the way the reader ended a previous story.
Example of the same story fragment appearing in two different contexts.
These techniques get even more powerful when combined with conditions that let us guarantee certain things about the story state before even selecting a narrative fragment. For instance, we can request that an event card only appear when the character we’ve cast in Slot A has an active “personal” socket, regardless of what it is. Since each personal socket corresponds to an item connected to that character, we can then write some story text where that item plays an important role:
_They/a/ held _item clenched tight in one hand, the can of kerosene in the other. “What are you doing?” _name/b/ asked.
This strikes a nice balance for our purposes between hinting at a dramatically consistent story, without actually doing all the incredibly difficult work of generating narrative from whole cloth. Why would Katrin burn her prized college diploma? Was it Bjorn’s trip below that led him to give up his drug addiction? Humans are remarkable meaning-making machines, and Ice-Bound’s fragments provide just enough leverage to imagine connective tissue between our isolated fragments, without us actually having to generate it.
Another example of this weakly-connected cause and effect is conditions that can require fragments to appear in conjunction with others sharing the same tag and cast members. For instance, readers who enjoy horror stories and start showing KRIS creepy Compendium pages might start seeing horrific symbols in their story maps. One set of these introduce some sort of monstrous force loose in the station: these are given the “monster” tag. We can then have ending fragments that require a “monster” tag to be already present: so, feeling in an actiony sort of mood, we might write a dramatic conclusion (perhaps involving a flamethrower) that could be the end to any of the various “monster” intros. This is some of what we mean when we say the system feels like playing with Legos: “monster” events become a block type that can attach to “monster” endings to produce something with narrative coherence. (We also do this in less melodramatic ways, too: creating emotional setups and payoffs involving a character dealing with loss, a romance, or a journey of self-discovery.)
One of the most visually pleasing aspects of the system is what we call “shimmer text,” that wriggles into other forms even as you’re reading it. We author this quite simply by including a run of alternatives set off by curly braces:
Katrin was {only seven|nine|eleven|just thirteen|already fifteen} when the accident happened.
As the text changes between options, the reader can tap one to “freeze” it in that configuration. We use this to create the feeling that KRIS is constantly exploring permutations of the story, even down to individual words, and also to give the reader a sense of editorial control: any writer can relate to the feeling of agonizing over the right word for the right moment. The speed and frequency of the changes can also be tuned with a special control tag for authorial effect: frantic constant shimmers suggest text KRIS is worried about, while slow, contemplative changes make him feel more musing. The choices themselves don’t mechanically affect the rest of the story, but can sometimes have a profound effect on your perception of an entire scene:
McKinley stared down at the bloody knife, {eyes filling with tears|feeling nothing at all|and his grin eventually turned into giddy laughter}.
Pulling all these tools together, we have a flexible system for authoring Ice-Bound stories that lets them adapt to the particular context the system decides to use them in, without becoming overwhelming for us as authors. Here’s an example of a complete story fragment, appropriate for a moment where one character has “gone below,” and when themes of despair and futility are not prevalent in the current story configuration:
"foolhardyRescue": {
conditions: "tag_goingBelow && !tag_manIsWicked && !theme_futility",
cast: "/tags_goingBelow/anyone/anyone/",
name: "_name/b/ sets out Below to search for _name/a/~.",
text: "_name/b/ was hefting the expedition pack onto _their parka-covered shoulders when _name/c/ found _them/b/~. \"What _mixin/swearmodifier/c/ are you doing?\" _they asked {frantically|calmly|angrily}. \"_name/a/~'s gone, _name/b/~. _They/a/~'s not coming back. Even if there wasn't _timeGate/anything strange about this place/1992/any weird shit going down/~, _they/a/~d be dead by now in this _mixin/swearAdjective/c/ cold.\" _name/b/~'s face was a mask as _they kept loading _their pack. \"For god's sakes, _mixin/friend/c/~, why?\"<br><br>_name/b/ pulled a strap tighter and finally looked at _them/c/~. \"Because,\" _they/b/ said simply, \"there's a chance _they/a/~'s still alive.\"",
themes: ["doingWhatsRight", "humanDignity", "trialByFire"]
}
While this isn’t exactly free writing in a notebook, it’s simpler than a lot of interactive narrative environments we’ve worked in in the past, and once we got the format down, we can more or less just write, staying in a creative zone but still ending up with content that can be flexibly used by our combinatorial narrative system.
We’ve got one more post in this series scheduled, talking about the visualization tools we built to help manage the space of possible narratives, so stay tuned. In the meantime, check out our Kickstarter page, or follow the official site, Facebook, or Twitter accounts to keep up with the project. More soon!
In development for over a year, both the book and game halves of our hybrid interactive narrative are nearing completion. But the printed book has always held some challenges. Our augmented reality works when the page has as little reflective glare as possible, which means using a particular paper stock, printing process, and page coating. Unfortunately, most print-on-demand services don’t offer what we need to address this and other design issues with the book.
If we meet our goal, we’ll be able to do a print run with a professional book printer, exactly to our specifications, and everybody wins: we get to make the perfect Ice-Bound Compendium, and you can take advantage of economies of scale and pick one up at a special pre-order price. Becoming a backer now is the cheapest way to get a Compendium and play Ice-Bound.
Check out the video or visit the Ice-Bound Kickstarter page for all the details. We have some really cool rewards, including early access, a customized Compendium unlocking secret content, and chances to collaborate with us on some of KRIS’s dreams and stories. Help us get Ice-Bound printed and be one of the first explorers of Carina Station!
The IndieCade festival starts a week from today, and we’re getting really excited!
Ice-Bound, exhibited last fall at the BookLab exhibit in San Francisco.
The line-up this year includes a fantastic mix of games of all styles, genres, and budgets: everything from Double Fine’s rule-bending RPG Hack n’ Slash, to the live-action/digital hybrid starship bridge crew simulator Artemis (yes, we have played this in our living room), to our friend John Mawhorter’s trio of games set in nature, Play the Environment. We’re incredibly honored to be part of the line-up this year, and can’t wait to see old friends and make new ones down in Culver City.
We’ll be demoing the first few chapters of Ice-Bound from our perch in Firestation One, showing off our combinatorial narrative system as well as giving visitors a chance to see the printed Compendium in person and try out the the augmented reality interaction for themselves. If you’ll be attending the festival and want to check us out, the Firestation will be open from 4-7pm on Friday October 10th, and from 10-6 on Saturday and Sunday. (Check the IndieCade site for tickets and the latest info.)
Players and puppeteers in a performance of “Coffee: A Misunderstanding”
This year we’re joining carpool forces with our friend Deirdra “Squinky” Kiai, whose interactive play “Coffee: A Misunderstanding” is also a finalist. We’ve therefore decided to call ourselves Team Iced Coffee, a name which will no doubt prove prophetic during our long, post-festival drive home.
Finally, we have some pretty big Ice-Bound news coming early next week! We can’t spill the beans just yet, but you can sign up to be notified about major updates on our website, or follow our blog, Facebook, or Twitter page to stay in the loop. More, very soon!
This is the second part in our series (continued in part three and part four) about the new interactive story system we designed for Ice-Bound. We talked in part one about how Ice-Bound stories are built up from templated fragments in three sequential categories: symbols, which can trigger events, which in turn can trigger endings. As you descend through the frozen levels of Carina Station, you encounter stories about its past occupants, each deeper and thus farther back in time. Each story is represented by a map, and these story maps are the subject of today’s blog post.
An early Ice-Bound story map with five sockets, three of which are active.
Visually, each story map shows the physical layout of one level of the station, the setting for one group of characters. But it’s also a map of possible stories that can be told about those characters. Each of the round “sockets” in the map is assigned to a symbol (the first of our three kinds of story fragments). A symbol can represent something about a particular character (Katrin might be paranoid, or Miquel wistful) but it can also signify dramatic possibilities for the story, such as the presence of a curious Russian doll (representing mystery) or laboratory equipment (representing discovery).
You explore these potential stories by choosing what parts of the map to illuminate: which sockets, and therefore which symbols, you want in your own version of the story. If Katrin is lonely and Bjorn is drunk, a different story might play out than if she is religious and he is driven. Our event fragments appear based on combinations of symbols, and ending fragments are triggered from combinations of symbols and events.
Riffing on the dramatic concept of Chekhov’s gun, which states that everything introduced into a story should serve a narrative purpose, we’ve taken to calling our model “Chekhov’s dollhouse.” Do you put the spotlight on the gun over the mantelpiece, and bring it (and the violence it implies) into your story? Or do you put the focus somewhere else? Unlike branching path models, where making a choice is usually irreversible and high-consequence (even if the consequence is only wondering what you missed), with our model you can freely rearrange the story as much or little as you like before committing to a single configuration, as easily as rearranging the furniture in a dollhouse.
While each level’s map always has the same shape and number of sockets, the symbols that fill them—the details of its potential story—are dynamically assembled when the level is first visited. How does this work? To answer, we need to first explain what happens when a story is resolved.
When you’ve got a certain story arranged the way you like, you signal to your AI collaborator KRIS that you think the story is finished. But KRIS is filled with self-doubt: is he as good as his human original? How would the real Kris Holmquist have ended this story? To convince him your version is right, you’ll need the printed Ice-Bound Compendium, a book filled with secrets, drafts, memories, and notes that KRIS’s creator, the enigmatic publisher Tethys House, has decided he shouldn’t be allowed to know.
Each potential ending to an Ice-Bound story—and each page of the printed book—is tagged with themes, representing recurring ideas in Holmquist’s work. These include duplicates and authenticity, the loss of innocence, the lure of Below (i.e. the mystery of Carina Station) and many others. As you view the book through the camera, pages whose themes overlap with your chosen ending will light up with hidden information, as KRIS’s subconscious reacts to them. By choosing one of these matching pages, you’re giving KRIS some outside evidence that the ending you’ve chosen is correct.
But showing KRIS pages from the Compendium has a second effect: he’ll learn the content of that page, and this might have consequences. To resolve a story you think should end with betrayal, you might show him a page with a tabloid article about his estranged daughter selling the rights to his neural scans after his death. This might well convince KRIS his novel should be about betrayal… but will it teach him betrayal was a theme of his own life, too?
Ice-Bound isn’t a puzzle game: there’s not one right answer. Any ending can be justified by multiple Compendium pages. It’s up to you as the player to find something that feels right for the story, while also balancing the information you want to share with KRIS about his past, and how his own story unfolds.
Regardless of its secondary effects on KRIS, resolving a story strengthens a particular theme, signaling to him that theme’s importance in his novel. As you descend to the next level, KRIS considers each of the new map’s sockets, and will try to fill them with symbols tagged with strengthened themes. So if you start telling KRIS Ice-Bound is about betrayal, he’ll start giving you stories that have more and more elements related to that theme woven into them. Focus on hints of advanced technology or unexplained powers? Ice-Bound will start turning into science fiction.
This is the second layer of combinatorial complexity in our narrative engine. Not only is an individual “build” of a story combinatorial—you can rearrange the “dollhouse furniture” to explore dozens of arrangements of active symbols, and the corresponding events and endings they trigger—but each level’s map is itself variable, since the set of symbols comprising it changes based on the pages you’ve shown to KRIS. This doubled complexity means there are tens or sometimes hundreds of thousands of different permutations of each of Ice-Bound‘s chapters.
How is this possible? Doesn’t this mean we have to write a massive library of content for each story: variations for each possible theme or combination of themes? The way we solve this is by having two libraries of content. Certain sockets on each map are reserved for “story-specific” symbols, authored for that particular story, while others can draw from a larger pool of content that can be pulled into any story.
Assigning symbols to sockets during level construction.
This is where our templating system really shines, tweaking a fragment to make sense no matter which story it’s dropped into. Our contextual grammars let us alter details based on things like time period (replacing a telegram in the 1940s with an email in the 2000s), character-specific language (Franz says “Mein Gott!” while Miquel says “What the hell?”), or even which other symbols are currently active: that gun over the mantelpiece might show up in somebody’s hands during a violent ending, or be replaced by a different item in another story. At the same time, the story-specific symbols let us give each story its own unique skeleton, making the results feel much more on-target than a completely generative system might produce.
We’re really proud of the templating system, and will probably write more about it specifically in a future update. But in short, along with the narrative engine it helps us builds stories out of highly specific but still generalizable pieces, letting us add a dramatic beat thematically appropriate to the player’s editorial decisions (say, one where someone begins to doubt their sanity) to the story of Ethan (a lonely radio operator wintering over during World War 2) just as easily as to the story of Miquel (a present-day scientist with a questionable ethical code).
But how can we manage this combinatorial complexity without losing our own sanity? In our next post in this series, we’ll talk about some of the authoring tools we’ve developed to write for this multiply-combinatorial engine. In the meantime, stay warm, keep track of us on Twitter or Facebook, or join our mailing list at ice-bound.com to get major project updates.