[Duman]

Crusader Kings II geliştirici günlüklerinde bu hafta Magne "Meneth" Skjæran oyundaki bir hatanın çözüm sürecini anlatıyor.

Merhabalar, ben Magne Skjæran, CK2'de programcı olarak çalışıyorum. Geçmişte modlama, optimizasyon ve arayüz geliştirmeleri ile alakalı bazı geliştirici günlükleri yazmıştım. Aynı şekilde geçtiğimiz hafta sizlere CK2 ekibindeki pozisyonların yetki ve sorumluluklarından bahsetmiştim.

Yaz halen devam ediyor ve Temmuz'un sonuna kadar ekibimizin büyük bir kısmı tatil yapmaya devam edecek. Ancak her şeye rağmen şov devam etmeli, bu sebeple bu 4 hafta boyunca CK2 günlükleri yazma sorumluluğunu ben devraldım.

Ekibin büyük bir kısmının tatilde olması, oyun namına çok az geliştirme yaşandığı anlamına geliyor. Bu da bu 4 geliştirici günlüğünün önümüzdeki yama ve eklentiye dair pek fazla bilgi içerememesiyle sonuçlanıyor. Ancak umuyorum bu günlükler ilginizi çeker.

Bugün sizlere bir hatanın yaşam sürecinden bahsedeceğim, oyundaki hatalar nasıl keşfedilir, her aşamasında kim görev alır ve nihayetinde nasıl giderilir. Aynı zamanda bu günlüğün sonunda 2.8 yama notlarından 5 maddeyi sizlerle paylaşacağım.

Hata
Bu kısmı gözünüzde daha iyi canlandırabilmeniz için aşağıdaki hatayı kullanacağım:

• Bazı durumlarda rahiplerin evlenemediği dinlerde, rahiplerin evlenebilmesi veya nişanlanabilmesine sebep olan hata giderildi.
  

Bu hata 2.7.1 yamasında giderilmişti. Bu hata Papa'nın kutsal kan hayranı bir akrabasının ortaya çıkmasıyla ve Papa'nın bu akrabayla nişanlanmasıyla sonuçlanıyordu. Xwedodah her ne kadar önemli bir şey olsa da, bu spesifik olay her zaman gözyaşlarıyla sonuçlanıyordu. Papa'nın yeğeni evlenebilecek yaşa geldiğinde nişan otomatik olarak bozuluyordu.

İşin doğrusu bu hata gideriminin asıl hali "Papa'nın Xwedodah'ı çok sevip evlenemeyecek olmasına rağmen yeğeniyle nişanlanması hatası giderildi" şeklinde olmalıydı.

Keşif
Bu hata 12 Şubat 2017'de beta kullanıcılarımızdan biri tarafından keşfedildi. Papa'nın yeğeniyle evlendiği farkedildi ve bunu rapor eden kullanıcının bu olayın gerçekleşmesinden hemen önce alınmış bir kayıt dosyası vardı.

Beta kullanıcıları tarafından yapılan raporlar, bir hatanın keşfedilebileceği birçok yoldan sadece bir tanesi.

Playtesting: Kalite kontrol testerlarımız zamanlarının bir kısmını oyunu oynamaya ayırıyorlar. Ancak bu oynama kısmı genellikle test edilen hususa yönelik oluyor, örneğin Monks and Mystics eklentisiyle ilgili playtesting esnasında spesifik bir tarikata katılıp onun mekaniklerini deniyorlar. Bu test aşaması esnasında denk geldikleri hataları rapor ediyorlar, bazı denge problemlerini dile getiriyorlar vs. Geliştirilmenin hangi aşamasında olduğuna göre bunlar direkt bir şekilde de rapor edilebiliyor, ilgili mekaniği geliştirmiş kişiyle konuşulabiliyor vb.

Task verification: Herhangi bir task (yapılması gereken iş, örneğin zindandaki karakterler için toplu eylem mekanikleri) tamamlandığında kalite kontrol ekibi bu mekaniğin olması gerektiği gibi çalışıp çalışmadığını kontrol eder. Eğer bu esnada bir problemle karşılaşırlarsa task'ı tekrardan açarlar veya hata raporu yaparlar. 

