Anno 1800 geliştirici günlüklerinde bu yazıda oyunun kalite kontrol sürecinden bahsediliyor.

Merhaba, benim adım Dorina ve Anno 1800 kalite kontrol ekibinin başıyım. 13 yıldır oyunlarda çalışıyorum, Anno 1701’de asistan olarak başladım ve birkaç yıl sonra kalıcı bir pozisyona yerleşip Anno 2070’te çalıştım. Anno 1800 kalite kontrol ekibine liderlik etmek gerçekten onur verici bir şey ve umarım bu günlük size kalite kontrolün farklı alanlardaki görevleri konusunda ilginç bir bakış açısı sunacak.

Oyunları test etme ve kalite kontrol konusuna geldiğimizde çoğu oyuncunun belli bir fikri olduğunu ve bu fikirlerini oldukça dile getirmek istediklerini görüyoruz. Eğer oynadığınız bir oyunda bugları bulabiliyorsanız bunları düzeltmek o kadar da zor olmamalı değil mi?

Bugün Anno 1800 kalite kontrol takımı hakkında konuşmak ve sizleri günlük işlerimizin sahne arkasına davet etmek istiyorum. Böylece oyun test etmenin ve oyun geliştirmenin karmaşık doğasını daha iyi görebileceksiniz.

Tüm Gün Oyun Oynamak

Kalite kontrolde çalışınca tüm gün oyun oynadığımıza dair bir inanç var, oyun test etmek işin bir parçası olsa da gerçek daha da farklı. Hatta oyunun durumunu ve bazı işlevlerini kontrol etmek için tüm gün oyun oynamak sadece arada sırada olan bir şey. Günlük işlerimiz oyunun belli bir yanını test edip kalitesini değerlendirmek veya bildirilen sorunları incelemekten oluşan belirli görevlerden oluşuyor. Karmaşık bir iştir çünkü durumu tekrar yaratmak zor olabilir ve sorunun nedenleriyle etkileri arasında hiçbir bağlantı yok gibi gözükebilir. Her yeni oyun geliştirme aşamasında test etmemiz gereken, özellikleri içeren geniş bir liste alıyoruz. Bu konuda ekibimizin içindeki ve ayrıca eklenen özelliklerin sorumlularıyla olan işbirliği oldukça önemli.

Kalite kontrol ekibimizin masaları stüdyonun tam ortasında yer alıyor çünkü oyunun tamamını gözden geçiren bir ekip olduğumuz için oyun yapımının merkez noktalarından biriyiz. Böylece diğer ekiplerle de iyi bağlantılar kurabiliyoruz, bir bakıma göz kulak oluyoruz. İnsanlar ayrıca masalarına geldiğimizde biraz tedirgin oluyor çünkü bu büyük ihtimalle ekledikleri özelliklerin bozuk olduğu anlamına geliyor.

Dedektif ve El Kitabı

İncelemeye başladığımızda, analitik becerilerimiz, tecrübemiz ve oyun yapımının çeşitli yönleri hakkındaki bilgimiz bizim ana silahımız oluyor. Bir durumu incelerken baktığımız detaylı dizayn belgesi kalite kontrolün el kitabıdır. Oyunu test ederken veya sorunları analiz ederken her zaman bunlar doğru çalışıyor mu diye bu belgeye başvururuz. Oyundaki her şeyin işlevini içerdiği için iki farklı tür test yaratmamıza izin veriyor: doğru çalışıyor mu diye baktıklarımız ve bilerek bozmaya çalıştıklarımız. Daha sonra tüm bilgileri geribildirim raporuna koyup ilgili geliştiriciye teslim ediyoruz.

Önceki günlükte bahsettiğimiz ticaret yollarına bakarsak bu belge o özelliği ve altında yatan tüm sistemleri ayrıntılarıyla anlatıyor, gemilerin ticaret yollarına nasıl eklendiğinin yanında menünün ve arayüzün nasıl çalışması gerektiği, ilgili sesler, yazılar, tuşlar vb. Bu özelliği test ederken her şeyin doğru çalıştığından emin olmak için kontrol listesinde sırayla ilerliyoruz. Bir bug düzeltildiği zaman düzeltilince başka şeyleri bozdu mu diye de daha fazla kontrol ediyoruz.

Sadece her şeyin düzgün çalıştığıyla ilgili veya gizli buglar var mı diye testler yapmıyoruz, üretim zincirlerinden savaşların zorluğuna kadar oyun dengesinde de yardım ediyoruz. Doğru çalışıyor mu ve yeterince kompleks mi (bazen de çok mu kompleks) diye hep sormamız gerekiyor.

Bir görev çok nadiren bir günde bitiyor çünkü geribildirim raporları ve sorumlu geliştiricilerle tartışmaları da içeriyor. Sorumlu kişi geribildirime göre özelliği değiştirdiğinde test aşaması tekrar başlıyor.

Bug Avına Çıkmak

Test sürecinde bir bug bulursak bunu bug takip etme aracımızla takip edip sorumlu geliştiriciye gönderiyoruz. Daha önce de bahsedildiği gibi sorun giderilene kadar test etme ve geribildirim döngüsü başlıyor.

“Hiçbir savaş planı düşmanla ilk çatışmadan kurtulmaz” lafını biliyor musunuz? Bugları test ederken ve düzeltirken bu düzeltme başka şeyleri bozabiliyor. Çoğu zaman engelleyen şeyin nerede olduğunu bilmiyoruz, bu yüzden ilk önce neyin sorun açtığını bulmamız gerekiyor.

Bir sorunu düzeltmenin başka bir soruna yol açtığını açıklamaya çalıştığımda kelebek etkisinden bahsetmeyi seviyorum, her kanat çırpma beklenmedik bir şeye yol açabilir. Bu yüzden bir güncelleme çıkarmadan önce oyunu en baştan tekrar test etmemiz gerekiyor ki başka bir şey bozulmuş olmasın.

Bu süreç görevden göreve değişir ve oyunu karmaşık doğasının bir parçasıdır. Buglar oyun yapımı sırasında ortaya çıkar ve bunların herhangi bir şeyi engellemediğinden emin olmamız gerekiyor çünkü bir bugu düzeltmek kodlama ekibimizin saatlerini alabilir.

Oyunu Daha İyi Yapmak

İşimizin bug test etmeye ve düzeltmeye bağlı olmayan başka bir yanı da vardır. Detaylı dizayn belgesiyle birlikte oyunu incelerken eksik bir şeyle veya oynayışla ilgili sorun çıkaran bir şeyle karşılaşabiliriz. Bu olursa neyin eksik olduğu veya neyin değiştirilebileceği konusunda önerilerimizi içeren bir rapor hazırlarız. Bu yüzden ekibimizin sahip olduğu bilgiler ayırt edici bir faktördür, hepimizin farklı tecrübe seviyelerine sahip farklı tür oyuncular olmamız da buna etki eder. Bu çeşitlilik önemli bir faktördür, böylece oyunu olabildiğince farklı bakış açılarından inceleyebiliriz.

Peki ya siz?

Umarım bu günlük oyun test etmenin karmaşık doğasını sizlere güzelce açıklamıştır. Test aşamasının oyundaki her farklı yanı etkilediğini unutmayın. Kalite kontrolde çalışmak heves, hırs ve üzerinde çalıştığınız oyunun yanında tüm oyunların genelinde derin bilgiye sahip olmak gerektirir.