World of Warcraft: Classic’in unutulmaz etkinliği Ahn’Qiraj War Effort’un arkaplanına oyun mühendislerinin gözünden bakıyoruz.

Savaş kapımızda. Bu ayın başlarında, World of Warcraft: Classic’in en çok beklenen etkinliklerinden biri olan Ahn’Qiraj War Effort başladı. Tüm Classic realmleri—Horde ve Alliance’ın birleşik gücü—bir araya gelerek kapıları açmak ve Ahn’Qiraj raidlerinin kilidini açmak için kaynaklara katkıda bulundu. 2006 yılında War of the Shifting Sands ilk (ve tek) kez gerçekleştiğinde, her realmden binlerce oyuncu kaosa katılmak ya da tanıklık etmek için Silithus’a uçtu ya da toynak attı. Katılım, geliştirme ekibinin en çılgın hayallerinin de ötesindeydi ve basitçe ifade etmek gerekirse, buna hazırlıklı değildik. Sunucular hızla aşırı yüklendi, mühendislerimiz sorunları düzeltmeyle ve oyuncuları yeniden bağlamayla uğraşırken birçok oyuncu 12 saatlik bir süre boyunca giriş yapma, bağlantı kesilmesi ve yeniden bağlanma döngüsüne girdi. Etkinlik sırasında sunucuları stabilize etmeyi başardık ve epeyce ders aldık, daha iyisini yapma fırsatları gördük. On beş yıl sonra, gecikme ile mücadele etmek ve sunucu çökmelerini ortadan kaldırmak için sunucu optimizasyonuna odaklanarak Silithus’taki etkinliğin 2006’da ilk yayınlanmasına kıyasla iki kat daha fazla oyuncuya ev sahipliği yaparken WoW Classic için WoW tarihindeki en destansı anlardan birini yeniden yaratmaya hazırdık.

Bu makalede, WoW Classic oynayış deneyimini korurken; kırılma noktalarını belirlemek ve optimizasyon çözümleri geliştirmek için otomatikleştirilmiş oyuncuları ve stres testlerini nasıl kullandığımızı gözden geçirerek bu heyecanla beklenen etkinliği nasıl yeniden oluşturabildiğimiz konusunda, donanımın çözemediği sorunları çözmek için yazılımda nasıl çözümler ürettiğimiz konusunda ve en az sunucu çökmeleriyle küresel bir olayı nasıl organize ettiğimiz konusunda size yol göstereceğiz.

War of the Shifting Sands’i Yeniden Yaratmak

Bu etkinliği nasıl tasarlamamız gerektiğine yaklaşırken aklımızda üç özel hedef vardı: Zincirleme çökmeleri önlemek, beklenen bölge oyuncu limitlerini arttırmak ve oyuncuları Silithus’un dışına atmadan önce ne kadar gecikmenin tolere edilebileceğini belirlemek. Sunucu performansını nasıl en üst düzeye çıkardığımıza dair ayrıntılara girmeden önce üzerinde çalıştığımız kısıtlamaları anlamak önemlidir: WoW Classic’in kod tabanının sınırlamaları, nüfus yönetimi çözümlerinin nasıl çalıştığı ve oynayışı nasıl etkiledikleri.

Ahn'Qiraj War Effort

Sınırların Ötesi

