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ą.

do góry

W dniu środa, 6 grudnia 2017 20:49:34 UTC+1 użytkownik g...@g...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

do góry

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 g...@g...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?

do góry

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 g...@g...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.

do góry

On Wed, 6 Dec 2017 13:45:21 -0800 (PST), g...@g...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.

do góry