An Open Letter to TaleWorlds
Why Total-Overhaul Mod Development is Hamstrung, And How TaleWorlds Can Prevent This Going Forward
Preface
This open letter is the product of massive amounts of frustration and concerns within the Bannerlord modding community. It’s been almost a year since Bannerlord Early Access was released, and based off of the ~30 patches that have been released for the game, we think TaleWorlds’ priorities are highly misaligned with the needs of the modding community.
This is not intended to be an exhaustive list of issues, but rather a meta-analysis of the assumptions and decisions TaleWorlds have made without considering the needs of their game’s stakeholders. We hope this letter will serve as a catalyst for improved transparency, communication, and collaboration between TaleWorlds leadership and the Bannerlord mod developers, so no one is left dealing with the consequences of short-sighted decision making.
You may be wondering why the majority of mods released for Bannerlord are small-scale tweaks, faction/culture overhauls, and generally don’t change the core gameplay of Bannerlord. The reason behind this is that TaleWorlds has put up artificial roadblocks throughout the game’s code that severely impede (and often, make it completely impossible) to make any large scale changes. The code to fix and modify some of the largest issues in the game (siege AI, crafting exploits, etc.) is all public, but those roadblocks prohibit modders from touching that code. As far as we are aware, the decision to put up these roadblocks was made behind closed doors, with little to no consideration of their impact on the ability for total-overhaul mods to carve out the worlds and gameplay we have envisioned.
In addition to these roadblocks, TaleWorlds has made it clear over the last year that they have been prioritizing expanding the base game and adding new features, rather than creating a polished and modular foundation for modders (and TaleWorlds themselves) to build off of.
We are asking for TaleWorlds to remove these roadblocks stopping us from making our mods, and to include us in the process behind making these decisions to prevent similar problems in the future.
What TaleWorlds Should Have Learned From Warband
Using Warband as a case study, we think it should have been obvious which features and functionalities were desperately needed by mod developers. For example, every single one of the most popular mods (Prophesy of Pendor, The Last Days of the Third Age, A World of Ice and Fire, Perisno, etc.) had custom campaign maps, playable non-human races, and would have benefited greatly from the ability to rig agents to custom skeletons. In Warband, these features had to be implemented using very rigid methods (such as adding custom body parts as armor pieces, hence why certain gear is locked to specific races in the before-mentioned mods). We think accommodating these widely needed features in Bannerlord’s engine and making them accessible to modders should have been a day one priority for Taleworlds. As of the writing of this letter, none of these much needed features are functional, and we have no idea where they lay in TaleWorlds priorities.
Every patch that comes out where these critical features are not addressed and are ignored in favor of developing new features feels like a slap in the face. After nearly a year and about 30 branches of the game released, we think it is now abundantly clear that Taleworlds (more specifically, the people deciding which features are prioritized at Taleworlds) is very out of touch with the needs of the community. To summarise, we’ve given TaleWorlds an entire year to iterate over a solid foundation for both the modders and TaleWorlds to build off of, but they have opted instead to continue building new (and somewhat underwhelming) features off of a flawed foundation instead.
The Main Problems
The following sections will detail some of the high-level programming centric issues that are actively preventing us from developing our total-overhaul mods. Resolving these problems would be a (very much appreciated) sign that TaleWorlds is prioritizing the needs of their stakeholders. Failing to address these concerns will likely result in many amazing total-overhaul mods being stuck in stagnation for the foreseeable future.
Pretty Much No Documentation
There are two critical things every open-source project must satisfy to allow for external developers to contribute or extend the exposed code.
The first of which is writing code in a way that is easy to read. TaleWorlds actually does a good job with this, and it is generally pretty easy to tell what exactly each class and method does just by reading its name.
The second of which is at least high-level documentation explaining how each system works, and how the maintainers intend for you to implement generic features.
The official documentation is almost non-existent, and is extremely narrow in scope. While it is understandable that the code is extremely volatile and being updated constantly, that is not an excuse for putting next to no effort into documenting your code.
The lack of modding documentation significantly increases the amount of time needed to implement simple features, and has led to many bad practices for newer/less knowledgeable mod developers (especially the use of
Harmony to patch code at runtime). Even seasoned software engineers within the community have to spend countless hours debugging and trying to understand how every system works at a high level. For less experienced coders unfamiliar with advanced C# topics like interfaces, delegates, and reflection, this is a nearly impossible task. Not to mention the event driven/non-linear flow of the program makes it even more difficult to understand where methods are actually executed. Even if there is an overridable callback/method that could help modders execute their code, this makes it unlikely for them to be aware of its existence, so they instead opt to use harmony.
It shouldn’t require the effort of a full time job to understand Bannerlords code at a high level. This issue affects pretty much every Bannerlord mod developer, and just a little effort to document Bannerlord’s code would be a huge quality of life upgrade for every developer, regardless of their experience.
Lots of Inaccessible Hard-Coded Behaviors
Another reason why the use of Harmony is so widespread is that TaleWorlds has populated many generic classes with hard-coded behavior that can’t be overridden. A simple example of this is the constant fields in the Campaign class.
Code:
public const float MapWidth = 900f;
public const float MapHeight = 900f;
public static readonly float MapDiagonal = Math.Sqrt(1620000.0);
The code snippet above implies that a Campaign map can only have a radius of 900. Since the const keyword was used, there is no way to change these without completely remaking the class (which is next to impossible, as explained in the next issue).
The screenshot of code above is from the AddBehaviors method within the Campaign class. This method is also not overridable, and modders have no choice regarding which of these they actually want their campaign instantiated with. Again, the obvious choice for modders is to patch this method with Harmony, as neither reimplementing the Campaign class nor overriding this method are possible.
These hard-coded behaviors are present in nearly every system of the game, from character creation to siege tactics. As a result, if a modder wants to change or remove these hard-coded behaviors and fields, they must choose to patch them with Harmony, or rip out and replace the entire system.
The Rampant use of the “Internal” Keyword.
internal keyword is used so that a particular method, field or class of code can’t be instantiated outside of the assembly it was defined in. In the context of Bannerlord, there are many classes and fields that are seemingly randomly defined as internal.
From what we know, the reason TaleWorlds slaps the internal keyword on seemingly arbitrary classes is to enforce “mod compatibility”. In case this wasn’t apparent already, since modders are forced to patch code with Harmony or completely redefine generic classes within their own submodules, compatibility between mods is entirely dependent on whether those mods patch the same areas of code.
Mod compatibility aside, slapping the internal keyword on generic and widely used classes makes it impossible to modify or extend many of the tightly-coupled systems utilizing said classes.
For example, the entire siege system in Bannerlord is based on the SiegeLane class. Every siegable scene has exactly 3 SiegeLanes (read: a possible route of attack, such as an area where ladders are deployed, siege towers roll up to, a destructible hole in a wall, or a gate that can be destroyed) that the defenders and attackers are balanced between. Just about every field and method within SiegeLane, and SiegeLane itself, are internal. Not only did this completely shatter the prospect of adding compatibility for more than 3 siege lanes in a siege, or having multiple layers of walls/gates, it means we would have to entirely reimplement all the classes that implemented or depended on SiegeLanes.
What is also frustrating is that this keyword is applied seemingly randomly. In the second screenshot of the previous section, the behaviors with a red squiggly line under them are internal. Most of these internal objects have no obvious difference in functionality between several other similar behaviors which aren’t internal. Even if there was a good reason for them to be internal, we would have no way of knowing without proper documentation.
In the context of total-conversion mods, we have a particular vision of how every system in the game should work, and the overwhelming number of internal and inaccessible classes make it impossible to modify or reimplement these systems.
This is the biggest reason why, to this day, not a single total-conversion mod has written any significant amounts of code outside of small tweaks and atomic mechanics.
In many cases, writing the code that makes the Bannerlord experience unique within our mods is not even limited by the capabilities of the engine, but the rampant use of the internal keyword. To say that this causes us frustration or smothers our passion and motivation is a vast understatement.
How TaleWorlds Can Resolve These Problems
The solutions to some of these problems are actually very simple. TaleWorlds could hire an intern with the sole task of documenting how you intend for us to extend and utilize everything from Gauntlet to FaceKey generation. It is not at all practical to offload the burden of documenting a codebase this large and complex onto modders. If TaleWorlds ever wants the Bannerlord modding scene to flourish into more than just small tweaks and patches, this is a must.
To fix the hardcoding issues, TaleWorlds needs to start thinking about their code from the perspective of a modder (What if the modders don’t want to simulate 500 tournaments at the start of a campaign? What if a mod has more than 6 major cultures and we’ve only built our culture selection screen to support 6?). Putting the ball in the modders’ court takes so much work off your hands, and we would be so grateful to be able to sculpt our worlds out as we please.
As for the massive overuse of the internal keyword, we ask that you remove it from every class, method, field, etc. within reason. If there’s ever a doubt in your mind that a particular piece of code might be useful for a modder to use in their own assemblies, it shouldn’t be made internal.
We have a strong opinion that the issue of mod compatibility should be entirely up to the mod developers. If a modder’s priority is to make their mod highly compatible, they are able to do that with good coding practices. Using the internal keyword as a way to try and force compatibility is having the opposite effect (modders using Harmony), and for total-conversion mods, it’s actively hurting our development.
Lastly, the biggest (and easiest) step to take would be improving the communication and collaboration between TaleWorlds and the entire community. We have no idea if our requested features are in the works, or if they are even being prioritized at all. A feature roadmap, or even a trello board providing some insight on prioritization, would give players and modders alike the confidence that TaleWorlds is building the game the stakeholders want.
Why Are These Issues Important?
As mentioned before, it is almost impossible to work on any non-atomic code for our mods. While our artists, sceners, and other team members are able to at least work on some things in the meantime, pretty much all of our mods are at a complete standstill in terms of programming and actually implementing our team’s work in the game itself. Until you fix these issues, our progress is severely hamstrung, and the time it will take to get our mods into our fans’ hands will be indefinitely pushed back.
In the words of Elon Musk:
“Too many MBAs [are] ruining companies”. We think it is unlikely that there wasn’t pushback from TaleWorlds engineers regarding these design decisions, and we ask that TaleWorlds starts taking their feedback more seriously as well. Many of us have first-hand experience of the dynamic between profit/deadline obsessed executives, and the engineers pouring their hearts into the game. Even the most loved developers have fallen to similar hubris (*cough* CDPR...).
Help us help you make the sequel that leaves Warband in the dust.
Sincerely and respectfully,
Kingdoms of Arda
The Old World
Trial of the Seven Kingdoms
The Kingdoms of Alantia
Touhou Gensokyo Warfare
Sword & Musket
Shinobi
Shokuho
The Long Night
La Commune de Paris Mod
In the Name of Jerusalem II
Medieval Third Crusade
