[Doraemon]

Stellaris geliştirici günlüklerinde bu hafta 3.2 yamasına dair bilgiler veriliyor.

3.2 "Herbert" Yaması Denge Değişiklikleri

Functional Architecture değişikleri hakkında buraya not düşmek gerekiyor; ekstra inşa alanı bu uygarlığın ilgi çekici yönlerinden biriydi fakat uygarlığın bu özelliği insanların ilgisini biraz fazla çekmeye başlamıştı (çıktığında yaşanan heyecandan sonra bile).

Lem yamasında olduğu gibi önceden bir denge düzenlemesi planlamış olmasak da sürekli değiştirilmesi ve ayarlanması gereken yerler buluyoruz oyunda. İlerleyen güncellemelerde de böyle yapmaya devam edeceğiz.

...ve şimdi performans iyileştirmeleri ve modlama konusunda sözü Caligula Ceasar’a bırakıyorum.

Kodlamaya Göz Atış
Merhaba! Oyunun kodlama dili ve modlanabilirlik konusundaki özellikleri hakkında uzunca bir düz yazı bekliyorsunuz… Fakat bu sefer, o konular hakkında söyleyebileceğim çok bir şeyim olmasa da yine de bahsedebileceğim bazı havalı ve teknik şeyler var.

Kodlama dilini çok iyi bilmeme rağmen, kullandığımız kodların performansı nasıl etkileyeceği benim için hâlen büyük bir gizem. Eklediğim bir şey performansı etkileyecek mi? Tabiki kodu nasıl daha etkili bir şekilde kodlayabileceğim konusunda oldukça fazla tahmin yürütebilirim ve bu, kodlamanın genel konsepti içerisinde bazen bu tahminler tutabilir. Fakat aradaki performans farkı ne kadar olacak? Ayrıca karmaşık kodları bulup onları geliştirerek ne kadar performans kazanabiliriz?

Moah, bir süre önce EU4 kodlama denetleyicisini Stellaris’e taşımada iyi bir ilerleme sağlamıştı. Fakat tek sorun, denetleyicinin kod üzerindeki bilgisi oldukça yetersizdi (çünkü çalışması için kodunun çoğu yerine künyeler yerleştirmek gerekiyor; basitçe ifade etmek gerekirse bu künyeleri bir efektin veya olayın başladığı her yere…). Ayrıca kodlarda sunulan bilgiyi okumak da oldukça zordu. Fakat şimdi, oyun tasarımcılarının insiyatifiyle, artık bu denetleyici ile neler yapabileceğimizi görmenin vakti geldi. 

Kodlardaki bilginin çözümlenmiş, sistematik ve okunabilir hâle getirilmesi üzerine sinir bozucu bir uğraştan sonra, oyunu büyük galaksi ayarlarında ve yapay zekaya ek avantajlar (0.75 araştırma maliyeti ve 1.25 yaşanabilir gezegen gibi bonuslar) vererek kodlayıcı denetleyicisi açıkken bir süre çalıştırdım. Sonra hatalar bulunabildi. Aldığımız çıktıların iki versiyonunu sizinle paylaştım: biri ilk denemelerde olduğu gibiydi- yani çalışmanın daha geniş kapsamlı bir şekilde yapılmasından öncesi gibiydi (özellikle, aktifleştirilmiş etkiler ve ekonomik tablolar hâlen yoktu), aynı zamanda kod üzerinde herhangi bir optimizasyon yapılmasından da önceydi bu- 3.2 yamasının betasındaki durum gibi. (Denememde; optimizasyonu yapılmamış hata ayıklama modunda denetleyicinin açılmasıyla birlikte her değerin hesaplanması için geçen zamanın ne kadar arttığına dikkat edin.)

Şimdi, belirtmem gerekiyor ki kodlama denetleyicisini bazı teknik sorunlar yüzünden 3.2 yamasıyla birlikte halka açmayacağız: kodlayıcıyı açmak oyunu %50 oranında yavaşlatıyor, yani hâlen denetleyicinin -ve performans etkisinin- istenildiği zaman açılıp istenildiği zaman kapatılabileceği bir yol bulmak için çalışmamız gerekiyor (ve bunu yapabilmemizin yolu şu anda; açık kodda olmayan derleyicilerde saklı.). Ama bu denetleyiciyi ilerleyen zamanda modçularla paylaşabilmeyi umut ediyoruz.

Erken Kazanımlarımız
İlk bulgularımızdan biri de oyun bazı kuralları her topluluk için sürekli ve çok sayıda kez tekrar ediyor olmasıydı, bu da oyunun performans konusunda dengesizliğe yol açıyor ve eşit bir performans alınmasını engelliyordu. En büyük sorun “can_vote_in_democratic_election” koduydu ki bu da oyunda yer alan tüm ülkelerdeki toplulukların destek değerini belirlemek için her gün ölçüldüğü ortaya çıktı. Evet doğru okudunuz: oyun emperyalist imparatorluklarda tüm ülkedeki her topluluğun oy verip veremeyeceğini kontrol ediyor, sonra başka ülkeleri sonra da tekrardan imparatorluk ülkesinde bunu yapıyor ve böylece devam ediyor… Bu tür sorunlar oyunda günlük cache dosyalarının oluşturmasıyla çözüldü: toplulukların durumları her gün bir kez hesaplanacak (veya, “species_has_happiness” kodunda olduğu gibi ülkedeki her tür için bir kez hesaplanıyor) ve kodun diğer yerleri ise sadece sonuca atıfta bulunacak. Dahası, toplulukların destek hesaplamalarında genel bir optimizasyona giderek her birlik için destek hesaplamasının yapılmasından ziyade her ülke için bu hesaplama yapılma yoluna gidildi.

Kodlama alanında ise, bazı parçaları ayrıştırarak, kodun bazı yerlerini kolaylıkla optimize edebileceğimizi fark ettik. Öncelikle “graygoo.555” kodu Gray Goo aktifken gerçekleşebilecek olayları (eventleri) Gray Goo aktif olmasa da çok sayıda kez tetiklemeye çalışıyordu. Ortaya çıktı ki bunun olmasının nedeni kodun “is_triggered_only” kodunun eksik olmasıydı, bu yüzden de “gray goo” kodu her gün her gezegen için tetiklenmeye çalışıyordu! Benzer şekilde, bazı test olayları da aynı şekilde kodlanmış, fakat “always = no” kodu da test olaylarının gerçekleşmesini sağlıyordu (bu yüzden bu test olayları asla gerçekleşmiyordu). Bunların performans üstünde küçük de olsa hissedilebilen bir etkisi vardı, bu yüzden ortadan kaldırılmaları gerekti.

Diğer tüm fikir düzenleyicilerden daha fazla performansa etki eden “triggered_opinion_galactic_community_in_breach” düzenleyicisi, ilk önce tuhaf gözükmüştü. Fakat aslında düzenleyicilerin sırasını değiştirerek bu problemi  düzeltilebileceği ortaya çıktı: oyun Galcom üyeliğini kontrol etmeden önce “is_in_breach_of_any” kodunu kontrol etmek istiyordu- kulağa çok büyük bir problemmiş gibi gelmiyor ama bu etkileyici: uygulanan tüm önergelerin ihlal edilip edilmemesi gibi durumlarını kontrol edemesine yol açacak başka bir etkiyi tetikliyordu yani aslında birçok etkiyi bir anda tetiklemiş oluyordu. Basitçe kodun sırasını değiştirmek olumlu bir sonuç verdi.

Son olarak, crime.1 olayı (oyunun erken versiyonlarındaki en yüklü olayların ikincisiydi) için aynı durum söz konuydu fakat daha karmaşık bir haldeydi. Buradaki asıl konu altta verdiğim kod parçasıydı:

Kod:

OR = {
            AND = {
                count_owned_pop = {
                    limit = {
                        is_shackled_robot = no
                        is_unemployed = yes
                        NOR = {
                            has_living_standard = { type = living_standard_utopian }
                            has_living_standard = { type = living_standard_good }
                            has_living_standard = { type = living_standard_shared_burden }
                        }
                    }
                    count > 3
                }
                owner = { is_gestalt = no }
            }
            AND = {
                count_owned_pop = {
                    limit = {
                        is_unemployed = yes
                        NOT = { has_living_standard = { type = living_standard_organic_trophy } }
                    }
                    count > 10
                }
                owner = { is_gestalt = yes }
            }
        }

