Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #31023 > unrolled thread

how 2 code 2 player pong over a network

Back to article view | Back to pl.comp.programming

Contents

  how 2 code 2 player pong over a network fir <profesor.fir@gmail.com> - 2017-12-06 09:28 -0800
    Re: how 2 code 2 player pong over a network godek.maciek@gmail.com - 2017-12-06 11:49 -0800
      Re: how 2 code 2 player pong over a network fir <profesor.fir@gmail.com> - 2017-12-06 12:22 -0800
        Re: how 2 code 2 player pong over a network fir <profesor.fir@gmail.com> - 2017-12-06 13:43 -0800
        Re: how 2 code 2 player pong over a network godek.maciek@gmail.com - 2017-12-06 13:45 -0800
          Re: how 2 code 2 player pong over a network slawek <fake@fakeemail.com> - 2017-12-06 23:14 +0100

#31023 — how 2 code 2 player pong over a network

recently i run some test with my friend girl assistant koteq/cybergoth 

the test app was 2 dots in window one i move with mouse other my assistant move and the other-person coordinates was sent per frame (via tcp socket) 

i think i would like to make some kind of peer-to-peer pong game (two paddles and one ball) but the problem may be i guess the delay betwean sending and incoming packets 

(i know what i ask is basic in network programming vut i never was coding it so i think i must rethink those basics and overall it is/should be interesting for every c programmer that want to touch a network at all) 

i guess the typical pessymistic delay 
between a time of sending and time of receiving may be 100 (200?) ms .. 
if game is moderatelly dynamic i think the element like paddle or ball may move with speed of one screen width/height a second so the difference in a position then could be 
1/10 or 1/5 of size of screen 

right now i got no idea how to make simple code for that game that would minimalize the inpact of this deley 
to players 

how to code that? 

should i code it in some symmetric way 
make the delay be halved on two players or what? 

[toc] | [next] | [standalone]

#31027

Kiedyś z kolegą tak zrobiliśmy, że sobie napisaliśmy któregoś wieczora
ponga na dwa komputery, podłączyliśmy jeden komputer do telewizora
i graliśmy jak za "starych dobrych".

Opóźnienia w sterowaniu były zasadniczo niezauważalne. Zdaje się, że
rzecz była rozwiązana w taki sposób, że mieliśmy dwie aplikacje - klienta
i serwera, i dwa klienty były podłączone do jednego serwera. Architektonicznie
takie rozwiązanie jest prostsze, i można też łatwo postawić serwer na osobnym
kompie, zmniejszając nieuczciwość wynikłą z inercji.

Jednak przy słabo obciążonej sieci lokalnej nie było żadnej dostrzegalnej
inercji, dlatego sugerowałbym najpierw napisać aplikację, a później przejmować
się ewentualnymi problemami, niż najpierw się przejmować problemami, a później
tak "przedobrzyć" z projektem, że w końcu aplikacja nigdy nie powstanie.

Stąd też najpierw po prostu napisz, zmierz, i może się okaże, że będzie dobrze.
A jak opóźnienia będą zbyt dokuczliwe, możesz to przerobić na strategię turową.

[toc] | [prev] | [next] | [standalone]

#31028

W dniu środa, 6 grudnia 2017 20:49:34 UTC+1 użytkownik godek....@gmail.com napisał:
> Kiedyś z kolegą tak zrobiliśmy, że sobie napisaliśmy któregoś wieczora
> ponga na dwa komputery, podłączyliśmy jeden komputer do telewizora
> i graliśmy jak za "starych dobrych".
> 
> Opóźnienia w sterowaniu były zasadniczo niezauważalne. Zdaje się, że
> rzecz była rozwiązana w taki sposób, że mieliśmy dwie aplikacje - klienta
> i serwera, i dwa klienty były podłączone do jednego serwera. Architektonicznie
> takie rozwiązanie jest prostsze, i można też łatwo postawić serwer na osobnym
> kompie, zmniejszając nieuczciwość wynikłą z inercji.
> 
> Jednak przy słabo obciążonej sieci lokalnej nie było żadnej dostrzegalnej
> inercji, dlatego sugerowałbym najpierw napisać aplikację, a później przejmować
> się ewentualnymi problemami, niż najpierw się przejmować problemami, a później
> tak "przedobrzyć" z projektem, że w końcu aplikacja nigdy nie powstanie.
> 
> Stąd też najpierw po prostu napisz, zmierz, i może się okaże, że będzie dobrze.
> A jak opóźnienia będą zbyt dokuczliwe, możesz to przerobić na strategię turową.

