Ağ Bağlantısı Pong Klonu

TCP soketlerinin, UDP iletişiminin vb. Temelleri var, ancak bunları gerçek zamanlı oyun ortamına nasıl uygulayacağım konusunda fazla bir şey bulamıyorum.

4 oyuncu ile bir Pong klon var ve üç istemci ve sunucu (sunucu dördüncü oyuncu) arasında kürek pozisyonlarını senkronize etmek gerekir. Şu anda gerçek zamanlı güncellemeler (raket hareketleri) göndermek için UDP ve oyun lobisini kurmak için TCP kullanıyorum.

Çok miktarda UDP trafiğini spam etmek kötü bir şey midir? Tıkanıklık özellikleri için DCCP gibi bir şeye bakmalı mıyım? Yoksa bu, küçük ölçekli bir projede gerçekten sorun değil mi?

İstemci / sunucu arasında senkronizasyon mesajları ne zaman gönderilmelidir? Şu anda sunucu, geçerli oyun durumuna sahip UDP paketlerini yönetebildiği kadar hızlı spam yapıyor ve istemciler, raket konumlarını olabildiğince hızlı bir şekilde sunucuya geri gönderiyor. Bunu yapmanın en iyi yolu bu mu? Eklemem gereken bazı mesajlar her X milisaniyede bir gönderilecek mi, yoksa yalnızca olaylar gerçekleştikçe mesaj mı göndermeliyim? (örneğin, kullanıcı girişi nedeniyle raket hızı değişmiştir)

İstemcilerin kürek pozisyonlarını eşler arası iletişim kurmaları daha iyi olur mu?

Bu soruları Pong bağlamında soruyorum ama aynı zamanda diğer oyunlarda veya genel çözümlerde bu sorunların nasıl aşılacağı ile de ilgileniyorum.

Yapılandırılabilir bir güncelleme aralığına sahip olun (böylece saniyede 5 paket veya 20 ayar yapabilir ve deneyebilirsiniz) ve her kare bir güncelleme gönderme zamanının geldiğini görür. Her etkinlik için basit bir oyun gönderme paketi ile iyi olabilirsiniz, ancak daha karmaşık bir oyunda bu pratik değildir. Ayrıca, bir paket havai yük olduğunu unutmayın, bu nedenle bir grup küçük paket gönderiyorsanız, bant genişliğini boşa harcarsınız.

Her güncelleme aralığı, her istemcinin raket konumunu sunucuya veya her istemciye (eşler arası) göndermesini sağlar. Sunucunun ayrıca top konumunu ve bir hız vektörünü göndermesini sağlayın. Her müşteri, topun hareketinin düzgün olması için tek oyuncuda olduğu gibi aynı ekran çizim kodunu çalıştırabilir. Çok oyunculu modda topun konum / hız güncellemelerini düzenli aralıklarla (ve her seferinde bir şeye çarptığında) gönderirsiniz.

Top konumu güncellemelerinin tüm istemcilerde bir oyun zamanını referans almasını sağlayın, böylece sipariş dışı paketleri atabilir ve hatta top konumunun enterpolasyonunu daha doğru hale getirebilirsiniz (geçmişte belirli bir zamanda konum ve hızı bilirsiniz, böylece yeni durum).

Tembel bir oyuna sahip bu modelle, topun zaman zaman geriye doğru hareket ettiğini veya biraz atladığını görebilirsiniz. Ancak iyi bir bağlantı ile oldukça pürüzsüz olmalı.

Trafik endişeleriyle ilgili olarak - eş başına saniyede 20-30'dan fazla paket göndermekten kaçınmak istersiniz. Genel durumda, daha küçük, daha az paket gönderirseniz, (biraz) daha az gecikme ve daha az bırakılan paket şansı yaşayacaksınız.

Kesinlikle güncellemeleri kare hızından daha hızlı göndermek istemezsiniz, çünkü oyuncular farkı söyleyemezler - aslında, eğer sadece saniyede 10 kez paket gönderirseniz ve alıcı taraftaki sonuçları enterpolat / tahmin ederseniz , çoğu oyuncu bir fark görmez.

Bu oldukça geniş bir soru, ama önemli yönleri özetlemeye çalışacağım.

Oyununuz için ağ kodunda verilecek ilk karar, bir eş / istemci kurulumunun eşler arası düzenlemesini isteyip istemediğinizdir. RTS'nin büyük olasılıkla tek istisnası olduğu çoğu oyun muhtemelen bir istemci / sunucu mimarisi kullanmaktadır. Başlıca avantajı, bu düzenlemenin daha fazla hataya dayanıklı olması ve her müşterinin aldığı veriler üzerinde daha fazla kontrol sağlamasıdır. Eşler arası çok daha az veri göndermeye izin verir, ancak her eşin dünyayı diğer eşlerin yaptığı gibi tam olarak simüle etmesini gerektirir. Eğer bir akran gecikirse veya senkronize olmazsa, herkes ya iyileşmelerini bekler ya da kaybolur.

