1. Crusader Kings III
  2. News

Crusader Kings III News

PC Dev Diary #94 - Anatomy of a Struggle ⚖️

Welcome to a dev diary I’ve been champing at the bit to write for months!
Coming with our next Flavor Pack "Fate of Iberia" is a new mechanic called the Struggle which will propose new challenges for the rulers within the Iberian peninsula.

► Read our Dev Diary #94 - Anatomy of a Struggle

https://store.steampowered.com/app/1303184/Crusader_Kings_III_Fate_of_Iberia/



[h2]The Basic Pitch​[/h2]
A struggle is a long-form conflict (generally not just a war, though they likely include them) covering a particular chunk of the map. They have different phases, each of which have different variant gameplay rules (e.g., “holy wars are disabled”, “characters of different religions may marry without”, or “Jerusalem can’t declare or be declared war on”).

Phases progress between each other by way of catalysts, specific gameplay actions (“declare war on an involved character”, “two involved characters become soulmates”, etc.) that accrue points towards a future phase. When enough points are accrued, the phase changes to the new one.

Struggles can be resolved, permanently affecting their area in some way, through dramatic and difficult ending decisions.

They are assumed to last at least a couple of centuries: a conqueror carving out a new realm from the ruins of an old giant wouldn’t be a struggle by itself, but if it includes dramatic aftershocks that last for generations, then it just might be.


​[h2]Philosophy​​[/h2]
So why are we introducing this mechanic attached to a flavour pack? Well, simply put, we didn’t think we could do the historical realities of Iberia justice without something like this.

The changing moods and temperaments of the peninsula over different decades, the way particular activities fluctuated between oddly permissive (by the standards of much of the rest of the world) and intensely strict, the role of notable characters and their policies in shaping the shifting tides of public opinion whether intentionally or not…

Medieval Iberia is just such a fascinating smorgasbord of mercurial special rules that we had to create a system that would allow us to model them, one that guided roleplay whilst giving it consequences, and provided default end goals for players other than just conquering all of Hispania.

Though Iberia badly needed such a thing, it would have been a waste to create a system tailored for only Iberia. Complex and shifting local circumstances and long-form conflicts that don’t always take the form of actively-prosecuted warfare are things seen in many parts of the world, and a setting-agnostic system that catered to the peninsula but could be easily repurposed elsewhere seemed like a very worthwhile project to spend time on.

So let’s get into how it works!


​[h2]Involvement​​[/h2]
Struggles are, first and foremost, local things. Local to large areas (Iberia, for instance, is a decently sized little peninsula), but still local. The most basic thing that defines them, then, is the struggle region - a predefined group of titles that the rules of the struggle apply within.

For FoI’s struggle, we’ve used the ol’ reliable world_europe_west_iberia region that’s been in the title since launch, but any region or combination of regions can be defined in the appropriate parameter. At the moment, these are static and only take regions, but we’re considering other options (e.g., titles, regions selected as part of the starting effect, etc.) for the future.




Cultures and faiths are regarded as either involved or not. This defines whether a specific culture or faith is seen as being a part of the “in-group” for the region, even when members of that in-group may occasionally (or frequently) be very hostile to each other. For the Iberian Struggle, for instance, a Castilian and an Andalusian both understand the changing nature of the peninsula instinctively in a way that an Anglo-Saxon would struggle to acclimate to.

Cultures become involved either on first starting a struggle, manually via script, or automatically when a certain percentage of their total counties are within the struggle region (the number is set per struggle, currently at 80% for the Iberian Struggle).

Hybrids and divergent cultures automatically become involved if they convert at least one county within the region on creation.

Neither cultures nor faiths lose their involvement automatically. Once they’re in, they’re in permanently, unless manually removed via script. For Fate of Iberia, this is necessary to keep the ruling class of al-Andalus, predominantly culturally insular families of Arabs or Berbers, involved, but it’s generally there to prevent wonky behaviour with struggles incorporating cultures and faiths from beyond their region who don’t actually have county within it.

