Uzun cevapları sevmeyenlerin özeti ...
Yapılabilir, ancak herhangi bir gecikme olması durumunda mükemmel çok oyunculu fizik yapmak imkansızdır . Gecikmenin neden fiziği etkilediği açıklanır ve daha sonra gecikmenin fizik simülasyonunuzdaki etkisini azaltmaya yönelik ipuçları sunulur.
Çok oyunculu bir fizik oyunu oluşturmak tehlikeyle dolu olabilir. "Mükemmel" bir çevrimiçi çok oyunculu fizik deneyimi yaratmak mümkün değil. Daha iyi hale getirmek için yapabileceğiniz şeyler var, ancak herhangi bir gecikmeyi varsayarak mükemmel fizik yapmanın bir yolu yok.
Sorun şu ki, fizik gerçekçi olmak için hızlı ve duyarlı olmalı, ancak aynı zamanda TÜM faktörlerin birleşik eylemlerine dayanarak hesaplanmalı - yani tüm oyuncuların birleşik eylemleri. Ve gecikme varsa, bu gerçek zamanlı olarak yapılamaz.
Farklı faktörleri kontrol altında tutabilip alamayacağınıza karar vermek ve gecikme süresi çok yükselirse oyuncunun deneyimlerinin bozulmayacağını anlamak sizin geliştiricinizdir. Bununla yaşayabilir (ve oyuncuların yapabilir), öyleyse devam et. İşleri nasıl daha pürüzsüz tutacağınızla ilgili bazı notlar için bu yazının sonuna bakın.
İşlerin nasıl berbat edilebileceğini gösteren bir örnek
İki oyuncunun (istemcilerin) bir sunucuya bağlı olduğu bir oyun hayal edin. Bir mesajın internetten istemciden sunucuya geçmesi 100 milisaniyede (1/10 saniye) sürüyor. Bir oyuncu bir şey yaptığında, sunucuya ne yaptıklarını söyleyen bir mesaj gönderilir. Sunucu daha sonra mesajı diğer oyunculara yayınlar, böylece oyuncunun ne yaptığını bilirler.
Şimdi, iki oyuncunun yerde fizik nesnesi olan bir kasa olduğu bir senaryo oluşturun. Oyuncu A bir tarafa çarpar ve bir yöne hareket ettirerek gönderir. Bununla birlikte, aynı zamanda, B oyuncusu başka bir yöne vurup başka bir yöne gönderiyor.
Bunu ele almanın farklı yollarına ve sonuçların ne olacağına bakalım ...
Ya fizik sadece sunucuda hesaplanırsa?
Farz edelim ki fizik yalnızca sunucuda hesaplanmış. Oyuncu A sunucuya "Ben bu şekilde sanırım" mesajını gönderir, 10/10. Oyuncu B "Sanırım bu şekilde diğer tarafa vurdum" mesajını gönderir. Sunucu, fizikteki değişimi iki eylemin kombinasyonundan hesaplar ve her iki oyuncuya da "Tamam, bu şekilde hareket eder" diyerek mesaj gönderir. Her iki oyuncunun da hareketlerine dayanarak mükemmel fizik gerçekleştirilir.
Fakat sorun şu ki, her iki oyuncu da sandığın tepkisini görmeden önce saniyenin 2 / 10'u olacak. Her iki oyuncudan gelen mesajlar sunucuya ulaşmak için saniyenin 1 / 10'unu, ardından sunucu hesaplama sonuçlarının her iki oyuncu için gönderilmesi için saniyenin 1 / 10'unu alır.
Alt satırda, laggy oyun.
Ya fizik müşteriden yeni hesaplanırsa?
Diyelim ki sadece müşteride hesaplanmış fizik var. Buna Oyuncu A'nın bakış açısından bakalım. A oyuncusu sandığı vurur ve derhal yönlerine doğru başlar. Sunucuya, Oyuncu A'nın ne yaptığını söyleyen bir mesaj da gönderilir.
Gerçi Aynı zamanda, B onların hit yapmış ve giderek sandık gördü onların yön ve onların yaptıklarından sunucuya bir mesaj gönderdi.
Saniyenin 10 / 10'u, sunucudan istemcilere bir mesaj gelir. A'ya B'nin yaptığı, A'ya yapılanlar söylenir. Sorun, iki müşterinin dediği gibi, "X oyuncusu bu noktada o vuruşta başarılı olmuş olabilir, ancak o yerde artık bir kasa kalmadı, bu yüzden onların vuruşları hiçbir şey yapmadı."
Alt satırda, senkronizasyon dışı iki oyun ve paylaşılan bir deneyime sahip olmayan oyuncular var. İkisi de farklı şeyler görüyorsa, çok oyunculu oyunun amacı nedir?
Fizik hem müşteri hem de sunucu üzerinde hesaplanırsa ne olur?
Bu durumda, fizik müşteride hesaplanır, böylece oyuncular anında gecikmesiz bir tepki görürler, ancak sunucuda da hesaplanır, böylece tüm oyuncular için "doğru" olur.
Her iki oyuncu da sandığı kendi yönlerine vurur ve her biri sandık hareketini yalnızca isabetlerine göre görür. Ama sonra saniyenin 10 / 10'u, sunucu geri döndü ve “Aslında, ikiniz de yanlışsınız. Sandık bu tarafa gitti” diyor. Aniden her iki oyuncu da sandığı sert bir şekilde yön değiştirdi ve yeni bir konuma getirdi.
Alt satırda, bir aksaklık oyunu.
Sonuç
Temel olarak, herhangi bir gecikme olduğunda, birden fazla oyuncuyla mükemmel bir fizik oyunu yapmanın bir yolu yoktur. Oldukça iyi bir oyun yapabilirsiniz, ancak her zaman bazı oyuncular için kötü bir deneyim yaratma konusunda aşırı gecikme riski vardır. Ancak, oyun deneyiminizi iyi tutmak için yapabileceğiniz şeyler var.
Çok oyunculu bir oyunu iyi yapmak için yapabileceğiniz şeyler
Basit çarpışma hacimlerini kullanın. Basit bir küp şeklinin yapacağı bir şeklin her detayını fizikle modellemekten rahatsız olmayın. Bir spikey topunun fizik için bir spikey top olarak modellenmesi gerekmez. Bunun yerine sadece bir küre olarak modelleyin.
Küçük önemsiz nesneleri yalnızca istemci öğeleri yapın. Bir örnek, kırık bir pencereden kırılmış cam parçaları olabilir. Her müşterinin kendi başına taklit etmesine izin verebilirsin ve farklı olup olmadıkları önemli değil.
Nesneleri yalnızca fizik nesnesi yapmaları gerekiyorsa aktif fizik nesne sayısını düşük tutmak için fizik nesnesi olmaları gerekiyorsa yapın.
Çok oyunculu fizik yaparken oyununuzu ağır çekimde çalıştırın. "Kurşun zamanı" düşünün belki. Yavaş hareket oyunları gecikmeyi telafi eder ve birden fazla oyuncunun birlikte fizikle etkileşimine izin verir.
Oyuncuların bir tür durumu birlikte kurmalarına izin verin ve sonra bazı ipuçlarında, fizik iki oyuncu için de simüle edilir ve her ikisi de birleşik eylemlerinin sonucunu izler. Oyuncular tamamlanıncaya kadar diziye müdahale edemezler.
Ayrı oyuncular fiziği böylece birbirlerini engelleyemezler. Bu, aynı anda sadece bir oyuncunun kontrolüne sahip olduğu bowling veya pool gibi bir oyun veya her oyuncunun kendi “sandbox” ını (bowling lane gibi) kullandığı bir oyun için harika olurdu.
Onları yenemezseniz, onlara katılın ve fiziği oyununuzun bir parçası haline getirin. Kırık bir fizik kanunu veya başka bir şeyle dolu karanlık bir evrende olduğun hakkında bir hikaye hayal et :)
Ek: Atış oyunları bununla nasıl başa çıkıyor?
Atış oyunları, aşırı karmaşık fizik yapmamakla başa çıkıyor. İstemci yan etkilerini kullanıyorlar, böylece oyuncular bir şeyleri hızlıca görebiliyorlar, ancak sonra sunucu ne olduğu konusunda son çağrıyı yapıyor.
Bir oyuncunun B'yi vurduğu bir senaryo düşünün. Tipik bir shooter oyununuz böyle bir şey yapacak ...
- A, B'ye isabet edip etmediklerini yerel olarak hesaplar ve bir isabet var gibi görünüyorsa, kan pufu gibi bir "isabet" efekti çalar. Bu, müşteri tarafında yapılır, böylece oyuncu hemen eylemlerine bir tepki görür. Bunu yapmazsan, oyun çok garip geliyor.
- A ayrıca sunucuya "Bu vektöre ateş ettim" diyen bir mesaj da gönderir.
- Sunucu mesajı aldığında, BT'nin oyuncuların nerede olduğunu düşündüğü yere bakar ve A'nın atış vektörünün B'ye çarpıp çarpmadığına karar verir.
- Sunucu A vuruşu B'ye karar verirse, B'ye vurulduğuna karar verir ve BOTH müşterilerine ne olduğunu söyleyen bir mesaj gönderir.
- Eğer sunucu A'ya BÜTMEME karar verirse, B iyi ve A "özlüyor". A'ya vurdukları gibi görünebilir ("Kan pufunu gördüm!"), Ancak sunucular özledikleri aramalar.
Öyleyse, bir B, onlara çarpmış gibi göründüğünde nasıl özleyebilir? Çünkü B taşındı, ancak A henüz görmedi çünkü sunucu henüz istemciye "B buraya taşındı" mesajı göndermedi.
Valf bu konuda kendi sitesinde iyi bir yazı yazıyor. Bkz http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking