Metin2 Quest Optimizasyonu Nasıl Yapılır? Gereksiz Yük ve Hatalı Döngüleri Azaltma

Metin2 quest optimizasyonu yalnız quest dosyasının daha kısa yazılması değildir. İyi optimize edilmiş bir quest, gereksiz yere tetiklenmeyen, ağır işlemleri sürekli tekrarlamayan ve oyuncu sayısı arttığında Game processine orantısız yük bindirmeyen yapıdır.

10 oyunculu test serverında fark edilmeyen küçük bir verimsizlik, 500 veya 1000 eş zamanlı oyuncuda ciddi CPU tüketimine dönüşebilir.

Bu nedenle quest performansı production yükü düşünülerek değerlendirilmelidir.

Quest Sistemi Game Performansını Nasıl Etkiler?

Questler oyun içerisindeki birçok olaya tepki verebilir.

Örneğin:

• login,
• logout,
• kill,
• levelup,
• NPC konuşması,
• item kullanımı,
• timer

gibi olaylar quest çalıştırabilir.

Seyrek çalışan bir işlem ağır olsa bile fark edilmeyebilir. Fakat her mob öldürüldüğünde veya çok kısa timer aralığında çalışan aynı kod yüksek oyuncu sayısında binlerce kez tetiklenebilir.

Temel problem çoğu zaman tek işlemin maliyeti değil:

işlem maliyeti × tetiklenme sayısıdır.

Önce Hangi Questin Sorunlu Olduğu Bulunmalı

Bütün questleri rastgele değiştirmek doğru optimizasyon yöntemi değildir.

Önce:

• CPU probleminin ne zaman başladığı,
• hangi güncellemeden sonra oluştuğu,
• hangi map veya event sırasında arttığı

belirlenmelidir.

Örneğin CPU yalnız yeni event aktif olduğunda yükseliyorsa event questi güçlü adaydır.

Login Questleri Neden Dikkat İster?

Oyuncu giriş yaptığında çalışan questler normal zamanda problem oluşturmayabilir.

Fakat server açılışında yüzlerce oyuncu kısa sürede giriş yaptığında aynı kod yüzlerce kez çalışır.

Login eventi içerisinde gereksiz:

• database sorguları,
• uzun kontroller,
• tekrar eden hesaplamalar

bulunması açılış yükünü artırabilir.

Bu nedenle login questleri mümkün olduğunca kontrollü tutulmalıdır.

Kill Eventleri Çok Sık Çalışabilir

Farm serverlarda oyuncular dakikada çok sayıda mob öldürebilir.

Bir when kill mantığının içerisinde ağır işlemler varsa yük hızla büyüyebilir.

Örneğin teorik olarak:

500 oyuncu × dakikada 20 kill = dakikada 10.000 tetiklenme.

Her tetiklenmede gereksiz ağır işlem yapılması productionda ciddi fark oluşturabilir.

Timer Kullanımı Neden Önemlidir?

Timerlar gerekli sistemlerde oldukça kullanışlıdır fakat çok kısa aralıklarla gereksiz kontrol yapmak verimsiz olabilir.

Örneğin bir değerin dakikada bir kontrol edilmesi yeterliyken saniyede bir kontrol edilmesi yaklaşık 60 kat daha fazla tetiklenme oluşturabilir.

Bu nedenle timer aralığı işin gerçek ihtiyacına göre belirlenmelidir.

Server Timer ile Oyuncu Timerı Aynı Mantıkta Değerlendirilmemeli

Bir işlem bütün server için bir kez çalışması gerekirken her oyuncu için ayrı timer oluşturulması gereksiz yük yaratabilir.

Örneğin global event zamanını kontrol eden mekanizma oyuncu başına ayrı ayrı çalışıyorsa online sayısı arttıkça maliyet büyüyebilir.

İşlemin kapsamı önce belirlenmelidir:

Bu kontrol server genelinde mi, oyuncu özelinde mi yapılmalı?

Gereksiz SQL Sorguları Quest Performansını Etkileyebilir

Bazı özel quest yapıları doğrudan database sorguları kullanabilir.

Örneğin her kill işleminde aynı database bilgisini tekrar okumak hem Game hem MySQL tarafında gereksiz yük oluşturabilir.

Bir veri quest içerisinde zaten mevcutsa veya daha seyrek güncellenebiliyorsa her tetiklemede SQL çalıştırmak doğru olmayabilir.

Özellikle yüksek oyunculu serverlarda:

küçük sorgu × binlerce tekrar = büyük database yükü

haline gelebilir.

SQL Sonucunu Kullanmadığınız Sorguları Çalıştırmayın

Quest geliştirirken debug veya eski sistemden kalmış sorgular productionda unutulabilir.

Sonucu hiçbir yerde kullanılmayan sorgular:

• MySQL CPU,
• network,
• database connection

üzerinde gereksiz yük oluşturur.

Production öncesi kullanılmayan kodlar temizlenmelidir.

Sürekli Oyuncu Listesi Taramak Riskli Olabilir

Bazı özel sistemlerde bütün online oyuncular üzerinde sık sık işlem yapılmak istenebilir.

100 oyuncuda hafif görünen bu yapı 1000 oyuncuda on kat daha fazla işlem oluşturabilir.

Özellikle bu tarama başka bir döngünün içerisinde yapılıyorsa maliyet daha hızlı büyüyebilir.

Bu nedenle mümkün olduğunda olay bazlı tasarım tercih edilmelidir.

Event-Driven Mantık Neden Daha Verimli Olabilir?