UDP, genellikle herhangi bir istemci / sunucu modeli için de genellikle doğru seçimdir. TCP bir eşler arası oyun için pratik olabilir, ancak o zaman bile UDP daha iyi bir seçim olabilir. Temel olarak, UDP sizin için daha az iş yapar, bu da daha fazla çaba ve aynı zamanda arızalarla nasıl başa çıkacağınız üzerinde daha fazla kontrol anlamına gelir.

Pong için yapacağım seçim, aksiyon odaklı bir oyun olması, istemci / sunucudur. Burada dikkat edilmesi gereken bir şey, bir oyuncunun "sunucu" olduğunu söyleseniz bile, kodunuzu esasen yerel bir sunucu çalıştıracak ve bir istemci olarak bağlanacak şekilde yapılandırmanız en iyisidir.

Kesinlikle herhangi bir yönde güncellemeleri "spamlamak" istemezsiniz. Her kare için sunucudan bir güncelleme yeterlidir ve sunucunuzun sabit bir kare hızında çalışması gerekir. Bu size bağlı, ancak denize girmeye gerek yok. 50ms'lik bir çerçeve (20 FPS), güzel pürüzsüz bir oyun oynamak için bol miktarda bulunur. İstemcide işleri pürüzsüz tutmak için enterpolasyondan yararlanmak istersiniz. İstemci sürekli olarak sunucu çerçevesi anlık görüntüleri arasında geçiş yapmalıdır, bu kolayca ayrı bir sorunun konusu olabilir.

İstemci güncellemeleri de sınırlandırılmalıdır, ancak istemciniz iyi bir kare hızında çalışıyorsa kare başına bir tane çok fazla olacaktır.

Hile yapmak ister misin?

Değilse, eşler arası gitmek gecikmenizi yarıya indirecektir, çünkü A <-> B <-> C yerine A <-> C'dir. Eğer öyleyse, senkronizasyonda adalet için yerel oyuncuya veya çoğu oyunun ne yaptığına tepki vermek isteyebilirsiniz - oyuncunun yerel olarak ne isterse yapmasına izin verin ve ardından sunucunun sonucu yerel olarak benzetilmiş olandan farklıysa geri çekin.

Bir pong klonu aslında biraz zordur, çünkü çoğu oyunun aksine (bir geliştirici olarak) bir tarafın bir vuruşu diğerini görmesini engelleyemezsiniz.

Genelleştirilmiş bir şeye gelince, duyduğum ancak gerekli bulamadığım bir teknik (aksiyon oyunları için olabilir) eylemleri gerçek zaman damgalarıyla tutmak (zaman alma - ping / 2) ve sunucuyu geri almak ( snap), daha önceki bir etkinlik gerçekleşirse ve daha sonra yapılacak işlemleri yeniden uygulayın. Bu şekilde, farklı oyuncuların etkileşimleri nedeniyle bir çatışma olmadığı sürece herkes yerel olarak tutarlı olur. Tek tehlike, gecikmeli bir bağlantı yaparlarsa 'zamanı geri alma' yeteneğidir.

Google ölü hesaplaşma. 4 oyuncu için güncelleme göndermek önemli olmayacak. Gönderilen veri miktarı bayt cinsinden olacaktır. Yani, sık güncellemelerin iyi olması gerektiği anlamına gelir. Ölü hesaplamayla, oynatıcıyı istemcide ve sunucuda taşırsınız. Sunucu otoritedir. İstemcilerin konumu sunucudan eşitlenemeyecek kadar uzağa döndüğünde, hizalamaya geri dönmelidir. http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking UDP'yi kullanmak en iyi yoldur. Bupdates, kayıp verilerin yakında yakında gelen verilerle değiştirileceğine sık sık gönderilir. TCP'nin paket yeniden iletimi oynatıcı konumu için buna değmez. İstemciyi ve sunucuyu senkronize tutma hakkında daha fazla bilgi için bu makaleye bakın.

Birkaç hafta önce 2 kişilik yerel ağ-pong oyunu programladım, işte böyle yaptım:

-Bir taraf bir sunucu açar, diğeri otomatik olarak bağlanır -Her ikisi de küreklerini x pozisyonlarını birbirlerine @ 60fps veya daha az [UDP] spam ederler -Bir taraf topa vurursa toplara yeni hız ve pozisyon hakkında karar verir ve gönderir diğerine [TCP] - top bir kürekten uçarsa, onu kaçıran oyuncu diğerine bir artış puanı mesajı ile temas eder ve top sıfırlanır [TCP] -top her zaman bağımsız olarak simüle edilir, pong basit top fiziğine uygun

Bu, 60 fps'de kabaca 0.3 ila 0.5 KByte / s trafik oluşturur ve oyuncuların algılarında gecikme olmaz, ancak yalnızca ping belirli bir eşiğin altındaysa, çünkü topların yeni pozisyonunun iletilmesi gerekir.

Ayrıca bu sistemle hile yapmak kolaydır ve çok kayıplı bir bağlantıyla senkronizasyondan çıkma olasılığı yüksektir, ancak pong'da hile yapmayı kim umursar ?!