World of Warcraft’ın modern versiyonu, 15 yıl önce piyasaya sürülen orijinal kod tabanının temeli üzerine inşa edildi. Oyunun çıkışından bu yana, Battle for Azeroth‘taki yüksek oyuncu sayılarının üstesinden gelmek için daha modern yöntemler geliştirdik, bunların başında shard’lama geliyor. Shardlar, WoW sunucularının oyun içinde 2006’da yapabildiğimizden çok daha fazla oyuncuyu barındırmasına imkân sağlıyor. Battle for Azeroth‘ta, oyuncu sayısı belirli bir eşiğe ulaştığında bir bölgenin (örn. Zuldazar) kopyasını oluşturarak sunucuların oyuncu yükünü yönetmek için bunları kullandık. Bu, oyuncuları bölgenin farklı versiyonlarına yayarak gecikme sorunlarını etkisiz hale getirir; çünkü, hareketlerinde ve büyü kullanımlarında kesin doğruluk için sürekli olarak sunucuya gönderdikleri paket miktarı nedeniyle işlemcinin en yoğun olduğu anlar oyuncu etkileşimleridir. Shardlama ek olarak oyuncu sayısının eşiği aştığı yeni bir bölgeye geçerken karşılaşılabilecek olası gecikme sorunlarını da azaltmaktadır. Kulağa hoş geliyor değil mi? Ancak burada dikkat edilmesi gereken bir şey var—WoW Classic, oyunun tuhaflıklarını korumayı da içeren orijinal 1.12 oyun verilerinin sadık bir yaratımı olacak şekilde tasarlandı. Shardlar, ender durumlarda düşman oyuncusu ya da NPC’si gibi avınızın yeni bir bölgeye geçerken kaybolmasına neden olur. Shardları içeride tutmak, bölge sınırları boyunca oyuncuları ya da NPC’lerin kovalandığı nostaljik oyun anlarından bazılarını kaybetmek anlamına geliyordu. Bu yüzden, artık orijinal oynanışa müdahale etmeyen ve aynı zamanda oyuncuları oynanamayan gecikmelerden dolayı acı çekmeye zorlamadan sunucuya daha fazla oyuncu almamıza izin veren bir çözüm bulmamız gerekiyordu.

Bu sorunu çözmek için, oyuncu popülasyonunu ve gecikme sorunlarını yönetmek adına katmanları—tüm bölgelerin kopyaları (örn. Eastern Kingdoms)—kullanmayı seçtik, orijinal sürümün unutulmaz cazibesini korurken, oyuncular farklı bir shard’a atanma riski olmadan bir kez daha world boss’ları bölgeler arasında kite’layabilir ve düşman oyuncuları bir bölgenin sınırlarının ötesine kadar kovalayabilirlerdi. Ancak katmanlar kalıcı olmayan bir çözüm olarak tasarlanmıştı. Orijinal 1.12 sürümü shard’lama ya da katmanlama teknolojilerini kullanmadığından, oyunculara, katmanları yalnızca WoW Classic çıkışında kullanacağımızın ve tüm dünyaya daha eşit bir şekilde dağıldıkça zamanla aşamalı olarak kaldıracağımızın sözünü vermiştik. İnanılmaz derecede yüksek aktif oyuncu popülasyonu nedeniyle hala katmanlamayı kullandığımız birkaç durum var (örn. Kuzey Amerika’nın Faerlina realmi), ancak oyunun çıkışından bu yana bu realmlerdeki etkin olan katmanların sayısını azalttık. 15 yıllık birikimle, Ahn’Qiraj savaşı, WoW Classic‘in en çok beklenen etkinlikleri arasındadır ve oyun çıktığında başlangıç bölgeleri haricinde yönetmek için katmanlar olmadan bir alanda en fazla oyuncunun olmasını beklediğimiz yerdi. Katmanlar ya da popülasyonu shard’lama teknolojisi olmadan, hızlı bir şekilde yaratıcı olmak zorundaydık.

Ahn'Qiraj War Effort

Unutulmaz Bir Deneyimi Yeniden Oluşturmak

Başsız istemciler—otomatikleştirilmiş oyuncular—oluşturarak ve onlara büyü kullanma, NPC’lerle savaşma ve etrafta gezinme gibi gerçek oyuncuların yaptıklarını taklit etmeleri talimatını vererek katman ve shard olmayan bir popülasyon çözümü bulma girişimine başladık. Bu, tek bir bölgede etkileşimde bulunan binlerce oyuncuyla performansın nasıl görünebileceğinin bir anlık görüntüsünü almamızı sağladı. Bu simülasyonları çalıştırdıktan sonra, gerçekçi oyuncu davranışlarını yakalayabilmek ve nasıl karşılaştırıldığını görebilmek için gönüllülerle stres testleri düzenledik. Bu bize yüksek oyuncu sayılarında belirli kırılma noktalarını ve sunucu kodlarımızın hangi parçalarının en çok sorunu yaşadığını gösterdi. Sunucu kare süresi ölçümleri, bir sunucunun yanıt vermemeye-kilitlenme olarak da bilinir-ne kadar yakın olduklarını görmek için yoğun bir şekilde incelendi.