A simpler example would be a hypothetical Anglo-Norman struggle for after the Conquest. We’d probably want to set Norman up as an involved culture, and wouldn’t want them to immediately become uninvolved because there are no Norman counties in the British Isles.


​[h2]But Characters Tho?​​[/h2]
Within the region, characters are defined by their personal involvement: the degree to which they’re considered part of the ongoing medley of social and cultural fluctuations that define an active struggle, and so how other characters (and counties) treat them. There are three levels to involvement:

  • Involved
  • Interloper
  • Uninvolved


Involved characters are those who are wholeheartedly engaged in the unique power dynamics of the struggle, and seen as insiders within the region. They may differ wildly from other involved characters, but involved characters are generally considered to appreciate the minutiae that make a struggle play differently from the rest of the world. Both their culture and faith must be flagged as being involved in the struggle, and either their capital is located within the struggle region or, if they’re unlanded, they’re physically there.

Interlopers are active within a struggle’s region but don’t quite grasp exactly how or why people from the region act the way they do. They generally don’t benefit from variant struggle rules as much as involved characters, but also aren’t as heavily restricted by them. Either their culture, their faith, or both are not flagged as being involved in the struggle, but their capital (or physical location if landless) is located within the region.

Uninvolved characters are outsiders and outlanders. Their concerns are remote to the struggle region, and even if they’re originally from that region, their isolation from it makes them lose touch with its subtleties and current events. Regardless of culture or faith, if their capital is located outside of the struggle region (or if they’re landless and physically not there), a character is considered uninvolved in that struggle. Uninvolved characters are generally expected to take penalties for holding counties within a struggle region, encouraging them to either delegate to vassals with a better level of involvement, or else getting more involved themselves.




​[h2]Phases​​[/h2]
Alright, so we know how a struggle covers an area, and how people are divided up into categories within that area. What do these categories and this area actually do?

For that, we need to look to phases.

Each phase reflects a sort of mood or temperament within a struggle region specific to that struggle, the outcome of many prior actions leading to a shifting tide of general opinion about what is and isn’t acceptable. Maybe some things that were taboo become mainstream for a time, and things otherwise considered acceptable are baulked at by even very conservative characters.

Though we’ll talk about how exactly you transition between phases a bit more in a moment, it’s worth noting that each phase has at least one (and usually more) future phase predefined for it, a phase that actions take in the course of play will gradually move the region’s “mood” towards.

Within the Iberian Struggle, phases are on a loosely even cycle: though there’s some lateral movement and backtracking possible, they mostly move evenly in a circle. This is purely a design choice, and more esoteric flows are entirely scriptable.


​[h2]Manifesting the Mood​​[/h2]
The actual effects of each phase can be split into three broad categories - parameters, character modifiers, and county modifiers. These are then further split by the involvement of different characters.

Parameters work similarly to doctrine parameters in faiths, or tradition parameters for cultures. They’re special rules, entirely defined within script (and so fully moddable) that can be referred to elsewhere in script to unlock unique content, provide special exemptions, or block off specific actions.

For example: in one phase, involved characters might be able to intermarry between faiths, in another, interlopers might receive cheaper holy wars whilst involved characters have them blocked entirely, and in both uninvolved characters may be blocked from culture converting involved cultures.



As with other breeds of parameter, struggle parameters are identified purely by their exact spelling and can thus be reused simply by duplicating them, either within a struggle or in other struggles, making them very versatile rules.

Character modifiers can be applied directly to involved or interloper characters. This generally chiefly affects involved characters, making some things easier and others harder, but we also use it to let interlopers occasionally have an easier time of bending or breaking local rules. Though these are our current guidelines, since these are all entirely scriptable, they can be changed according to the tonal needs of any given struggle.

Uninvolved characters do not have a character modifier slot - we don’t want characters in India getting negative modifiers for not being involved or interlopers in a struggle in Iberia!

