Hello, backers. We meet again in good spirits!
We’ve got quite a bit of development progress to get into, but before we jump into that, we’re going to do a quick repeating feature at the top of every update addressing some of the common questions we get. Usually we get these same questions several times a day, so hopefully this will help keep everyone up to date:
ESSENTIAL Q&A
Q: How/where do I upload my guild crest?
A: We’ll be including crest uploads as part of the actual game, so there’s never a deadline. It will only be accessible by backers.
Q: When is the game coming out?
A: Later this year. We used the overfunding to significantly increase the size of the game and extend the release date.
WHITE BOX
As you may have heard, Factions is out. We’ve finished all the combat upgrades which you can try in the game (we’ve also decreased the “grind” quite a bit based on feedback we got). This means that every character ability ranks up and becomes more powerful, which was the last combat system we needed for single player combat.
To mention it again, everything we did for Factions is for the single player. Even the intro cinematic in Factions is actually the intro to the single player game, and the combat boards in Factions are key fights in the single player campaign. We’re using all parts of the buffalo, so to speak.
During this time we’ve finished final design work on all our systems. With this documentation finished, implementation has begun.
Here’s a recap: The Banner Saga has three primary gameplay systems: combat, conversation and travel. You switch between these to advance the story. Conversation tracks your decisions and advances the plot, travel is a combination of Oregon Trail and King of Dragon Pass, moving the story forward while creating events related to what you’re doing. Travel also accounts for exploring towns, just like how you see Strand in Factions. The turn-based combat occurs when conflicts arise. Each of these systems feeds into the others.
What is a white box?
This a term used to describe the entire game from front to back laid out with placeholder assets. Sometimes it’s called a gray box because in 3D games designers will rough out the shape of the world or levels with simple gray boxes so that they can playtest it before doing time-consuming and expensive final art.
What this means is that we have been implementing every travel scene, every conversation and every combat into the engine and tying the whole thing together via scripting so that we can actually play the entire game. White boxing takes the game from being a series of design docs and makes them exist in the game in rough form. Travel will have placeholder art, combat will have placeholder enemies and conversation will have placeholder dialogue that we can easily iterate on.
What a white box is invaluable for is 1) making sure the systems are functioning correctly, 2) other work can be developed based on this (for example, sound and music), 3) making sure the transitions between systems work well, and 4) Iteration! This last bit is probably the most critical part because it’s only once you have everything playable that you can start to refine it until it shines. Imagine making a game as drawing an enormous mural. A painter doesn’t start in the corner of the picture and complete the image one inch at a time. He roughs in the entire image in pencil, makes changes to the composition, blocks in the colors, adds shading and lighting, then starts to do the detail work. Making a game is a similar process of iteration.
In our case we scoped out the game in rough documentation. We re-scoped when we got 7x the funding. We created gold standards (final look and feel) for travel, conversation and combat. We then started to build the framework for each of these systems. You can see travel functionality when you pan the camera in Strand and the story is already playable through Inkle Writer. We had the great fortune of being able to use Inkle Writer as our conversation toolset, and this has saved us literally months. Inkle Writer will allow us to output functional code that easily plugs into our engine to control variables and conditionals. We took combat past the point of being functional into full polish. As this was our highest risk system it made sense to front-load the work on combat. Playtesting and feedback made sure that it’s as good as we can make it, and we’ve iterated the hell out of it.
TYING IT ALL TOGETHER
Game development has a lot of hidden nooks and crannies. For example, when you think of designing a game you say things in your head like “when the player wins this battle they’ll cut to a conversation…” but how does that happen? You don’t want a programmer to sit down and input every aspect of the game as hard-coded data, which is time-consuming and prone to errors. Instead we’ve created a data-driven system that allows any developer to adjust and modify variables, triggers, actions, conditionals, etc at will.
Each individual game can approach this in whatever way works for them. In an extraordinarily complex game like Star Wars: The Old Republic it’s virtually impossible for any one department to understand all the systems that spiderweb to draw the game together. For example, let’s just take cinematics. The developer accounts for calling appearances, tracking any previous variables like story decisions, calling any other PCs and NPCs in the scene, tracking the characters equipment, and then a slew of specific details about what animation to play, which camera to use, which VFX or sound FX to play and a dozen other choices. And that’s multiple OAVs (Object-Action-Value string) per line of dialogue, sometimes numbering in the dozens. Now take that whole packaged cinematic up one level and you’re integrating where it appears in the world, what prerequisites are associated with triggering it, what state the environment and characters are in, what event spawned this current one, what will be spawned after, what variables change as a result and how the information is given to the player through UI indicators or journal updates. Branching storylines will exacerbate all of this to an incredible degree. At the end of production on The Old Republic, BioWare had literally dozens of designers called “scripters” whose entire job was just to tie everything together. You probably didn’t even know they existed because their work tends to be invisible.
In The Banner Saga we’re able to boil this down to a much more manageable level. First of all, as a 2D game we’ve already reduced a massive amount of complexity. Secondly, we’ve streamlined the whole system to only account for exactly what The Banner Saga needs, not an engine that needs to be applicable for both first person shooters and puzzle games, for example.
Here’s a practical example: we need to track a package of things that happen. “When you do this, that happens, which changes this and puts you on that path.” We’re calling these packages “Happenings” and they tie everything together. It’s just a word we made up. Happenings sounds like a weird thing to call a system but we’ve found that the more identifiable a name, the less likely you are to confuse what you’re talking about. When you have lots of systems interacting with each other, this is vitally important. For example, we call a package of animation, abilities, sounds and VFX for a particular character a “phantasm” so when we use that word we know exactly what we’re talking about.
A happening is made up of the exact the elements needed to start and finish an event. We have triggers, actions, variables and resolution. A happening can spawn other happenings running simultaneously and each tracks different values until they resolve. Here’s an example of how you might construct a happening:
Your trigger is what calls the happening. Let’s say we want Crossing a variable threshold. Ok, once the threshold is crossed we’ve triggered the happening. Maybe this is a number of days that have passed, or a travel stat changing from 2 to 1. Then what happens? Let’s say the action is Go to combat: X. This will put the player in a pre-defined (or random, if we specify) combat. Once this action is complete it goes to the next value. Maybe it’s another action: Go to conversation: X. The player cuts to conversation mode which can introduce variables. If it does create a new variable, this probably spawns a new happening to track the variable. Or it may result in a linear variable, like moving time forward. This would create Modify Days: X. When the conversation ends we go to the next value, which may be Go to travel: X. This will put the caravan back into travel mode where they’ll trundle along until they trigger the next happening.
This is a very simplified example, but in sequence it may look something like this:
Happening: Plot_element8
Trigger: Cross a variable threshold: days=23
Action: Go to combat: forest_ambush
Action: Go to conversation: part2_13
Variable: Modify days: days+2
Action: Go to travel: road_to_strand
Resolution: end
This is a linear sequence of events, but each happening in itself is linear- we don’t track conditionals here. At day 23 of travel we got ambushed. After the fight we had a conversation and did something that took 2 more days. Afterward we were back in travel, heading toward Strand. The new happenings that trigger are what make the game branch and diverge. For example, you may make a decision in the above conversation that causes a new series of events to be set in motion. Maybe there was a heated debate about which way to go and one of your companions lashed out in violence. This new happening doesn’t require a trigger because it was spawned in the above conversation. Here’s what it might spawn:
Happening: conversation2_13_bob_attacks
Variable: remove_bob
Variable: morale-2
Action: Go to combat: bob_dies
Resolution: end
In this case the decision I made in conversation caused bob to die and that modified some variables and spawned a combat immediately. Once the combat has resolved it’s gone, but the previous happening is still going. I return from combat and do “Go to travel: road_to_strand” before that happening will end. Most of these variables and conditionals are applied in conversation, which uses a whole different set of toggles called markers to define different conditionals that then inform global changes or variables to the parent happening.
This is just one example. The list of functional triggers, actions and variables is much deeper and includes everything we need to make The Banner Saga functional and dynamic.
Now first of all, let me mention that this isn’t ground-breaking stuff. Most games use something like this and ours is fairly simple, based on our understanding of it working at big companies. But as you can imagine, this can start stacking up to get fairly complex. Fortunately, with the game itself being well-defined we can afford to add complexity to the story, where we want to see it.
When a company plans to make a game it can choose where to place its complexity. If you want full 3D environments, top of the line visuals and animation, complex physics, branching dialogue and advanced combat or inventory systems you’ll pay for those exponentially. You can almost think of it as each major feature you add to a game amplifies the difficulty of all the other features. Indie games success has almost always been in taking one or two features and taking them to their furthest extent, usually trying something that feels new in the process. Story has always been our primary focus and our other systems bend to its maniacal demands.
The main point of this long explanation is that this is currently where we are in development— hooking up the white box.
TRAVEL DESIGN
We’ve now finalized the design for travel, conversation and combat (single player features like AI, spawners, random battle generation, etc). In this update I’ll go over an explanation of travel and some of the features involved there.
Everything in this section is a step-by-step example of us identifying a problem, coming up with multiple solutions and implementing the one that works best for the game. We think it’s great to be able to show the whole process, not just the final result. For reference, we do this with just two or three of us, in a single room, throwing ideas around and mocking them up within minutes. While working for a big company the process would be very different. We’d write a “user story,” schedule a conference room, have a three-hour meeting, document the result, send it up the chain for approval, integrate the feedback, get it approved, pass it by the upper management/publisher, get more feedback and integrate a variety of requests from management or marketers who don’t really understand the system in the first place. Then we’d find out it got cut and… anyway…
We knew the travel involved two key features since it’s earliest conception: we want the player to travel across vast, beautiful landscapes, and we want them to be making decisions that affect other systems including combat, conversation and the story in general. The gameplay requires that the player can set up camp at any point and make decisions about the path they wish to take.
Additionally, as described in update #30, players will have to deal with events that arise as they travel. The decisions they make persist and affect their story, similar to King of Dragon Pass. It’s like managing a rolling settlement. This is still the core fundamental experience of traveling.
However, as we began to mock up the system we found one issue in particular that we needed to solve. Here’s an example of the travel mode as we’ve implemented it:
Just like our trailer, the player travels across a land that looks like this. The events as we described are ready to go and events would work fine here. The caravan trundles along similar to Oregon Trail towards their destination.
However, from this angle we knew that we had an issue to solve: unlike Oregon Trail the landscape isn’t abstracted. If we have wide distances between two points we have four problems: 1) to make the world feel appropriately large we would need to create a massive amount of content to fill the space. This would require us to either sacrifice other systems to buy the necessary time or have a lot of very repeatable assets which would defeat the purpose of making the player watch it. 2) Watching travel for extended periods of time would be boring even if it were all unique. We want the player to feel like they’re making progress, not passively waiting for something to happen. 3) If we make the play-time correct instead of the distance it will feel like the world is tiny, with only a casual stroll between major cities and milestones, and the fiction would fall apart. 4) We want the player to feel the impact of choosing different paths. If they choose a different path via the story and end up on a similar looking travel screen it won’t feel significant.
Our first instinct was to create an overhead map for the player to fill the gaps, as so:
In this design we have a map with different waypoints. Systems like this are used in plenty of RPGs like Dragon Age: Origins, Final Fantasy Tactics or FTL. The player would choose a destination from any adjacent location and they would head in that direction. When they reached the location they would go back down into the side-scrolling travel mode show above. This would let us give the impression of traveling a long distance without having to sit through it, while also letting us show off beautiful landscapes at key locations. Since we define those locations we could make sure that they use unique art.
This had a few problems, too. World maps tend to make a world feel small, not big, by shrinking huge distances down to a short line. It also gave the impression that the world is just a series of points and not a real place. In gameplay terms we didn’t like how the player would watch their caravan slide across the map without any indication of what was happening to them, which felt impersonal. We also didn’t want the player spending significant time staring at the same map over and over.
To address the issue of tracking how far a day of travel is and make the distance feel more concrete and larger, we considered the “dashed line” approach used in, for example, Indiana Jones when he travels by plane.
When selecting a location, it would generate a travel plan in dashes. The red dashes would represent a passage of time (say, for example, 1 dash = 1 day of travel) and the blue dashes would represent at what point the caravan would shift to side-scrolling travel. In this mode, the player would press a button each day they wished to travel, similar to changing seasons in King of Dragon Pass.
We quickly scrapped this idea. It felt too gamey, UI-centric and potentially boring, and would still require us to code, playtest and create art for an even more complex system which burns development time.
Ultimately what we came back to is that you’re traveling a vast, beautiful landscape. By utilizing the travel tools that we already have we drew up this:
In this version, the player transitions from close-up travel to a camera that is pulled back to show an expansive landscape. When reaching a landmark or town you still travel at 1:1 scale, amongst trees, guards manning city walls and animals in the field, but now you’ll also travel along gorgeous vistas of massive scope.
The caravan shrinks to show just how many people could be in your population, potentially in the thousands. The distance between two landmarks can fit in a relatively short period of play time, while still giving the sense that you’re traveling a vast distance. Our minimal HUD at the top counts up, tracking days as they pass, reused from the deployment HUD in combat (which you’ll recognize if you’ve played Factions).
Not only does this save development time but it makes travel beautiful again. We can animate things happening around you, weather, things blowing in the wind, show the state of your caravan and have landmarks appear in the world. You make decisions about which paths to take in either popups or dialogue, triggered as part of the story. This will make the decisions feel more organic than clicking a point on the static image.
However, we still missed the greater sense of your place in the world that the map gave us, so while traveling, you can press a button to pull down the map behind you. It works aesthetically and lets the player check their location without stopping the action. This is not the real map, incidentally:
THE GODS COMETH
I’ve now been in conversation with the backers who were generous enough to earn a place in the heavens as viking gods. This means we’ve also finalized the lore documents and have worked out the mythology and history of the world. I have to say, on a personal note I think the gods are coming along really excellently and will add a ton of depth to the world.
Gods each have a unique godstone, and crossing these along the journey will give you the option to learn backstory. Godstones also act as milestone markers and instill bonuses to those who path beneath. When you see a godstone in the game you’ll be glad for it.
COMING UP
We’ll be going into more detail about travel details and how they interact with other modes, probably going deeper into conversation and single player combat as well. As we’ve mentioned in previous updates, stats like endurance, morale, population, supplies, the number of warriors in your caravan and a few other factors all determine how fast you travel and the state of the locations you can travel to, but also factor into the other systems. Your choices in each gameplay mode affect the others.
At some point we’ll also be doing a featured update on the animation process where we go over everything involved in making a hand-animated character.
PUSHING AHEAD (PLEASE READ)
We know many people are anxious for the game to come out, so are we. Our original estimation was Nov 2012 and when we were given the option to take longer, and make a better game, we decided to take it.
That said, we don’t want to make any more delays to the game. We think most of you will agree that the best way to do this is to halt anything that isn’t related to getting chapter 1 out the door.
When we complete the Saga finished systems will continue to make their way into Factions.
We are shipping the game for Steam first, and the standalone port (on Desura, GOG and Amazon) will be our immediate task after that. Yes, that does mean Steam will get it slightly sooner because we’re already integrated in Steam. However, the game is universal to all backers, so even if you prefer the standalone version you will have access to the Steam version. We don’t see any reason to withhold the game while we convert it to work as a standalone. We are also going to be more quiet between updates as they can take a lot of time to produce.
To put it simply, it’s full steam ahead on the single player game and everything gets shipped as it gets done. The good news is it’s coming along great!
Until next time,
—Alex