Non-QA developers: Kalite kontrol dışı geliştiriciler de oyunu sürekli olarak oynuyor ve oyunda karşılaştıkları hataları rapor ediyorlar. Ancak hata bulmanın bu oyunlarda ana odak noktası olmadığını hatırlatalım.

Forum monitoring: Diğer yöntemlerde hatalar yama çıkarılmadan önce keşfedilmeye çalışılırken, kimi durumlarda çıkarılan yamalarda bazı sorunlar olabiliyor. Bu gibi durumlarda genellikle bu hatalar oyunu oynayan sıradan oyuncular tarafından farkediliyor ve bu oyuncuların bazıları forumlarda, reddit'te veya çeşitli mecralarda bundan bahsediyorlar. Kalite kontrol ekibimiz bu gibi yerleri takip ederek bahsedilen hatayı teyit etmeleri durumunda rapor oluşturuyor. Eğer bahsedilen hata, verilen bilgiler doğrultusunda teyit edilemezse bu kişilerden daha fazla bilgi vermesi isteniyor. Bu şekilde bir hata raporu ancak ve ancak hata kalite kontrol çalışanı tarafından teyit edildiyse veya çok sayıda kişi bu hatayı aldığını söylüyorsa rapor ediliyor. Bu sebeple oyundaki herhangi bir hatanın hızlıca giderilmesini istiyorsanız, bundan bahsettiğiniz konuda tam olarak bu hatanın nasıl ortaya çıktığını adımlarıyla anlattığınıza emin olun.

Rapor
Bir hata bulunduktan sonra bu hatanın rapor edilmesi gerekiyor. Raporlar için JIRA'yı kullanıyoruz, bu yazılım birçok meselede bize kolaylık sağlıyor.



Yukarıda az önce örneğini verdiğimiz Papalık hatasıyla alakalı raporu görebilirsiniz.

Bir raporda olması gereken ana hususlar şu şekilde:

Başlık: Meseleyi özetleyen bir başlık. Bu başlığın şu formatta olması gerekiyor: "Proje - Eklenti - Etkilenen Alan - Tanım". Bu örneğimizde başlık "CK2- MnM - AI - Papa kendi soyundan gelen birinin kızıyla nişanlanıyor". Başlık tek bir bakışta durumun ne olduğunu ifade ediyor olmalı.

Tanım: Tanıma başlığa sığmayan herhangi ayrıntılar dahil edilebilir. Bu kısım genellikle hatanın nasıl keşfedildiğini, neyin sebep olduğuna dair teorileri, hata raporu yapan kişi tarafından keşfedilmediyse bu hatanın keşif kaynağını vb. hususları içerir.

Teyit Adımları: Bu kısım belki de en önemli kısım, rapor edilen hatanın nasıl tekrardan görülebileceğini, teyit edilebileceğini içerir. Bu kısım olmadan bahsedilen bugla karşılaşmak çoğu zaman imkansızdır. Bir kere gerçekleşmiş olay bir daha gerçekleşmiyorsa bunu tespit etmesi çok zordur. Bu hem hatayı gideren kişi için, hem de hatanın giderildiğini teyit eden kişi için zorluk yaratır.

Sonuç: Sonuç kısmı 2 alt bölümden oluşuyor, hatanın sebep olduğu sonuç ve olması gereken sonu. Bu kısım genellikle diğerlerinden daha bariz bilgiler içeriyor, ancak özellikle denge sorunları gibi hususlarda bu kısım çok faydalı olabiliyor. Aynı zamanda işin teyit kısmında sorunun olması gerektiği gibi giderilip giderilmediği hususunda da önem sarfediyor.

Atama
Bir hata rapor edildikten sonra, bu hatanın giderilmesiyle kimin görevlendirildiği, kimin atandığı kısmı geliyor. Burada aynı zamanda bu raporun ne derece önceliğe sahip olduğu, ne zaman giderilmesi gerektiği kısımlar da mevcut. Atamalar hatanın kimin iş alanında olduğuna göre yapılıyor ve bu atama genellikle kalite kontrol elemanları tarafından gerçekleştiriliyor.