Finally, we have county modifiers. These are applied to any county in the struggle region according to the direct holder of each county and their involvement; they generally have situational variables depending on phase for involved characters, mild to moderate debuffs for interlopers, and moderate to heavy debuffs for uninvolved characters.


​[h2]Catalysts​​[/h2]
Transitioning from a phase to any of its future phases requires the activation of catalysts: notable events, gameplay actions, and consequences to existing mechanics that drive the current phase towards a specific future phase.

Catalysts themselves can be anything. A war being declared, a type of character being seduced, a certain type of scheme failing, and so on. They’re set inside a phase’s future phase block, and, as with other elements of struggles, are entirely scriptable. Virtually any effect block in the entire title can be made into a catalyst with a bit of thought.

Whenever a catalyst is activated, meaning that the thing that sets them happens, the current phase gains points towards the future phase that that catalyst was tied to (for instance, a notable interfaith marriage might help an uncertainty-focused phase gain points towards a tolerance-focused phase). Catalysts themselves are repeatable and the points they give vary with the difficulty of the catalyst in question - two notable characters becoming soulmates might well be worth more points than a notable character being executed, for instance.

Points for put into simple tallies: when one tally for a future phase is met, that future phase becomes the new current phase, though there’s a grace period of a month before the actual switch.

On the off chance that all of the dozens or hundreds of characters involved in a struggle are being incomprehensibly boring, we should note the existence of one special catalyst: the passage of time. Every phase has a default future phase, and receives a single point per year towards that phase’s tally, representing the natural trend of public discourse towards particular conclusions. This can (and essentially always will) be overridden or exacerbated by more dramatic catalysts being activated, but even in very calm struggle, change is always coming.


​[h2]Ending Decisions​​[/h2]
A core part of the identity of struggles is that they’re not things that can be solved just by painting the map - after all, if they were, then the Iberian Struggle would’ve ended in its first decade when Musa ibn Nusayr had essentially subjugated the entire peninsula.

We wanted to provide more difficult and interesting goals for ending a struggle than just conquering the whole struggle region. After all, it really doesn’t matter if you’ve conquered everyone if that hasn’t dealt with the underlying societal causes besetting a struggle locale.

Ending decisions are our solution to this, being major, demanding decisions with consequences for the entire struggle region when taken and usually pretty intricate requirements.

In order for a struggle to be endable through the usual flow, at least one phase must have an ending decision defined, though they can be ended manually through script also. The Iberian Struggle has three ending decisions, each tied (both mechanically and thematically) to a different phase).


​[h2]The Iberian Struggle​​[/h2]
To finish up, let’s take a look at the new Iberian Struggle’s design (though I’ll put an obligatory reminder that this stuff isn’t final and that we generally continue to adjust things as we balance and playtest).

The Iberian Struggle’s phases are Opportunity, Hostility, Compromise, and Conciliation. Opportunity can lead to either Hostility or Conciliation, depending on how the peninsula’s leaders treat each other, whilst both Hostility and Conciliation respectively build or degrade towards Compromise, which in turn decays into Opportunity, starting the cycle again.

In Opportunity, Iberia is approaching a stage of uncertainty after notable spikes (hostile or friendly) in prior relations between faiths and cultures have abated. Struggle modifiers and parameters make war easier and cheaper, changing cultures and faiths easier and cheaper, but also unlock interfaith marriages and block off holy wars. Friendly interrelations between disparate characters activate catalysts guiding it towards Conciliation, whilst violent ones do the same for Hostility.

For Hostility, aggressive actors have brought tensions to a simmering fever pitch, and even the slightest differences may be cause for aggressive persecution. The phase’s effects make wars cheaper and more brutal for all involved, reduce economic and technological progress, and increase the capacity of many characters for hostile schemes. Violence can’t persist forever though, and either efforts at building bridges or simple exhaustion will eventually bring even the most violent Hostility phase towards Compromise.

