Süper basit çok oyunculu kurulumumun muhtemelen iyi bir fikir olmadığını biliyorum, ama neden?

Sadece eğlence için basit bir MOBA yapıyorum. Ben her şeyi tek oyunculu yapıyordum, o zaman farkettim ki "ah bok muhtemelen çok oyunculu eklemeliyim, ha."

Daha önce hiç ağ oluşturma ile hiçbir şey yapmadım, bu yüzden Lidgren'i oyunuma nasıl entegre edeceğimizi öğrenmek eğlenceli ve harikaydı. Mesele şu ki, bir şeyler yapma şeklimin yanlış olduğunu biliyorum, çünkü bildiğim kadarıyla ana akım oyunların kullanması için yeterince sağlam değil, ama sorun ne?

Yaptığım şey, temelde, bir oyuncu bir eylem yaptığında, sunucuya "hey, sadece bu şeyi yaptım" diyen bir mesaj gönderir. Sunucu ve istemci aynı simülasyonu çalıştırıyor. Sunucu daha sonra diğer tüm istemcilere o adamın o şeyi yaptığını söyleyen bir mesaj gönderir.

Çoğunlukla, birkaç durumda, bir oyuncu bir şey yaptığında, müşteri serin olduğunu varsayar ve kendi başına devam eder. Orada taşımak için bir yere sağ tıklayıp zaman, o oyuncunun müşteri sadece orada onun adamı hareket başlar ve daha sonra bu konuda onu söylüyorum sunucuya bir mesaj gönderir.

Temel olarak:

• Oyuncu 1, altı saniye boyunca% 100 daha hızlı hareket etmesini sağlamak için bir büyü yapar
• Oyuncu 1'in yerel istemcisi bu tutkuyu Unit nesnesine ekler
• Oyuncu 1'in istemcisi sunucuya "hey ben sadece bu büyüyü yaptım" diyen bir mesaj gönderir
• Sunucu, bu büyüyü yapmak için gerçekten yeterli manaya sahip olduğundan emin olur ve eğer öyleyse, bu buff'ı sunucunun bu Unit nesnesinin kopyasına ekler
• Sunucu diğer tüm istemcilere "hey bu adam sadece bu büyüyü yaptı" diyen bir mesaj gönderir
• Diğer tüm istemciler mesajı alır ve "ah tamam cool" olur ve bu tutkunu o oyuncu için kendi yerel Unit nesnesine ekler

Büyük oyunların nasıl çok oyunculu oynadığını görmek için şeyleri gözden geçiriyorum ve bu şeylerde biraz uğraşmaya başlayan biri için kafa karıştırıcı, ancak Kaynak motoru , her şeydeki tüm değişiklikleri içeren bir paket gönderiyor gibi görünüyor dünya her kene? Yine, bu şeyler için tamamen yeni, ama gerçekten o kadar çok veri zorlayabilir misiniz?

Bu biraz rahatsız edici olsa da özür dilerim, ama temel olarak, daha basit sistemimin neden doğru yol olmadığını merak ediyordum, çünkü eğer öyleyse, diğer oyunlar bunu kullanacaktı, değil mi?

Byte56'nın cevabına ek olarak, dikkate alınması gereken birkaç şey daha var:

Müşteriler arasında oyuncu hareketi hakkında nasıl iletişim kuracaksınız? Yalıtılmış olaylar olma eğiliminde olan ve muhtemelen biraz seyrek olan diğer oyuncu eylemlerinin aksine, hareket süreklidir. Güncelleme gönderme ve alma hızınız için bir sınır vardır. Byte56'nın bahsettiği Müşteri tarafı tahmini, tipik olarak müşteri konumu ve hızı hakkında periyodik güncellemeleri içerir. Müşteri daha sonra Kübik Spline gibi bir şey kullanarak aralarında yerel olarak enterpolasyon yapar .

Önceki konulara bağlanan ikinci bir sorun, UDP'nin garantili teslimatı olmamasıdır. Gönderdiğiniz her iletinin doğru sırada geldiğinden emin olamazsınız. Paket 1, 2 ve 3 gönderebilirsiniz ve sunucu 2'den sonra 3 sonra 1 alır ve çoğu zaman doğru sırada olurlar ve çoğu zaman gelirler, ancak her zaman değil. Yani, paketleri kaybetmek için sağlam bir sisteme ihtiyacınız var. Basit bir onay sistemi yeterlidir. Tipik olarak, diğer düğüme son 32 iletiyi alıp almadığını (32 bit int için) ve alınan son iletinin ne olduğunu söyleyen bir bit alanı kullanılır. Bu şekilde, iletileri kritik veya kritik olarak etiketleyebilir ve kritik iletileri almazlarsa yeniden gönderebilirsiniz. Burada oldukça iyi bir tartışma var .

