tr-demoscene
the scene => coding => pc => Konuyu başlatan: skate - 06.07.2007 13:57:14
-
Arkadaşlar yazdığım bir TCP server'ın clientlarıyla senkronize olabilmesiyle ilgili şöyle bir problemim var. Elbette ki serverla clientların tarih saat bilgileri birbiriyle tam tutmaz. Ancak server connection gerçekleştiğinde kendi tarih saat bilgisini milisaniyeye kadar hassas bir şekilde gönderebilir ve bu sayede server ve client senkronize olabilir. Client bir event gerçekleştiğinde o eventi servera yollarken serverın saatine göre ayarlayabilir ve bu sayede server packet delaylerini hiç önemsemeden interpolasyonlarını düzgün bir şekilde yapabilir.
şimdi benim derdim şu. Server timer bilgisini clienta ilk gönderdiğinde de bir packet delay oluyor. Eğer bu delayi ölçmeyi başarabilirsem pakette gelen değere bu delay değerini ekler ve senkronu başarılı bir şekilde yapmış olurum. Ancak ne yazık ki bunu nasıl yapacağımı bulamadım. Bunu yaklaşık olarak yapmak için gönderdiğim pakete bir yanıt alıp aradaki süreyi ölçebilir ve tahmini olarak bu süreyi ikiye bölebilirim. Ama bu ne derece gerçekçi bir sonuç verir açıkçası bilemiyorum. Çünkü server yoğun olduğu zaman response delayleri de işin içine girecektir. Ayrıca clientın servera ulaştığı zamanla serverın clienta ulaştığı zaman tam olarak eşit olmayacaktır.
Sanırım bu işi çözmenin en makul yöntemi yukardakine benzer tahmini bir hesaplama yapıp daha sonra kalibrasyonlarla timerları tam olarak senkronize etmek. Bu konuda fikirlerim var ve çok iyi sonuç verebilirler diye umuyorum. Ama bu işlere girişmeden sizlere bir danışayım dedim. Biliyorum ki aranızda bu konularda çok tecrübeli isimler var. Doğru yolda mıyım?
-
http://www.isoc.org/inet2000/cdproceedings/1d/1d_2.htm
...
the users request high network performance for the delay and the throughput, for example, in the usage of the server and client environments. But, in the Internet it is impossible to guarantee network performance because the Internet is made of many sub-networks, which are distributedly managed by their own policies.
...
As a candidate to solve this problem, we propose NTP (network time protocol) to measure delay and jitter between them.
-
@Gnostic: Yanıt için teşekkürler. Ancak bunu profesyonel bir uygulamada kullanmak için sormadım. Dikkatini çekerim "the scene -> coding -> pc" bölümüne attım soruyu. Bu bir multiplayer oyun (senin ilk beta testerı olduğun :)) için geliştirdiğim bir algoritmayla ilgili. GPS falan kuracak hali yok oyunu oynayacak kişilerin :D Geri kalan bölümde anlatılanlar ise benim tahmin metodlarımla örtüşüyor zaten. Bu işi tek server tek client ve ekstra birşey kullanmadan tahminden çıkarmanın bir yolu varmıdır ben onu araştırıyordum ama anlaşılan pek yok.
-
hesapladigin degeri arasira tazelemende fayda var sanirim.. lag nedeniyle bu kontrol cesitli zamanlarda farkli sonuclar verecektir.. surekli bunun ortalamasini alip devam etmek mantikli gozukuyor..
-
veri alis verisi sirasinda olusan delay'in degisken olmasi probleminden kurtulabilecegini sanmiyorum. eninde sonunda bir tahmin yapma zorunda kalacaksin.
nasil bir multiplayer sistemi dusunuyorsun? neden client ve server zaman acisindan senkronize olmak zorundalar?
-
multiplayer oyunda senkronizasyon cok hayati rol oynuyor, ben istanbul oyunununa senkronizasyon ekleyene kadar oyunun oyuncuda yarattigi husran hissini gormeliydiniz :) hatta Hydrogen gormustu :)
Yani oyuncular oyunda saga sola kostururken, aslinda her makine ve serverda ayni anda farkli yerlerde olabiliyorlar. ornegin bir oyuncunun digerine ates ettiginde server'in atisin isabetli olup olmadigina karar vermesi icin server ve client arasindaki her paketin time_stamplerle isaretlenmesi gerekiyor.
Ghost'un da dedigi gibi network delaylari degisken olacaktir. Fakat burada soyle bir avantajimiz var. Genelde delaylerdeki degiskenligin daha cok tcpip deki paket resendlerden kaynaklandigi ortaya cikmis. Yani 100 paket gondersek ve delaylerinin histogramini cikarsak dagilimin esit olmadigini goruyoruz. dagilim genelde minimum delayin tamsayi katlarinda spike'lar seklinde oluyor.
Bu yuzden oyuncu oyuna girerken n tane paket gonderip sonuclarin histogramini cikarmak ve bu histogrami analiz edip server ile o client arasindaki delayi hesaplayarak client'in saatini set etmek gerekiyor (saatlerimizi ayarlayalim). Bu islemi zaman zaman tekrarlamak isteyebiliriz. Fakat onemli olan aslinda delayin degismesinden ziyade, saatlerin senkron devam etmesi. Yani mesela oyuncu oyuna ilk girdiginde bu sekilde saatleri senkron edersek ve sonraki 2 saat boyunca network delay ne olursa olsun, iki bilgisayardaki saatlerin ayni anlarda saniyeleri atmasi mumkundur. delayler ne olursa olsun iki bilgisayar da birbirlerine oyun eventlerini timestampli gonderdikten sonra, her iki bilgisayar da paketi delayli bile alsa timestampe bakarak interpolasyon yapabilir. Mesela:
1- 1000: 1. oyuncu x0,y0 noktasindan x1,y1 e kosmaya basladi. diyelim ki 1100'de varacak
2- 1020: server bu paketi aldi. O anda hiz bilgilerini kullanarak 1. oyuncuyu x2,y2 noktasina koydu (arada bir nokta yolun tam beste birinde mesela) ve onu gorebilecek butun oyunculara bunu sinyalledi
3- 1050: 2. oyuncu paketi aldi. icinde 1000 aninda 1. oyuncunun x0,y0 dan x1,y1e kosmaya basladigini okudu. Bu sirada onun bilgisayarainda 1. oyuncu hala x0,y0 da idi. Simdi 2. oyuncunun client'i kendine bir yol secip bir 1. oyuncuyu hareket ettirmeli. 1100 de x1,y1e vardirmali, bunun icin iki kat hizli kosturabilir veya baska non lineer bir yol secebilir.
Courtesy of Istanbul MMORPG :)
-
anladim. time_stamp'in gerekliliginin farkindayim. skate server ve client saatlerini sync'lemeye calisiyor sandim ben. gercek zamanli bir multiplayer sistemi o zaman.
-
yok nightlord'un dediği gibi aslında client'da bir time_delta hesaplamaya çalışıyorum. ve yine nightlord'un belirttiği gibi bu deltayı birkez hesapladımmı (doğru olarak) bir daha sorun çıkmayacağını düşünüyorum. şu anda amacım ıstanbul gibi detaylı bir oyun yapmak değil. yalnızca son zamanlarda fazla ıstanbul oynamak beni birden böyle birşey kodlamaya itti. amacım kendimi geliştirmek. Benim şu anda yaptığım şeyin ıstanbul'a göre daha zor tek bir tarafı var. Point to click değil WASD kullanıyor olmam. Yani eğer becerirsem o kadar kaliteli olmasa bile WOW tarzı birşey yapmış olucam. Time synch olayını yapabilirsem bir şekilde WASD olayını da becerebirilim diye düşünüyorum. Ama bu işi görünüşte süper bile yapacak olsam yine de ıstanbul ekibini taktir ediyorum. Çünkü bir de işin security tarafı var ki akıllara zarar. Mesela benim şu anki engine'im sabit 1 bytelık bir header ve komut tanımı için yine 1 byte kullanıyor. Client ID ve diğer birçok parametre için ise her ihtimale karşı (bazıları biraz gereksiz olsa da) 4'er byte yani 32 bit kullanıyor. Bu kadar basit bir yapısı var ve herhangi bir encryption v.s. yok. Elbette ki basit bir XOR key ekleyebilirim ama ne olursa olsun düşünülmesi gereken çok detay var. Security çok önemli. Ekibi tekrar tekrar tebrik ediyorum.
Nightlord, senin yazdıklarından doğru yolda olduğumu hissettim. Benim de anlamaya çalıştığım buydu zaten. Anlaşılan siz de paketlerin içine bir time stamp koyuyormuşsunuz. Benim de aklıma başka bir yol gelmemişti.
ışin en ilginç tarafı geyik olarak point to click ve WASD ile ilgili tartışmaların döndüğü onlarca forum buldum. Hatta çok yüzeysel olarak coderlar arası tartışma forumları da buldum. Ama bir kişi adam gibi bir tutorial yazmamış bu konuda. Okuduğum MMORPG tutoriallarının hepsi de client ağırlıklı idi. Server-Client yapısıyla ilgili iyi bir tutorial bilen varsa okumak isterim.
-
asagidaki kitaplar isine yarayabilir.
http://www.fetchbook.info/compare.do?search=9781584503637
http://www.fetchbook.info/compare.do?search=9781584502432
ikinci kitap bende var ama icerigini hatirlayamiyorum su an. :) aksama bi goz gezdirip ayrintili bir mesaj atarim buraya.
-
teşekkürler ghost, hemen göz atıyorum.
Edit: Göz attım. Her ne kadar içerik olarak çok ortaklık barındırsa da engineimin DirectX bağımlılığı olmaması, doğrudan winsock2 kullanması nedeniyle DirectPlay anlattığını tahmin ettiğim "Programming A Multiplayer FPS In DirectX" kitabını eliyorum ve "Massively Multiplayer Game Development, 1st Ed. (Illustrated)" kitabını almayı düşünüyorum. Sanırım senin elindeki kitap da o. Reviewını bekliyorum.
-
evet o kitap. uzun zaman once okumustum. buraya biseyler yazabilmek icin bir daha gozden gecirdim az once. oncelikle sunu soyliyeyim bu kitap alisilagelmis "evet mmg, yapiyoruz. en bastan baslayalim" modunda bir kitap degil. kitabin icerigi 20'den fazla oyun yapimcisinin (programci, dizaynci, vs) yazdigi 5-20 sayfalik makalelerden olusuyor. Her bir makale birbirinden bagimsiz olarak okunabiliyor. yani en bastan bi MMG projesi ele alinip, kitabin sonuna kadar onun uzerinde calismiyor. her yazar kendi alaninda konuyla ilgili oldukca bilgilendirici makalelerle katkida bulunmus. Zaten cok fazla kod yok kitap icinde. Bolca UML ve dizayn dokumani mevcut. Yani teorik bilgi bayagi fazla. Teorik dedigim dizayn seviyesinde bilgiler oldukca fazla. yoksa icindeki bilgiler aslinda bayagi pratik.
katilimcilar arasinda onemli projelerde calismis isimler var. Ultima Onlie, Baldur's Gate, Star Wars Galaxies, Total Annihilation, Asheron's Call 2, Earth & Beyond vs gibi oyunlarda imzalari var.
Kitabin bolumlerine gelirsek:- MMP Design Techniques.
- Server-Side Development.
- Client-Side Development.
- Database Techniques
- Game Systems.
Kitapla gelen CD'de, kod ornekleri var diyor ustunde. ama ben hic bakmadim, bir sey diyemiyecegim o konuda.
Son soz olarak, bu kitabin icinde seni bir anda nirvanaya ulastiacak coding bilgileri yok. Ama oyun sistemini tam kurmadan once bu kitaba bir goz atman oldukca yararli olur diye dusunuyorum. Icinde ogrenilecek pek cok sey var.
Ayni yayimci firmanin "Game Programming Gems" serisi ve "AI Programming Wisdom" kitaplari da ayni sitilde hazirlanmis. Iclerinde cok guzel makaleler var. Eger bulabilirsen onlara da goz atmani tavsiye ederim. Bende yok bu kitaplar ama kitapciya yaptigim ziyaretlerde okumustum cogunu. Game Programming Gems ozellikle cok guzel.
Kitapligimda bir tane daha Multiplayer oyun yapimi kitabi bnuldum onu da asagiya acikliyim bari.
edit: bu kitabin ikincisi cikmis. henuz inceleme firsati bulamadigim icin farki nedir bilemiyorum.
-
Kitapligimdaki diger kitap ise "Developer's Guide to Multiplayer Games". Bu kitap biraz daha pratik konulara yer vermis. Daha cok step-by-step turunde bir yaklasim sergiliyor. Soyle diyim kitap "Visual Studio'ya windows application'i nasil yazilir" konusuyla basliyor. oyun icin MYSQL database'i kullanimindan, online oyunlara ozel TCP/IP network library hazirlamaya kadar gidiyor.
Bu kitabin sadece TCP sockets bolumunu okudum. O yuzden cok fazla yorum yapamiyorum. Acikcasi ben pek faydali bulmadim. Yukarida anlattigim diger kitap kadar yararli olmadi bana. Ama senin isine yarayabilir belki. Online olarak pdf'sini bulabilirsen bir goz at derim. kimbilir. :)
Not: Oyun programlama uzerine baska bi kac kitabim daha var. Ama onlar multiplayer merkezli degil, genel olarak oyun programlama uzerine. ilgini cekerse onlar hakkinda da bir kac bir sey yazarim.
-
game programming gems serisi, 2,3,4 ... diye gidiyor hatta galiba. ben birincisini okumustum.
-
Bilgiler için çok teşekkürler arkadaşlar. Benim ihtiyacım olan kesinlikle kod örneği değil. Hatta kod örnekleri ben hep sınırlamış ve kafamı karıştırmıştır. Netekim bu projeye ilk başladığımda da başıma aynısı geldi. Bulduğum örnekler hep MFC örnekleriydi. Ben de bu örnekleri sallayıp winsock bilgilerimi tazeledikten sonra ws2_32.dll harici bir bağımlılığı olmayacak şekilde yazdım server kodunu. Client ise bu DLL hariç standart SDL libraryleri kullanıyor yalnızca. Kararlıyım, bu işin içine saçma sapan libler, frameworkler karıştırmayacağım. Ama linux, mac ve diğer platformlar konusunda özür dilerim, bu kadarıyla uğraşamayacağım. Proje büyürse belki bu konuda gönüllüler çıkar, o başka.
Gelelim kitaplara. "Game Programming Gems"in seri olduğunu bilmiyordum. Tahminen ben de ilkine göz atmıştım. O zamanlar game programminge çok focuslanmış olmadığım için çok ilgilenmemiştim ancak şimdi arşivime katabilirim belki.
Ghost'un elinde bulunan ilk review ettiği kitap ise sanırım tam aradığım şey. Çünkü benim aklımdaki soru zaten "Amerika'yı yeniden keşfetmeden önce, acaba bu amcamlar nasıl yapmışlar, ne yol izlemişler?" türü sorulardı. ınanın diyagram bile fazla. Örneğin Nightlord'un "başta bir kere timerları synch edip sonrasında paketleri timestamp ile göndermek" konusunda benim fikrimi destekleyici yorumları bana yetti. Bunu yapmanın birkaç nokta hariç bir zorluğu yok. Benim derdim yöntemin işe yarar bir yöntem olması. Yoksa Visual Studio projesi nasıl açılır, TCP-IP server/client nasıl yazılır, interpolasyon nedir v.s. bunları anlatan kitaplara ihtiyacım yok.
-
Bu arada unutmadan bu konuda 2ka'nın da yorumlarını duymak isterim. Sanırım TCP-IP konusunda aramızdaki en eski ve en sıkı coder kendisidir. Yanılıyor muyum Blackwind? :)
-
Skate, yardimci olmasi acisindan: Istemci ve sunucu arasindaki latency'i olcmek icin kendi algoritmani gelistirmektense, Windows TCP/IP stack'inden bu bilgileri isteyebilirsin.
Windows Vista ve Windows Server 2008 ile birlikte gelen yeni nesil TCP/IP stack'i ESTATS olarak da bilinen TCP baglanti tabanli gelismis istatistik destegi getiriyor. Gerekli API'lar iphlpapi'da:
http://msdn2.microsoft.com/en-us/library/bb485738.aspx
http://msdn2.microsoft.com/en-us/library/bb451840.aspx
http://msdn2.microsoft.com/en-us/library/bb451854.aspx
FINE_RTT diye arat. Bu istatistikler hem smoothed, hem cok granuler, hem de TCP rexmit gibi eventler hesaplarin icinde var. IPHLPAPI'i zaten oyle ya da boyle kullanmak zorunda olacaksin.
Windows 2000, Windows XP ve Windows Server 2003 de benzer ancak daha az granuler istatistikleri (baska API'lar ile) tutuyor. IPHLPAPI'dan aratarak kullanabilirsin.
Problemin cozumu icin IMHO, istemci'lerin karar vermesini kisitlamalisin. Sunucu zamani tick'lere bolmeli (1 tick == 100ms mesela), ve bu tick'ler icinde eline gecen bilgileri degerlendirip oyuncularin tick sonu itibariyle state'lerini butun istemcilere timestamp ile gondermeli. Istemciler "bu timestamp'te burada ise simdi yaklasik olarak surada olmali" gibi varsayimlarda bulunmamali, boylece cok granuler time sync gerekliligi de ortadan kalkar.
-
@penthy: öncelikle "güncel" bilgiler için çok teşekkür ederim. aradığım şey aynen de buydu. elbette ki oyunu Vista, 2008 only yapmak gibi bir niyetim yok. bu yüzden eski standartlardaki en uygun çözüm üzerinden gideceğim. ticklere bölme konusunu daha önce hiç düşünmemiştim. bence çok güzel ve zekice bir çözüm. kesinlikle kullanacağım. genellikle iyi bir connectionda ping time'ın <100 ms olduğu düşünülürse 1 tick = 100 ms her ne kadar örnek bir değer olsa da oldukça da ideal bir değer. özellikle "ateş etme" gibi durumlarda client ne zaman ateş tuşuna basarsa bassın eventi ilk tick bloğunda tetikletmek hem server hem diğer clientlardaki problemi büyük ölçüde çözer. tekrar sağol :)
-
ticklere bol diye ben diyecektim denmis. bildigim her fps engine'i aynisini yapiyor. ornegin source engine'de saniyede 33, 66 ya da 100 gibi degerler kullaniliyor. default olan 33 tickrate'in oyunculara yeterli gelmedigini de belirteyim.
seni bu konuda yeni gordum, q3 engine ve source engine konusunda connection optimization dokumanlari okumani tavsiye edeyim.
-
evet bu konularda yeniyim ve zaten kendimi geliştirmek için uğraşıyorum bu projeyle. quake'in bu konuda süper optimizasyonları olduğuna eminim ancak 8-16 falan değil de 1000+ kişinin aynı anda bağlantı yapmasına göre optimize edilmiş bir connection tutorial'ı daha uygun olmaz mı? quake ile ilgili dökümanları her halikarda okurum o başka.
-
o zaman open source star wars galaxies serveri var onun koduna bir bak.
ayrica quake degil quake 3. source engine daha basarili ve daha komplekstir, q3 yerine ona baksan daha cok bilgi sahibi olursun.
-
starwars galaxies bende orjinal olarak var ve servera 6 ay para ödeyip bir kez girmemiş olmak gibi de bir kerizlik rekorum var (detaylara hiç girmeyelim) :D
source engine, quake 3 ve starwars galaxies, hepsini de inceleyeceğim vakit buldukça. tavsiyeler için teşekkür ederim.
aslında bir süredir bu projeye ara verdim ama her zamanki gibi ara vermem olaya biraz daha dışardan bakmamı sağladı ve yeni fikirler verdi bana. uzun süredir istediğim UDP olayını da ekleyeceğim engine'e. özellikle movement gibi şeyleri UDP ile çözmeyi düşünüyorum. connection, inventory ve benzeri şeyler için TCP/IP daha secure olacaktır diye düşünüyorum. bakalım şu tutorialları okuduktan sonra fikirlerim ne derecede değişecek. şu ana kadar daha çok forum tartışmalarını okudum ki elbette ki herkes "bence..." diye başlıyordu postlara :)