Standing opposite Hostility is Conciliation, where pragmatic politicking builds bridges between even very disparate realms. Characters in this phase aren’t really tolerant by the modern meaning of the word, but many of the harsher biases of their time are temporarily dropped or ignored in the name of expediency. Wars become more expensive and truces longer, but there’s opportunity to unite against outsiders intervening in Iberian matters, and ruling over more multicultural and multifaith realms becomes easier and more beneficial.

Periods of interreliance like this don’t generally last. Granted privileges decay, ignored biases relapse, and power-hungry nobles tear down bridges for short-term gain. Even the most wholeheartedly supported Conciliation phase decays towards Compromise eventually.

Finally, Compromise. In this phase, Iberia has reached a point of equilibrium. Wars are less likely and most costly, but economic investment and other forms of passive stability are easier and better, whilst interfaith marriages flourish. The exhausted pragmatism of Compromise isn’t permanent, and will someday give rise to the cynical dynamism of Opportunity. The cycle begins anew.

Naturally we’ve peppered all of this with phase-specific events, decisions, interactions, the odd CB, and so on. Most phases also add variant unlocking criteria to existing pieces of content, adjusting the circumstances under which things like the Claim Throne scheme or Found Holy Order decision can be used - most commonly temporarily extending them to characters who’d usually not have access.

Say you don’t want to move on from a phase, though. Maybe you think Hostility’s the place for you, or you’d prefer a more permanent Conciliation, and want to break the endless cycle of social transmutation - well, unless you wanted permanent Opportunity, you’re in luck, because we’ve got ending decisions for Hostility, Compromise, and Conciliation.




Hostility’s ending decision is Dominance, reflecting the final ascension of one of Iberia’s warring states to a position of not just military dominance, but social and spiritual hegemony.

This gives your house an incredibly powerful modifier, making county and faith conversion within Iberia markedly faster, improving relations with those who share your faith or culture but markedly worsening them with other involved cultures or faiths, and making Holy Wars and Conquests cheaper and easier to access. It requires holding several important duchies, having a monocultural, monofaith primary kingdom, and being the only major player independent ruler in Iberia.




Conciliation’s ending decision is Détente, making temporary accommodations into more permanent ones.

Involved cultures gain a huge amount of cultural acceptance with each other, a house modifier that improves the opinion of different faiths and cultures, and several signature mechanics of the Conciliation phase become permanent for involved culture characters within Iberia: namely, interfaith marriage and disabled holy wars. Additionally, Iberian characters may join defensive wars for targets within Iberia against any aggressor from outside of Iberia.

It requires a certain level of fame, being allied to every other independent involved Iberian ruler, and completely controlling an Iberian kingdom without controlling more than a certain fraction of Iberian territory.




Compromise’s ending decision is Status Quo. Where Dominance is enforcing will and Détente finding accommodation, Status Quo is accepting that times have changed, that attempts to unite the peninsula are futile, and that its peoples and realms should go their separate ways and leave their neighbours be.

Status Quo balkanises Iberia, transferring duchies to connected kingdoms if appropriate and making every kingdom within Iberia its own de jure empire whilst permanently destroying Hispania. Ruling houses across the former struggle region gain a modifier for two centuries making them better at fighting in lands of their own cultural heritage, whilst the capital counties of all independent rulers become strongholds for the next century. Some CBs within Iberia become more expensive.

The requirements for Status Quo are a bit byzantine, essentially because it functions as the opt out decision if Dominance or Détente prove too difficult to work towards. If Iberia can’t be subjugated or coerced into cooperation then, in extremis, it can always be destroyed.


​[h2]Future Use​​[/h2]
The Iberian Struggle is our first go at a struggle system, and it’s one we’re fairly pleased with. That said, we’ve certainly taken note of how the feature seems to have caught the popular imagination over the last week or so, and we’re very interested to hear your thoughts now that there’s a bit more information available.

First up, though, let’s get a little disambiguation out of the way. The basic mechanic here, the struggle system, is free. It will be merged into the base game with 1.6 and available for use in mods (and potentially future DLCs) immediately.