Kod bu haliyle oldukça yavaş çalışıyordu ve önceden elde ettiğimiz sonuçlardaki aynı prensipleri kullanmanın fazlaca faydasını gördük. “Count_owned_pop” ayrıca herhangi bir şeyi hesaplamanın performans açısından yüklü bir yol çünkü bu kodu oyunun içinde işlenecek şekilde dönüştürürken oldukça fazla performans kaybı oluyordu. Kodun işleyişi ise şu şekilde gerçekleşiyordu: örneğin 80 topluluğun olduğu bir gezegende, kod döngü haline girerek her topluluk için hesaplama yapıyordu ve her topluluk için bir dizi tetikleyiciyi kontrol ediyordu. Ne yazık ki bu sıralama ile yüzünden 3 adet işsiz topluluğun olduğu her gezegende kodun şartlarını günde iki kez kontrol ediyordu:

• Olay tetikleyicisi için gerekli şartlar gayrimeskun  gezegenlerde her gün kontrol ediliyordu. Ya da daha az sıklıkta olsa da yılda 44000 kez, kesin konuşmak gerekirse.
  
• Gezegenlerde ne tür toplulukların çalışmadığını kontrol etmeden önce gezegende işsiz topluluk olup olmadığını kontrol etmiyordu. “OR” kodu tüm “count_owned_pop” bölümünde de hatalı sonuç veriyordu ki bu da kodun tekrardan başa sararak kontrol yapmasına yol açıyordu. “num_unemployed > 3” kodunun, başlangıca yerleştirilmesiyle performans açısından büyük bir fayda sağladı.
  
•  İşsiz toplulukların “gestalt” etiğinde olup olmadığını kontrol ettikten sonra ülkenin “gestalt” bilincinde olmadığını kontrol ediyordu. “Gestalt” kontrol sırasının başa gelecek şekilde değiştirilmesiyle birlikte kodun sadece bir “count_owned_pop” döngüsünü kullanacak şekilde ayarlanmış oldu.
  

Kod:

num_unemployed > 3 #early out before the expensive count_owned_pop to come
        OR = {
            AND = {
                owner = { is_gestalt = no }
                count_owned_pop = {
                    limit = {
                        is_unemployed = yes
                        is_shackled_robot = no
                        NOR = {
                            has_living_standard = { type = living_standard_utopian }
                            has_living_standard = { type = living_standard_good }
                            has_living_standard = { type = living_standard_shared_burden }

                        }
                    }
                    count > 3
                }
            }
            AND = {
                owner = { is_gestalt = yes }
                count_owned_pop = {
                    limit = {
                        is_unemployed = yes
                        NOT = { has_living_standard = { type = living_standard_organic_trophy } }
                    }
                    count > 10
                }
            }
        }

İlerleyen Analizlerden Elde Edilen Kazanımlar
Bunlar havalı değişikler olsa da bunların ötesinde sadece elimizdeki listeye bakarak daha fazla önemli performans kazanımları elde etmemiz biraz zorlaştı. Ve tablolama yönetimine hoşgeldiniz! Elimizdeki sonuçları bir tabloya kopyaladık; birkaç formül ve bir pivot tablo kullandıktan sonra kodlar arasında “tüm potansiyel işlerin toplam etkisinin” ve “topluluklar üzerinde tüm kodların etkisinin” ne olduğu konusunda analiz yapmamızı sağlayacak duruma geldik.

Buradaki görsel performans geliştirmelerinden sonraki değerleri gösteriyor

Bu bize bazı şeyleri belirlememizi sağladı. Öncelikle “ai_resource_production” az miktarda hesaplama yapmasına rağmen absürt miktarda yüksek performans yüküne neden oluyordu. Buradaki suçlu ise “planet_resource_compare” (çoğunlukla burada kullanılan) tetikleyicisinin oldukça yüklü olmasıydı. Kısaca buradaki sorun ise tüm gezegenlerdeki her kaynağın, kaynak değerlerini tekrardan hesaplamasıydı (ayrıca bu hesaplamaya her topluluğun ürettiklerini de dahil edin!). Elde ettiğimiz sonuçlardan ortaya çıktı ki bu durumu, sadece ilgili kaynakların seçilerek yeniden hesaplanmasıyla birlikte bir noktaya kadar (%75’e kadar)  azaltabileceğimizin mümkün olduğunu gördük. Fakat performans yükünün azaltılması yeterli değildi, bu yüzden tetikleyicinin kullanımını biraz azalttık. Mod yapanların da bu kodu çok fazla kullanmamasını tavsiye ediyorum.

