War Robots bu Nisan ayında 10. yıl dönümünü kutluyor! Ve bugüne kadar onu geliştirmeye ve desteklemeye devam ediyoruz, sadece oyuncularımıza yeni özellikler sunmakla kalmıyoruz, aynı zamanda teknik olarak da geliştiriyoruz. Bu yazıda, bu büyük projenin teknik gelişiminde uzun yıllara dayanan deneyimimizi tartışacağız. Ama önce, projenin mevcut haliyle bir anlık görüntüsü: Yüz binlerce DAU (Günlük Aktif Kullanıcı) Yüz milyonlarca kurulum On binlerce eşzamanlı 12 kişilik maç Dört büyük platformda mevcut (iOS, Android, Steam, Amazon) Android ve PC dahil on binlerce desteklenen cihaz Yüzlerce sunucu Yaklaşık 20 istemci geliştiricisi, 9 sunucu geliştiricisi, 8 kişiden oluşan bir çapraz proje geliştirme ekibi ve 3 DevOps Yaklaşık 1,5 milyon satırlık istemci tarafı kodu Unity'yi 2014'teki sürüm 4'ten itibaren kullanıyoruz ve şu anda 2024'te 2022 LTS sürümünü kullanıyoruz. Bu tür bir projenin işlevselliğini korumak ve daha fazla yüksek kalitede gelişme sağlamak için yalnızca acil ürün görevleri üzerinde çalışmak yeterli değildir; aynı zamanda teknik durumunu iyileştirmek, geliştirmeyi basitleştirmek ve yeni içeriğin oluşturulmasıyla ilgili olanlar da dahil olmak üzere süreçleri otomatikleştirmek de çok önemlidir. Ayrıca, mevcut kullanıcı cihazlarının değişen pazarına sürekli olarak uyum sağlamalıyız. Metin, Pixonic (MY.GAMES) Geliştirme Departmanı Başkanı Pavel Zinov ve War Robots'un Baş Geliştiricisi Dmitry Chetverikov ile yapılan röportajlara dayanmaktadır. Başlangıç 2014'e geri dönelim: War Robots projesi başlangıçta küçük bir ekip tarafından oluşturuldu ve tüm teknik çözümler, hızlı geliştirme ve pazara yeni özellikler sunma paradigmasına uyuyor. Şu anda şirketin özel sunucuları barındıracak büyük kaynakları yoktu ve bu nedenle War Robots, P2P mantığına dayalı çok oyunculu bir ağ ile pazara girdi. Photon Cloud, istemciler arasında veri aktarımı için kullanıldı: Hareket etme, ateş etme veya başka herhangi bir komut olsun, her oyuncu komutu, ayrı RPC'ler kullanılarak Photon Cloud sunucusuna gönderildi. Özel bir sunucu olmadığından oyunun, tüm oyuncular için maç durumunun güvenilirliğinden sorumlu olan bir ana istemcisi vardı. Aynı zamanda, geri kalan oyuncular tüm oyunun durumunu yerel istemcileri üzerinde tam olarak işlediler. Örnek olarak, hareket için herhangi bir doğrulama yoktu; yerel müşteri robotunu uygun gördüğü şekilde hareket ettirdi, bu durum ana müşteriye gönderildi ve ana müşteri bu duruma koşulsuz olarak inandı ve bunu maçtaki diğer müşterilere iletti. Her müşteri bağımsız olarak savaşın bir kaydını tuttu ve maçın sonunda bunu sunucuya gönderdi, ardından sunucu tüm oyuncuların kayıtlarını işledi, bir ödül verdi ve maçın sonuçlarını tüm oyunculara gönderdi. Oyuncu profilleri hakkındaki bilgileri depolamak için özel bir Profil Sunucusu kullandık. Bu, Cassandra veritabanına sahip birçok sunucudan oluşuyordu. Her sunucu Tomcat'teki basit bir uygulama sunucusuydu ve istemciler onunla HTTP aracılığıyla etkileşime giriyordu. İlk yaklaşımımızın dezavantajları Oyunda kullanılan yaklaşımın bir takım dezavantajları vardı. Ekip elbette bunları biliyordu ancak nihai ürünün geliştirilme ve pazara sunulma hızı nedeniyle bir takım tavizlerin verilmesi gerekiyordu. Bu dezavantajların başında ana istemci bağlantısının kalitesi geliyordu. Müşterinin ağı kötüyse, maçtaki tüm oyuncular gecikme yaşadı. Ve ana istemci çok güçlü bir akıllı telefonda çalışmıyorsa, üzerine yüklenen yüksek yük nedeniyle oyunda veri aktarımında da bir gecikme yaşandı. Yani bu durumda ana istemcinin yanı sıra diğer oyuncular da zarar gördü. İkinci dezavantaj ise bu mimarinin hilecilerle sorun yaşamaya yatkın olmasıydı. Nihai durum ana istemciden aktarıldığından, bu istemci, kendi takdirine bağlı olarak, örneğin maçta ele geçirilen bölgelerin sayısını saymak gibi birçok maç parametresini değiştirebilir. Üçüncüsü, Photon Cloud'daki eşleştirme işleviyle ilgili bir sorun var: Photon Cloud Eşleştirme odasındaki en yaşlı oyuncu ana müşteri oluyor ve eşleştirme sırasında onlara bir şey olursa (örneğin bağlantı kesilmesi), grup oluşturma işlemi olumsuz etkileniyor. İlgili eğlenceli gerçek: Photon Cloud'daki eşleştirmenin bir grubu maça gönderdikten sonra kapanmasını önlemek için bir süreliğine ofisimize basit bir bilgisayar bile kurduk ve bu her zaman eşleştirmeyi destekledi, bu da Photon Cloud ile eşleştirmenin başarısız olamayacağı anlamına geliyor . Bir noktada sorunların ve destek taleplerinin sayısı kritik bir boyuta ulaştı ve oyunun teknik mimarisini geliştirmeyi ciddi olarak düşünmeye başladık; bu yeni mimariye Altyapı 2.0 adı verildi. Altyapı 2.0'a geçiş Bu mimarinin arkasındaki ana fikir, özel oyun sunucularının oluşturulmasıydı. O zamanlar müşterinin ekibinde kapsamlı sunucu geliştirme deneyimine sahip programcılar yoktu. Ancak şirket eş zamanlı olarak AppMetr adını verdiğimiz sunucu tabanlı, yüksek yüklü bir analitik projesi üzerinde çalışıyordu. Ekip, günde milyarlarca mesajı işleyen bir ürün yaratmıştı ve sunucu çözümlerinin geliştirilmesi, yapılandırılması ve doğru mimarisi konusunda kapsamlı uzmanlığa sahipti. Böylece ekibin bazı üyeleri Altyapı 2.0 çalışmalarına katıldı. 2015 yılında oldukça kısa bir süre içerisinde Windows Server üzerinde çalışan Photon Server SDK çerçevesine sarılmış bir .NET sunucusu oluşturuldu. İstemci projesinde yalnızca Photon Sunucu SDK ağ çerçevesini tutarak Photon Cloud'u terk etmeye karar verdik ve eşleştirme için istemcileri ve ilgili sunucuları bağlamak için bir Ana Sunucu oluşturduk. Mantığın bir kısmı istemciden özel bir oyun sunucusuna taşındı. Özellikle temel hasar doğrulaması getirildi ve maç sonucu hesaplamaları sunucuya yerleştirildi. Mikro hizmetlerin ortaya çıkışı Altyapı 2.0'ı başarılı bir şekilde oluşturduktan sonra hizmetlerin sorumluluklarını ayırma yönünde ilerlemeye devam etmemiz gerektiğini fark ettik: bunun sonucunda mikro hizmet mimarisi oluşturuldu. Bu mimari üzerinde oluşturulan ilk mikro hizmet klanlardı. Oradan ayrı bir İletişim hizmeti ortaya çıktı ve bu, mikro hizmetler arasında veri aktarımından sorumluydu. Müşteriye, oyun sunucusundaki meta mekaniklerden sorumlu "hangar" ile bağlantı kurması ve Photon Cloud üzerinden UDP kullanarak API istekleri (hizmetlerle etkileşim için tek bir giriş noktası) yapması öğretildi. Yavaş yavaş hizmetlerin sayısı arttı ve sonuç olarak eşleştirme mikro hizmetini yeniden düzenledik. Bununla birlikte, Gelen Kutusu haber işlevi oluşturuldu. Klanlar oluşturduğumuzda, oyuncuların oyunda birbirleriyle iletişim kurmak istedikleri açıktı; bir tür sohbete ihtiyaçları vardı. Bu başlangıçta Photon Chat'e dayalı olarak oluşturuldu, ancak son istemcinin bağlantısı kesildiğinde tüm sohbet geçmişi silindi. Bu nedenle bu çözümü Cassandra veritabanını temel alan ayrı bir mikro hizmete dönüştürdük. Altyapı 4.0 ve sunucu konumları Yeni mikro hizmet mimarisi, birbirinden bağımsız çok sayıda hizmeti rahatlıkla yönetmemize olanak tanıdı; bu, tüm sistemi yatay olarak ölçeklendirmek ve kesinti sürelerini önlemek anlamına geliyordu. Oyunumuzda sunucuların duraklatılmasına gerek kalmadan güncellemeler gerçekleşmiştir. Sunucu profili, istemcilerin çeşitli sürümleriyle uyumluydu ve oyun sunucularına gelince, istemcinin eski ve yeni sürümleri için her zaman bir sunucu havuzumuz var; bu havuz, uygulama mağazalarında yeni bir sürümün piyasaya sürülmesinden sonra yavaş yavaş değişti ve oyun sunucuları eski sürümden zamanla kayboldu. Mevcut altyapının genel hatlarına Altyapı 4.0 adı verildi ve şuna benziyordu: Mimariyi değiştirmenin yanı sıra, dünyanın her yerinden oyuncuları kapsaması gerektiği için sunucularımızın nereye yerleştirileceği konusunda da bir ikilemle karşılaştık. Başlangıçta birçok mikro hizmet, özellikle bu sistemin ölçeklendirme açısından sunduğu esneklik nedeniyle çeşitli nedenlerden dolayı Amazon AWS'de bulunuyordu; çünkü bu, oyun trafiğinin arttığı anlarda (mağazalarda ve mağazalarda öne çıktığı zamanlar gibi) çok önemliydi. UA'yı artırmak için). Ayrıca o zamanlar Asya'da iyi ağ kalitesi ve dış dünyayla bağlantı sağlayacak iyi bir barındırma sağlayıcısı bulmak zordu. Amazon AWS'nin tek dezavantajı yüksek maliyetiydi. Bu nedenle zamanla sunucularımızın birçoğu kendi donanımlarımıza, dünya genelindeki veri merkezlerinde kiraladığımız sunuculara taşındı. Bununla birlikte Amazon AWS, sürekli değişen kodun (özellikle Ligler, Klanlar, Sohbetler ve Haber hizmetlerine ilişkin kodlar) ve kararlılık tarafından yeterince kapsanmayan kodların geliştirilmesine izin verdiği için mimarinin önemli bir parçası olarak kaldı. testler. Ancak mikro hizmetin stabil olduğunu anladığımız anda onu kendi tesislerimize taşıdık. Şu anda tüm mikro hizmetlerimiz donanım sunucularımızda çalışmaktadır. Cihaz kalite kontrolü ve daha fazla ölçüm 2016 yılında oyunun sunumunda önemli değişiklikler yapıldı: Savaştaki tüm mekanizmalar için tek bir doku atlasına sahip Ubershaders konsepti ortaya çıktı, bu da çekiliş çağrılarının sayısını büyük ölçüde azalttı ve oyun performansını artırdı. Oyunumuzun on binlerce farklı cihazda oynandığı ortaya çıktı ve her oyuncuya mümkün olan en iyi oyun koşullarını sunmak istedik. Bu nedenle, temelde bir oyuncunun cihazını analiz eden ve belirli oyun veya işleme özelliklerini etkinleştiren (veya devre dışı bırakan) bir dosya olan Kalite Yöneticisi'ni oluşturduk. Üstelik bu özellik, bu işlevleri belirli cihaz modeline göre yönetmemize olanak tanıdı, böylece oyuncularımızın yaşadığı sorunları hızlı bir şekilde çözebildik. Ayrıca Kalite Yöneticisi ayarlarını sunucudan indirmek ve mevcut performansa bağlı olarak cihazdaki kaliteyi dinamik olarak seçmek de mümkündür. Mantık oldukça basittir: Kalite Yöneticisinin tüm yapısı, her biri performansın bir yönünden sorumlu olan bloklara bölünmüştür. (Örneğin, gölgelerin kalitesi veya kenar yumuşatma.) Kullanıcının performansı düşerse sistem blok içindeki değerleri değiştirmeye ve performansın artmasına neden olacak bir seçeneği seçmeye çalışır. Kalite Yöneticisinin gelişimine biraz sonra döneceğiz ancak bu aşamada uygulanması oldukça hızlıydı ve gerekli kontrol seviyesini sağladı. Grafik geliştirme devam ederken Kalite Yöneticisi üzerinde çalışmak da gerekliydi. Oyun artık tamamen grafik programcılarımız tarafından uygulanan basamaklı dinamik gölgeler içeriyor. Yavaş yavaş, projenin kodunda oldukça fazla varlık ortaya çıktı, bu nedenle farklı işlevlere erişimi sınırlamanın yanı sıra bunların yaşamlarını yönetmeye başlamanın iyi olacağına karar verdik. Bu özellikle hangar ile savaş kodunu ayırmak açısından önemliydi çünkü oyun bağlamı değiştiğinde birçok kaynak temizlenemiyordu. Çeşitli IoC bağımlılık yönetimi kapsayıcılarını keşfetmeye başladık. Özellikle StrangeIoC çözümüne baktık. O zamanlar çözüm bize oldukça hantal görünüyordu ve bu nedenle projede kendi basit DI'mızı uyguladık. Ayrıca hangar ve savaş bağlamlarını da tanıttık. Ayrıca projenin kalite kontrol çalışmalarına başladık; Üretim ortamındaki çökmeleri, ANR'leri ve istisnaları belirlemek için FirebaseCrashlytics oyuna entegre edildi. AppMetr adı verilen dahili analitik çözümümüzü kullanarak müşteri durumunun düzenli olarak izlenmesi ve sürümler sırasında yapılan değişikliklerin karşılaştırılması için gerekli kontrol panellerini oluşturduk. Ayrıca projenin kalitesini artırmak ve kodda yapılan değişikliklere olan güveni artırmak için otomatik testleri araştırmaya başladık. Varlık sayısının artması ve içerikteki benzersiz hatalar, bizi varlıkları organize etme ve birleştirme konusunda düşünmeye yöneltti. Bu özellikle mekanikler için geçerliydi çünkü yapıları her biri için benzersizdi; bunun için Unity'de araçlar oluşturduk ve bunlarla gerekli ana bileşenlere sahip mekanik maketler yaptık. Bu, oyun tasarım departmanının bunları kolayca düzenleyebileceği anlamına geliyordu ve biz de çalışmalarımızı mekaniklerle birleştirmeye ilk kez bu şekilde başladık. Daha fazla platform Proje büyümeye devam etti ve ekip onu diğer platformlarda yayınlamayı düşünmeye başladı. Ayrıca başka bir nokta olarak, o dönemdeki bazı mobil platformlar için oyunun, platformun mümkün olduğunca çok sayıda yerel işlevini desteklemesi önemliydi, çünkü bu, oyunun öne çıkmasına olanak sağlıyordu. Böylece War Robots'un Apple TV için deneysel bir sürümü ve Apple Watch için yardımcı bir uygulama üzerinde çalışmaya başladık. Ayrıca 2016 yılında oyunu bizim için yeni olan bir platform olan Amazon AppStore'da piyasaya sürdük. Teknik özellikler açısından bu platform benzersizdir çünkü Apple gibi birleşik bir cihaz serisine sahiptir, ancak bu hattın gücü düşük kaliteli Android'ler seviyesindedir. Bunu akılda tutarak, bu platformda lansman yaparken bellek kullanımını ve performansı optimize etmek için önemli çalışmalar yapıldı; örneğin atlaslar, doku sıkıştırma ile çalıştık. Giriş ve başarılar için Game Center'ın bir benzeri olan Amazon ödeme sistemi müşteriye entegre edildi ve bu nedenle oyuncunun giriş bilgileri ile çalışma akışı yeniden düzenlendi ve ilk başarılar başlatıldı. Aynı zamanda müşteri ekibinin ilk kez Unity Editor için bir dizi araç geliştirdiğini ve bunların motorda oyun içi videolar çekmeyi mümkün kıldığını da belirtmekte fayda var. Bu, pazarlama departmanımızın varlıklarla çalışmasını, savaşı kontrol etmesini ve izleyicilerimizin çok sevdiği videoları oluşturmak için kamerayı kullanmasını kolaylaştırdı. Hilecilere karşı mücadele Unity'nin ve özellikle sunucudaki fizik motorunun bulunmaması nedeniyle maçların çoğu oyuncu cihazlarında taklit edilmeye devam etti. Bu nedenle hilecilerle ilgili sorunlar devam etti. Destek ekibimiz periyodik olarak kullanıcılarımızdan hileci videolarıyla geri bildirim aldı: Uygun bir zamanda hızlandılar, haritanın etrafında uçtular, diğer oyuncuları bir köşeden öldürdüler, ölümsüz oldular vb. İdeal olarak tüm mekanizmaları sunucuya aktarırız; ancak oyunun sürekli olarak geliştirilmekte olduğu ve halihazırda oldukça miktarda eski kod biriktirdiği gerçeğine ek olarak, yetkili bir sunucuyla yaklaşımın başka dezavantajları da olabilir. Örneğin altyapı üzerindeki yükün artması ve daha iyi bir İnternet bağlantısı talebi. Kullanıcılarımızın çoğunun 3G/4G ağlarında oynadığı göz önüne alındığında, bu yaklaşım her ne kadar bariz olsa da soruna etkili bir çözüm değildi. Ekip içindeki hilecilerle mücadeleye alternatif bir yaklaşım olarak yeni bir fikir ortaya attık: bir "yeterlilik" oluşturmak. Çekirdek, verilen hasarı onaylarken farklı oyuncuların birden fazla simülasyonunu karşılaştırmanıza olanak tanıyan bir mekanizmadır; Hasar almak oyunun ana özelliklerinden biridir ve neredeyse oyunun geri kalanı buna bağlıdır. Örneğin rakiplerinizi yok ederseniz fenerleri ele geçiremeyeceklerdir. Bu kararın fikri şuydu: Her oyuncu hâlâ tüm dünyayı simüle ediyordu (diğer oyuncuları vurmak da dahil) ve sonuçları sunucuya gönderiyordu. Sunucu, tüm oyuncuların sonuçlarını analiz etti ve oyuncunun sonuçta hasar görüp görmediğine ve ne ölçüde hasar gördüğüne karar verdi. Maçlarımız 12 kişiliktir, dolayısıyla sunucunun hasar verildiğini kabul etmesi için bu durumun 7 oyunculu yerel simülasyonlara kaydedilmesi yeterlidir. Bu sonuçlar daha sonra daha fazla doğrulama için sunucuya gönderilecektir. Şematik olarak bu algoritma şu şekilde temsil edilebilir: Bu plan, kendilerini savaşta öldürülemez hale getiren hilecilerin sayısını önemli ölçüde azaltmamıza olanak sağladı. Aşağıdaki grafikte bu kullanıcılara yönelik şikayet sayıları ve sunucuda hasar hesaplama özelliklerinin etkinleştirilmesi ve hasar yeter sayısının etkinleştirilmesi aşamaları gösterilmektedir: Bu hasar verme mekanizması hile ile ilgili sorunları uzun süre çözdü çünkü sunucudaki fizik eksikliğine (ve dolayısıyla yüzey topografyası ve robotların uzaydaki gerçek konumu gibi şeyleri hesaba katmadaki yetersizliğe) rağmen, Tüm müşteriler için yapılan simülasyon ve onların fikir birliği, kimin kime ve hangi koşullar altında zarar verdiği konusunda net bir anlayış sağladı. Projenin daha da geliştirilmesi Zamanla, dinamik gölgelere ek olarak, Unity Post Processing Stack ve toplu işlemeyi kullanarak oyuna post-efektler ekledik. İşlem sonrası efektlerin uygulanması sonucunda geliştirilmiş grafik örnekleri aşağıdaki resimde görülebilir: Hata ayıklama yapılarında neler olduğunu daha iyi anlamak için bir günlük kaydı sistemi oluşturduk ve dahili test uzmanlarından günlükleri toplayıp hataların nedenlerini bulmayı kolaylaştırabilecek yerel bir hizmeti dahili altyapıya yerleştirdik. Bu araç hala QA tarafından oyun testleri için kullanılıyor ve çalışmalarının sonuçları Jira'daki biletlere ekleniyor. Ayrıca projeye kendi yazdığımız Paket Yöneticisini de ekledik. Başlangıçta, çeşitli paketler ve harici eklentilerle (projede zaten yeterli sayıda birikmiş olan) çalışmayı geliştirmek istedik. Ancak Unity'nin işlevselliği o zamanlar yeterli değildi, bu nedenle dahili Platform ekibimiz paket versiyonlama, NPM kullanarak depolama ve GitHub'a bir bağlantı ekleyerek paketleri projeye bağlama yeteneği ile kendi çözümünü geliştirdi. Hâlâ yerel bir motor çözümü kullanmak istediğimiz için Unity'deki meslektaşlarımıza danıştık ve 2018'de Paket Yöneticisini yayınladıklarında Unity'nin nihai çözümüne bazı fikirlerimiz dahil edildi. Oyunumuzun mevcut olduğu platformların sayısını artırmaya devam ettik. Sonunda klavye ve fareyi destekleyen bir platform olan Facebook Gameroom ortaya çıktı. Bu, kullanıcıların uygulamaları PC'de çalıştırmasına olanak tanıyan Facebook'un (Meta) bir çözümüdür; aslında bir Steam mağazası analogudur. Tabii ki, Facebook'un hedef kitlesi oldukça çeşitlidir ve Facebook Gameroom, başta oyun olmayanlar olmak üzere çok sayıda cihazda kullanıma sunuldu. Bu nedenle ana kitlenin bilgisayarlarına yük getirmemek için mobil grafikleri oyunda tutmaya karar verdik. Teknik açıdan bakıldığında, oyunun gerektirdiği tek önemli değişiklik SDK'nın entegrasyonu, ödeme sistemi ve yerel Unity giriş sistemini kullanan klavye ve fare desteğiydi. Teknik olarak, oyunun Steam için yapılan yapısından çok az farklıydı ancak cihazların kalitesi önemli ölçüde düşüktü çünkü platform, bir tarayıcıdan başka bir şey çalıştıramayan oldukça basit cihazlara sahip sıradan oyuncular için bir yer olarak konumlandırılmıştı. Mind Facebook oldukça büyük bir pazara girmeyi umuyordu. Bu cihazların kaynakları sınırlıydı ve özellikle platformda kalıcı bellek ve performans sorunları vardı. Daha sonra platform kapandı ve oyuncularımızı mümkün olan yere Steam'e aktardık. Bunun için platformlar arasında hesap aktarımını sağlayan kodların bulunduğu özel bir sistem geliştirdik. VR'da War Robots'u denemek 2017'nin bir diğer dikkat çekici olayı: çentikli ilk akıllı telefon olan iPhone X'in piyasaya sürülmesi. O zamanlar Unity çentikli cihazları desteklemiyordu, bu nedenle kullanıcı arayüzünü ölçeklendirmeye ve telefon ekranındaki farklı güvenli bölgelerden kaçınmaya zorlayan UnityEngine.Screen.safeArea parametrelerini temel alan özel bir çözüm oluşturmak zorunda kaldık. Ayrıca 2017'de başka bir şey denemeye karar verdik: oyunumuzun VR versiyonunu Steam'de yayınlamak. Geliştirme yaklaşık altı ay sürdü ve o dönemde mevcut olan tüm kasklar üzerinde yapılan testleri içeriyordu: Oculus, HTC Vive ve Windows Mixed Reality. Bu çalışma Oculus API ve Steam API kullanılarak gerçekleştirildi. Ayrıca PS VR kulaklıklar için demo sürümün yanı sıra MacOS desteği de hazır hale getirildi. Teknik açıdan bakıldığında sabit bir FPS'yi korumak gerekiyordu: PS VR için 60 FPS ve HTC Vive için 90 FPS. Bunu başarmak için, standart Frustum ve Occlusion'un yanı sıra yeniden projeksiyonlara (bazı kareler önceki karelere göre oluşturulduğunda) ek olarak, kendi kendine kodlanan Bölge Ayırma kullanıldı. Hareket hastalığı sorununu çözmek için ilginç, yaratıcı ve teknik bir çözüm benimsendi: Oyuncumuz robot pilot oldu ve kokpite oturdu. Kabin statik bir unsurdu, dolayısıyla beyin onu dünyada bir tür sabit olarak algıladı ve bu nedenle uzayda hareket çok iyi çalıştı. Oyun ayrıca, Unity'nin bu sürümünde Cinemachine henüz mevcut olmadığından, birkaç ayrı tetikleyicinin, komut dosyasının ve ev yapımı zaman çizelgesinin geliştirilmesini gerektiren bir senaryoya sahipti. Her silah için hedefleme, kilitleme, takip ve otomatik nişan alma mantığı sıfırdan yazıldı. Sürüm Steam'de yayınlandı ve oyuncularımız tarafından büyük beğeni topladı. Ancak Kickstarter kampanyasından sonra, VR için tam teşekküllü bir PvP nişancı oyununun geliştirilmesinin teknik risklerle dolu olması ve pazarın böyle bir projeye hazır olmaması nedeniyle projenin geliştirilmesine devam etmemeye karar verdik. İlk ciddi hatamızla uğraşıyoruz Oyunun teknik bileşenini iyileştirmenin yanı sıra yeni oluşturmak ve mevcut mekanikleri ve platformları geliştirmek için çalışırken, yeni bir promosyon başlatırken geliri olumsuz yönde etkileyen oyunda ilk ciddi hatayla karşılaştık. Sorun, "Fiyat" düğmesinin yanlış şekilde "Ödül" olarak konumlandırılmasıydı. Oyuncuların çoğu bu duruma şaşırdı, gerçek para birimiyle alışveriş yaptı ve ardından para iadesi istedi. O zamanlar teknik sorun, tüm yerelleştirmelerimizin oyun istemcisine yerleştirilmiş olmasıydı. Bu sorun ortaya çıktığında, yerelleştirmeleri güncellememize imkan verecek bir çözüm üzerinde çalışmayı daha fazla erteleyemeyeceğimizi anladık. Yerelleştirme dosyalarının CDN'ye otomatik olarak yüklenmesini sağlayan TeamCity'deki projeler gibi CDN'ye ve eşlik eden araçlara dayalı bir çözüm bu şekilde oluşturuldu. Bu, kullandığımız hizmetlerden (POEditor) yerelleştirmeleri indirmemize ve ham verileri CDN'ye yüklememize olanak sağladı. Bundan sonra sunucu profili, istemcinin her sürümü için yerelleştirme verilerine karşılık gelen bağlantıları ayarlamaya başladı. Uygulama başlatıldığında profil sunucusu bu bağlantıyı istemciye göndermeye başladı ve bu veriler indirilip önbelleğe alındı. Verilerle çalışmayı optimize etme 2018'e doğru ilerleyelim. Proje büyüdükçe sunucudan istemciye aktarılan veri miktarı da arttı. Sunucuya bağlanırken denge, mevcut ayarlar vb. hakkında oldukça fazla veri indirmek gerekiyordu. Mevcut veriler XML formatında sunuldu ve standart Unity serileştiricisi tarafından serileştirildi. Oyuncu cihazları, istemciyi başlatırken ve profil sunucusu ve oyun sunucusuyla iletişim kurarken oldukça büyük miktarda veri aktarmanın yanı sıra, mevcut bakiyeyi depolamak ve seri hale getirmek/seri durumdan çıkarmak için çok fazla bellek harcadı. Uygulamanın performansını ve başlatma süresini iyileştirmek için alternatif protokoller bulmaya yönelik Ar-Ge çalışmaları yapılması gerektiği ortaya çıktı. Test verilerimizle ilgili çalışmanın sonuçları bu tabloda gösterilmektedir: Protokol boyut tahsis zaman XML 2,2 MB 18,4 MiB 518,4 ms Mesaj Paketi (sözleşmesiz) 1,7 MB 2 MiB 32,35 ms Mesaj Paketi (str tuşları) 1,2 MB 1,9 MiB 25,8 ms Mesaj Paketi (int anahtarları) 0,53MB 1.9 16.5 Düz Tamponlar 0,5 MB 216 B 0 ms / 12 ms / 450 KB Sonuç olarak, özellikle tamsayı anahtarlarıyla Mesaj Paketi kullanıldığında, geçişin benzer çıktı sonuçlarına sahip FlatBuffers'a geçmekten daha ucuz olması nedeniyle, Mesaj Paketi biçimini seçtik. FlatBuffer'lar için (ve protokol arabellekleri ile), mesaj formatını ayrı bir dilde tanımlamak, C# ve Java kodu oluşturmak ve oluşturulan kodu uygulamada kullanmak gerekir. İstemci ve sunucuyu yeniden düzenlemenin bu ek maliyetine katlanmak istemediğimiz için, Mesaj Paketi'ne geçtik. Geçiş neredeyse kusursuzdu ve ilk sürümlerde, yeni sistemde herhangi bir sorun olmadığına ikna olana kadar XML'e geri dönme özelliğini destekledik. Yeni çözüm tüm görevlerimizi kapsıyordu; istemci yükleme süresini önemli ölçüde azalttı ve ayrıca sunuculara istekte bulunulurken performansı artırdı. Projemizdeki her özellik veya yeni teknik çözüm bir “bayrak” altında yayınlanmaktadır. Bu bayrak oyuncunun profilinde saklanır ve oyun başladığında bakiyeyle birlikte müşteriye gelir. Kural olarak, yeni bir işlevsellik, özellikle de teknik bir işlevsellik yayınlandığında, birçok istemci sürümü hem eski hem de yeni işlevleri içerir. Yeni işlevsellik aktivasyonu, yukarıda açıklanan bayrağın durumuna tam olarak uygun olarak gerçekleşir; bu, belirli bir çözümün teknik başarısını gerçek zamanlı olarak izlememize ve ayarlamamıza olanak tanır. Yavaş yavaş projedeki Bağımlılık Ekleme işlevini güncellemenin zamanı gelmişti. Mevcut olan, artık çok sayıda bağımlılıkla baş edemiyordu ve bazı durumlarda, kırılması ve yeniden düzenlenmesi çok zor olan, bariz olmayan bağlantılar ortaya koyuyordu. (Bu özellikle kullanıcı arayüzüyle ilgili yenilikler için şu veya bu şekilde geçerliydi.) Yeni bir çözüm seçerken seçim basitti: diğer projelerimizde kanıtlanmış, iyi bilinen Zenject. Bu proje uzun süredir geliştiriliyor, aktif olarak destekleniyor, yeni özellikler ekleniyor ve ekipteki birçok geliştirici bir şekilde buna aşinaydı. Yavaş yavaş War Robots'u Zenject kullanarak yeniden yazmaya başladık. Tüm yeni modüller onunla geliştirildi ve eski modüller yavaş yavaş yeniden düzenlendi. Zenject'i kullandığımızdan bu yana, daha önce tartıştığımız bağlamlar (savaş ve hangar) dahilinde daha net bir yükleme hizmetleri dizisi aldık ve bu, geliştiricilerin projenin geliştirilmesine daha kolay dalmalarına ve yeni özellikleri daha güvenli bir şekilde geliştirmelerine olanak sağladı. bu bağlamlar içerisinde. Unity'nin nispeten yeni sürümlerinde, eşzamansız/bekleme yoluyla eşzamansız kodla çalışmak mümkün hale geldi. Kodumuz zaten eşzamansız kod kullanıyordu, ancak kod tabanında tek bir standart yoktu ve Unity komut dosyası oluşturma arka ucu eşzamansız/beklemeyi desteklemeye başladığından, Ar-Ge yapmaya ve eşzamansız kod yaklaşımlarımızı standartlaştırmaya karar verdik. Diğer bir motivasyon da koddan geri arama cehennemini kaldırmaktı; bu, sıralı bir eşzamansız çağrılar zincirinin olduğu ve her çağrının bir sonrakinin sonuçlarını beklediği zamandır. O zamanlar RSG veya UniRx gibi birçok popüler çözüm vardı; hepsini karşılaştırdık ve tek bir tabloda derledik: RSG.Söz VUK TPL ve bekleme Tek Görev Eşzamansız UniTask Tamamlanana kadar geçen süre, s 0.15843 0.1305305 0.1165172 0.1330536 0,1208553 İlk kare Zamanı/Kendi, ms 105,25/82,63 13.51/11.86 21.89/18.40 28.80/24.89 19.27/15.94 İlk kare tahsisleri 40,8 MB 2,1 MB 5,0 MB 8,5 MB 5,4 MB İkinci kare Zaman/Kendi, ms 55,39/23,48 0,38/0,04 0,28/0,02 0,32/0,03 0,69/0,01 İkinci kare tahsisleri 3,1 MB 10,2 KB 10,3 KB 10,3 KB 10,4 KB Sonuçta çoğu geliştiricinin aşina olduğu eşzamansız C# koduyla çalışmak için standart olarak yerel eşzamansız/beklemede kullanmaya karar verdik. Eklentinin avantajları üçüncü taraf bir çözüme güvenme ihtiyacını karşılamadığından UniRx.Async'i kullanmamaya karar verdik. Gerekli minimum işlevsellik yolunu izlemeyi seçtik. RSG.Promise veya sahiplerinin kullanımını bıraktık, çünkü her şeyden önce yeni geliştiricilerin bu, genellikle alışılmadık araçlarla çalışacak şekilde eğitilmesi gerekiyordu ve ikinci olarak, üçüncü taraf kodu için bir sarmalayıcı oluşturmak gerekiyordu. RSG.Promise veya tutucularda eşzamansız Görevler kullanır. Eşzamansız/beklemede seçimi aynı zamanda şirketin projeleri arasındaki geliştirme yaklaşımının standartlaştırılmasına da yardımcı oldu. Bu geçiş sorunlarımızı çözdü; asenkron kodla çalışmak için net bir süreç elde ettik ve desteklenmesi zor geri arama cehennemini projeden kaldırdık. Kullanıcı arayüzü yavaş yavaş geliştirildi. Ekibimizde yeni özelliklerin işlevselliği müşteri programcıları tarafından geliştirildiğinden ve düzen ve arayüz geliştirmesi UI/UX departmanı tarafından yürütüldüğünden, aynı özellik üzerinde çalışmayı paralelleştirmemize olanak tanıyacak bir çözüme ihtiyacımız vardı. Programcı mantığı yazarken düzen tasarımcısı arayüzü oluşturabilir ve test edebilir. Bu sorunun çözümü, arayüzle çalışma MVVM modeline geçişte bulundu. Bu model, arayüz tasarımcısının yalnızca bir programcıyı dahil etmeden bir arayüz tasarlamasına değil, aynı zamanda henüz gerçek bir veri bağlanmadığında arayüzün belirli verilere nasıl tepki vereceğini görmesine de olanak tanır. Pixonic ReactiveBindings adı verilen kendi çözümümüzün hızlı prototiplemesinin yanı sıra kullanıma hazır çözümlerle ilgili biraz araştırma yaptıktan sonra, aşağıdaki sonuçları içeren bir karşılaştırma tablosu derledik: CPU zamanı Mem. Tahsis Mem. Kullanım Nane Veri Bağlama 367 ms 73 KB 17,5 MB DisplayFab 223 ms 147 KB 8,5 MB Birlik Kaynağı 267 ms 90 KB 15,5MB Pixonic Reaktif Bağlamalar 152 ms 23 KB 3 MB Yeni sistem, öncelikle yeni arayüzlerin üretimini basitleştirmek açısından kendini kanıtladığında, onu tüm yeni projelerde ve projede ortaya çıkan tüm yeni özelliklerde kullanmaya başladık. Yeni nesil mobil cihazlar için oyunun yeniden düzenlenmesi 2019 yılına gelindiğinde Apple ve Samsung'un grafik açısından oldukça güçlü birkaç cihazı piyasaya sürüldü, bu nedenle şirketimiz War Robots'ta önemli bir yükseltme fikrini ortaya attı. Tüm bu yeni cihazların gücünden faydalanmak ve oyunun görsel imajını güncellemek istedik. Güncellenen görsele ek olarak, güncellenen ürünümüz için çeşitli gereksinimlerimiz de vardı: 60 FPS oyun modunun yanı sıra farklı cihazlar için farklı kalitede kaynak desteklemek istiyorduk. Mevcut kalite yöneticisi ayrıca, bloklar içindeki kalitelerin sayısı arttıkça, anında değiştirilerek üretkenliği azalttığından ve aynı zamanda her birinin test edilmesi gereken ve ek yük getiren çok sayıda permütasyon yarattığından, yeniden çalışmaya ihtiyaç duydu. Her sürümde QA ekibinin maliyetleri. Müşteri üzerinde yeniden çalışırken başladığımız ilk şey, çekimi yeniden düzenlemekti. Orijinal uygulama kare oluşturma hızına bağlıydı çünkü oyun varlığı ve onun istemcideki görsel temsili tek ve aynı nesneydi. Çekimin oyun varlığının artık görsellere bağımlı olmaması için bu varlıkları ayırmaya karar verdik ve bu, farklı kare hızlarına sahip cihazlar arasında daha adil bir oyun sağladı. Oyun çok sayıda atışla ilgilenir, ancak bunların verilerini işlemeye yönelik algoritmalar oldukça basittir - hareket etme, düşmanın vurulup vurulmadığına karar verme vb. Varlık Bileşen Sistemi konsepti, mermi hareketinin mantığını düzenlemek için mükemmel bir seçimdi. oyunda, bu yüzden buna bağlı kalmaya karar verdik. Ayrıca tüm yeni projelerimizde zaten mantıkla çalışmak için ECS kullanıyorduk ve bu paradigmayı birleştirme için ana projemize uygulamanın zamanı gelmişti. Yapılan çalışmanın sonucunda önemli bir gereksinimin farkına vardık: görüntüleri 60 FPS'de çalıştırma yeteneğinin sağlanması. Ancak savaş kodunun tamamı ECS'ye aktarılmadığından bu yaklaşımın potansiyeli tam olarak hayata geçirilemedi. Sonuçta performansı istediğimiz kadar artırmadık ama düşürmedik de; bu, bu kadar güçlü bir paradigma ve mimari değişime rağmen hâlâ önemli bir gösterge. Aynı zamanda yeni grafik yığınımızla hangi düzeyde grafik elde edebileceğimizi görmek için PC versiyonumuz üzerinde çalışmaya başladık. O zamanlar hala önizleme sürümünde olan ve sürekli değişen Unity SRP'den yararlanmaya başladı. Steam sürümü için ortaya çıkan resim oldukça etkileyiciydi: Ayrıca yukarıdaki resimde gösterilen grafiksel özelliklerin bazıları güçlü mobil cihazlara aktarılabilir. Bu özellikle geçmişte iyi performans özelliklerine, mükemmel sürücülere ve sıkı bir donanım ve yazılım kombinasyonuna sahip olan Apple cihazları için geçerliydi; bu, bizim tarafımızdan herhangi bir geçici çözüme gerek kalmadan, çok yüksek kalitede bir resim üretmelerine olanak tanır. Tek başına grafik yığınını değiştirmenin görüntüyü değiştirmeyeceğini hemen anladık. Güçlü cihazların yanı sıra daha zayıf cihazlara yönelik içeriklere de ihtiyaç duyacağımız açıkça ortaya çıktı. Böylece farklı kalite düzeylerine yönelik içerik geliştirmeyi planlamaya başladık. Bu, mekanizmaların, silahların, haritaların, efektlerin ve bunların dokularının kalite açısından ayrılması gerektiği anlamına geliyordu; bu da farklı niteliklere sahip farklı varlıklar anlamına geliyordu. Yani, HD kalitesinde çalışacak fiziksel modeller, dokular ve mekanik dokular seti, diğer niteliklerde çalışacak mekaniklerden farklı olacaktır. Ayrıca oyun, haritalara büyük miktarda kaynak ayırıyor ve bunların da yeni niteliklere uyacak şekilde yeniden yapılması gerekiyor. Mevcut Kalite Müdürünün varlık kalitesini kontrol etmemesi nedeniyle ihtiyaçlarımızı karşılamadığı da ortaya çıktı. Bu yüzden öncelikle oyunumuzda hangi niteliklerin mevcut olacağına karar vermemiz gerekiyordu. Mevcut Kalite Yöneticimizin deneyimini dikkate alarak, yeni sürümde, belirli bir cihaz için mevcut maksimum kaliteye bağlı olarak kullanıcının ayarlarda bağımsız olarak geçiş yapabileceği birkaç sabit nitelik istediğimizi fark ettik. Yeni kalite sistemi, kullanıcının sahip olduğu cihazı belirler ve cihaz modeline (iOS durumunda) ve GPU modeline (Android durumunda) bağlı olarak belirli bir oynatıcı için mevcut maksimum kaliteyi ayarlamamıza olanak tanır. Bu durumda, önceki tüm nitelikler gibi bu kalite de mevcuttur. Ayrıca her kalite için maksimum FPS'yi 30 ile 60 arasında değiştirecek bir ayar var. Başlangıçta yaklaşık beş kaliteye (ULD, LD, MD, HD, UHD) sahip olmayı planladık. Ancak geliştirme süreci sırasında bu kadar çok özelliğin geliştirilmesinin çok uzun zaman alacağı ve kalite kontrol üzerindeki yükü azaltmamıza izin vermeyeceği ortaya çıktı. Bunu aklımızda tutarak sonuçta oyunda şu nitelikleri elde ettik: HD, LD ve ULD. (Referans olması açısından bu niteliklerle oynayan seyircilerin mevcut dağılımı şu şekildedir: HD - %7, LD - %72, ULD - %21.) Daha fazla niteliği hayata geçirmemiz gerektiğini anladığımız anda varlıkları bu niteliklere göre nasıl sıralayabileceğimiz üzerinde çalışmaya başladık. Bu çalışmayı basitleştirmek için şu algoritmayı kabul ettik: Sanatçılar maksimum kalitede (HD) varlıklar oluşturacak ve ardından komut dosyaları ve diğer otomasyon araçları kullanılarak bu varlıkların bazı kısımları basitleştirilecek ve diğer nitelikler için varlıklar olarak kullanılacak. Bu otomasyon sistemi üzerinde çalışma sürecinde aşağıdaki çözümleri geliştirdik: Varlık İçe Aktarıcı – dokular için gerekli ayarları yapmamızı sağlar Mech Creator – Unity Prefab Varyantlarına dayalı çeşitli mekanik versiyonlarının yanı sıra ilgili proje klasörlerinde dağıtılan kalite ve doku ayarlarının oluşturulmasına olanak tanıyan bir araç. Texture Array Packer – dokuları doku dizileri halinde paketlemenizi sağlayan bir araç Kaliteli Harita Oluşturucu - kaynak UHD kalitesinde bir haritadan birden fazla harita kalitesi oluşturmaya yönelik bir araç Mevcut makine ve harita kaynaklarını yeniden düzenlemek için birçok çalışma yapıldı. Orijinal mekanizmalar farklı nitelikler göz önünde bulundurularak tasarlanmamıştı ve bu nedenle tek prefabriklerde saklandı. Yeniden düzenleme sonrasında, esas olarak mantıklarını içeren temel parçalar çıkarıldı ve Prefabrik Varyantlar kullanılarak belirli bir kaliteye sahip dokulara sahip varyantlar oluşturuldu. Ayrıca, niteliklere bağlı olarak doku depolama klasörlerinin hiyerarşisini hesaba katarak bir makineyi otomatik olarak farklı niteliklere bölebilecek araçlar ekledik. Belirli varlıkları belirli cihazlara sunmak için oyundaki tüm içeriği paketlere ve paketlere bölmek gerekiyordu. Ana paket, oyunu çalıştırmak için gerekli varlıkları, tüm kapasitelerde kullanılan varlıkları ve her platform için kalite paketlerini içerir: Android_LD, Android_HD, Android_ULD, iOS_LD, iOS_HD, iOS_ULD vb. Varlıkların paketlere bölünmesi, Platform ekibimiz tarafından oluşturulan ResourceSystem aracı sayesinde mümkün oldu. Bu sistem, varlıkları ayrı paketler halinde toplamamıza ve daha sonra bunları istemciye yerleştirmemize veya CDN gibi harici kaynaklara yüklemek üzere ayrı ayrı almamıza olanak sağladı. İçerik sunmak için yine platform ekibi tarafından oluşturulan DeliverySystem adı verilen yeni bir sistem kullandık. Bu sistem, ResourceSystem tarafından oluşturulan bir bildirimi almanıza ve belirtilen kaynaktan kaynakları indirmenize olanak tanır. Bu kaynak monolitik bir yapı, ayrı APK dosyaları veya uzak bir CDN olabilir. Başlangıçta, kaynak paketlerini depolamak için Google Play (Play Asset Delivery) ve AppStore'un (İstek Üzerine Kaynaklar) yeteneklerini kullanmayı planladık, ancak Android platformunda, otomatik istemci güncellemeleriyle ilgili birçok sorun ve kısıtlamalar vardı. depolanan kaynakların sayısı. Ayrıca dahili testlerimiz, CDN'li bir içerik dağıtım sisteminin en iyi şekilde çalıştığını ve en istikrarlı olduğunu gösterdi; bu nedenle kaynakları mağazalarda depolamayı bıraktık ve bunları bulutumuzda depolamaya başladık. Remaster'ın yayınlanması Remaster'ın ana çalışması tamamlandığında yayınlanma zamanı gelmişti. Ancak, piyasadaki bazı popüler oyunların kullanıcıların 5-10 GB veri indirmesini gerektirmesine rağmen, başlangıçta planlanan 3 GB boyutun kötü bir indirme deneyimi olduğunu hemen anladık. Bizim teorimiz, yeniden düzenlenmiş oyunumuzu piyasaya sürdüğümüzde kullanıcıların bu yeni gerçekliğe alışacağı yönündeydi, ama ne yazık ki. Yani oyuncular mobil oyunlar için bu tür büyük dosyalara alışkın değildi. Bu soruna hızla çözüm bulmamız gerekiyordu. Bundan sonra birkaç kez HD kalitesiz versiyonunu yayınlamaya karar verdik ama yine de daha sonra kullanıcılarımıza ulaştırdık. Remaster'ın geliştirilmesine paralel olarak proje testlerini otomatikleştirmek için aktif olarak çalıştık. QA ekibi, projenin durumunun otomatik olarak takip edilebilmesini sağlayarak harika bir iş çıkardı. Şu anda oyunun çalıştığı sanal makinelerin bulunduğu sunucularımız var. Kendi kendine yazılan bir test çerçevesi kullanarak, projedeki komut dosyalarıyla herhangi bir düğmeye basabiliriz ve aynı komut dosyaları, doğrudan cihazlarda test yaparken çeşitli senaryoları çalıştırmak için kullanılır. Bu sistemi geliştirmeye devam ediyoruz: kararlılığı, performansı ve doğru mantık yürütmeyi kontrol etmek için sürekli çalışan yüzlerce test zaten yazılmıştır. Sonuçlar, QA uzmanlarımızın geliştiricilerle birlikte en sorunlu alanları (test çalıştırmasından gerçek ekran görüntüleri dahil) ayrıntılı olarak inceleyebileceği özel bir kontrol panelinde görüntülenir. Mevcut sistemi devreye almadan önce regresyon testi çok zaman alıyordu (projenin eski versiyonunda yaklaşık bir hafta), bu da hacim ve içerik miktarı açısından mevcut sistemden çok daha kısaydı. Ancak otomatik test sayesinde oyunun güncel sürümü yalnızca iki gece test ediliyor; bu daha da geliştirilebilir ancak şu anda sisteme bağlı cihaz sayısıyla sınırlıyız. Yeniden düzenlemenin tamamlanmasına doğru Apple ekibi bizimle iletişime geçti ve yeni Apple A14 Bionic çipin (2020 sonbaharında yeni iPad'lerle piyasaya sürülen) yeteneklerini göstermek için bize yeni bir ürün sunumuna katılma fırsatını verdi. yeni grafikler. Bu mini proje üzerinde çalışırken, Apple çiplerinde 120 FPS'de çalışabilen, tamamen çalışan bir HD sürümü oluşturuldu. Ayrıca yeni çipin gücünü göstermek için çeşitli grafiksel iyileştirmeler eklendi. Rekabetçi ve oldukça zorlu bir seçim sonucunda oyunumuz Apple Etkinliğinin sonbahar sunumunda yer aldı! Tüm ekip bu etkinliği izlemek ve kutlamak için toplandı ve gerçekten harikaydı! Photon'u terk edip WorldState mimarisine geçiş. Hatta oyunun yeniden düzenlenen versiyonunun 2021 yılında piyasaya sürülmesinden önce bile yeni bir görev ortaya çıkmıştı. Birçok kullanıcı, o zamanki mevcut çözümümüz olan ve Photon Sunucu SDK'sıyla çalışmak için kullanılan Photon taşıma katmanının kökü olan ağ sorunlarından şikayetçiydi. Diğer bir sorun, sunucuya rastgele bir sırayla gönderilen çok sayıda ve standartlaştırılmamış sayıda RPC'nin varlığıydı. Ayrıca, maçın başlangıcında dünyaların senkronizasyonu ve mesaj kuyruğunun taşması ile ilgili sorunlar da vardı ve bu da ciddi gecikmelere neden olabiliyordu. Durumu düzeltmek için ağ eşleştirme yığınını, sunucuyla iletişimin RPC çağrıları yerine paketler ve oyun durumu alma yoluyla gerçekleştiği daha geleneksel bir modele taşımaya karar verdik. Yeni çevrimiçi maç mimarisine WorldState adı verildi ve Photon'u oyundan kaldırmayı amaçlıyordu. LightNetLib kütüphanesini temel alan aktarım protokolünü Photon'dan UDP'ye değiştirmenin yanı sıra, bu yeni mimari aynı zamanda istemci-sunucu iletişim sisteminin kolaylaştırılmasını da içeriyordu. Bu özellik üzerinde çalışmanın bir sonucu olarak, sunucu tarafındaki maliyetleri düşürdük (Windows'tan Linux'a geçiş ve Photon Server SDK lisanslarından vazgeçerek), kullanıcı uç cihazları için çok daha az talepkar olan ve sorun sayısını azaltan bir protokol elde ettik. sunucu ve istemci arasındaki durum senkronizasyonunun bozulmasıyla yeni PvE içeriği geliştirme fırsatı yarattı. Oyunun kodunun tamamını bir gecede değiştirmek imkansız olacağından WorldState üzerindeki çalışmalar birkaç aşamaya bölündü. İlk aşama, istemci ile sunucu arasındaki iletişim protokolünün tamamen yeniden tasarlanmasıydı ve mekanizmaların hareketi yeni raylara kaydırıldı. Bu, oyun için yeni bir mod oluşturmamıza olanak sağladı: PvE. Yavaş yavaş, mekanikler sunucuya, özellikle de en yenilerine (mekanik hasar ve kritik hasar) taşınmaya başladı. Eski kodun WorldState mekanizmalarına kademeli olarak aktarılmasına yönelik çalışmalar devam ediyor ve bu yıl da birkaç güncellememiz olacak. 2022'de yeni bir platformu kullanıma sunduk: Facebook Cloud. Platformun arkasındaki konsept ilginçti: Son oyuncunun oyunu çalıştırmak için güçlü bir PC'ye veya akıllı telefona sahip olmasına gerek kalmadan, oyunları buluttaki emülatörlerde çalıştırmak ve bunları akıllı telefonlar ve PC'lerdeki tarayıcıya aktarmak; yalnızca istikrarlı bir İnternet bağlantısı gereklidir. Geliştirici açısından bakıldığında, platformun kullanacağı ana yapı olarak iki tür yapı dağıtılabilir: Android yapısı ve Windows yapısı. Bu platformdaki daha büyük deneyimimiz nedeniyle ilk yolu seçtik. Oyunumuzu Facebook Cloud'da başlatmak için oyundaki yetkilendirmeyi yeniden yapmak ve imleç kontrolünü eklemek gibi çeşitli değişiklikler yapmamız gerekiyordu. Ayrıca platformun CDN'yi desteklememesi nedeniyle tüm yerleşik kaynakları içeren bir yapı hazırlamamız gerekiyordu ve emülatörlerde her zaman doğru şekilde çalışamayan entegrasyonlarımızı yapılandırmamız gerekiyordu. Grafik yığınının işlevselliğini sağlamak için grafik tarafında da birçok çalışma yapıldı çünkü Facebook emülatörleri gerçek Android cihazları değildi ve sürücü uygulaması ve kaynak yönetimi açısından kendi özelliklerine sahipti. Ancak bu platformun kullanıcılarının hem bağlantıların dengesiz olması hem de emülatörlerin dengesiz çalışması gibi pek çok sorunla karşılaştığını gördük ve Facebook, 2024 yılı başında platformunu kapatma kararı aldı. Programcılar tarafında sürekli yaşanan ve bu kadar kısa bir yazıda ayrıntılı olarak ele alınamayacak olan şey, projenin teknik riskleri ile düzenli çalışma, teknik metriklerin düzenli olarak izlenmesi, hafıza ile sürekli çalışma ve kaynakların optimizasyonu, problemlerin araştırılmasıdır. iş ortağı SDK'larının üçüncü taraf çözümleri, reklam entegrasyonları ve çok daha fazlası. Ayrıca kritik çökmeleri ve ANR'leri düzeltmeye yönelik araştırma ve pratik çalışmalarımızı sürdürüyoruz. Bir proje bu kadar çok sayıda tamamen farklı cihazda çalıştığında bu kaçınılmazdır. Ayrıca sorunların nedenlerini bulmaya çalışan kişilerin profesyonelliğine de dikkat çekmek isteriz. Bu teknik problemler genellikle doğası gereği karmaşıktır ve nedeni bulunmadan önce birkaç analitik sistemden gelen verileri üst üste koymak ve ayrıca bazı önemsiz olmayan deneyler yapmak gerekir. Çoğunlukla karmaşık sorunların çoğunda test edilebilecek tutarlı bir şekilde tekrarlanabilir bir durum yoktur, bu nedenle bunları düzeltmek için sıklıkla ampirik veriler ve mesleki deneyimimiz kullanılır. Bir projedeki sorunları bulmak için kullandığımız araçlar ve kaynaklar hakkında birkaç söz söylenmelidir. AppMetr – oyuncu sorunlarını incelemek için cihazlardan anonimleştirilmiş veriler toplamanıza olanak tanıyan dahili bir analiz çözümü. Okuyucunun daha iyi bilebileceği benzer araçlardan bazıları şunlardır: Firebase Analytics, Google Analytics, Flurry, GameAnalytics, devtodev, AppsFlyer, vb. Google Firebase Crashlytics Google Play Konsolu – Android Vitals Günlükler – stüdyo içindeki oynatma testlerinde sorun aramayı en aza indirmenize olanak tanıyan, hata ayıklama yapılarındaki günlüklerden oluşan bir sistem Açık Test Alanı – oyunumuz, yeni değişiklikleri test etmenize ve çeşitli teknik deneyler yapmanıza olanak tanıyan genel test sunucularına sahiptir. Birlik Profilcisi XCode Aletleri Bu, projenin var olduğu süre boyunca gerçekleştirdiği teknik iyileştirmelerin sadece küçük bir listesidir. Proje sürekli olarak geliştiğinden ve teknik yöneticiler, hem son kullanıcılar hem de stüdyoda onunla çalışanlar da dahil olmak üzere ürünün performansını iyileştirmeye yönelik planlar hazırlamak ve uygulamak için sürekli çalıştığından, gerçekleştirilen her şeyi listelemek zordur. geliştiricilerin kendileri ve diğer departmanlar. Önümüzdeki on yılda ürünün sahip olacağı pek çok iyileştirmemiz hala var ve bunları sonraki yazılarımızda paylaşabileceğimizi umuyoruz. Doğum günün kutlu olsun, War Robots ve tüm bunları mümkün kılan teknik uzmanlardan oluşan devasa ekibe teşekkürler!