The Iberian Struggle itself, however, is paid content attached to the Fate of Iberia DLC. Though anyone can add their own struggles without needing to depend on this flavour pack, this particular struggle and its content are part and parcel of the DLC.

With that out of the way, are there parts of the system you’d like to see refined and made more flexible? What are the struggles you’d like to see made in future? What’s your jankiest idea for hope for how to use the struggle system?

As ever, I’ll be around in the thread for the next hour or so to answer your queries.

Paradox announce Crusader Kings III: Fate of Iberia and Surviving Mars Content Packs

Paradox Interactive continue building up their strategy games with both Crusader Kings III and Surviving Mars having new upcoming content releases.

Read the full article here: https://www.gamingonlinux.com/2022/04/paradox-announce-crusader-kings-iii-fate-of-iberia-and-surviving-mars-content-packs

Crusader Kings 3 Fate of Iberia DLC set for May release date

Medieval Spain takes centre stage in the next add-on pack for Crusader Kings III. The feudal grand strategy game's next piece of DLC is called Fate of Iberia, and Paradox has revealed that its release date is set for May 31.


Seasoned Crusader Kings players will know that the Iberian peninsula is one of medieval Europe's most dynamic regions, with internal dynastic squabbles and massive cultural upheavals coming fast and furious over the course of a couple centuries. Fate of Iberia focuses on these, adding a new Struggle system, as well as a heap of new events, decisions, clothing and headgear for the cultures of the region.


Crusader Kings III covers the period of the Reconquista, which historically saw predominantly Christian states wage wars against the Muslim rulers who had claimed most of the Iberian peninsula in the 8th century. In Fate of Iberia, you'll have the option to either attempt to unify the realm under one faith, or broker a peace by dividing the land between the warring creeds.


Read the rest of the story...


RELATED LINKS:

Crusader Kings 3 gets a patch for weird-looking eyes

This Crusader Kings 3 mod shifts the action to feudal Japan

Crusader Kings 3's new DLC is an essential strategy add-on

Dev Diary #93 - Turmoil in the Peninsula ⚔️

Greetings!

Winter is slowly fading behind us (at least in the northern hemisphere), and spring is starting to take over. A new season calls for an announcement. I’m happy to present you with our next Flavor Pack: Fate of Iberia, due to be released on the 31st of May!
We are obviously talking about Mediterranean Iberia, not the former Kingdom in Georgia.

► Read our Dev Diary #93 - Turmoil in the Peninsula

https://store.steampowered.com/app/1303184/Crusader_Kings_III_Fate_of_Iberia/



In addition to being one of the most played regions, the Iberian peninsula is interesting because of the complexity of the geopolitical situation, and the richness of the events occurring during the time period of Crusader Kings 3.
It gives us a good opportunity to bring more flavor for both the Christians and Muslims living there.

With this new flavor pack, we want to offer you the opportunity to truly decide the fate of the whole peninsula, either by reenacting history or creating an alternative that pleases you more. In order to model the complexity of the situation, we are introducing a new system, the Struggle.
It will be changing the rules and increasing the challenge for the rulers within the Iberian peninsula. You can have an idea of how the game will be affected in the screenshot below. The effects will vary a lot depending on the stage of the struggle, but we will go into details in the next dev diary :)

The Struggle will both create new opportunities and add constraints for the rulers within Iberia

A new 867 bookmark features a revamped Iberian cast of characters, giving players the perfect place to jump in and deflect history as they see fit. The Struggle will persist into the 1066 start date as well. The bookmark lets you choose between different vassals, either from the Christian Kingdoms, or Al-Andalus. Each of them offers different starting challenges and choices.. For instance, in the south, Emir Adanis and Ibn Marwan are both Dukes under the Sultanate of Al-Andalus. But they also are neighbors and rivals. Starting with one of them will certainly imply crossing swords and scheming against the other.

The new 867 bookmark will be available for everyone, while being more interesting to experience if you own Fate of Iberia


We also seized the opportunity to update the map, refining the county and duchy divisions, as well as the cultures and faiths. This means the stage is more accurately set for the start of our game.

