John Watson is the co-owner and technical director of Stoic Studio. He has been programming since he was 6. He came to Stoic after doing some work on the Hubble at NASA, and serving as lead combat programmer on Bioware's The Old Republic.

INTRODUCTION

Banner Saga 2 is the second part of a planned trilogy. After the successful launch of Banner Saga 1, we had a mighty tailwind and our sails were full.

However, we soon hit some challenges which slowed us down and distracted us for some time.

After what amounted to two years of brutal crunch to get the first game launched we took a much-needed break. The three of us variously rested, traveled and caught up on the parts of our lives that had been suppressed or neglected.

Then, a series of technical projects, including localization and porting, consumed most of John Watson's time for the next year. Alex Thomas, the writer of the first game, decided to set off on his own to work on his own project. We brought Drew McGee on to write the next game, and he and Arnie Jorgensen began preproduction and planning. We had some false starts, but a year later, with E3 2015 looming on the horizon, we started production in earnest. We brought Matthew Rhoades onto the team for technical design work and that E3 showing was our first fully fleshed out vertical slice of the game.

WHAT WENT WELL

1) Everyone Worked Hard

With such a small team, this is incredibly important. There were four of us working full time on the game, with important collaborations occurring at various times throughout. Composer Austin Wintory is involved from day one in blocking out the story arc with us. Igor Artyomenko, a fantastic artist hailing from Kazakhstan, came in to help Arnie with the art load. KPow Audio are involved in planning. Powerhouse Animation needs to get their workload in the pipeline early, because they could easily become a bottleneck otherwise.

The four full-timers spent every day collaborating on Slack, with impromptu video chat meetings throughout the day, and a daily kickoff video meeting each morning at 9 a.m. We tracked our tasks and milestones carefully, and everyone did their best to maintain forward momentum and prevent blocking anybody else.

2) Idea Generation

Everyone on the team contributed ideas and feedback throughout development. Ideas and story flow could be challenged by anyone, as could gameplay mechanics and presentation. This collaboration goes beyond the four full-timers to all of our major collaborators. Everyone working on the project is a veteran and their ideas are duly considered.

Each person certainly has their expertise and role to fill, but no role is rigidly partitioned from everyone else. The team's maturity allowed us to have candid conversations and discussions without worry about hurting people's feelings or causing ill will.

3) High Morale

Seeing the game come together was very exciting for everyone, and most of the time the mood was upbeat and optimistic. We were all confident that we were making something good, and that we would be able to pull it off. The biggest question in development was about how long it would take to complete. Having a confident, optimistic outlook toward the game as a whole helped us weather the difficult periods of heavy workload and unfortunate crunch.

4) Flexibility

As a team, we were able to switch gears quickly and make major changes to the game where needed. Something not coming together well, or taking longer than expected? Seriously consider cutting it. Chapter flow not smooth? Re-arrange, split, and re-combine chapter boundaries. Game mechanic not fun enough? Redesign it.

Some examples: 

We originally made horseborn units rectangular 1x2 tile units, thinking it would add some refreshing variety to the battlefield. However, after much effort, they were still a little wonky and not really adding anything but confusion. They got cut back to squares after all that work.

Chapter 10 turned into a mega-chapter with the highly complex events of Lundar being only the midpoint. Chapter 10 got split, chapter 12 got cut, and chapter 14 got re-arranged.

Our original design for higher-ranked units involved a common mechanic of resetting stats to their minimum values and allowing the player to slowly re-build them up. However, once in the game, we really didn't like the way it played. We went over about four different iterations before we came up with the Talent system, which we all really feel good about.

5) Pre-Existing Tech

We built Banner Saga 2 with the same engine we've been using all along. This allowed us to hit the ground running with production, and re-use all the tools with which we are familiar. We built quite a few new features onto the engine. If you slice off the year we spent working on localization, porting, and slow pre-production, we really made the entire game in less than a year using our existing tech.

The Banner Saga Engine has a nice mature pipeline allowing us to quickly make changes and see them immediately in-game without needing a new build at all. Our automated build system operates in the cloud and serves out new builds whenever the code changes, with a turnaround time of less than five minutes. The builds are served to the content developers directly through the Steam client on a private branch, which means no manual intervention is needed to get new builds or make sure you have the latest build. This all streamlines things quite a bit for everyone.

We had already gone through an entire iteration of music and sound implementation, and that experience informed both Austin Wintory's and Kpow's efforts on Banner Saga 2. Powerhouse animation had created an immense number of animations for the first game, so when we gave them another sizeable workload, they were able to ramp up immediately.

WHAT WENT POORLY

1) Tools

Since John's time was almost entirely consumed in creating new features and supporting localization and porting efforts, the content development tools didn't advance as much as they could have. Many of the irritants and inconveniences of the tools from the first game persisted throughout development.

The game content is almost entirely data-driven, but some of the systems, notably the ability system, has no tool to assist in its data creation. So combat abilities, some of the most complex behaviors in the game, have to be created by editing JSON in a text editor. There are other subsystems that likewise have no tool, and require manual JSON intervention.

The game dialog and story was written in Inkle Writer, a free tool by our friends at Inkle who are responsible for the fantastic game 80 Days. Our heavy usage of Inkle Writer, however, has exceed its intended limits and causes problems on a regular basis. As much as Inkle Writer has helped us get the game off the ground, it's time for Banner Saga 3 to upgrade.

The game engine itself is based on Adobe AIR, which is a fairly capable piece of technology. AIR provides a compiler and runtime for ActionScript 3 bytecode, and a library of application interfaces for input, file handling, networking, and simple graphics. It also provides a full 3D interface for doing GPU accelerated rendering. Furthermore, it compiles natively to Windows, Mac OS X, iOS, and Android, and allows you to link with as much custom native code as you like. The unfortunate side of this is that Adobe puts very little priority on supporting developers, and as a result the AIR technology is difficult to use, the tools are perpetually buggy, and it appears to be slowly dying through neglect. The kicker is that it's a total black box, and no source code license is available, so when something goes wrong, you may well just be screwed.

The difficulties with Adobe AIR manifest primarily on the Android platform, which is a nightmare scenario already due to the extensive device and OS fragmentation. However, it extends also the the console porting world. Since Adobe AIR isn't being actively pushed forward onto new platforms, it means that we needed to take a different approach with porting. Fortunately, based on our years of experience with Autodesk ScaleForm, we knew that we could wrap the game entirely in ScaleForm. The downside was that wrapping an entire game of this size is not a typical use case for ScaleForm. It's generally used in Triple-A studios to provide cool GUIs and HUDs in games. We definitely pushed ScaleForm to its limits and beyond, and had to work closely with Autodesk throughout to address issues. More on this later.

2) Multitasking & Bottlenecks

A downside to having a small team is that each member is responsible for a wide variety of tasks. When you are multitasking, it is very likely that the neglected or down-priority tasks are blocking other people from getting their work done effectively or on time. As with most games, each of the elements and systems depend on most of the others, inevitably creating circular dependencies and feedback loops. While desirable from a gameplay standpoint, these interlocking dependencies can create production challenges. We're hoping to be able to hire a full time producer for Banner Saga 3 to help us keep on top of these issues.