Crusader Kings III geliştirici günlüklerinde bu yazıda bir hatanın raporlanmasından çözülmesine kadar olan süreç anlatılıyor.

Herkese merhabalar, bendeniz jakeowaty, Crusader Kings 3’ün QA şefiyim, PDXOxycoon ile birlikte bugün sizlere oyunda bir hata ile karşılaşıldığında, raporlamayla çözüm arasındaki süreçten bahsedeceğiz.

Hata Raporlama Bölümü

Elinizde sıcak bir içecek, birkaç saatliğine ortaçağdaki krallığınıza hükmetmek için oyunu açtığınızda arkaplanda çok sayıda işlem gerçekleşmeye başlıyor ve bu işlemlerin herhangi bir sorun yaşanmadan gerçekleşmesi, Crusader Kings 3 gibi fazlasıyla komplike bir oyunda daha büyük bir önem sarfediyor. Oyuna yeni mekanikler eklendikçe oyun daha komplike hale geliyor ve ekonomi, yapay zeka, savaş ve etkileşimler arasında dengeyi daha iyi sağlamak, yeni içeriğin her zaman beklemeye değecek bir içerik olmasını sağlamak gerekiyor.

Bizim işimiz neyin çalışıp neyin çalışmadığını anlamak, oyun sizin elinize ulaşmadan evvel sıkıntılı kısımları geliştirici ekibine raporlamak. Bazı hatalar siz ne kadar uğraşırsanız uğraşın oyuncunun eline gelene kadar gizli kalabiliyor, işte burada devreye siz giriyorsunuz. Biz, siz onlardan haberdar dahi olmadan ciddi, büyük hataları ortadan kaldırıyoruz. Farklı sistemler, diller, tecrübeler ve oynanış biçimleriyle bizim en büyük yardımcımız sizsiniz, bunun için de forumda Hata Raporlama Bölümüne sahibiz. Bu bölüm aracılığıyla yorumlarınızı bizlerle paylaşabilir, karşılaştığınız hatanın nasıl tekrar tetiklenebileceğine dair bilgiler verebilirsiniz. Bunu yaptığınızda QA ekibi çok daha verimli bir şekilde çalışabilir ve bir sonraki hata giderim güncellemesinde daha fazla hatanın ortadan giderilmesini sağlayabilir.

Teyit

Zaman ayırıp bir hata raporunda bulunduktan sonra, QA ekibi forumlarda dolaşarak kendi bilgisayarlarında mevzubahis hatayı teyit etmeye çalışıyorlar, kimi durumlarda bu hatalardan nasıl kaçınılabileceğine dair önerilerde bulunabiliyoruz. Sağladığınzı adımları, ekran görüntülerini vb. unsurlar sayesinde raporu teyit ettikten sonra ekibimizin anlayabileceği bir dile bunu çeviriyoruz, Jira’ya.

Jira kullanması inanılmaz faydalı bir araç, doğal olarak QA ekibi de Jira’yı etkili bir şekilde kullanabiliyor. Genellilke proje bazlı analizleri, eskimiş raporların kapatılması gibi eğlenceli işleri QA üstleniyor. Evet, yıllardır çözülmeyen ve topluluk tarafından dahi belki de fark edilmeyen bazı hataları kimi zaman özellik varsayabiliyoruz veya sistemler bu süre zarfında değiştiği için artık hata olarak görülmeyebiliyor. Kimi zaman o kadar uzun süredir oyuna etki eden bazı hataların oyuncular tarafından fark edilmediğini gördüğümüzde şaşırabiliyoruz.

Ekran görüntüsü korkutucu gelebilir ancak korkulacak bir şey yok. Ekibin Jira raporlarını verimli bir şekilde kullanması için uzun süredir çaba sarfediyoruz. Örneğin “dün konuştuğumuz şu şeyi düzeltin” diye bir rapor gelirse, bunu hatırlamamız ve gidip testini yapmamız zor olacaktır. Bir ay sonrasına gittiğimizde kimse bu şekilde tanıma sahip bir raporun neden bahsettiğine dair en ufak bir fikre sahip olmayacaktır.

Bu sebeple her alanın düzgün bir şekilde doldurulması gerekiyor, ek olarak hata raporu bölümündeki oylar hataların önceliğini belirleyebilmemizi sağlıyor.

Bahtsız Tasarımcı