Screenshot of the new county division in Iberia

We mostly focused on the Northern part of the region.

The new culture set up for the year 867

The new faith set up for the year 867


You might have noticed the addition of the Mozarabic faith, but again, we will detail that in a future dev diary, along with the rest of the content you can expect from a Flavor Pack!

We are excited to go into the details and share all of this with you in the coming weeks! Until then, I wish you a lovely day and enjoy the trailer!

[previewyoutube][/previewyoutube]


Cheers,

P.S.: While we do not expect the save versions to be incompatible, please make sure you wrap up your previous playthrough to ensure a seamless transition. If you encounter issues, you can of course roll these saves back to a previous version UNLESS you are playing in Ironman.

Dev Diary #92: From Report to Resolution 🔧

Let's talk about the process a bug goes through from being reported to being resolved and put into an update for CK3!



► Read our Dev Diary #92: From Report to Resolution

💡 This week, please visit our forums to see the images & memes prepared for you ːcrusader_helmetː



Whenever you launch the game, get yourself a your favorite gamer juice and steel your resolve for a few good hours of managing a medieval kingdom, there is a lot of stuff that happened behind the scenes to make it a memorable experience, free from issues. For a game as complex as Crusader Kings 3, this is even more important, and as the features get added to the game, it becomes more and more complicated, like a careful balancing act between economy, AI, warfare, interactions - all to ensure the experience you receive in the newest update is something worth waiting for!

We are but a few humble people, whose job is to find out what works and what doesn’t and report any and all issues to the team before the game hits your platform of choice. But what happens when sometimes issues do remain hidden away and they will take spitting behind your shoulder 3 times on a 3rd fortnight of a 5th month on a leap year, during a full moon while dancing hokey-pokey to uncover?

This is where you can come in and help! We can get rid of serious, big issues, find them ahead of time before you even realize they existed in the first place, and try and deliver a polished product. For anything else - well, it’s the economy of scale. With the variety of systems, languages, experiences, playstyles - YOU are the biggest help of all, in how a game can be shaped. And for that we have a special platform, called Bug Report Forum, where you can air out your grievances, provide feedback, reproduction steps and situations that irk you on the constant, so that our QA team can go through them much more efficiently and supply the team with a steady stream of new bugs to iron out for the next bug fix patch or release.

[Comic on logging]​

Once you take your valuable time to report the issue that ruins your mojo when playing Crusader Kings, it lands on our Forum as a thread. We then take turns, employing QA power to go through the forums and reproduce them locally on our machines to ensure if the issue is serious, or perhaps we can offer support by providing advice on how to avoid it.

Once the ticket is verified internally, using your reproduction steps, your description, screenshots, crash logs and saves, we then take the time to translate it into a language that our internal team can understand - Jira.

There’s an art to this. Jira is an extremely helpful and smart tool to use, and QA by nature becomes naturally adept at using it skillfully. It’s usually the QA who does project-wide database evaluations, scrubbing it from obsolete tickets and updating any and all lingering ones to make sure the project team can focus on what’s important - making more fun stuff!

Wait… Obsolete? You mean you just CLOSE old tickets?

We do… sometimes. For example, if we had an issue lingering around in some hidden away system for a long time (and sometimes not even you, our community, are able to find it for years on end) - the issue becomes obsolete - either we just make the bug into a feature, or because we change a system entirely - it becomes changed so it’s not even a problem anymore. Happens on occasion, and even we are quite surprised that some bugs that linger for long never get picked up by the players, but hey - bugs are features too! Right?

Riiiiiiiiiight…?

[Excerpt from “How to JIRA” guide]​

Now that might look like a lot, but trust me - there’s a way to learn this. First of all, it’s pretty straight forward; complex, but not complicated. We have been campaigning for the team to use Jira tickets efficiently. For example, if we get a ticket that says “Fix the thing we talked about yesterday” and there is nothing else in it, how can we remember what we have done, what needs to be done and how do we go back to it to retest? And again - fast-forward time to a month later and believe me - nobody will remember what in the world such a ticket meant.