Gördüğümüz başka bir şey de, ummadığımız bir şekilde, “iş”lerin aslında performans olarak çok yüklü olmasıydı. Spesifik olarak ağırlıkları ve “muhtemelen” kontrolleri çok fazla yük bindiriyordu. Ağır olmaları konusunda nasıl zaman ve performans kazançları sağlayabileceğimiz hakkında bazı fikirlerimiz olsa da henüz bunlar hakkında konuşmayacağız (bu sorunu 3.2 yamasını hazırlarken çok geç fark ettik çünkü üstlerinde bazı yenilemeler yapmak zorunda kaldık) fakat muhtemel kontroller üzerinde bunları nasıl hafifleteceğimiz konusunda bazı yollar bulduk. Her yedi günde bir, toplulukların iş önbelleklerini yeniden hesaplayacak ve böylece toplulukların her işte çalışmaya elverişli olup olmadığını kontrol ettikten sonra hesaplamalarına devam edecek. Çoğu işin genelde ilk kısmı kontrol edecek standart “muhtemel” kontrol şemaları var - spesifik olarak, sırasıyla; işçi, uzman, yönetici ve drone işlerinde çalışanları arasında paylaşılan bir dizi tetikleyici var. Bazı değişikler ile birlikte; topluluklar üzerindeki bu 4 hesaplamayı önceden yapıp sonra işler arasında bir döngü oluşturarak doğru sonuçları doğru işler ile eşleştirerek önemli bir (neredeyse 3’te 2 oranında) performans kazancı elde edebileceğimiz ortaya çıktı.

(Mod yapanlara not: kodun formatı artık biraz daha farklı. Eğer daha önceden “worker/specialist/complex_specialist/ruler/drone_job_check_trigger” kodunu kullanacaksanız, artık örneğin “possible_precalc = can_fill_ruler_job” gibi yolları belirlemeniz gerekiyor. Eğer bunu uygulamak istiyorsanız artık yeni versiyonda bunları “game_rules” bölümünden değiştirmelisiniz.”)

Son olarak oyundaki kurallar çoktan optimize edilerek bazı performans sorunları giderilmiş olsa da bazı noktalarda hâlen geliştirilecek noktalar da yok değil. İlki toplulukların var olup olmadığını kontrol etmekti. Kod ve kodun işleyişi de toplulukların bir gruba katılıp katılamayacağını kontrol ettiği ortaya çıktı ki, grup kurulduktan sonra bunu kontrol etmeyi bırakıyordu. Açıkça ortada olduğu gibi, bu ideal bir yapı değil, yani kodun kontrol yapma gerekliliği kaldırıldı ve işleyişte de azalan toplulukların da geçersiz sayılması esas hâle gelecek şekilde değiştirildi.

İkinci olarak bir topluluğun bir gruba ait olup olmadığına karar vermekti: hemen hemen tüm gruplar kendi kültür yapısına uygun toplulukların kendisine katılmasına izin verse de bu kontrol son bölüme koyulmuştu. Kontrol kodunu başlangıca getirince bu hesaplamanın yükünü büyük ölçüde azaltabildik.

Son olarak -her grup için her gün kontrol edilen- bir grup talep oldukça aşırıydı. Sıralamanın değiştirilmesiyle ve eşdeğer fakat daha hafif kontrol kodlarının (örneğin any_owne_pop yerine any_owned_species kodunun) kullanılmasıyla performans artışına gidildi. Bunun da oldukça önemli bir etkisi vardı, yani topluluk gruplarının (kullandıkları oyun kuralları dışındaki) ayak izleri üçte iki oranında azaltılmış oldu.

İleride Çalışacağımız Performans Sorunları
Yaptıklarımız umarım en azından oyunun son bölümde kendini hissettirir bir performans artışı sağlacaktır. Yaptığım testler bu yönde olumlu sonuçlar elde ettiğimizi gösteriyor fakat ne ölçüde bir performans artışının yaşandığını söylemek oldukça güç. Ne var ki bu çalışmamız sadece kod performansının ayakizi üzerinde odaklanmıştı, yani bakmamız gereken daha fazla farklı şey olacak. Performans söz konusu olduğunda iş asla bitmez ve 3.3 yamasına kadar yeni geliştirmeler yapabileceğimiz zamanımız olacaktır umarım.