Bir hata teyit edilip, Jira’ya aktarıldıktan ve önceliği belirlendikten sonra herhangi bir geliştirici hatayı gidermek için işe koyulabilir. Bu kişi genellikle bir programcı veya tasarımcı olacaktır. Kimi zaman hatanın başka sebeplerden kaynaklanması durumunda farklı bir roldeki kişi devreye girebilir. Hatanın varlığını kanıtladıktan sonra, neden varolduğunu anlamamız gerekiyor.

Yakın zamanda Kutsal Tarikatların savaşa çağrıldıklarında kendi kendilerine toplanıp kendi kendilerini terhis ettikleri bir hata vardı. Bunun sebebi, Kutsal Tarikatların müttefik olarak Büyük Kutsal Savaşlara katıldıklarında kendi ordularını toplayabilmesiydi, yani buradaki problem Tarikatların ordularını toplaması değil, topladıktan hemen sonra terhis etmeleriydi. İlk olarak bunu neden yaptıklarını anlamaya çalıştık.

Debug mod ve kaynak kodları üzerinden her fonksiyonu izleyip tam olarak ne yaşandığını anlayabiliyoruz. Bu şekilde Tarikatların girdikleri savaşın onlar için bir anlam ifade etmediğini, dolayısıyla otomatik olarak orduları topladıktan sonra gereksiz buldukları için terhis ettiklerini gördük. Düşmanlarına baktığımızda hiçbiri düşmancıl bir Mezhebe mensup değildi, aynı zamanda Tarikat Lideri tarafından toplandıkları da görünüyordu, yani başka bir karakter onları kiralamıyordu.

Bu şekilde asıl hatanın Tarikatların kendilerini terhis etmesinde değil, Tarikatların toplanma koşullarında olduğunu anladık.

Yapay zeka kodlarına çok fazla girmeyeceğim fakat özetlemek gerekirse, mevcut işleyiş “eğer Kutsal Tarikat toplanabiliyorsa, topla” şeklindeydi. Bu sebeple Tarikatların, toplanamayacakları senaryoda neden toplanabilir olduklarını anlamamız gerekti.

Burası bir Tarikatın bir karakter tarafından kiralanıp kiralanamayacağını belirliyor. Bu durum Tarikat Lideri olan karakter için de geçerli.

Bir Kutsal Tarikat kendi başına savaşa katıldığında, pCharacter’in Tarikat Lideri olduğu görülüyor. Ancak biraz aşağıda, karakterin kendisini ilgilendiren bir savaşta yeralıp yeralmadığına dair bir kontrol kodu bulunuyor. Bu kod, biraz evvel ordunun terhis olmasına sebep olan kodun ta kendisi.

Kutsal Tarikatın Tarikat Lideri tarafından kiralanıp kiralanamayacağına dair olan koda geri dönüyoruz.

Basitçe anlatabilmek için tüm “eğer”leri bir araya topladım. Kira limitiyle ilgili bir sıkıntımız yok, zira Tarikat Lideri olarak gidip başka bir Kutsal Tarikatı toplamıyoruz. Halihazırda başkası tarafından kiralanmış değiliz, orada da sıkıntı yok. Üçüncü “eğer”de hiç sıkıntı yok zaten Tarikat bizim, en son “eğer” ise Tarikatın maliyetini karşılayıp karşılayamayacağımız.

Mesele şuna geliyor, eğer kendi Kutsal Tarikatımıza sahipsek, her zaman kullanabiliyoruz ancak bu sebeple savaşın bizim için makul olup olmadığına bakmıyoruz. Bunun için de basit bir çözümümüz var.

Savaşın makul olup olmadığının kontrolü sadece Tarikat Lideri için esgeçiliyor, Tarikat Liderinin mezhebini kontrol etmek gibi bir derdimiz de yok. Bu sebeple geriye sadece bu kod kalıyor, eğer Tarikatı kiralamak isteyen kişi Tarikatın Lideriyse, savaşın mantıklı bir savaş olup olmadığını kontrol et.

Birleşim Süreci

Hata giderildikten sonra, değişikliğin ana sürümle birleştirilmesi için bir talepte bulunuyoruz. Birleşim öncesinde, ilgili disipline mensup arkadaşlar değişiklikleri kontrol edebilir, inceleyebilir, herhangi bir yan etkisi olup olmadığını belirleyebilir. Bu denetleme süreci, mevzubahis hata giderimi oyunun bir sonraki büyük güncellemesiyle birlikte paylaşılacaksa çok daha titiz olur.