As a result, making sure all the fields are appropriately filled out is paramount to an efficient use of the database, and to make our team’s lives just a little bit easier when having to deal with a big pile of bugs that come from you or from our internal reporting.

If everything is sorted, and everyone is on the same page, it makes it a lot easier for the producers to schedule when and how to report. And the upvoting on the forum? That’s an incredibly powerful tool to let us know which tickets need to be prioritized and fixed, no matter what. That’s how we can influence what is important to be fixed first.

[QA chasing the Programmers]​

The (un)lucky Programmer/Designer​
Once the bug has been verified, put into Jira, assigned a version and prioritized, a Developer can pick the bug up for fixing. This is typically either a Designer or a Programmer, depending on where the bug originates. In some cases the bug is reassigned to another role if the bug is found to be caused in another part of the game. Now that we know what the issue is and how it’s experienced, we need to investigate the how and why it happens.

As an example of this, let us look at the recently fixed issue where the Holy Orders would raise themselves and immediately disband if they were called into a war. This issue was a side effect of letting Holy Orders raise themselves for Great Holy Wars: whenever a Holy Order is at war as an ally (which they qualify as during the Great Holy Wars), they would raise their armies.

We start by looking at why the Order is disbanding the armies. If they’re raised, they must have something to fight against, right?

[Code controlling if a order’s armies should be disbanded]​

Through developer magic known as debug mode and source code, we can step through each individual function call to see what’s going on. Stepping through this function leads us to finding that the war they are fighting in is not relevant to them, causing them to disband. Looking at the enemies in the war they’re in, none of them are of a hostile Faith. We also see that they are hired by the Grandmaster of the Order, so the Order itself decided to raise their armies, not another character hiring them.

Holy Orders will not fight in wars where the opposing side does not have any participants of hostile Faith. Because we found the Holy Order disbanding due to being raised against an irrelevant enemy, we must look at the logic which controls how they are raised.

I will spare you the initial dig down the AI code, but the short of it is: if a Holy Order can be raised, raise it. So we need to see why the Holy Order can be raised when it clearly should not be able to. We arrive at the following function.

[Code to check the Holy Order can be hired by a Character]​

This logic checks if the Order can be hired by a character. This goes for any character looking to use the Order in question, even the Grandmaster of the Order. The Grandmaster of the Order is part of the war, so let us see where it leads us. Starting from the top, we check if the character can use the Order. Let us take a look at how that goes.

[Code to check if a character can use the Holy Order]​

This is the code that checks if a character can use a Holy Order. When the Holy Order joins a war on its own, pCharacter is the Grandmaster, which is the Owner of the Holy Order. Makes perfect sense that the Grandmaster can make use of his own Holy Order. But, make notice further down: there is a check there, verifying if the character is in a relevant war. This is the same function that caused the army to disband earlier.

Returning back to the function which checks if a Holy Order can be hired by our Grandmaster.

[Code to check the Holy Order can be hired by a Character 2]

To simplify things, I have collapsed all the irrelevant parts; contained within each “if” section is something which will cause the function to fail, and not allow the Grandmaster to hire their own Order. Let’s go through these relevant parts. We don’t run afoul with the hire limit, as we don’t hire any other Holy Orders as the Grandmaster of one. We are not already hired by someone else, so we skip that part. We own this order, so we don’t touch the third “if” statement. Finally, we can afford to hire our own Order. Look at that, this means we can hire the Holy Order!

But returning back to the finding that the Holy Order would immediately disband because we’re not in a relevant war. This is where we find our solution: if we own our own Holy Order, we can always use it, but because of this we will not look if the war we are in is relevant at all. So we have a very simple solution to the problem.

[Solution to preventing the Holy Order from being raised]​

We know that the check for relevant wars is only skipped if we are the Grandmaster of the Order, we don’t need to check the faith of our own Grandmaster, so this is what we’re left with: if the one who wants to hire the Holy Order is the Owner of the Order, check if they are in a relevant war or not.

