Unity Realtime Multiplayer'ın tüm kapsamını kapsayan bu serinin ilk yazısında, ağ oluşturmanın temellerini ve kabul edilebilir oyuncu deneyimleri konusunda önemli hususları ele alacağız. Özellikle ağ hızları, bunların arkasındaki altyapı, olası gecikmeler ve bu sorunlarla baş etme yöntemleri hakkında konuşacağız. Mobil, konsol, PC veya VR gibi modern oyunların çoğu için ağ etkileşimi kritik öneme sahiptir. Basit bir çok oyunculu oyun ya da iddialı bir MMO oyunu oluşturmanız fark etmez; ağ programlama bilgisi çok önemlidir. Herkese merhaba, ben MY.GAMES'in Baş Yazılım Mühendisi Dmitrii Ivashchenko. "2023'te Birlik Ağ Ortamı" hakkındaki bu makale dizisi, ağ ortamlarının kritik yönlerini ve kısıtlamalarını kapsayacak, çeşitli protokolleri (TCP, UDP ve WebSocket dahil) inceleyecek ve Güvenilir UDP protokolünün önemini vurgulayacaktır. NAT'ın gerçek zamanlı çok oyunculu oyunlar üzerindeki etkisini keşfedeceğiz ve oyun verilerinin ağ aktarımı için hazırlanması konusunda size rehberlik edeceğiz. Temellerden taşıma protokolleri, ağ mimarisi kalıpları, Unity için hazır çözümler ve daha fazlası gibi daha gelişmiş kavramlara kadar çeşitli konulara bakacağız. Projeleriniz için en uygun seçimi bulmanıza yardımcı olmak amacıyla hem resmi Unity çözümlerini hem de üçüncü taraf araçlarını analiz edeceğiz. Bu ilk gönderide, ağ programlamanın kritik unsurlarını ele alacağız ve geliştiricilerin ağ oluşturma özelliğine sahip oyunlar oluştururken sıklıkla karşılaştıkları engellere ve sorunlara bakacağız. Altyapıyı anlamak İnternet, her biri benzersiz işlevlere sahip çeşitli cihazlardan oluşan karmaşık bir sistemdir. Bunlardan bazılarından bahsedelim. Tipik olarak bireyin internete bağlantısı bilgisayar veya akıllı telefon gibi bir cihazla başlar. Bunlar, yerel ağ ile ISP arasındaki iletişimi sağlayan yönlendiriciler veya modemler aracılığıyla yerel bir ağa bağlanır. ISP, birden fazla yerel ağdan gelen trafiği yöneten daha büyük yönlendiricilere ve anahtarlara sahiptir ve bu cihazlar, kıtalar ve okyanuslara yayılan yüksek kapasiteli yönlendiriciler ve fiber optik kablolardan oluşan karmaşık bir ağ içeren İnternet'in omurgasını oluşturur; Bu omurganın bakımından omurga sağlayıcıları olarak bilinen ayrı şirketler sorumludur. Ek olarak veri merkezleri, web sitelerinin, uygulamaların ve çevrimiçi hizmetlerin bulunduğu güçlü sunucuları barındırır. Bir web sitesine veya çevrimiçi hizmete erişim talebinde bulunduğunuzda, talebiniz bu geniş ağ üzerinden ilgili sunucuya gider ve ardından veriler aynı yol üzerinden geri gönderilir. Ağ kısıtlamaları TCP, UDP, Aktarma Sunucuları ve gerçek zamanlı çok oyunculu oyun geliştirme dünyasına dalmadan önce, ağ sistemlerini bir bütün olarak sağlam bir şekilde anlamak çok önemlidir. Bu, hub'lar ve yönlendiriciler gibi cihazların rollerini ve işlevlerini anlamayı ve bu cihaz ve ortamların çalışmasından kaynaklanabilecek olası sorunlara ilişkin farkındalığı içerir. Ağ teknolojileri fiziksel dünyadan izole değildir ve çeşitli fiziksel sınırlamalara tabidir: bant genişliği, gecikme, bağlantı güvenilirliği; tüm bu faktörlerin, ağ bağlantılı oyunlar geliştirirken dikkate alınması önemlidir. Bu temel ilkeleri ve kısıtlamaları anlamak, oyunlarınızın başarılı ağ entegrasyonu için gereken olası çözümleri ve stratejileri daha iyi değerlendirmenize yardımcı olacaktır. Bant genişliği Bant genişliği, belirli bir sürede bir ağ üzerinden iletilebilecek maksimum veri miktarıdır. Veri iletim hızları doğrudan mevcut bant genişliğine bağlıdır: bant genişliği ne kadar fazla olursa, aynı anda o kadar fazla veri yüklenebilir. Bant genişliği saniye başına bit cinsinden ölçülür ve iki türde olabilir: simetrik (eşit yükleme ve indirme hızlarıyla) ve asimetrik (farklı yükleme ve indirme hızlarıyla). Simetrik bağlantılar genellikle fiber optik ağlarda olduğu gibi kablolu ağlar için kullanılırken, mobil verilerde olduğu gibi kablosuz ağlarda asimetrik bağlantılar kullanılır. Bant genişliği genellikle saniye başına bit (bps) veya saniye başına megabit (Mbps) gibi katlarla ölçülür. Yüksek bant genişliği, daha fazla verinin daha kısa sürede aktarılabileceği anlamına gelir; bu, gerçek zamanlı çok oyunculu oyunlar için kesinlikle gereklidir. Gidiş-dönüş süresi RTT veya Gidiş-Dönüş Süresi, bir veri paketinin göndericiden alıcıya ve sonra tekrar geri gitmesi için geçen süreyi ölçer. Bu, oyuncuların oyun sırasında yaşayabileceği gecikmeyi etkilediği için ağ bağlantılı oyunlarda önemli bir ölçümdür. RTT yüksek olduğunda oyuncular oyunu olumsuz etkileyebilecek gecikmeler yaşayabilir. Bu nedenle oyun geliştiricileri, daha akıcı ve daha duyarlı bir oyun deneyimi sağlamak için RTT'yi en aza indirmeye çalışmalıdır. Ağ gecikmeleri Ağ gecikmesi (genellikle "gecikme" olarak anılır), bir veri paketinin göndericiden alıcıya iletilmesi için gereken süredir. Birinci şahıs nişancı oyunları gibi yüksek yanıt verme gereksinimleri olan oyunlarda küçük ağ gecikmeleri bile oynanışı önemli ölçüde etkileyebilir. Veriler ışık hızına yakın hızlarda iletilse de mesafe yine de sistemi etkileyerek gecikmelere neden olabiliyor. İnternetin çalışması için gereken altyapı nedeniyle çoğu zaman gecikmeler ortaya çıkar ve giderilemezler. Bu, fiziksel kablolar üzerinden iletim, yönlendiriciler ve anahtarlar gibi ağ cihazlarındaki gecikmeler ve gönderen ve alan cihazlardaki işlem gecikmeleriyle ilgili nedenlerden kaynaklanabilir. Bununla birlikte, bu altyapı gecikmeleri azaltmak için hala optimize edilebilir. Işık hızı ve ağ gecikmesi Veri aktarım araçlarının ağ gecikmesini nasıl etkilediğinden bahsedelim. Optik fiberler aracılığıyla ışıkla iletilen veriler, tam olarak ışık hızında aktarılmaz. Gerçekte, optik fiberlerdeki ışık, fiberin malzemesinin hız üzerinde etkisi olduğundan, vakumda olduğundan daha yavaş iletir. (Işığın maksimum hızı saniyede yaklaşık 299 milyon metre veya saatte 186 bin mildir, ancak yine de bu yalnızca ideal vakum koşullarıyla mümkündür.) Yani optik fiberde ışık göreceli olarak daha yavaş bir hızda iletilir. Ayrıca, bakır kablolarla iletilen verilerin optik fibere kıyasla önemli ölçüde daha düşük olduğunu da belirtelim, çünkü optik fiberler bakır kablolara göre daha fazla bant genişliğine sahiptir ve parazitlere karşı daha az hassastır. Rota Mesafe Zaman (Işık Hızı) Zaman (Optik fiber) RTT Amsterdam - Londra 360 kilometre 1 ms 2 ms 4 ms Amsterdam-New York 5850 kilometre 20 ms 29 ms 58 ms Amsterdam - Pekin 7800 kilometre 26 ms 39 ms 78 ms Amsterdam - Sidney 16700 km 56 ms 83 ms 166 ms Yukarıdaki tablo, veri paketlerinin şehirler arasında geniş bir daire içinde optik fiber üzerinden iletildiğini varsaymaktadır ki gerçekte durum nadiren böyledir. Veri paketlerinin yönlendirilmesi çoğunlukla birçok ara noktaya ("atlamalar") sahiptir ve bu da veri dağıtım süresini önemli ölçüde artırabilir; her ara nokta bir gecikme ekler ve gerçek seyahat süresi önemli ölçüde artırılabilir. Optik fiber üzerinden (ışık hızına yaklaşan hızlarda) iletilen bir veri paketinin Amsterdam'dan Sidney'e gidiş-dönüş yolculuğunu tamamlamak için 150 milisaniyeden fazla zaman gerekiyor. İnsanlar milisaniyelik gecikmelere karşı özellikle duyarlı olmasalar da araştırmalar, 100-200 ms'ye ulaştığımızda gecikmenin insan beyninde zaten farkedildiğini gösterdi. 300 ms'yi aşarsa insan beyni bunu yavaş bir reaksiyon olarak algılar. Ağ gecikmesini 100 ms'yi aşmayacak şekilde azaltmak için içeriğin coğrafi olarak mümkün olduğunca yakın kullanıcılara sunulması gerekir. Veri paketlerinin geçişini dikkatli bir şekilde kontrol etmeli ve mümkün olduğunca az sıkışıklıkla açık bir yol sağlamalıyız. Titreşim Titreşim, ağ gecikmelerindeki bir değişiklik veya "dalgalanmadır"; ardışık veri paketleri arasındaki gecikme süresindeki değişikliği açıklar. Veri paketleri düzensiz aralıklarla ulaştığında bu, ağ aktarımında istikrarsızlık olduğunu gösterir. Buna ağ tıkanıklığı, trafikteki değişiklikler ve ekipman eksiklikleri gibi çeşitli faktörler neden olabilir. Ortalama bir gecikme kabul edilebilir sayılsa bile, yüksek titreşim, özellikle çevrimiçi oyun gibi gerçek zamanlı uygulamalarda veya gecikme tutarlılığının önemli olduğu internet telefonu içeren uygulamalarda sorunlara neden olabilir. Titreme miktarı çok büyükse, oyuncular oyun karakterlerini veya nesneleri hareket ettirirken gecikme veya "kekeme" yaşayabilir. Bu aynı zamanda veri paketlerinin hedeflerine ulaşmaması veya yararlı olamayacak kadar geç ulaşması nedeniyle paket kaybına da yol açabilir. Titreşim aynı zamanda oyunun genel adaletini de etkileyebilir. Örneğin, bir oyuncunun yüksek titreşimi varken diğerinin yoksa, ikincisi avantajlı olacaktır çünkü eylemleri daha hızlı kaydedilecek ve görüntülenecektir. Paket kaybı Paket kaybı, bir veya daha fazla veri paketinin hedeflerine ulaşamaması durumudur. Bu, ağ sorunları, aşırı trafik yükü veya ekipman sorunları gibi çeşitli nedenlerden kaynaklanabilir. Bu tür bilgilerin ilgili olduğu gerçek zamanlı oyunlarda paket kaybı, karakterin "donması", nesnelerin kaybolması veya oyuncular arasında oyun durumu tutarsızlığı gibi gözle görülür sorunlara neden olabilir. Paket kaybı, iletim sırasında gerekli bilgiler kaybolabileceğinden oyunun tamamen kesintiye uğramasına neden olabilir. Bu nedenle paket kaybıyla başa çıkacak veya oyun üzerindeki etkisini en aza indirecek mekanizmalar geliştirmek önemlidir. Tıklama oranı Onay oranı veya simülasyon oranı, oyunun her saniye veri üretme ve yönetme sıklığını ifade eder. Onaylama sırasında sunucu alınan verileri işler ve sonuçları istemcilere göndermeden önce simülasyonlar gerçekleştirir. Sunucu daha sonra bir sonraki onay işaretine kadar dinlenir. Daha hızlı bir tıklama oranı, istemcilerin sunucudan yeni verileri daha çabuk alacağı anlamına gelir, oynatıcı ile sunucu arasındaki gecikmeyi azaltır ve isabet kaydı yanıt verme hızını artırır. 60Hz'lik bir tıklama hızı, 30Hz'den daha verimlidir çünkü simülasyon adımları arasındaki süreyi kısaltarak daha az gecikmeye yol açar. Ek olarak, bu hız, sunucunun saniyede 60 güncelleme iletmesine olanak tanır, bu da istemci ile sunucu arasındaki gidiş-dönüş gecikmesini yaklaşık 33 ms azaltır (istemciden sunucuya -16 ms ve sunucudan istemciye başka bir -16 ms). Bununla birlikte, sunucu her tıklama hızı için ayrılan aralık dahilinde tıklamaları işlemekte zorlandığında lastik bantlama, oyuncuların ışınlanması, reddedilen isabetler ve fizik hataları gibi oyun sorunları ortaya çıkabilir. Örneğin, bir sunucu 60Hz tıklama hızına ayarlanmışsa ancak her tıklama için mevcut olan yaklaşık 16,67 milisaniye (1 saniye / 60) içinde gerekli simülasyonları ve veri aktarımını tamamlayamıyorsa bu sorunlar ortaya çıkabilir. Sınırlamalarla başa çıkmak Gecikme ve paket kaybıyla ilgili bölümlerde tartıştığımız gibi gecikme, çözmemiz gereken bir sorundur ve titreşim, kesintisiz bir oyun deneyimi yaratmayı daha da zorlaştırır. Gecikmeyi göz ardı edersek ve bunu hafifletmek için gerekli adımları atmazsak, "aptal bir terminal"le karşı karşıya kalırız. Aptal terminallerin istemciye gösterdikleri simülasyonu anlamasına gerek yok; bunun yerine yalnızca istemcilerden sunucuya giriş verileri gönderirler ve sonuç durumunu görüntülemek için sunucudan alırlar. Bu yaklaşım, doğruluğa öncelik vererek her zaman doğru kullanıcı durumunun görüntülenmesini sağlar. Ancak birkaç dezavantajı vardır: Sunucunun güncelleme sıklığının yeterli olmaması, gecikmeye ve dengesiz bir oyun deneyimine neden olabilir. Oyun, müşterinin potansiyel kare hızına bakılmaksızın sunucunun hızında çalışacaktır. Bu, yüksek frekanslı bir oyunu, gözle görülür bir giriş gecikmesiyle düşük kaliteli bir deneyime dönüştürebilir. Yanıt vermedeki gecikmeler bazı oyun türlerinde kabul edilebilir olabilir, ancak hepsinde kabul edilemez. Oyun dünyasının modası geçmiş bir görselleştirmesi, diğer oyunculara doğru şekilde nişan almayı zorlaştırabilir. Oyuncular, gecikmeyi telafi etmek için daha erken hedefleyerek eylemlerini önceden tahmin etmelidir. En kötü senaryoda oyuncular hedeflerini tamamen kaçırabilirler. Düşman, düzensiz hareket etmese bile, ekrana kıyasla zamanda 100-150 ms önde gibi görünebilir. Bu tutarsızlık, oyuncuların ekranlarına göre hedefleri tam yerinde olsa bile ıskalamalarına neden olabilir. Bu nedenle, "aptal terminal" yaklaşımı doğru durum temsilini sağlarken, doğasında var olan sınırlamalar nedeniyle oyun deneyiminin kalitesini potansiyel olarak düşürebilir. İstemci Tarafı enterpolasyonu RTT salınımlarının kaosunu ve titreşimi birleştirdiğimizde sonuç, istenmeyen bir oyun deneyimidir. Sunucudan yapılan sık olmayan güncellemeler ve kötü ağ koşulları görsel istikrarsızlığa neden olabilir. Ancak gecikme ve titreşimin etkisini en aza indirmenin istemci tarafı enterpolasyonu gibi yolları vardır. İstemci tarafı enterpolasyonu ile istemci, nesnelerin sunucudan gönderilen konumlarına güvenmek yerine, zaman içindeki nesnelerin durumunu sorunsuz bir şekilde enterpolasyon yapar. Bu yöntem dikkatlidir çünkü yalnızca sunucudan gönderilen gerçek durumlar arasındaki geçişi yumuşatır. Güvenilir bir sunucuya sahip bir topolojide, istemci genellikle sunucudaki gerçek modelleme durumunun arkasında RTT'nin kabaca yarısı kadar bir durumu görüntüleyebilir. Ancak istemci tarafı enterpolasyonunun doğru çalışması için sunucudan iletilen son durumun gerisinde kalması gerekir. Bu, enterpolasyon süresi boyunca gecikme artışına neden olur. Kekemeliğin önlenmesi için bu sürenin paket gönderme süresinden daha kısa olması gerekir. İstemci önceki duruma enterpolasyon yapmayı bitirdiğinde yeni bir durum alacak ve işlemi tekrarlayacaktır. Ölü Hesaplaşma Periyodik olmayan durum güncellemelerinin etkisini en aza indirmek için bazı geliştiriciler Dead Reckoning (DR) olarak da bilinen ekstrapolasyon yöntemini kullanır. Bu teknik, bir oyun nesnesinin bilinen son değerlerine göre gelecekteki konumunu, dönüşünü ve hızını tahmin etmeyi içerir. Örneğin, eğer oyuncu her üç karede bir nesnenin mevcut konumunu, dönüşünü ve hızını içeren bir paket gönderirse Bolt'un ekstrapolasyon algoritması, yeni veriler gelene kadar nesnenin sonraki üç karede nerede olacağını tahmin edebilir. Bu durumda, yeni bir paketin tahmin edildiği gibi gelmemesi durumunda yine aynı tahmin yöntemini kullanabileceğimizi belirtmek önemlidir. Ancak geleceğe dair ne kadar uzun süre tahminde bulunursak, hata yapma olasılığı da o kadar yüksek olur; Bu sorunu çözmek için DR algoritması, gerçek veriler alındıktan sonra düzeltmeler yapmak için "öngörülen hız karışımını" kullanır. Ekstrapolasyon, oyunlarda yapay paket gecikmelerine olan ihtiyacı azaltır ve oyuncular için gerçek zamanlı eylemlerin daha hızlı görüntülenmesini sağlar. Ayrıca çok oyunculu oyunlarla çalışırken kayıp veya eksik paketlerle daha etkili bir şekilde ilgilenir. Bu, eksik konum, dönüş ve hız bilgilerinin oyunda herhangi bir gecikmeye neden olmadığı anlamına gelir. DR yararlı olabilse de enterpolasyon kadar kesin değildir. Ek olarak, bir FPS oyunu oynuyorsanız ve gecikme telafisi ile etkili çekimler yapmak istiyorsanız DR kullanmak zorlayıcı olabilir. Bunun nedeni, değerlerin tahmin edilmesini içeren ekstrapolasyonun, her oyuncunun ekranında gördüklerinde farklılıklara neden olabilmesidir. Enterpolasyonlu değerler kullanıyor olsaydınız, size dik olarak hareket eden bir oyuncuya doğrudan nişan alabilir ve yine de şutu kaçırabilirsiniz. İstemci tarafı tahmini İstemci tarafındaki enterpolasyon ve ekstrapolasyon gecikmeleri azaltır, ancak oyun yine de "yavaş" hissedebilir. İşte tam bu noktada "İstemci Tarafı Tahmin" devreye giriyor: Bir düğmeye bastıktan hemen sonra oyuncu karakteri hareket etmeye başlıyor, bu da halsizlik hissini ortadan kaldırıyor. Doğru yapılırsa bu tahmin sunucunun hesaplamalarıyla neredeyse aynı olacaktır. İstemci Tarafı Tahmini, sunucu ve istemcinin gördükleri arasında farklılıklara neden olur. Bu, "beklenmeyen" görsel efektlere yol açabilir. İşlenmemiş oyuncu eylemlerini hesaba katmak ve bunları her sunucu güncellemesinden sonra yeniden uygulamak önemlidir. İyileştirmelere rağmen, herhangi bir sunucu güncellemesi ile oyuncunun bunu gördüğü an arasında hala önemli bir gecikme var. Bu, örneğin oyuncunun mükemmel bir atış yaptığı ancak başka bir oyuncunun güncel olmayan bir pozisyonunu hedef aldığı için ıskaladığı senaryolara yol açar. Gecikme Telafisi olarak bilinen tartışma alanının başladığı yer burasıdır. Gecikme telafisi Gecikme telafisi, örneğin bir oyuncunun mükemmel bir atış yaptığı ancak diğer oyuncunun "modası geçmiş" konumunu hedef aldığı için ıskaladığı sorunu çözmeyi amaçlayan tartışmalı bir tekniktir. Gecikme telafisinin ilkesi, sunucunun dünya durumunu istediği zaman yeniden oluşturabilmesidir. Sunucu, atışla ilgili bilgileri içeren veri paketinizi aldığında, atış anında dünyayı yeniden yaratır ve isabet edip etmediğine karar verir. Ne yazık ki, gecikme telafisi hile yapmaya müsaittir. Sunucu, oyuncunun gönderdiği zaman damgalarına güveniyorsa, oyuncu daha sonra bir atış göndererek ancak bunun bir süre önce yapıldığını taklit ederek sunucuyu "kandırabilir". Bu nedenle gecikme telafisinden kaçınılmalıdır. Yukarıda istemci tarafında açıklanan üç teknik, sunucudan istemciye güven anlamına gelmez ve bu tür suiistimallere açık değildir. Bu seride, tüm bu teknikleri daha ayrıntılı olarak inceleyeceğiz ve verileri en hızlı, en kompakt ve güvenilir şekilde nasıl ileteceğimizi öğreneceğiz. 1. bölümün kapanışı Oyuncularınız farklı cihazlardan, farklı yönlendirici modellerinden ve çok çeşitli sağlayıcılardan hizmet alarak oyun oynayacak. Bazen yüksek hızlı internet için fiber optik kabloyla bağlanırlar, bazen de Wi-Fi bağlantısı, hatta 3G mobil internet kullanabilirler. Bu, ağ koşullarının büyük ölçüde değişebileceği ve gecikmeyi, paket kaybını ve genel bağlantı kararlılığını etkileyebileceği anlamına gelir. Bir oyun geliştiricisi olarak, bu farklı ortamları anlamak ve mümkün olan en iyi oyun deneyimini sağlamak için ağ işlemlerinizi tasarlamak çok önemlidir. Hiç şüphesiz zorlayıcı ama doğru bir şekilde yapılan bu uygulamaların üst düzeyde uygulanması, başarılı çok oyunculu oyunları diğerlerinden ayıran şeydir. Bir sonraki bölümde TCP, UDP ve WebSockets gibi ana veri aktarım protokollerini tartışacağız.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Bu ses hikayenin orijinal dilinde üretilmiştir!

Unity Gerçek Zamanlı Çok Oyunculu, Bölüm 1: Ağ İletişiminin Temelleri

Çok uzun; Okumak

@dmitrii

Credibility

İLGİLİ ÖYKÜLER