Haritalandırma kısmında herhangi bir limitasyon görüşü malesef şahıslar bazında bir yorumdan öteye geçemez.
Bu kadar basit işte anlayana...
Oyunun bize koyduğu temel teknik sınır, 32-bit mimariden gelen bellek adresleme limitidir. 32-bit bir süreç en fazla 2^32 baytı adresleyebilir; bu da yaklaşık 4 GB’lık bir sanal adres alanına karşılık gelir. Bu nedenle oyun (özellikle sunucu prosesi) yüksek yük altında CPU’dan önce çoğunlukla virtual address space sınırına takılır: yük arttıkça daha fazla bellek ayırma ihtiyacı doğar, ancak 32-bit dünyada bu kapasite sert biçimde sınırlıdır. Sonuç olarak çökme, çoğu senaryoda “RAM yetmedi” değil, adres alanı tükendi / parçalandı (fragmentation) seviyesinde gerçekleşir.
Bu çerçevede “yeni bölge eklemek” bellek tüketimini doğrudan artırır. Sunucu texture taşımasa da yeni bir bölge; harita verileri, collision/navmesh (pathfinding), spawn tabloları, NPC state’leri ve script engine verileri, bölgeye özel event/instance yönetimi gibi kalemleri beraberinde getirir. Ayrıca bölge büyüdükçe entity sayısı (item drop, mob, oyuncu yoğunluğu) artar ve bu da heap üzerinde daha fazla allocation demektir. Özetle, bölge sayısı arttıkça sunucunun baseline (taban) bellek ihtiyacı yükselir; yoğun saatlerde de peak daha sert büyür ve 32-bit limitine daha hızlı yaklaşılır.
Karaköy genişlemesiyle seviye sınırının 49’dan 59’a çıkarılması da sadece “seviye” değişikliği değildir. Itemizasyonun genişlemesi, yeni görevler, düşman çeşitliliği, drop tabloları, üretim reçeteleri ve buna bağlı sistemsel büyüme eğilimi; hem baseline’ı hem de peak’i artırarak 32-bit bellek sınırına dayanan bir yapıda stabilite riskini yükseltir.
Bu nedenle “yeni sunucu açma” kararında kademeli açılımı öneriyoruz:
Sunucuyu 49 cap ile açmak (daha düşük baseline/peak ile daha stabil başlangıç),
Karaköy/59 içeriğini planlı ve ölçümlenebilir şekilde rollout etmek,
Her adımda crash kayıtları, RAM/heap kullanımı ve fragmentation göstergeleri üzerinden bellek bütçesini kontrol ederek ilerlemek.
Bu yaklaşım, oyuncu talebini tamamen reddetmeden; 32-bit mimarinin getirdiği sert sınırları yönetilebilir hale getirerek “istikrarı önceleyen” bir geçiş planı sağlar.
Haritalandırma kısmında herhangi bir limitasyon görüşü malesef şahıslar bazında bir yorumdan öteye geçemez.
Bu kadar basit işte anlayana...
Oyunun bize koyduğu temel teknik sınır, 32-bit mimariden gelen bellek adresleme limitidir. 32-bit bir süreç en fazla 2^32 baytı adresleyebilir; bu da yaklaşık 4 GB’lık bir sanal adres alanına karşılık gelir. Bu nedenle oyun (özellikle sunucu prosesi) yüksek yük altında CPU’dan önce çoğunlukla virtual address space sınırına takılır: yük arttıkça daha fazla bellek ayırma ihtiyacı doğar, ancak 32-bit dünyada bu kapasite sert biçimde sınırlıdır. Sonuç olarak çökme, çoğu senaryoda “RAM yetmedi” değil, adres alanı tükendi / parçalandı (fragmentation) seviyesinde gerçekleşir.
Bu çerçevede “yeni bölge eklemek” bellek tüketimini doğrudan artırır. Sunucu texture taşımasa da yeni bir bölge; harita verileri, collision/navmesh (pathfinding), spawn tabloları, NPC state’leri ve script engine verileri, bölgeye özel event/instance yönetimi gibi kalemleri beraberinde getirir. Ayrıca bölge büyüdükçe entity sayısı (item drop, mob, oyuncu yoğunluğu) artar ve bu da heap üzerinde daha fazla allocation demektir. Özetle, bölge sayısı arttıkça sunucunun baseline (taban) bellek ihtiyacı yükselir; yoğun saatlerde de peak daha sert büyür ve 32-bit limitine daha hızlı yaklaşılır.
Karaköy genişlemesiyle seviye sınırının 49’dan 59’a çıkarılması da sadece “seviye” değişikliği değildir. Itemizasyonun genişlemesi, yeni görevler, düşman çeşitliliği, drop tabloları, üretim reçeteleri ve buna bağlı sistemsel büyüme eğilimi; hem baseline’ı hem de peak’i artırarak 32-bit bellek sınırına dayanan bir yapıda stabilite riskini yükseltir.
Bu nedenle “yeni sunucu açma” kararında kademeli açılımı öneriyoruz:
Sunucuyu 49 cap ile açmak (daha düşük baseline/peak ile daha stabil başlangıç),
Karaköy/59 içeriğini planlı ve ölçümlenebilir şekilde rollout etmek,
Her adımda crash kayıtları, RAM/heap kullanımı ve fragmentation göstergeleri üzerinden bellek bütçesini kontrol ederek ilerlemek.
Bu yaklaşım, oyuncu talebini tamamen reddetmeden; 32-bit mimarinin getirdiği sert sınırları yönetilebilir hale getirerek “istikrarı önceleyen” bir geçiş planı sağlar.
Teknik bilgileri gayet net şekilde ifade etmiş arkadaş. Teşekkürler. Videomda da söylediğim üzere " Yapmak isterlerse, yaparlar, çözmek isterlerse çözerler ama isterler mi, bunu birlikte göreceğiz."
Nara yeteneğini engellemek mantıklı bir çalışma olur. Benim anladığım kadarıyla yeni yetenek veya kodlarla boğuşmadan oyundaki hazır yeteneklerle bu iş çözülmeye çalışıyor. Semiha'nın yeteneği görünüşe göre düzgün çalışmıyor. Belkide Boss'a nara atıldığında boss hareket edememeli. Nara yine çalışır ama boss kaçmaması için belirli bir süre kazanılabilir. Hatta belkide boss nara atana bi erg gibi bir şey atar ve nara atan da ölebilir. Tabi burada oyun daha da zorlaşacaktır. Şifacıların ck ile tankı tutmaları gerekir.
DavuTT yazdı: ↑15 Ara 2025 17:23
Nara yeteneğini engellemek mantıklı bir çalışma olur. Benim anladığım kadarıyla yeni yetenek veya kodlarla boğuşmadan oyundaki hazır yeteneklerle bu iş çözülmeye çalışıyor. Semiha'nın yeteneği görünüşe göre düzgün çalışmıyor. Belkide Boss'a nara atıldığında boss hareket edememeli. Nara yine çalışır ama boss kaçmaması için belirli bir süre kazanılabilir. Hatta belkide boss nara atana bi erg gibi bir şey atar ve nara atan da ölebilir. Tabi burada oyun daha da zorlaşacaktır. Şifacıların ck ile tankı tutmaları gerekir.
Yetenek sistemine müdahale söz konusu olamaz.
Yapılabilecek en optimum şey;
Olası her hiddet sıfırlaması sonrasında(nara atarak, acıma yaparak vb. vb.) tüm bosların sersemletme atarak içine çekme yeteneği kullanması olmalıdır. Bu sayede gbz gibi bosslarda savaşçının da önemi ayrıca öne çıkar.
Umarız çözüm önerileri dikkate alınır ve sürdürülebilir bir oynanış gerçekleşir. Oyunun ortamını ve insanlarını seviyorum. Hoş sohbetlerin ve dostluğun olacağı bir ortamı inşa edecek sistemin oluşu da bunu daha güzel kılacaktır.