Bir sonraki adım, sunucu performansını neyin etkilediğini analiz etmekti, böylece bu devasa görevi anlaşılır hedeflere ayırmaya başlayabilirdik. Karşılaştığımız şey bir polinom problemiydi, bu da ona daha hızlı bir donanım vererek çözemeyeceğimiz anlamına geliyordu, çünkü donanım katlanarak daha iyi olan bir şey değildir. Bunun yerine, hangi verilerin oyunculara ne sıklıkla iletileceğini kasıtlı olarak seçerek optimizasyonu elden geçirmeliydik. Bu muammayı açıklamak için, bir daire içinde zıplayan 20 oyuncumuz olduğunu varsayalım. Sunucu, her oyuncunun eylemlerini paketler (veri çıkışları) aracılığıyla diğer 19’una aktarır. Bu 20 kişilik grupta, sunucu 380 paket işler (toplam 20 oyuncu * 19 alıcı = 380 paket). Bu sorun, bölgede daha fazla oyuncu aynı eylemi yaptığında daha da artar. Örneğimizi 500 oyuncuya çıkarırsak, sunucudan 249.500 paket gönderilmiş olur. Örneğimizi yeniden 1.500 oyuncuya çıkarırsak, sunucuya 2.248.500 paket gönderilmiş olur. Oyuncu eylemlerine bağlı olarak, saniyede birden çok paket gönderilir— yukarıdaki örneklerin yalnızca bir eylemi hesaba kattığını unutmayın. Sunucuya gönderilen paket sayısı ne kadar fazlaysa, sunucunun tek bir oyuncu için alması gereken işlem süresini artırır ve ardından diğer tüm oyuncuların eylemlerini gerçekleştirmeye devam eder. Bu sorun arttığında, sunucular kilitlenmeye yaklaşmaya başlar. WoW Classic’te, realm başına 2006’da olduğundan çok daha fazla oyuncumuz bulunuyor, bu nedenle beklentimiz, kapıların etrafında daha önce yaptığımızdan daha fazla oyuncuyu barındırmamızdır.

Sunucu Performansını Optimize Etmek

Sunucularımız bir kilitlenme ile karşılaştıklarında çökecek ve yeniden başlayacak şekilde tasarlandı, bu nedenle işlem süresini en aza indirmeye yardımcı olmak için elimizden gelen her şeyi yapmanın kritik olduğunu biliyorduk. Bazı testlerden sonra, hareketin sunucularımıza ağır yük getiren ilk işlem gücü parçası olduğu ortaya çıktı. Yönlenme güncellemelerini (bir karakter modelinin baktığı yönü gösterme) bırakarak başladık ve yalnızca bir oyuncu harekete başladığında, durduğunda ya da klavye hareketini kullandığında oyuncu güncellemeleri gönderdik. Aşırı sayıda oyuncuyla meydana gelen gecikme zaten tehlikeye atıldığından, küçük yönlenme güncellemeleri göndererek CPU zamanını harcamak, sistemin girdileri doğru bir şekilde yeniden üretimini kötüye götürürdü. Bu nedenle, onları göndermeyi bırakmak daha iyiydi. Bir bölgede daha fazla oyuncu olması adına hareket güncellemelerini gönderme sıklığımızı ardımızda bırakmaya karar verdik. Mümkün olduğunca çok oyuncunun Silithus’a girmesine izin verirken, sunucular çökmeden önce kırılma noktasını bulmaya çalıştığımızı unutmayın. Sonuçta, karakterinize hiç giriş yapamamaktansa bazı hareket güncellemelerini kaçırmak daha iyidir. Daha düşük öncelikli olarak işaretlenen verileri de azaltmaya başladık. “Daha az önemli” olarak nitelendirilen bir eylem, “daha önemli” eylemlerle aynı oranda gönderilmemeliydi. Ne kadar önemli olduklarına bakılmaksızın aynı anda birçok mesajın gönderildiğini gördük ve kodu, size daha az önemli bilgileri toplu olarak ve daha az sıklıkla gönderecek şekilde optimize ettik.

