Why Stoic Games is sharing The Banner Saga’s game engine

Last year, indie studio Stoic Games burst onto the scene with the crowdfunded and beautifully animated strategy RPG title The Banner Saga – a game built on the developer’s own tech.

In the time since, a similar title has emerged from developer Skyshine. Bedlam’s themes, visual style and some of its turn-based mechanics may differ from The Banner Saga’s, but the same technology is in fact ticking away behind the scenes.

We caught up with John Watson, technical director of Stoic Games (pictured), to find out why his studio decided to share its proprietary game engine, and whether he is open to more indies developing games based on The Banner Saga’s technology.

Why decide to give other indies access to Stoic’s technology/engine?
John Mueller of Skyshine has been a longtime friend of [Stoic art director] Arnie Jorgensen, both of them great artists with a comics background. Sometime after the launch of The Banner Saga, John Mueller approached us with a game idea for Bedlam, with game mechanics that were in many ways isomorphic with the game mechanics of the Banner Saga, and hence with the feature set of the engine.

Our engine was always made with the single purpose of making Banner Saga and its peculiar systems, so my default position on sharing the engine would be one of reticence, as any deviation from the supported feature set would require programming effort. However, the similarities between the two games made technology sharing imminently feasible.

What support did you offer to Skyshine? How did you balance this with working on your own games?
When Skyshine began, we were already neck deep in porting efforts, as well as ramping up production on Banner Saga 2.

We kicked off the collaboration with several full-day jam sessions. We spent a day with Sam Gage and John Mueller, taking a tour of every feature of the game and the toolset. We walked them through every feature and created examples of scenes, animations, user interfaces, and so on. A short time later, their programmer Jeff Johnson met with me for a day to go over the structure and architecture of the code, the systems, and the build pipeline.

These jam sessions resulted in a good bit of documentation, as well. Throughout the development, Jeff and I communicated regularly, and my role was almost entirely answering questions, giving advice, or pointing them in the right direction. Jeff did all of the actual programming for the Bedlam-specific modifications. At one point we got together for another full day of in-person jam session to do a massive integration to their codebase, which provided them with our support for the game on mobile platforms.

Any deviation from our engine’s supported feature set would require programming effort. However, the similarities between the two games made technology sharing imminently feasible.

Did Skyshine’s work highlight any improvements that needed to be made to the Stoic engine?
Certainly. The act of leading multi-person jam sessions in the tools prompted a good bit of preliminary clean-up and preparation on my part. Answering the questions that arise certainly helps guide the production of better documentation, which was a major outcome of the exercise.

Did they alter/add to the engine in any way?
They definitely modified the engine. For one thing, the turn mechanics and health mechanic is different in battles. The navigation network of nodes on the world map was something they added as well.

How well does your engine fit with their game? Why?
I believe that the engine fits well with Bedlam, primarily because Skyshine deliberately created a game design that would fit within the constraints of the engine. The difficulty of game development, regardless of engine, will be adversely affected by the developers’ attempt to fight against the constraints of the engine.

Small indie development, as opposed to large team development, can suffer from the effects of isolation.

What are the advantages of indies sharing technology?
Sharing technology is a growth exercise for both parties. For the provider – myself – it forces reflection and self-evaluation. It creates an opportunity to tidy things up and put on some finishing touches that had been previously omitted.

Small indie development, as opposed to large team development, can suffer from the effects of isolation. Working largely as the only programmer on a team can limit one’s exposure to other techniques and ideas. This isolation is generally not a feature of large team development.

When I worked at BioWare/EA, I had access to other programmers, great minds, and seemingly limitless technical resources. Since I’ve been indie, I sometimes struggle to maintain those kinds of relationships. On Skyshine’s side, the advantage is that they were able to take a game from conception to launch in about one year, which is remarkable indeed.

What are the disadvantages?
The disadvantage is really one of limited resources. Small indie teams like ours really don’t operate with any slack, so adding more responsibilities to my plate is something I don’t take lightly. Part of working on a small team is being realistic about how much you can actually get done, and taking your priorities seriously.

Over the last 18 months, my priorities have been to localize our game into many languages, port to iOS and Android, PS4, Xbox One, and Linux, and of course the massive task of producing Banner Saga 2. Fortunately, the Skyshine team was incredibly competent and were able to take the technology and run with it with a refreshing amount of independence.

Why is it important for indie studios to consider proprietary tech rather than sticking with established tools like Unity/Unreal?
The tech one uses for development should fit your goals. Most games – Banner Saga included – are filled with mountains of custom systems and mechanics. Any one of these features can require enormous amounts of bespoke programming work, regardless of the underlying engine chosen.

In the case of Bedlam, their design mechanics fit with our bespoke work rather comfortably. If an indie developer sees a game out there, and they are able to imagine an isomorphism between that game’s mechanics and their own, perhaps that game engine could be modified to support their own game design. It’s worth considering. If you go with Unity or Unreal, you get this marvelous toolset to build your design with, but there’s often still a staggering amount of work ahead of you.

If you go with Unity or Unreal, you get this marvelous toolset to build your design with, but there’s often still a staggering amount of work ahead of you.

Would you be open to other indies using your tech? How can studios get involved? Do you have any requirements?
Yes, we are open to the idea. We’ve spoken to a few people about it, and produced some additional documentation describing exactly what the engine is, and what it can do. I’m actually very interested in providing modding tools to the community to make their own Banner Saga-like adventures.

We publish our content development tool, Zeno, alongside the game on Steam. If you have Banner Saga installed, you have Zeno as well. There is a free DLC available on Steam, called "The Banner Saga – Mod Content", which contains all the source assets to the Banner Saga, so you can build it from scratch and modify.

I dream of spending more time in streamlining the mod process once we’ve gotten Banner Saga 2 out the door. If a developer is interested i using the engine, investigating the Zeno content tool is a great place to start.