Bunu yaparken, müşterilerinizin birbirleriyle senkronize olmayacağını da aklınızda bulundurmanız gerekir. Her biri, en iyi durum senaryosunda, bir sonrakinde çalışırken önceki iki ağ çerçevesi arasında enterpolasyon yapan diğer oyuncuları gösterecektir. Bu nedenle, bir oyuncunun bir eylem gerçekleştirirken gördüğü şeyin, o eylemi gerçekleştirdiği zaman oyunun gerçek durumu olmadığını (adil bir şekilde) dikkate alan bir sisteme ihtiyacınız vardır. Eski, senkronize olmayan bir oyun durumuna tepki veriyordu.

Son olarak, eğer bu oyun rekabetçi olmak istiyorsa, hile konusunda da endişelenmeniz gerekir. Bu nedenle, mümkün olduğunca (ve makul), müşterilere güvenmemeli ve eylemlerinin mümkün olduğunu doğrulamalısınız. "Hayır, o duvardan geçemezsin. Hayır koşu hızından daha hızlı yürüyemezsin. Hayır, o hedefi vurduğunu iddia edemezsin." vb.

Daha fazla fikir için, o ikinci bağlantıdaki diğer makalelere göz atmanızı öneririm.

İyi şanslar!

Açıkladığınız şey aslında istemci tarafı tahminidir , ancak sunucu ve istemci aynı fikirde olmadığında ne olacağını söylemezsiniz.

İstemcinin sadece aptal bir terminal olduğu günlerden gelişti, girdisini sunucuya gönderdi ve sunucu istemciye sonucu söyledi. Bununla birlikte, oyunlar LAN'ın ötesine geçtiğinde (ve daha önce sıklıkla) bu durumda gecikme farkedilirdi. Açıkladığınız şey, bunu düzeltmek için müşteri tarafı tahmini getirildi. Artık istemci, sunucunun yanıt vermesini beklerken hareketi simüle eder. Sonra sonuç üzerinde bir anlaşmaya varırlar. Sunucu yetkisi ile.

Sonraki adımlar anlaşmazlıklara nasıl yanıt vereceğinizdir. Bunun için yerinde bir şey yoksa, istemci ve sunucu aynı fikirde olmadığında müşteriye kauçuk bantlama veya tele-bağlantı sağlarsınız.

Zamanlama. Diğer yanıtlar, sunucudaki ve farklı istemcilerdeki olayların zamanlamasından bahsetmez. Oyuna bağlı olarak, bu dikkat edilmesi gereken bir şey olabilir. Gecikme (gecikme olarak da bilinir), bir paketin gönderilmesi ile alındığı zaman arasında değişken bir gecikme sağlar. Zaman zor olabilir, ancak potansiyel sorunları elimden geldiğince açıklamaya çalışacağım. Bu konuda endişelenmeden alabileceğiniz bazı oyunlar var, ancak burada sorunlara neden olabileceğinin basit bir örneği.

Herkesin geldiği anda paketler üzerinde hareket ettiğini varsayalım.

@ Time 0 (wall time), Player 1 puts up a shield   (Message has been sent, but not received by anyone)
@ Time 1, Player 2 shoots player 1   (Message has been sent, but not received by anyone)

Zaman 0 (T0) ve T1'in birbirine yakın olduğunu varsayalım.

Bundan sonra ne olacağı, buna kimin baktığına ve paketlerin sunucuya gelme sırasına bağlıdır. Sunucu her zaman son sözü söylemelidir. Sunucu paketleri yukarıda verilen sırayla alırsa, sunucu atıştan önce kalkanı uygular ve oyuncu 1 (P1) hayatta kalır. P1'in bakış açısından, kalkanı kendisi koyduktan sonra, kaleyi atıştan önce görecek ve hayatta kalacak. Peki P2 ne olacak? Çekimi hemen görecekler çünkü vurdular, ama önce kalkanı görecekler mi? Eğer (T0 + latency between P1 and the server + the latency between the server and P2) > T1kalkan atıştan sonra ortaya çıkacak ve P2 atışlarının P1'i öldürdüğünü düşünecektir. Sunucunun bu durumu bir şekilde düzeltmesi gerekecektir.

Bununla birlikte, sunucu paketleri ters sırada alırsa (T0 <T1 olsa bile oldukça mümkündür), bunun tersi gerçekleşir. P2 doğru (ve muzaffer) iken P1 yanlış (ve ölü).

Bu gibi durumlarla başa çıkmanın birkaç yolu vardır, ancak en kolayı sunucunun her şeyi yapmasına izin vermektir. Bunu istemcide simüle etmeye çalışabilirsiniz, ancak ölüm gibi kalıcı eylemlere izin vermeyin. Oyuncular, sunucudan önemli oyun değişikliği onaylarını beklemek zorunda kalacaklar.

Eylemlerle zaman damgası göndermek faydalı olabilir. Çoğunlukla müşterilere güveniyorsanız, bu zaman damgalarını, ilk varsayımımızı takip etmek yerine ilk olarak hangi eylemin gerçekleştiğini belirlemek için kullanabilirsiniz. Bu zor olabilir, çünkü geçmişten mesaj almak genellikle zamanı tersine çevirebilmeniz gerektiği anlamına gelir.

Zaman eğlenceli değil mi? Sonunda ne yaparsanız yapın, bu zaman sorunlarının farkında olmak yardımcı olur.