Bir hatanın önceliği bu hatanın giderilmesinin önemine göre belirleniyor, bu önem 0 (olabildiğince hızlı giderilmeli) ile 5 (öncelik taşımıyor) arasında değişiyor. Örneğin oyunun çökmesine sebep olan şeyler 1 (çözülmeli) iken Papa'nın nişanlanma hatası 3 (orta) seviye önceliğe sahipti. Proje şefi bu hata giderimlerinin öncelikleri hususunda son söze sahip oluyor ancak genellikle bunları kalite kontrol elemanları belirliyor diyebiliriz.

Aynı şekilde bir de hatanın şiddet seviyesi var, bu kısım hatanın önceliğinden ziyade, hatanın oyunu ne kadar etkilediğini belirliyor. Bu hususlar genellikle birbiriyle benzerlik taşısa da örneğin bir yerdeki imla hatası yüksek önceliğe sahipken düşük şiddete sahip olabiliyor. Bu kısım direkt olarak kalite kontrolcüler tarafından belirleniyor.

Bunların hepsinin ardından hatanın ne zaman giderileceğini belirlemek kalıyor. Bu kısım bu hatanın herhangi bir sprinte atanmasıyla belirleniyor, önemli hatalar ilerlemekte olan sprintin bir parçası haline getirilirken, daha az öneme sahip hatalar genelikle birkaç hafta sonra başlayacak olan sprint'e dahil ediliyor. Buradaki istisnai durumlar genellikle yeni mekaniklerle alakalı hatalar oluyor, onları olabildiğince hızlı gidermeye çalışıyoruz. Çünkü burada eski hataların giderilmemesinden ziyade listeye yeni hataların eklenmemesi de önem taşıyor. Tüm sprintlerin içerisinde son 4 haftanın sprintlerinin sonuncusu sadece hata giderimleriine ayrılıyor. İlk 3 haftada ise diğer meselelerde çalışılmasını engelleyebilecek hatalar gideriliyor.

Hatanın dahil edildiği sprinte gelindiğinde bu hata için spesifik bir görevlendirme yapılıyor. Bunu genellikle proje şefi yapsa da, az çok kimin neyle ilgileneceğini önceden kestirmeniz mümkün. 

Hata Giderimi
Sprintteki daha yüksek önceliğe bağlı şeylerle ilgilenilince sıra bu spesifik hatayı gidermeye gelir. Bir hatayla ilgili çalışmaya başlandığında o hatayı gidermekle görevli kişi Start Progress'e basar - böylelikle o hata üzerinde çalışmaya başlandığı herkes tarafından bilinir. 

Ardından bu hatayı giderecek kişi teyit adımlarını takip ederek hataya tam olarak neyin sebep olduğunu anlamaya çalışır. Papa örneğinde hata giderme sorumluluğu bendeydi ve teyit adımları kusursuz bir şekilde çalışıyordu. Böylelikle AI'ın evlilik mantığını gözden geçirip birinin Papayla evlenmesine sebep olacak anda durdurup kodu inceleyerek teokrasilerdeki evlenme koduna ulaştım. Görünüşe göre CanMarry fonksiyonu hiçbir zaman hedefin evlenmeye müsait olup olmadığını kontrol etmiyordu, evlilik etkileşimi ediyorud. Bu sebeple karakterler nişanlanabiliyorlardı, ancak evlenemiyorlardı.

Sonuç olarak CCharacter::CanMarry fonksiyonuna yeni bir kod eklememiz gerekti.

Kod:

if ( ( GetGovernment()->IsTheocracy() && !GetReligion()->CanPriestsMarry() ) || ( pCharacter->GetGovernment()->IsTheocracy() && !pCharacter->GetReligion()->CanPriestsMarry() ) )
       return false;

Bu yukarıdaki kod, nişanlanan karakterlerin rahiplerin evlenilmesine müsaade edilmeyen bir dinden olup olmadığını kontrol ediyor. Oyunda bu değişikliği yaptıktan sonra tekrardan save dosyasını açıp denedim ve Papa'nın bu sefer kimseyle nişanlanmadığını gördüm.

Hatayı giderdikten sonra yapmam gereken şey, yama notlarına ilgili değişiklikle ilgili madde girmekti. Hata giderimi ve yama notları halledildikten sonra oyunun beta sürümü geceyarısı otomatik olarak beta kullanıcılarımız tarafından test edilmek üzere güncelleniyor.