Bufflar ve debufflar, performansımızdaki bir diğer büyük darbeydi. Dünyanın her yerinde, özellikle moblarla savaşırken, bufflar ve debufflar birimlere her zaman uygulanır. Bu çok önemli bir şey gibi görünmese de, etrafta çok sayıda oyuncu olduğunda bu bilginin dolaştırılması gerekiyordu. Düşük öncelikli verileri azaltmaya benzer şekilde, artık oyunculara art arda birden fazla paket göndermekten kaçınmak için buffları ve debuffları toplu hale getiriyoruz.

Oyuncu Popülasyonlarını Yönetmek

Sunucuları her bölgede daha fazla oyuncuyu idare edecek şekilde optimize etmenin yanı sıra, tüm bir realmin nüfusunu (orijinal 1.12 WoW realminin başa çıkabileceğinin iki katından fazla) sığdırmanın imkânsız olması bizden kaçmadı. Kimin içeri girmesine ve kaç oyuncunun içeri girmesine izin verebileceğimizi kontrol ederek bölgeye erişimi sınırlamak için zor kararlar almak gerekiyordu. Silithus’ta yalnızca seviye 60 karakterlere izin vermeye ve doluysa uygun karakterlerin de içeriye girmesine izin vermemeye karar verdik. Bu kısıtlamayı oluşturmak, Silithus’taki etkinliğin oyun sonu içeriği olduğu bilindiğinden ve düşük seviye karakterler diğer bölgelerde de seviye 20’den 30’a kadar olan oyuncular için amaçlanan Barrens’ta dolanan anubisathları öldürerek War Effort’a katılabildiğinden yapılacak doğru seçimdi. İkinci çakışma noktası, bir alanda sunucuya çökertmeden kaç oyuncunun üstesinden gelebileceğimizi bilmemizdi; daha sonraki soru, en iyi performans / oyuncu oranı için bu sayının neye indirilmesi gerektiği oldu. Testlere göre, üst üste dizilmişlerse bu sayının yaklaşık 1.500 oyuncu olduğunu gördük. Bununla birlikte, etkinlik tüm bölgeye yayıldığından, oyuncular dağıldığında minimum performans sorunları gördük.

Etkinlik tüm bölgenin kısımlarında gerçekleşecek şekilde planlanmıştı, bu nedenle bu etkinliğin birden çok katmanda çalıştığından emin olmamız gerekiyordu. Bu, gong’u bir katmanda çalan Scepter taşıyıcısının, etkinliği o realme bağlı diğer tüm katmanlarda da başlatması gerektiği anlamına geliyordu. Etkinliğin tetikleyicisi bir oyuncu etkileşimine dayandığından, aynı realmdeki tüm oyuncuların görebilmesi için Scepter taşıyıcısının birden çok katmanda görünür olmasını sağlamak istedik. Bu ilginç bir sorun yarattı, çünkü sunucular artık bu bilgileri normalde birbirleriyle iletişim kurmaları gerekmeyecek şekilde iletmek zorunda kaldılar. Bu, verileri birden çok katmanda, potansiyel olarak binlerce oyuncuya yansıttığımızdan emin olmak için sunucular aracılığıyla güncellemeleri derleyip gönderirken pek çok karmaşıklık yaratabilirdi.

Bu teknolojiyi Stranglethorn Fishing Tournament’ın gelmesiyle geliştirmeye başladık ve daha sonra Onyxia, Nefarian, Zul’Gurub ve Rend world buff’larına uyguladık. İstendiği gibi çalıştığını hissettiğimizde, onu Ahn’Qiraj savaş etkinliği için diğer teknolojimizle birlikte test etmeye hazırdık.