The merge request process - everyone judges you​
When the fix has been created, it is put into what is called the merge request; this is the step before the fix is put into the upcoming build. Before it gets merged, there are a bunch of steps. It starts with one or more members of the team of appropriate discipline reviewing the changes being applied. This is the first step to spotting any unintended side effects that may occur with any given fix. The scrutiny of these reviews increase drastically with several more steps if the fix will go into an upcoming release.

[Merge request overview for Preventing Holy Orders from raising themselves in irrelevant wars]​

Merge requests have a template that must be filled in when filed. This process gives both the fixer and reviewer the chance to review the implications of a fix and whether or not to actually commit it to a particular version. We make a serious consideration on how risky a fix is, can the fix have unintended knockon effects and the like, and how it impacts the overall performance of the game, does the fix contain a lot of computationally heavy code or script that will degrade performance.

The golden rules of managing a merge request are:

Reviewer is right until proven wrong.
Discipline leads are always right.


Adding a fix to a build generally requires approval from the discipline lead, tech lead and another reviewer, and only the tech lead can actually merge the fix into the build when we’re getting close to release.

[The commit fixing the issue]​

The reviewer(s) give feedback on the merge request, and these must be addressed in one way or another. In the overview, you can see that the fix ended up being five commits in total, where just one of them was the fix itself. The rest were either addressing comments made in the review process or issues raised by the automated build and testing system, which we call pipelines. Speaking of pipelines.

[Pipeline for merge request]​

Pipelines verify the integrity and quality of the code, build the game and test the game while the review process is going. All of these must pass for the merge request to be allowed to merge, unless explicit permission is given from the programmers, and in the case of an upcoming release the pipelines must be green. No exceptions.

Once the fix has been merged, we hand it back over to the sadistic wonderful QA team.

[Happy tears from QA after a 2 year old issue was resolved]​

Once a ticket gets processed, churned through the complicated development machine, the issue is removed from the game, the correct code, script or asset gets merged into the game, the ticket is then marked as resolved.

This is when we get our hands on it one more time to verify if the fix has not only resolved the issue listed therein, but also that it has no other knock-on effects. Think of big fixes like a domino - you push one piece and the others will fall. Sometimes a different set of dominos, that we set up a long time ago, gets randomly pushed and some older issues reappear out of nowhere. It happens when you deal with a complex codebase, in which case you sometimes do see returning fan favorites.

But all we have to do is revisit the older system, fix it (again), and away we go! Unless yet another bug is retriggered, in which case… Well, we have to revisit yet another system. Videogames are hard, m’kay?

This is why we sometimes need to go through the same ticket again, and again, and again, until we are very sure it fixes more things than it breaks. Sometimes bugs linger in our database for a long time. Trust us - we know that issues you mentioned on release still persist and we want to fix everything, but with every release we get a new batch of tickets we have to go through…

So.
Many.
Times.
However, once the fix is confirmed, and the build is locked in - we are ready to press the large green button and release it for your scrutiny and repeat aforementioned hokey-pokey jig again!

The Update - Are we done yet?​
Not really. On our end we close the bug as resolved, but there is one last thing that comes into play on resolving a bug. This is all of you, the community. The QA team catches most of the problems before a release is made, but sometimes for an issue to reoccur, you need the stars to align on a laptop manufactured on 29th of February 2020 while the player is doing the Macarena.

Paraphrasing, of course, but there are cases where an issue can reemerge later. This can happen due to a myriad of factors that are hard to account for. Some issues can be related to hardware and specific circumstances we don’t have the capacity to test for. This is when we rely on you all to be vigilant and report issues back to us. The more detailed and specified, the better. Once this is done we go back from the top of this expose and do the dance one more time.

If no one in the community experiences the issue again, then it stays resolved.

I hope you all have enjoyed this little expose into the life of a game developer! Thank you for your time, and we wish you a very pleasant day.

Until next time!