Jira for Some Reason the Magic Didn t Happen Create to Try Again
Hello, everyone, and welcome back the Dev Diary. Let's take a little talk about the Anatomy of a Game (Development)! I'll be your host for today, @jakeowaty, electric current QA Lead on Crusader Kings three, and I'yard joined by Elisabeth, known as @PDXOxycoon in these hither parts - a wonderful developer, a gentlewoman and a scholar, who you may have seen a few times already! (Eastditor'due south note: Can I mention the raw onion story?)
Today we are hither to tell you about the process a bug goes through from existence reported to being resolved and put into an update. Grab yourself the beverage of your choice, and enjoy this little expose on how we get almost resolving bugs on Crusader Kings three!
Bug study forum
Whenever you launch the game, become 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 brand it a memorable experience, free from issues. For a game every bit complex as Crusader Kings three, this is even more of import, and equally the features get added to the game, it becomes more than and more complicated, like a careful balancing human activity between economy, AI, warfare, interactions - all to ensure the feel yous receive in the newest update is something worth waiting for!
We are just a few humble people, whose job is to find out what works and what doesn't and study whatsoever and all issues to the team earlier the game hits your platform of choice. Simply what happens when sometimes issues do remain hidden away and they volition take spitting behind your shoulder 3 times on a tertiary 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 assistance! We tin can get rid of serious, big issues, find them ahead of time before yous even realize they existed in the starting time identify, and try and evangelize a polished production. For anything else - well, it's the economy of scale. With the multifariousness of systems, languages, experiences, playstyles - You lot are the biggest help of all, in how a game tin exist shaped. And for that we have a special platform, called Issues Study Forum, where you tin can air out your grievances, provide feedback, reproduction steps and situations that irk you on the constant, so that our QA squad can go through them much more than efficiently and supply the team with a steady stream of new bugs to iron out for the next bug set up patch or release.
Verification
[Comic on logging]
One time you lot take your valuable time to written report the issue that ruins your mojo when playing Crusader Kings, information technology lands on our Forum equally a thread. Nosotros 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 maybe we tin can offer support by providing advice on how to avoid it.
Once the ticket is verified internally, using your reproduction steps, your clarification, screenshots, crash logs and saves, we then take the time to translate it into a language that our internal squad 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 proficient at using information technology skillfully. It's usually the QA who does project-wide database evaluations, scrubbing information technology from obsolete tickets and updating any and all lingering ones to make sure the projection team tin can focus on what'south important - making more fun stuff!
Wait… Obsolete? You mean you just CLOSE old tickets?
We do… sometimes. For example, if we had an effect lingering around in some subconscious abroad system for a long fourth dimension (and sometimes non even you, our customs, are able to find it for years on finish) - the issue becomes obsolete - either we just make the bug into a characteristic, or considering we change a system entirely - it becomes changed then it's not fifty-fifty a trouble anymore. Happens on occasion, and even we are quite surprised that some bugs that linger for long never go picked up by the players, only hey - bugs are features besides! Right?
Riiiiiiiiiight…?
Jira - or how I learned to end worrying about my mental health and learned to comprehend the madness
[Excerpt from "How to JIRA" guide]
At present that might look like a lot, but trust me - there's a fashion to learn this. Get-go of all, information technology's pretty straight forward; circuitous, but not complicated. We have been campaigning for the squad to use Jira tickets efficiently. For example, if nosotros get a ticket that says "Fix the thing we talked nearly yesterday" and there is nothing else in it, how tin we remember what we have done, what needs to be washed and how do we go back to it to retest? And over again - fast-forrad time to a calendar month afterwards and believe me - nobody will remember what in the globe such a ticket meant.
Every bit a effect, making certain all the fields are appropriately filled out is paramount to an efficient employ of the database, and to make our squad's lives but a little bit easier when having to deal with a large pile of bugs that come from you lot or from our internal reporting.
If everything is sorted, and anybody is on the same folio, 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'south how nosotros tin can influence what is important to exist fixed offset.
[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 tin pick the problems 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 institute to be acquired in another part of the game. Now that we know what the issue is and how it's experienced, nosotros need to investigate the how and why information technology happens.
As an instance 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 upshot of letting Holy Orders raise themselves for Peachy Holy Wars: whenever a Holy Order is at war equally an marry (which they authorize as during the Great Holy Wars), they would raise their armies.
We start past looking at why the Club is disbanding the armies. If they're raised, they must have something to fight against, correct?
[Code controlling if a order's armies should be disbanded]
Through developer magic known as debug mode and source code, we can pace through each individual function call to meet what'due south going on. Stepping through this function leads united states of america 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. Nosotros besides see that they are hired by the Grandmaster of the Order, so the Order itself decided to raise their armies, not some other character hiring them.
Holy Orders will not fight in wars where the opposing side does not take any participants of hostile Organized religion. Because we found the Holy Social club disbanding due to being raised confronting an irrelevant enemy, nosotros must look at the logic which controls how they are raised.
I will spare you the initial dig down the AI code, simply the short of it is: if a Holy Gild tin can be raised, raise it. Then nosotros need to encounter why the Holy Order can be raised when information technology clearly should non be able to. We arrive at the post-obit function.
[Code to check the Holy Order can be hired by a Graphic symbol]
This logic checks if the Guild can be hired by a grapheme. This goes for whatever graphic symbol looking to apply the Guild in question, even the Grandmaster of the Lodge. The Grandmaster of the Order is part of the war, and then let us see where information technology leads the states. Starting from the superlative, we check if the character can utilise the Club. Permit us take a look at how that goes.
[Lawmaking to bank check if a character tin use the Holy Guild]
This is the code that checks if a character tin can use a Holy Gild. When the Holy Gild 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 brand use of his own Holy Club. Merely, make notice further down: there is a check there, verifying if the character is in a relevant state of war. This is the same function that caused the army to disband earlier.
Returning back to the office which checks if a Holy Order tin be hired by our Grandmaster.
[Lawmaking to check the Holy Order tin can exist hired past a Character 2]
To simplify things, I take complanate all the irrelevant parts; contained within each "if" department is something which will cause the function to fail, and not allow the Grandmaster to rent their own Lodge. Permit'south get through these relevant parts. We don't run afoul with the hire limit, every bit we don't hire whatsoever other Holy Orders as the Grandmaster of one. We are non already hired by someone else, then we skip that part. We ain this lodge, and then we don't impact the tertiary "if" statement. Finally, nosotros can afford to hire our ain Order. Look at that, this ways we tin can hire the Holy Lodge!
But returning back to the finding that the Holy Social club would immediately disband considering nosotros're not in a relevant war. This is where we discover our solution: if nosotros own our ain Holy Order, we can always utilize it, but considering of this we will not look if the war nosotros are in is relevant at all. So we have a very simple solution to the problem.
[Solution to preventing the Holy Gild from being raised]
Nosotros know that the check for relevant wars is only skipped if we are the Grandmaster of the Gild, we don't demand to cheque the faith of our own Grandmaster, then this is what we're left with: if the i who wants to hire the Holy Gild is the Owner of the Order, check if they are in a relevant war or non.
The merge request process - everyone judges you
When the fix has been created, it is put into what is chosen the merge request; this is the step before the fix is put into the upcoming build. Before information technology gets merged, there are a agglomeration of steps. It starts with 1 or more members of the team of advisable discipline reviewing the changes beingness applied. This is the first step to spotting any unintended side effects that may occur with any given prepare. The scrutiny of these reviews increase drastically with several more than steps if the set 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 set and whether or not to actually commit it to a detail version. We make a serious consideration on how risky a set up is, can the set up have unintended knockon effects and the like, and how it impacts the overall operation of the game, does the fix contain a lot of computationally heavy lawmaking or script that will dethrone operation.
The golden rules of managing a merge request are:
- Reviewer is right until proven wrong.
- Subject field leads are always right.
Adding a set up to a build generally requires approval from the bailiwick atomic number 82, tech atomic number 82 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 asking, and these must be addressed in one way or some other. In the overview, y'all can see that the prepare ended up being five commits in full, where but i of them was the fix itself. The residual were either addressing comments fabricated in the review procedure or issues raised by the automatic build and testing system, which we call pipelines. Speaking of pipelines.
[Pipeline for merge asking]
Pipelines verify the integrity and quality of the code, build the game and test the game while the review procedure is going. All of these must pass for the merge asking to be allowed to merge, unless explicit permission is given from the programmers, and in the case of an upcoming release the pipelines must exist light-green. No exceptions.
One time the ready has been merged, we hand information technology back over to the sadistic wonderful QA team.
The (sadistic) QA verification - where QA asks the fixer: "why are you lot running?!"
[Happy tears from QA after a 2 year old issue was resolved]
In one case a ticket gets candy, churned through the complicated evolution machine, the issue is removed from the game, the correct code, script or asset gets merged into the game, the ticket is and then marked as resolved.
This is when we get our easily on it one more time to verify if the fix has not only resolved the upshot listed therein, but also that it has no other knock-on effects. Think of large fixes like a domino - y'all push ane piece and the others will fall. Sometimes a different set of dominos, that we set up 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 instance you lot sometimes do see returning fan favorites.
Simply all we have to exercise is revisit the older system, fix it (once more), and away nosotros go! Unless yet some other bug is retriggered, in which case… Well, we have to revisit yet another system. Videogames are hard, 1000'kay?
This is why we sometimes need to become through the same ticket once again, and again, and again, until nosotros are very sure it fixes more things than it breaks. Sometimes bugs linger in our database for a long time. Trust united states of america - we know that problems yous mentioned on release still persist and we want to ready everything, but with every release nosotros get a new batch of tickets nosotros accept to go through…
And then.
Many.
Times.
However, once the set is confirmed, and the build is locked in - nosotros are ready to press the big green push button and release it for your scrutiny and repeat same hokey-pokey jig again!
The Update - Are we washed nevertheless?
Not actually. On our end we close the bug as resolved, but there is 1 concluding thing that comes into play on resolving a issues. This is all of you, the community. The QA team catches most of the problems earlier a release is made, but sometimes for an issue to reoccur, you lot demand the stars to align on a laptop manufactured on 29th of Feb 2022 while the actor is doing the Macarena.
Paraphrasing, of form, just at that place are cases where an consequence can reemerge later. This can happen due to a myriad of factors that are hard to business relationship for. Some issues can exist 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 than detailed and specified, the better. Once this is washed we get back from the top of this expose and exercise the dance 1 more fourth dimension.
If no one in the community experiences the result again, then it stays resolved.
I hope you lot all take enjoyed this little expose into the life of a game developer! Thank y'all for your time, and we wish yous a very pleasant twenty-four hour period.
Until next fourth dimension!
Source: https://forum.paradoxplaza.com/forum/developer-diary/ck3-dev-diary-92-anatomy-of-a-game-from-report-to-resolution.1518991/
0 Response to "Jira for Some Reason the Magic Didn t Happen Create to Try Again"
Post a Comment