Birleşim taleplerinin riayet edilmesi gereken bir şablonu vardır. Bu şablon, hem hatayı giderenin hem de hata gideriminin sebep olabileceği yan etkileri denetleyen kişinin olayı daha iyi anlamasını sağlar. Hata gideriminin nasıl bir risk taşıdığını belirleyip, oyunun performansını zedelemesi gibi hususlardan bahsetmemiz gerekir.

Birleşim taleplerinin altın kuralları aşağıdaki gibidir.

1. Denetmen yanlış olduğu kanıtlanmadıkça doğrudur.
2. Kısım şefleri her zaman haklıdır.

Bir hata giderimini sürüme dahil etmek genellikle bir kısım şefinin onayına tabiidir. Ardından teknik şef, çıkışa yakın bir zamanda hata giderimini sürüme dahil eder.

Denetmenler birleşim talebine dair yorumlarda bulunabilir, aşağıda hatanın toplamda 5 değişiklik ile giderildiğini görüyorsunuz fakat bunlardan sadece 1 tanesi hatayı asıl gideren değişiklikti, diğerleri denetim süresince yazılan yorumlar doğrultusunda yapılan diğer değişiklikler ve otomatik build/test sistemimiz tarafından verilen uyarılara yönelikti.

Veri hatları, kodun bütünlüğünü ve kalitesini kontrol eder, denetim süreci devam ederken testler yapar. Bunların hepsinin ana sürüme dahil edilebilmesi için birleşim talebinden geçmesi gerekir. Hata giderildikten sonra iş QA ekibimize kalır.

QA Teyiti

Raporu aldık, geliştirme makinamıza yükledik, oyundaki hatayı giderdik, ardından birleşim talebi yolladık ve sürüme dahil ettik. Artık raporu “ÇÖZÜLDÜ” olarak işaretleyebiliriz.

Burada çözümün mevzubahis hatayı gidermek yerine, çeşitli yan etkilere sahip olup olmadığını tekrar kontrol ediyoruz. Büyük hata giderimlerini domino gibi düşünebilirsiniz, bir hatayı giderdiğinizde diğerleri de düşmeye başlar. Uzun zaman önce dizdiğiniz dominoların rastgele bir şekilde devrilmeye başladığını, giderildiğini zannettiğiniz bazı eski hataların yeniden günyüzüne çıktığını görebilirsiniz. Fazlasıyla komplike bir kod tabanıyla muhatap olduğunuzda bu gibi işler kaçınılmaz.

Bunun için yapmamız gereken şey eski sisteme geri dönüp, tekrardan hatayı gidermek. Eğer hata bir şekilde yeniden tetikleniyorsa, bu sefer başka bir sistemi değiştirmeniz gerekebilir.

Tam olarak bu sebeple, aynı rapora defalarca uğrayıp, raporla bağlantılı değişikliklerin kırdığından çok düzelttiğinden emin olmaya çalışıyoruz. Kimi zaman hatalar sistemde çko uzun süre kalabiliyor, sizlerin de bahsettiği hataların oyunda olduğunu biliyoruz ancak her çıkışla birlikte yeni raporlarla mücadele ediyoruz.

Hata giderimi teyit edildikten sonra, büyükçe bir yeşil butona basıp güncellemeyi çıkartıyoruz.

Güncelleme

Daha bitmedi. Hatayı gidermiş olsak da, bir hatanın giderilmesinde önemli bir faktör daha var: topluluk. QA ekibi sürüm çıkmadan birçok hatayı bulup ortadan kaldırıyor ancak bazı hataların tetiklenebilmesi için nadir rastlanabilecek unsurların denk gelmesi gerekebiliyor, örneğin 29 Şubat 2020’de üretilmiş bir laptopta oyunu oynarken, bir yandan Macarena yapmak gibi.

İşin özeti, bazı hatalar çok uzun süre sonra tekrardan meydana gelebiliyor. Örneğin bazı hatalar donanımla ilgili olabiliyor, test edemeyeceğimiz spesifik şartlar altında gerçekleşebiliyor. İşte burada devreye siz giriyorsunuz ve bize raporlar göndererek işimizi yapabilmemizi sağlıyorsunuz. Bu raporlar ne kadar detaylı olursa bizim için o kadar iyi.

Eğer toplulukta kimse mevzubahis hatayla karşılaşmıyorsa, sorunun çözülmüş olduğunu anlıyoruz.

Oyun geliştiriciliğine dair bu anlatıdan memnun kaldığınızı umuyorum. Sonraki günlükte görüşmek üzere.