Ahn'Qiraj War Effort

Çözümlerle Deney Yapmak

Artık büyük teknolojik engelleri aştığımıza ve sunucu performansını optimize etmek için çeşitli yöntemler uyguladığımıza göre, üzerinde çalıştığımız her şeyi test etme zamanı gelmişti. 10 saatlik savaşın, ölçeği yalnızca bir saat sürecek şekilde küçülterek kısaltılmış bir versiyonunu oluşturduk.

İlk stres testi sırasında, ne olacağını görmek için neredeyse tüm oyuncuların bölgeye girmesine izin verdik. Bir noktada, tüm 1.12 realm kapasitesinin neredeyse %150’sindeydik. Bu, test realmimizin çöküşünü gördüğümüz zamandı. Bölgeyi kaç kişiyle sınırlayacağımıza dair çok yüksek bir sayı koyduğumuzu biliyorduk ve bu sayıyı fazlasıyla aşan sayılar görüyorduk. Sorunu araştırdık ve oyuncuların hem bölgeye girmesine hem de bölge dışına çıkmasına izin veren kodun, aynı anda birçok oyuncuyu işlemeyen bir kuyruk olduğunu fark ettik. Bu yüzden oyuncuların taşınmaması ve alışılmadık derecede uzun bir süre uçuş yollarında sıkışıp kalmasının nedeni buydu. Sunucuyu geri yükledik ve stres testine devam ettikçe ayarlamalar yaparak devam ettik. Sayıyı yavaşça, hâlâ gecikmeli ve biraz oynanabilir hissettiğimiz bir noktaya indirdik ve daha önce gördüğümüzden çok daha fazla sayıda oyuncuyu elimizde tuttuk. Yalnızca bir buçuk saat sürmesi gereken etkinliğin tamamlanması, çökmeler nedeniyle dört saate kadar sürdü.

İkinci stres testi bir hafta sonra yapıldı. Bu, optimizasyonlarımızın işe yarayıp yaramadığını görmemizi sağladı. Stres testine girdikten hemen sonra iyileştirmelerin farkına vardık—oyuncular artık Silithus’a giden uçuş yollarında takılıp kalmıyorlardı! Silithus’ta rahatça kaç oyuncu barındırabileceğimizi gösteren yeterli veriye ulaşabilmiştik. Her iki testten sonra, gecikmeyi yönetme ile sunucu kararlılığı arasındaki en iyi dengeyi oluşturduğunu düşündüğümüz rakamlarla ilerledik. Bu testler, optimizasyonlarımızın işe yarayıp yaramadığını görmemize imkân sağladı ve bölge sınırlarını tanımlamamıza ve bunları yinelememize izin verdikleri için her iki testi de başarılı saymamızı sağladı.

Sunucu Çözümlerini Azeroth’a Yaymak

Başlangıçta, optimizasyonların yalnızca Silithus için War of the Shifting Sands sırasında aktif olması planlanmıştı. Küresel olarak kullanıma sunmanın güvenli olacağını belirledikten sonra, bunları 1.13.5’te tüm dünyaya uyguladık. War Effort başladığında, oyuncular malzemeleri teslim etmeye ve böcek cesetlerini toplu halde toplamaya başladı. Sadece Silithus’ta değil, başkentlerimizde ve açık dünya bölgelerimizde de büyük bir oyuncu artışı gördük. Bu optimizasyonlar, bu deneyimlerin daha performanslı olmasına yardımcı olarak Azeroth’ta büyük ölçekli PvP savaşlarının gerçekleşmesine izin verdi. Hatta bazı oyuncular, diğer faction’ı bir Hive’dan temizlemek için world boss Thunderaan’ı spawnlayacak kadar ileri gitti.