wiem ze na lokalnej sieci opoznienia beda raczej minimalne i mozna je najprawdopodobniej olac
ale ja mowie o przypadku z laczeniem sie miedzy miastami (jak napisalem testowalismy to z moją koleżanką-asystentką i dzialalo ale
opznienie raczej są i trzeba pomyslec jak do tego podejsc

- najprawdopodobniej sporo ludzi juz ten problem rozwiazalo i sa jakies dobre metody ale jak mowi ja sie tym poki nie zajmowalme i teraz czeka mnie rozkminienie tego probblemu

ps prosty prototym samego polaczenia jest napisane mozesz sobie odpalic i nawet poeksperymentowac z kodem

minddetonator.htw.pl/ppt.zip

[toc] | [prev] | [next] | [standalone]

#31031

W dniu środa, 6 grudnia 2017 21:22:32 UTC+1 użytkownik fir napisał:
> W dniu środa, 6 grudnia 2017 20:49:34 UTC+1 użytkownik godek....@gmail.com napisał:
> > Kiedyś z kolegą tak zrobiliśmy, że sobie napisaliśmy któregoś wieczora
> > ponga na dwa komputery, podłączyliśmy jeden komputer do telewizora
> > i graliśmy jak za "starych dobrych".
> > 
> > Opóźnienia w sterowaniu były zasadniczo niezauważalne. Zdaje się, że
> > rzecz była rozwiązana w taki sposób, że mieliśmy dwie aplikacje - klienta
> > i serwera, i dwa klienty były podłączone do jednego serwera. Architektonicznie
> > takie rozwiązanie jest prostsze, i można też łatwo postawić serwer na osobnym
> > kompie, zmniejszając nieuczciwość wynikłą z inercji.
> > 
> > Jednak przy słabo obciążonej sieci lokalnej nie było żadnej dostrzegalnej
> > inercji, dlatego sugerowałbym najpierw napisać aplikację, a później przejmować
> > się ewentualnymi problemami, niż najpierw się przejmować problemami, a później
> > tak "przedobrzyć" z projektem, że w końcu aplikacja nigdy nie powstanie.
> > 
> > Stąd też najpierw po prostu napisz, zmierz, i może się okaże, że będzie dobrze.
> > A jak opóźnienia będą zbyt dokuczliwe, możesz to przerobić na strategię turową.
> 
> wiem ze na lokalnej sieci opoznienia beda raczej minimalne i mozna je najprawdopodobniej olac
> ale ja mowie o przypadku z laczeniem sie miedzy miastami (jak napisalem testowalismy to z moją koleżanką-asystentką i dzialalo ale
> opznienie raczej są i trzeba pomyslec jak do tego podejsc
> 
> - najprawdopodobniej sporo ludzi juz ten problem rozwiazalo i sa jakies dobre metody ale jak mowi ja sie tym poki nie zajmowalme i teraz czeka mnie rozkminienie tego probblemu
> 
> ps prosty prototym samego polaczenia jest napisane mozesz sobie odpalic i nawet poeksperymentowac z kodem
> 
> minddetonator.htw.pl/ppt.zip

troche poprawilem by nie wywalal tych chamskich mesage boxow na brak polaczenia - przy okazji opisuje problem - jesli juz mam polczenie dokonanae to po restarcie klienta laczy ponownie bez szemrania, natomiast po restarcie servera
nie chce polaczyc i trzeba wtedy zrestartowac klienta by polaczyl
- ktos moze wie czemu?

cyt-->

besides some may run some prototype on which i test connections 

minddetonator.htw.pl/ppt2.zip 

(for win32, no malware, some may seem that messy/adhoc code of my inside (over my power dll green fire which is not open)) 


i got yet one problem related to this winsock 

i managed to do it this way that it is not important if you runn client or server first, it will quietly connect if both are run, hovever 
problem is: both are connected i close client and then reopen it - it will get connected again with no problem, hovever if i close server and then reopen it it not get connected (i must then close client and reopen it then it get connected) 

does maybe someone get some idea why it can be, and what to change 
to client be automativcally connectet after restarting the server?

[toc] | [prev] | [next] | [standalone]

#31032

W dniu środa, 6 grudnia 2017 21:22:32 UTC+1 użytkownik fir napisał:
> W dniu środa, 6 grudnia 2017 20:49:34 UTC+1 użytkownik godek....@gmail.com napisał:
> > Kiedyś z kolegą tak zrobiliśmy, że sobie napisaliśmy któregoś wieczora
> > ponga na dwa komputery, podłączyliśmy jeden komputer do telewizora
> > i graliśmy jak za "starych dobrych".
> > 
> > Opóźnienia w sterowaniu były zasadniczo niezauważalne. Zdaje się, że
> > rzecz była rozwiązana w taki sposób, że mieliśmy dwie aplikacje - klienta
> > i serwera, i dwa klienty były podłączone do jednego serwera. Architektonicznie
> > takie rozwiązanie jest prostsze, i można też łatwo postawić serwer na osobnym
> > kompie, zmniejszając nieuczciwość wynikłą z inercji.
> > 
> > Jednak przy słabo obciążonej sieci lokalnej nie było żadnej dostrzegalnej
> > inercji, dlatego sugerowałbym najpierw napisać aplikację, a później przejmować
> > się ewentualnymi problemami, niż najpierw się przejmować problemami, a później
> > tak "przedobrzyć" z projektem, że w końcu aplikacja nigdy nie powstanie.
> > 
> > Stąd też najpierw po prostu napisz, zmierz, i może się okaże, że będzie dobrze.
> > A jak opóźnienia będą zbyt dokuczliwe, możesz to przerobić na strategię turową.
> 
> wiem ze na lokalnej sieci opoznienia beda raczej minimalne i mozna je najprawdopodobniej olac
> ale ja mowie o przypadku z laczeniem sie miedzy miastami (jak napisalem testowalismy to z moją koleżanką-asystentką i dzialalo ale
> opznienie raczej są i trzeba pomyslec jak do tego podejsc
> 
> - najprawdopodobniej sporo ludzi juz ten problem rozwiazalo i sa jakies dobre metody ale jak mowi ja sie tym poki nie zajmowalme i teraz czeka mnie rozkminienie tego probblemu
> 
> ps prosty prototym samego polaczenia jest napisane mozesz sobie odpalic i nawet poeksperymentowac z kodem
> 
> minddetonator.htw.pl/ppt.zip

Możesz zamiast TCP spróbować zrobić po UDP. Wprawdzie wtedy trzeba
będzie wprowadzić jakąś strategię synchronizacji (żeby pakiety które przychodzą
z bardzo dużym opóźnieniem nie wpływały na rozgrywkę), ale może będzie
szybciej.

Co do przekonania, że ktoś ten problem rozwiązał, to raczej bym na to
nie liczył. Opóźnienie to opóźnienie i nie da się go usunąć (ewentualnie
można się zastanowić nad szybszym internetem, albo nad postawieniem
serwera w mieście pomiędzy waszymi miastami). Można się bawić w jakieś
modele, predykcje itp. ale to tylko częściowo skompensuje problem.

Oczywiście w przypadku tej partykularnej gry, jaką jest pong, można sobie
poradzić z tym problemem bardzo łatwo - ważna jest tylko pozycja i prędkość
piłki w momencie odbicia od paletki - po upłynięciu owego czasu można
deterministycznie określić, w której klatce piłka znajdzie się u przeciwnika.
Jeżeli gracze ufają sobie nawzajem, to wystarczy w momencie obronienia
albo zdobycia punktu wysłać informację o tym, czy się to udało.
Wówczas serwer może zaktualizować położenie piłki do drugiego gracza
dopiero wówczas, gdy dostanie odpowiedź. 

Taka strategia będzie działała o tyle, o ile czas transmisji pomiędzy klientami
będzie dużo mniejszy niż czas, w jakim piłka przeleci z jednego końca
do drugiego. W przeciwnym razie warto się zastanowić z krótkotrwałym
wstrzymaniem gry do czasu, aż drugi gracz nie dostanie informacji od
pierwszego.

Można też zrobić synchronizację z klientami - serwer zaktualizuje klatkę
rozgrywki dopiero wtedy, kiedy dostanie odpowiednią informację od obu
klientów (na przykład z numerem klatki), zaś klient wyśle informację dopiero
po przesłaniu potwierdzenia od serwera.

[toc] | [prev] | [next] | [standalone]

#31033

On Wed, 6 Dec 2017 13:45:21 -0800 (PST), godek.maciek@gmail.com wrote:
> nie liczył. Opóźnienie to opóźnienie i nie da si=
> ę go usunąć (ewentualnie

Da się.

Ale padam z nóg - polska prywatna służba zdrowia - i nie mam siły 
pisać. 

Tzn. opóźnienia nie znikną, ale gracze nie będą ich odczuwali. Myk w 
serwerze "in middle". I w rozpisaniu co ma być lokalnie a co przez 
ten serwer. A ten serwer może być "in middle" wirtualnie, bo w realu 
to jeden z komp. graczy.

[toc] | [prev] | [standalone]

Back to top | Article view | pl.comp.programming

csiph-web