Ardından yapılan değişikliği belirtip hatayı Giderildi olarak işaretledim. Papalık raporu rapor oluşturulduktan 6 gün sonra çözüldü olarak işaretlendi, ancak bazı hatalar olur ki dakikalarda giderilir, bazıları ise aylar alır.

Teyit
Bunun ardından kalite kontrolcüler oyuna girerek hatanın gerçekten giderilip giderilmediğini, bu hatanın giderilmesi esnasında yapılan değişiklikler sonrasında oyunda başka problemler belirip belirmediğini kontrol eder.

Bunu yapmak için teyit adımlarını uygulayıp meselenin halen yaşanıp yaşanmadığını görmek, eğer komplike bir husussa başka bir şekilde gerçekleşebilip gerçekleşmediğini incelemek yeterlidir.

Kalite kontrolcüler sonucu yeterli bulduğunda hata raporu tam anlamıyla çözülmüş demektir ve çözülmüş raporu 'kapandı' olarak işaretlerler. Eğer sonradan herhangi bir sebepten ötürü aynı hatayla tekrardan karşılaşılırsa eski rapor tekrardan açılabilir.

Bazı durumlarda hatalar teyit sürecinden sonra dahi tekrardan görülebilmektedir. Papa raporu çözüldü işaretlendikten 45 gün sonra kapatılmıştı. Bu teyit sürecinin sprint süresinden daha uzun olmamasına gayret ediyoruz.

Çıkış
Hata rapor edildi, çözüldü ve çözüldüğü teyit edildi. Şimdi geriye kalan şey bu hata giderimini yamayla oyunculara sunmak.

Herhangi bir hata giderimi sonrası proje çıkış öncesi smoke test adını verdiğimiz bir süreçten geçiyor. Bu süreç nedir, desteklediğimiz 3 işletim sistemi olan Windows, Mac ve Linux'ta oyunun sıkıntısız çalışıp çalışmamasıdır. Diğer süreçlerden farklı olarak bunu CK2 ekibi değil, Paradox'un merkez kalite kontrol ekibi gerçekleştirir.

Merkez kalite kontrolcüler yamaya 'çıkabilir' izni verdikten sonra herhangi bir değişiklik yapılmaz, birkaç gün veya hafta sonrasında yama çıkarılır.

Özet
Tüm bu sistem hataların daha kolay bulunabilmesi ve bulunduktan sonra çözüldüğünde çözülmüş kalmasını amaçlar. Buna rağmen CK2'nin komplike yapısından dolayı oyun çok sayıda bugla çıkabilmektedir. Aynı zamanda her yamada varlığı bilinen hatalar olabilmektedir, kimi zaman bir hatayı çözmek oyunda başka bir hatanın belirmesiyle sonuçlanabilir. Bu hataları çıkış öncesi minimize etmeye gayret gösteriyoruz ancak her zaman hatalar olacak ve biz bu hataları gidermek için çalışmaya devam edeceğiz. 

Umuyoruz ki CK2'de hataları giderme sürecimizi anlattığımız bu günlüğü ilgi çekici bulmuşsunuzdur.

Şimdi söz verdiğimiz üzere aşağıda 2.8 yamasından rastgele 5 maddeyi görebilirsiniz.

• Yapayzeka artık yazmayı öğrendi, artık "societies" görevleri yerine oyuncuya "soceities" görevleri vermiyor. Bu yeni özelliğiyle birlikte yapayzeka artık görev verilebilecek karakterleri daha iyi tespit ediyor.
  
• Konsey görüşünü görmenin hükümdarın favorlarını kaale almaması problemi giderildi.
  
• Manichean dini için kutsal tarikat eklendi.
  
• Guardianlar artık doğum itibariyle atanabiliyor. (ancak 6 yaşına kadar herhangi bir etkisi yok)
  
• Yapayzeka artık oyun ayarlarından bu durum yasaklanmışsa, matrilineal evlilik edinmek için uğraşmaya çalışmıyor.
  

Bu haftalık bu kadar, haftaya sizlere 2.8 yamasıyla birlikte modlamada yaptığımız geliştirmelerden sözedeceğiz.