In case you missed it on the Kickstarter, here's
the update Alex posted last week:
- - - - - - - - - -
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 s...