Kapı açma etkinliği henüz gerçekleşmemiş olsa da, bazı sunucular savaş çabalarının ilerlememesiyle ilgili garip sorunlar yaşıyordu. Bazı sunucuların War Effort’u tamamlama hızı o kadar hızlıydı ki, her teslim mantığında beş günlük zamanlayıcının başlamasını engelleyebilecek bir yarış durumu olmasına neden olacaktı. Bu uç durumun gerçekleşme şansı çok düşük olduğundan, bu sunucuları manuel olarak düzeltebildik ve daha sonra bu sorunu gelecekteki realmlerin War Effort’unu tamamlamaları için çözebildik.

War Effort’lar tamamlandıktan ve kapıları açmak için beş gün geçtikten sonra, dünyada açılan ilk realmler olan Çin realmlerini izlemeye başladık. Aktif bir Gong’a sahip ilk Çin sunucusu Ouro’ydu. Katman popülasyonlarımızı izlerken, her katmandaki çoğu oyuncunun Silithus’ta olduğunu gördük. Aynı anda birkaç bin oyuncu için birden çok maksimum katmanda gerçekleşen olay, daha önce hiç yapmadığımız bir şeydi. Görünür bir gecikme olmasına rağmen, sunucularımız Çin realmlerinin ilk açılışı sırasında herhangi bir çökme yaşamadı.

Gong’un Çalınması!

4 Ağustos’ta, sunucular sıfırlandıktan kısa bir süre sonra Kuzey Amerika’da Gong’larını çalmaya hazır birkaç realm olacağı belirtildi. Karşılaşılabilecek sorunları izlemek ve ele almak için bu alanları tek tek Game Master hesaplarında ve gözlem araçlarımız aracılığıyla aktif olarak izledik. Her realm açıldı ve etkinliği sorunsuz başlattılar. Scepter taşıyıcıları prestijli Black Qiraji War Tank bineklerini aldılar, oyuncular daha da büyük böceklerle savaşmak zorunda kaldı ve istikrar bizi memnun etti. İlk sıfırlama sonrası sunucumuzun beş günlük bekleme süresini tamamlamasını beklerken, önemli bir sorun fark ettik: Sunucu yeniden başlatıldıktan sonra etkinlikler devam etmiyordu. Bu, bir sunucu çökerse ya da yeniden başlarsa, etkinlikteki tüm ilerlemeyi kaybedeceğimiz anlamına geliyordu. Bu problem WoW Classic’in geliştirilmesinin başlangıcından beri var olmasına rağmen, sunucu yeniden başlatmalarında devam eden etkinliklerin kullanımıyla ilgili pek çok uygulama yoktu. Ekibimiz sorunu hızlı bir şekilde çözebildi, ancak bir düzeltmeyi uygulayana ve mevcut olan tüm War Effort’ların durumunu veritabanımızda uygun bir şekilde kataloglayana dek başka bir yeniden başlatma yapılmamasını sağlamamız gerekiyordu.


Bazıları, sunucuların çökmesine izin vermenin, orijinal Ahn’Qiraj savaşını kaotik kılan ve dolayısıyla onu unutulmaz kılan şey olduğunu iddia edebilir. Bunun yerine, her sunucuda aynı anda Silithus’taki yaklaşık 1.500 oyuncuyla paylaşılabilecek çok daha istikrarlı bir deneyim oluşturarak aynı tutkuyu geliştirmeye çalıştık. Klasik Ahn’Qiraj savaşı anılarının, 10 saatlik etkinlikte kesintisiz olarak mümkün olduğunca çok oyuncunun oynaması olmasını istedik. Birkaç realm çöküşü yaşamamıza rağmen, onları hızlı bir şekilde yeniden çevrimiçi hale getirmeyi başardık. Bu realmler tamamen geri getirildi, dakikalar içinde yeniden çevrimiçi oldu ve daha sonra herhangi bir kilitlenme meydana gelmedi.

Dünya çapında 4.000’den fazla oyuncu Scarab Lord oldu ve her sunucu War Effort’unu ilerlettikçe bu sayı artmaya devam ediyor. Ahn’Qiraj War Effort başladığından beri Classic’teki heyecan ve bağlılığı izlemek inanılmazdı ve ikinci War of the Shifting Sands için bize katılan herkese minnettarız!