Örneğin, oyunun sonlarına doğru kullanıcı arayüzünün (user interface) gecikmeli çalıştığı yönünde bazı şikayetler duydum. Bu durum yaptığımız performans çalışmasıyla birlikte birazcık düzelmiş olabilir fakat yine de yaptığımız çalışmalar kullanıcı arayüzü üzerine değildi. Çoğu da zaten kullanıcı arayüzünü istediğimiz kadar hızlandırmadı. Özellikle gezegen ve tür görüntüleme ekranlarında ve kolonizasyon seçme menüsünde istediğimizi elde edemedik ve bunları hızlandırmak için çalışıyoruz (ve, tabi ki, eğer başka sorunları düşünen birileri varsa bunları belirtmeniz yararlı olabilir).

Modlanabilirlik Geliştirmeleri
Modlanabilirlik geliştirmelerinden bahsetmeden herhangi bir geliştirici günlüğü yazmak istemiyorum. Dediğim gibi şimdilik bunlardan çok fazla yok fakat insanların hoşuna gidebilecek birkaç şey de var:

• “Create_nebula” efekti oyuna eklendi. Ama galaksi haritasındaki görsel efektler oyun sırasında yenilenmediğinden, bu efekti en azından galaksi oluştururken kullanmak en iyisi olacaktır.
  
• Kararlar için şimdi “on_queued” ve “on_unqueued” efekti eklendi.
  
• Terraformlama şimdi Megacorp ekonomik sistemini kullanıyor. Bu da demek oluyor ki artık maliyetlerin artık ayarlanabilir kaynak tabloları var ve  artık “economic_unit” düzenleyicisiyle birlikte bunları uygulayabilirsiniz.
  
• “Species_gender” tetikleyicisi eklenerek artık türlerin liderinin cinsiyetininin ne olabileceğini kontrol edebiliyorsunuz.
  
• Artık ayrıca galaksi haritasında üzerine geldiğinizde çıkacak kendiniz özel ipuçlarını ayarlayabilirsiniz.
  
• “On_capital_changed” ve “on_planet_class_changed” kodları için şimdi “on_actions” kodu kullanılabilir.
  
• “Traditions” için, eğer “Traditions” uygulanmazsa bunu ifade edecek ipuçları gösterilecek artık.
  

Ayrıca mod yapımcılarının güncellemesi gereken bazı şeyler olacak (bahsedildiği üzere Terraformlama dışında):

• “any/count/every/random_planet_army” kodu gezegenin yöneticisinin askerleri yerine şimdi gezegendeki tüm askerleri kastediyor.
  
• “Set_starbase_building/module” ve varyantlarını kaldırmak için geçerli olan kodlar, “0” değerinde olmak yerine artık hepsi “1” değerinde.
  
• “component_templates, valid_for_country” kodu ağırlık merkezi olmak yerine artık tetikleyici görevinde.
  
• “Fire_on_action” kodunun “prev” ve “from” değerlerini belirlerken çıkan sorunlar artık çıkmıyor.
  

Mod konusunda son bir not olarak da; eğer kapsamlı ve uzunca yazılmış geliştirici günlüklerini özleyen varsa endişe etmeyin! Yeni oyunlarımızda kodlama konusunda uğraşanlar varsa kullandığımız kodlama dilinde çok fazla potansiyel olduğunu biliyorsunuzdur. Çalışmakta olduğumuz bazı havalı şeyler var, ama bunlardan henüz söz edebileceğimiz veya hangi yamada olduğunu söyleyecek bir seviyede değiller.

Son olarak da kodlama konusundaki dokümanlarımızı yapımcı günlüğünün sonuna ekliyorum ki eğer değişikler konusunda atladığımız bir şey varsa kendiniz bakıp görebilirsiniz. Ayrıca modlarınızı güncellemek istiyorsanız ve 3.2 yamasına erken erişim sağlamak istiyorsanız, şu bağlantı üzerinden başvuruda bulanabilirsiniz: https://pdxint.at/3bZbVJN