Bir durum yalnız değişiklik gerçekleştiğinde kontrol edilebiliyorsa sürekli polling yapmak yerine ilgili olayda işlem yapmak daha verimli olabilir.

Örneğin bir değer yalnız oyuncu level aldığında değişiyorsa her birkaç saniyede oyuncunun levelini kontrol etmek yerine levelup olayında değerlendirmek daha mantıklıdır.

Bu yaklaşım:

sürekli kontrol yerine gerektiğinde çalışma

mantığıdır.

Quest State Yapısı Sade Tutulmalı

Quest state sistemi iş akışını düzenlemek için kullanılır.

Ancak gereksiz karmaşık state geçişleri:

• bakım zorluğu,
• beklenmeyen tetiklenmeler,
• debug problemleri

oluşturabilir.

Optimizasyon yalnız CPU kazanmak değildir. Kodun tahmin edilebilir olması da production güvenilirliğini artırır.

Aynı Hesabı Tekrar Tekrar Yapmayın

Quest içerisinde aynı sabit veya aynı event süresince değişmeyen değer tekrar hesaplanıyorsa uygun kapsamda bir kez hesaplanması düşünülebilir.

Ancak cache benzeri optimizasyon yapılırken eski veri kullanma riski de değerlendirilmelidir.

Amaç:

gereksiz tekrarları azaltırken oyun mantığını bozmamaktır.

Debug Mesajları Productionda Yük Oluşturabilir

Geliştirme sırasında faydalı olan yoğun debug çıktıları productionda gereksiz log üretimine neden olabilir.

Özellikle çok sık tetiklenen questte her çalışmada log yazılıyorsa:

• disk I/O,
• log boyutu,
• hata analizi

olumsuz etkilenebilir.

Debug çıktıları production sürümünde kontrollü kullanılmalıdır.

Quest Hatası Log Spam Oluşturuyorsa

Bir quest saniyede tekrar tekrar hata üretiyorsa yalnız log dosyasını silmek çözüm değildir.

Hatanın tekrar çalışmasına neden olan:

• timer,
• event,
• yanlış fonksiyon çağrısı,
• eksik değer

düzeltilmelidir.

Aksi halde log temizlendikten kısa süre sonra tekrar büyür.

Quest Değişikliğini Direkt Productionda Denemeyin

Özellikle:

• event,
• dungeon,
• ekonomi,
• item

ile ilgili quest değişiklikleri test serverında denenmelidir.

Testte yalnız normal kullanım değil:

• iptal,
• disconnect,
• tekrar giriş,
• aynı anda çok oyuncu,
• beklenmeyen item durumu

gibi uç senaryolar da kontrol edilmelidir.

Quest Reload Her Zaman Güvenli mi?

Çalışan server üzerinde quest reload işlemleri bazı durumlarda kullanılabilir ancak productionda aktif oyuncuların bulunduğu quest state yapıları düşünülmelidir.

Büyük değişikliklerde kontrollü bakım ve restart daha güvenli olabilir.

Filesın yapısına göre davranış değişebileceği için her değişiklik için tek yöntem kullanılmamalıdır.

Optimizasyondan Önce Ölçüm Alın

Quest değiştirilmeden önce:

• Game CPU,
• ilgili core,
• oyuncu sayısı,
• map yoğunluğu

kaydedilmelidir.

Değişiklik sonrasında aynı koşullarda tekrar ölçüm yapılır.

Örneğin:

Önce:
CH1 Core2 = %91 CPU

Quest düzenlemesi sonrası aynı yoğunluk:
CH1 Core2 = %57 CPU

gibi ölçülebilir sonuç optimizasyonun gerçekten işe yaradığını gösterir.

Quest Performans Kontrol Tablosu

Quest Optimizasyonunda Yapılmaması Gerekenler

Performans uğruna gerekli kontroller kaldırılmamalıdır.

Örneğin item verme sistemindeki güvenlik kontrolünü kaldırmak birkaç işlem kazandırabilir fakat dupe açığı oluşturabilir.

İyi optimizasyon:

daha az gereksiz işlem + aynı doğruluk

sağlamalıdır.

Sık Sorulan Sorular

Metin2 quest lag yapar mı?

Evet. Çok sık tetiklenen veya ağır işlem yapan questler Game CPU kullanımını artırabilir.

Quest sayısı fazla olması sorun mu?

Tek başına değildir. Önemli olan hangi questlerin ne sıklıkta çalıştığıdır.

Timer sayısını azaltmak performansı artırır mı?

Gereksiz veya aşırı sık timerlar varsa evet. Ancak gerekli oyun mekanikleri bozulmamalıdır.

Quest içinden SQL kullanmak yanlış mı?

Her durumda yanlış değildir. Fakat sık eventlerde gereksiz sorgu kullanımı database yükünü ciddi artırabilir.

CPU yüksekse bütün questleri kapatmalı mıyım?

Hayır. Önce problemli process ve olay belirlenmeli, ardından aday questler ölçülmelidir.

Sonuç

Metin2 quest optimizasyonunda en önemli prensip şudur:

Bir kodun ne kadar ağır olduğundan önce kaç kez çalıştığını düşünün.

Tek seferde birkaç milisaniye alan gereksiz işlem, binlerce tekrar sonucunda ciddi Game yüküne dönüşebilir.

Sağlıklı süreç:

ölçüm → problemli event → tetiklenme sıklığı → SQL/timer/loop analizi → düzenleme → yoğunluk testi

şeklinde ilerlemelidir.

Bu yaklaşım özellikle oyuncu sayısı büyüyen Metin2 PvP projelerinde donanım yükseltmeden önce yazılım tarafındaki gereksiz yükün temizlenmesini sağlar.